Ryan, Could you please explain what you mean by saying that if you revoke a single certificate that it is akin to revoking all variations of that certificate? I don't think I agree. There are situations where the certificate is revoked for reasons (e.g. issues of certificate format/content) that have nothing to do with distrusting the underlying key pair. Thanks, Ben
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Sunday, September 17, 2017 7:57 PM To: userwithuid <userwith...@gmail.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Old roots to new roots best practice? Hi there, I agree, Gerv's remarks are a bit confusing with respect to the concern. You are correct that the process of establishing a new root generally involves the creation of a self-signed certificate, and then any cross-signing that happens conceptually creates an 'intermediate' - so you have a key shared by a root and an intermediate. This is not forbidden; indeed, you can see in my recent suggestions to Symantec/DigiCert, it can and often is the best way for both compatibility and interoperability. Method #2 that you mentioned, while valid, can bring much greater compatibility challenges, and thus requires far more careful planning and execution (and collaboration both with servers and in configuring AIA endpoints) However, there is a criticism to be landed here - and that's using the same name/keypair for multiple intermediates and revoking one/some of them. This creates all sorts of compatibility problems in the ecosystem, and is thus unwise practice. As an example of a compatibility problem it creates, note that RFC5280 states how to verify a constructed path, but doesn't necessarily specify how to discover that path (RFC 4158 covers many of the strategies that might be used, but note, it's Informational). Some clients (such as macOS and iOS, up to I believe 10.11) construct a path first, and then perform revocation checking. If any certificate in the path is rejected, the leaf is rejected - regardless of other paths existing. This is similar to the behaviour of a number of OpenSSL and other (embedded) PKI stacks. Similarly, applications which process their own revocation checks may only be able to apply it to the constructed path (Chrome's CRLSets are somewhat like this, particularly on macOS platforms). Add in caching of intermediates (like mentioned in 4158), and it quickly becomes complicated. For this reason - if you have a same name/key pair, it should generally be expected that revoking a single one of those is akin to revoking all variations of that certificate (including the root!) Note that all of this presumes the use of two organizations here, and cross-signing. If there is a single organization present, or if the 'intermediate' *isn't* intended to be a root, it's generally seen as an unnecessary risk (for the reasons above). Does that help explain? On Sun, Sep 17, 2017 at 11:37 AM, userwithuid via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Forgot the links: > > [1] https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/hNOJJrN6WfE > [2] https://groups.google.com/forum/#!msg/mozilla.dev. > security.policy/RJHPWUd93xE/RqnC3brRBQAJ > [3] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7 > d1c45c2f47f93be372a17b96b50757d5a2 > [4] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aef > a40a53406a3aec26039efa6b2e0e7244c1 > [5] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf > 597f12d2cad2f63d1a4aa37493800ffb80 > [6] https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580c > cee590cc9b5ad677f134fc137a6d57d2e7 > [7] https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb > 24a9db406fee12d2cc90180517616e8a18 > [8] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a > 4fcce203d4c2eddcaa4013763b5a23d81f > [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 > _______________________________________________ > 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
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
