Re: Old roots to new roots best practice?
On 20/09/17 03:49, userwithuid wrote: >> I agree, Gerv's remarks are a bit confusing with respect to the concern. Ryan is polite. :-) > Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part > then and should probably be acknowledged as such, @Gerv. Yes, I acknowledge that this point was confusing; I should have said something more like this: >> 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. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
On Tue, Sep 19, 2017 at 10:49 PM, userwithuid via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Either way, in the specific case, StartCom, this criticism seems to be > inapplicable, as the revoked one was never deployed in the first place. I don't think that's a fair conclusion. As noted in the StartCom discussions, the mere existence of such certificate is enough to make it possible for clients (hostile or misinformed) to serve this chain and trigger the behaviour, and thus, as Gerv noted: "While this is probably not a policy violation, it's not good practice." - which is absolutely true. This is not the first time StartCom has done something 'like' this - that is, not a policy violation, but not good practice. During the SHA-1/SHA-2 migration, the (old management) of StartCom signed an existing SHA-1 intermediate with the same name, key, and other attributes with SHA-2. That these were otherwise equivalent meant clients were non-deterministic in their selection of SHA-1 and SHA-2, and may block such certificates, warn on such certificates, or fail to work. The "good practice" in this case is to issue new certificates off a new (SHA-2) intermediate with a new name and new key - not trying to continue to use 'both' intermediates. Many other CAs did this successfully. Things like this are relative in the sense of execution on best practice / avoidance of issues, both those explicitly prohibited and those being 'bad ideas'. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
On Monday, September 18, 2017 at 1:58:03 AM UTC, Ryan Sleevi wrote: > 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) Great, from that I gather method 1 is indeed not discouraged and maybe even preferred over 2, which is certainly good to hear, thanks. :-) Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part then and should probably be acknowledged as such, @Gerv. > 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!) Hmmm, I think I see the point you are making here, in general. Like, if both a revoked a non-revoked version of an intermediate are sent by a server, it might potentially break a client that does "naive" revocation checking like you described; path first, then check (e.g. openssl?). Worse, a client that has an intermediate cache _and_ does "naive" revocation checking might break long after the revoked one has been last sent (maybe the revoked one even came from a different server altogether). That would suck and the only server-side fix would be to switch to a cert signed by a new intermediate. Do you know a real-world client example for the latter though? Old Apple as you mentioned? Or was this just theoretical? Either way, in the specific case, StartCom, this criticism seems to be inapplicable, as the revoked one was never deployed in the first place. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
Hi Ben, While I wasn't trying to suggest the reasoning was the same, I was trying to highlight that for many implementations, the revocation of a single certificate (where there may exist multiple cross-signs) induces enough non-determinism to effectively constitute revoking all of them. That is, clients that encounter the revoked cert - which cannot reliably be predicted - may treat the entire chain as revoked even if alternative, unrevoked paths exist. This should mean that CAs should be aware of, and cautious of, such revocations. The best mitigation to this is avoiding a large number of cross-signs and rotating keys or names often. On Tue, Sep 19, 2017 at 12:28 AM Ben Wilson wrote: > 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 > Cc: mozilla-dev-security-policy > > 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 > >
RE: Old roots to new roots best practice?
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 Cc: mozilla-dev-security-policy 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
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
Re: Old roots to new roots best practice?
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=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 [4] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1 [5] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80 [6] https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580ccee590cc9b5ad677f134fc137a6d57d2e7 [7] https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 [8] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f [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
