> From what I've gathered, they want to deprecate storing private keys > without associated certificates, which would be really bad. There is an > audited infrastructure for key generation and storage, including > smartcard support, and adding a requirement that keys may only be added > together with a certificate would lead to a situation where I'd have to > generate a private key outside the secure infrastructure and keep it > outside until my certificate is ready, at which point I can finally > transfer it to the audited code for safekeeping.
Let's look at this use-case the other way around. What is missing is a simple enrollment application which does noting but - (optionally) obtain policy parameters from a CA[1] - generate a private key - generating a cert request - submit that cert request to the CA[2] - package a received cert along with the private key into a PKCS12 container Steps [1] and [2] would need a standardized protocol (not HTML forms). Why that way? Reading an argument that the browser is "secure infrastructure" and "audited code" makes me shudder (sorry). I'd rather prefer a specialized app for that purpose, which is small, self-contained and _can_ be audited. Not another key-generation-bug or insertion-of-malicious-javascript disaster waiting around the corner (for the latter reason, nobody should ever do key generation via a web page which requires Javascript, anyway!) So while not knowing the whole discussion at all, I can very easily see a security argument for deprecating browser-based key generation. The downside is that it does need a new application which (to my knowledge) isn't there already. But the building blocks are there (I once wrote a self-signed-certificate generator, took me at most 20 lines of Java plus another 100 or so lines for the GUI). Olaf
