Old roots to new roots best practice?

[userwithuid]

Quoting Gerv from the latest StartCom thread [1]:
"* The key for their new root certificate was also used in a couple of
intermediates (one revoked as it was done incorrectly - again, lack of
testing!). While this is probably not a policy violation, it's not good
practice."

Everyone including StartCom itself acknowledges that the one "done incorrectly", the revoked one, shouldn't have happened. This thread is not about that.

I want to understand the meaning and reasoning for the rest of the bullet point as it makes no sense to me. I asked this before in the StartCom/Certinomis thread [2], where Kathleen said the same as Gerv, but it got no response, so I'm trying again.

I can think of 3 ways to support old and new roots in parallel:

1.
In the other thread I mentioned that major CAs like Amazon [3], Comodo [4] and GlobalSign [5] also seem to use the key for a root cert in an "intermediate". This is used to create the following trust paths:

modern client: new root (in store) --- issuing intermediate A0 --- leaf
legacy client: old root (in store) --- new root! (same key/name, but different cert; "intermediate") --- issuing intermediate A0 --- leaf

2.
The alternative solution seems to be to "reuse" the key of the issuing intermediate instead, as done by e.g. Entrust [6] or Let's Encrypt/IdenTrust [7]. Paths:

modern: new root --- issuing intermediate A1 (eg signed by ISRG Root) --- leaf
legacy: old root --- issuing intermediate A2 (same key/name as A1, different cert, eg signed by IdenTrust) --- leaf

3.
Yet another solution would be to have no key/name sharing @ CA level, and instead sign a leaf with multiple keys during the issuing process to create multiple unrelated paths. That would result in having more than one leaf cert though, so it is not a viable solution in general.

modern: new root --- issuing intermediate N --- leaf L1
legacy: old root --- issuing intermediate O --- leaf L2 (different cert, but possibly same key)



Looks like StartCom chose 1. [8] instead of 2. This was explicitly permitted by Mozilla in [9]. So why are they now criticized for it? Am I missing something, did I get it wrong above? In general: Is 1. really "not good practice" to switch roots, do Mozilla or others prefer 2.?*



* I sure hope not. Option 1 implicitly makes server admins provide either only the new path, or both old and new paths, never just the old one. Option 2 allows "only old" as well. Since trust stores keep old roots for compat, "only old" works when admins test it, so they can use that and forget "new". Hence you can't easily remove legacy roots from the trust store because compat; chicken/egg. (unless you get the right=new intermediates into the trust store/interm cache/validation path somehow; that's ugly but sometimes possible e.g. with NSS you can have neutral trust entries and iiuc AIA chasing could also do this?).

[userwithuid]

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

[Ryan Sleevi]

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?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

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 <ben.w...@digicert.com> 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

[userwithuid]

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.

[Ryan Sleevi]

On Tue, Sep 19, 2017 at 10:49 PM, userwithuid via dev-security-policy <
dev-secur...@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'.

[Gervase Markham]

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