On 04/05/2018 20:58, Wayne Thayer wrote:
The optimist in me thinks we might be getting close to resolving this issue
(the last one remaining for the 2.6 policy update). Here is another
proposal that attempts to account for most of the input we've received:
Add the following to section 5.2 (Forbidden and Required Practices):
CAs MUST NOT generate the key pairs for end-entity certificates that have
an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.
PKCS#12 files must employ an encryption algorithm that is sufficiently
strong to protect the key pair for its useful life based on current
guidelines published by a recognized standards body. PKCS#12 files MUST be
encrypted and signed; or, MUST have a password that exhibits at least 112
bits of entropy, and the password MUST be transferred using a different
channel than the PKCS#12 file.
This isn't perfect. I would appreciate your comments if you have
significant concerns with this proposed policy.
- Wayne
Given the fiasco of at least one major PKCS#12 implementation only
allowing embarrassingly weak encryption, while simultaneously insisting
on not accepting other private key import formats:
Wouldn't it be prudent to allow transport of PKCS#12 files (with weak
compatible encryption) inside a much stronger encrypted container such
as a strongly encrypted S/MIME message or a strongly encrypted TLS
transmission (HTTPS, LDAPS etc.).
The idea being that the weak PKCS#12 encryption is not treated as the
private key protection, but merely as a file format artifact.
I have previously given a (hypothetical) example of a procedure that
relies on tamper-evident physical envelopes rather than cryptography to
protect the private key delivery. That would be another example of
using a different mechanism than PKCS#12 encryption for turning an
insecure channel into a secure private key delivery mechanism.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
