Basically I like the new wording:
> PKCS#12 files [...] SHALL have a password containing at least 112 bits
> of output from a CSPRNG, [...]
But I think there is a practical problem here: Directly using the output of any
random number generator ("C" or not) to generate a password will lead to
passwords which contain most probably characters that are either not printable
or at least not type-able on a 'normal' western style keyboard. Therefore I
think we need to reword the password strength section a little bit, maybe like
the following:
> PKCS#12 files [...] SHALL have a 14 character long password consisting
> of characters, digits and special characters based on output from a
> CSPRNG, [...]
When I originally proposed my wording, I had the serial numbers in my mind (for
which directly using the output of a CSPRNG works), but didn't think on the
encoding problem.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens
www.siemens.com/ingenuityforlife
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike,
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany;
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
WEEE-Reg.-No. DE 23691322
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> Gesendet: Mittwoch, 2. Mai 2018 07:45
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> to policy
>
> On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> > Ryan - thanks for raising these issues again. I still have concerns
> > about getting this specific in the policy, but since we're now
> > headed down that road...
> >
> > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > A few problems I see with the proposed text:
> > >
> > > - 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. This is basically the same CSPRNG
> > > conversation but it's worth looking at https://www.keylength.com/
> >
> >
> > The latest proposal replaces "sufficient" with "at least 64 bits of
> > output from a CSPRNG". We could go back to "sufficient strength for
> > the keys it protects", but that also leaves quite a bit of room for
> > misinterpretation.
> >
> > Are there objections to "at least 112 bits of output from a CSPRNG"
> > as Tim proposed?
>
> I'd recommend making a requirement that it be "protected" by at least
> as many bits of strength as the key it protects. Not doing so could cause
> compliance issues: things like PCI [1] and the NIST [2] recommendations
> require this type of protection.
> However, like Wayne said, this still leaves room for interpretation,
> if mentioning bits is necessary, can we just bump it up to 256 rather than
> 112?
>
> I went back to the word "protect" to rule out the use of 3DES because
> bumping up the password past 112 bits doesn't really do much good if the
> underlying algorithm maxes out its protective strength at 112.
> I realize this will decrease the utility of the p12/pfx files since
> none of the adequately protected files would be openable on any
> version of Windows. However, the team at Microsoft is well aware of this and
> they can prioritize their own backlog (they just don't appear to have been
> given the right incentive to do so as of yet). Perhaps we can add a
> date-gate..
>
> How about:
>
> PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password
> containing at least 112 bits of output from a CSPRNG, and the password
> SHALL be transferred using a different channel than the PKCS#12 file.
> Beginning January 1, 2020 PKCS#12 files must be protected by at least 256
> bits of output from a CSPRNG.
>
> This would give people like Microsoft some extra time to update their
> implementations to support AES.
>
>
> -Carl
>
> [1] PCI - DSS v3.2, Section 3.5
> [2] 800-57 Part 1, Section 6.2.1.3 -
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt
> 1r4.pdf _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
