On Friday, December 15, 2017 at 1:34:30 PM UTC-8, Matthew Hardeman wrote: > On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote: > > > Unfortunately, the PKCS#12 format, as supported by UAs and Operating > > Systems is not a great candidate for the role of carrying keys anymore. You > > can see my blog post on this topic here: http://unmitigatedrisk.com/?p=543 > > > > The core issue is the use of old cryptographic primitives that barely live > > up to the equivalent cryptographic strengths of keys in use today. The > > offline nature of the protection involved also enables an attacker to grind > > any value used as the password as well. > > > > Any plan to allow a CA to generate keys on behalf of users, which I am not > > against as long as there are strict and auditable practices associated with > > it, needs to take into consideration the protection of those keys in > > transit and storage. > > > > I also believe any language that would be adopted here would clearly > > addresses cases where a organization that happens to operate a CA but is > > also a relying party. For example Amazon, Google and Apple both operate > > WebTrust audited CAs but they also operate cloud services where they are > > the subscriber of that CA. Any language used would need to make it clear > > the relative scopes and responsibilities in such a case. > > I had long wondered about the PKCS#12 issue. To the extent that any file > format in use today is convenient for delivering a package of certificates > including a formal validation chain and associated private key(s), PKCS#12 is > so convenient and fairly ubiquitous. > > It is a pain that the cryptographic and integrity portions of the format are > showing their age -- at least, as you point out, in the manner in which > they're actually implemented in major software today.
So I have read this thread in its entirety now and I think it makes sense for it to reset to first principles, specifically: What are the technological and business goals trying to be achieved, What are the requirements derived from those goals, What are the negative consequences of those goals. My feeling is there is simply an abstract desire to allow for the CA, on behalf of the subject, to generate the keys but we have not sufficiently articulated a business case for this. In my experience building and working with embedded systems I, like Peter, have found it is possible to build a sufficient pseudo random number generator on these devices, In practice however deployed devices commonly either do not do so or seed them poorly. This use case is one where transport would likely not need to be PKCS#12 given the custom nature of these solutions. At the same time, these devices are often provisioned in a production line and the key generation could just as easily (and probably more appropriately) happen there. In my experience as a CA the desire to do server side key generation almost always stems from a desire to reduce the friction for customers to acquire certificates for use in regular old web servers. Seldom does this case come up with network appliances as they do not support the PKCS#12 format normally. While the reduction of friction is a laudable goal, it seems the better way to do that would be to adopt a protocol like ACME for certificate lifecycle managment. As I said in a earlier response I am not against the idea of server side key generation as long as: There is a legitimate business need, This can be done in a way that the CA does not have access to the key, The process in which that this is done is fully transparent and auditable, The transfer of the key is done in a way that is sufficiently secure, The storage of the key is done in a way that is sufficiently secure, We are extremely clear in how this can be done securely. Basically I believe due to the varying degrees of technical background and skill in the CA operator ecosystem allowing this without being extremely is probably a case of the cure is worse than the ailment. With that background I wonder, is this even worth exploring? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
