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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
