As I was reading this very interesting thread, I kept asking myself
"what are we trying to protect". Are we trying to protect a "Private
Key" or a "PKCS#12" file? I suppose the consensus of the community,
based mainly on compatibility issues, is that we can't avoid the
solution of a PKCS#12 file, so we need to figure out how to send this
file with reasonable security to the Subscriber.
We have two areas of concern:
1. How to prevent an attacker from getting the PKCS#12 file
2. If an attacker obtains the PKCS#12 file, make sure the encryption is
reasonable and endurable to practically sustain a decryption attempt
that would practically take longer to crack than the lifetime of the
Certificate
For area 1, the file must be distributed via secure channel. Some
recommendations:
1. Web page (protected by https) via authentication of the Subscriber
2. S/MIME encrypted email by using an existing Subscriber valid
Certificate
3. Some might also use pgp for S/MIME
4. Registered post, if delivered in a simple USB
5. Registered, or not registered post, if delivered in a FIPS 140-2
Level 3 USB drive
6. ...
7. ...
Do we need to expand on this list? What if there are other
equally-secure methods that we haven't listed? This definitely doesn't
look like a policy text to me. It describes very specific
practices/procedures that should be the CA's job to discover and
Auditor's to verify, but I also understand that in practice, some CAs
haven't demonstrated good judgment on these topics and auditors didn't
help either.
For area 2, obviously, if an attacker obtains the PKCS#12 file and has
infinite time, the key will be decrypted. I believe the discussion
resulted in two dominating factors:
* The encryption algorithms in the PKCS#12 file
* The password quality
For the encryption algorithms, I recommend that we defer to other
organization's guidelines, such as SOGIS, NIST or ETSI, that have
extensively studied the "strength" of encryption algorithms. I can't
tell if this community or Mozilla is confident enough to choose a
specific set of "approved" encryption algorithms.
For the password quality, we should follow the definition of a "Random
Value" as described in the Baseline Requirements
*"Random Value*: A value specified by a CA to the Applicant that
exhibits at least 112 bits of entropy."
And yes, I would also recommend the usage of a CSPRNG. With that said,
even if this process (performed by the CA) produces complex passwords
that contain special characters and (in an unlikely event) might take 20
minutes to type, it is still going to be used "just once" and the
Subscriber can then do whatever he/she wants with it. The Subscriber can
change the passphrase to "1234" for all we care. As far as the CA is
concerned, the main job is done. The file has been encrypted with a
reasonably secure algorithm and protected with a reasonably secure
passphrase.
Of course the passphrase will be delivered separately!
Finally, I would like to ask if the community thinks that it's
reasonable to put all of our protection efforts on area 2. If we raise
the bar on area 2 (the proper protection of the PKCS#12 file), we don't
need to worry "too much" about area 1. We could even send a file via
plain e-mail because it won't matter if the attacker obtains the file.
It is already encrypted securely. I would still recommend both but I
also understand the convenience of the Subscribers and the delivery
methods for some of these files in types of devices that I am not aware
of (IoT, some smart phones, etc).
Dimitris.
On 4/5/2018 1:01 πμ, Buschart, Rufus via dev-security-policy wrote:
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
