I think that what is needed most of all in Web PKI space right now is to arrive at a statement of what applications and servers should expect so they can be designed to work with the PKI that exists rather than the infinite set of possibilities that are consistent with PKIX but not deployed.
At the moment we have a system that depends a great deal on 'lore' which is only understood by a handful of people and is mostly arrived at by trial and error: * Server Lore: The PKI/SSL features that the servers actually support * Client Lore: The PKI/SSL features that the clients actually implement * CA Lore: How certs rollover, PKI topology A lot of the lore results from different people trying to 'do the right thing' in different ways. Some of it results from one side trying to do the right thing but not being supported by another. Quite a bit of the lore results from the common misconception that the primary purpose of the Web PKI is to encrypt stuff rather than to assure people that they are talking to the right party and that that party is accountable in some fashion. Standards that rely on Lore are not really standards in my view. On the code signing thing, I agree that running the right code is probably the most important security concern right now. There is nothing Chrome can do to improve security if the Chrome executable has been compromised. Anti-Virus vendors such as Comodo have been moving away from traditional AV approaches of looking for badness to a default-deny approach. We only run the code we know is trustworthy rather than only nerfing the code known to be bad. Code signing could be an important part of that approach but it is actually pretty difficult right now as every code signing scheme is different and while most are open, some are closed (e.g. iOS). Most of the schemes out there depend on some form of X.509 PKI and some form of digital signature. Some only authenticate the installation package, others have signatures on the running .exe and .obj files, some have manifests. It would be nice if there was some form of registry that actually catalogued all this variation and that might lead to some future project to come up with a single scheme that could be applied to all code. There is really no good reason for the Java code signing scheme to be completely different from the .Net scheme and require a completely different validation strategy. _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
