I get that, but any CA that can securely erase and forget the user’s contribution to the password and certainly do the same thing to the entire password, so I’m not seeing the value of the extra complexity and interaction.
-Tim From: Ryan Hurst [mailto:ryan.hu...@gmail.com] Sent: Tuesday, May 1, 2018 3:49 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy > I'm not sure I agree with this as a recommendation; if you want both parties > to provide inputs to the generation of the password, use a well-established > and vetted key agreement scheme instead of ad hoc mixing. > Of course, at that point you have a shared transport key, and you should > probably > just use a stronger, more modern authenticated key block than PKCS#12, > but that's a conversation for another day. I say this because it is desirable that the CA plausibly not be able to decrypt the key even if it holds the encrypted key blob. On Tue, May 1, 2018 at 12:40 PM, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: > - What is sufficient? I would go with a definition tied to the effective > strength of > the keys it protects; in other words, you should protect a 2048bit RSA key > with > something that offers similar properties or that 2048bit key does not live > up to > its 2048 bit properties. Yup, this is the typical position of standards bodies for crypto stuff. I noticed that the 32 got fixed to 64, but it really should be 112. > - The language should recommend that the "password" be a value that is a mix > of a user-supplied value and the CSPRNG output and that the CA can not store > the user-supplied value for longer than necessary to create the PKCS#12. I'm not sure I agree with this as a recommendation; if you want both parties to provide inputs to the generation of the password, use a well-established and vetted key agreement scheme instead of ad hoc mixing. Of course, at that point you have a shared transport key, and you should probably just use a stronger, more modern authenticated key block than PKCS#12, but that's a conversation for another day. > - The language requires the use of a password when using PKCS#12s but > PKCS#12 supports both symmetric and asymmetric key based protection also. > While these are not broadly supported the text should not probit the use of > stronger mechanisms than 3DES and a password. Strongly agree. -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
