Re: How to use Cross Certificates to support Root rollover

[Ryan Sleevi via dev-security-policy]

Top-posting, to try and reset the legibility on things.

Regarding the definition for "cross-certified intermediate":

Both scenarios you describe are cross-certificates. This is perhaps clearer
with RFC 4158's treatment of it (for which the BR language was borrowed
from), and may not be as obvious from RFC 5280's Section 3.2. I had hoped
that the context and clarity for the situation I was describing made it
clear that the certificate path would transit both New Root's Subject and
Public Key and Old Root's Subject and Public Key.

The choice of the language for "cross-signed intermediate" was to highlight
that, from the perspective of a relying party which only trusts Old Root,
the existence of New Root is completely opaque that it's a
cross-certificate. That is, to the client, it's just another intermediate
in the certification path. For clients which trust New Root, it's an
intermediate that happens to also be a trust anchor, and so they can
potentially substitute New Root (the self-issued version) in the
certificate path.

That is, the specific path under discussion was
End Entity -> Issuing Intermediate -> New Root signed-by Old Root -> Old
Root

Clients which have New Root as a trust anchor can build the path
End Entity -> Issuing Intermediate -> New Root

The choice of this construction, over the one you provided, is that it
allows for a certificate path that is simultaneously valid if either New
Root or Old Root are trust anchors. The alternative, in which multiple
versions of the intermediate also exist, is possible (and I believe may
align with what Let's Encrypt did?), but can represent greater challenges.

Regarding clients with mandates to use SHA-256 chains: I can understand
customers want lots of things, and no one wants to tell them they're wrong
;) However, anyone who is checking the signature algorithm on trust anchors
is wrong :) In your R1/R3 case, the entire certification path is signed
with SHA-256. The trust anchor is just delivered via a self-issued cert
that isn't.

However, assuming common sense and customers are things that are, somewhat
unfortunately, at odds with each other, then yes, making use of the
notBefore and notAfter to affect the scoring of the path is a valid
approach. The important thing to recognize is that clients can't and
shouldn't dictate the particular path, because the trust graph is, well, a
graph (see RFC 4158). Constraints that a Subscriber imposes are irrelevant,
because Relying Parties are free to construct adequate paths. That said,
other CAs - and perhaps the canonical example of this was Sectigo - have
long integrated such activities into their root and intermediate generation
scripts. DigiCert did as well, with their integration of the legacy
Symantec infrastructure.

The majority of clients fit within a few buckets for path building:
- Prefer the path they're supplied over having to do more work
- When comparing two certificates, prefer the 'more recent' (> notBefore)
certificate or the 'longer' (> notAfter) one
- Not all clients sort. For example, Mozilla's legacy and libpkix
implementation did. Mozilla's (new) mozpkix does not apply any sorting,
other than attempting trust anchors before intermediates and preferring
self-signed paths over others.

The rest I'm not sure how to respond to. "Customers want X, but customers
don't want to learn about X" seems to be the take away. I don't mean that
to sound dismissive, but it's one where it sort of externalizes the costs,
where every time a customer wants X, all client applications need to adopt
to the new root to support X, while also still supporting the CA's other
products A, B, C. When A, B, and C can all still work with X, my hope was
to try and find a path to transition, so that we can reduce the number of
certificates included to being those that fit a reasonable subset and have
clear timelines. For context, Cloudflare's tool cfssl (
https://github.com/cloudflare/cfssl ,
https://blog.cloudflare.com/introducing-cfssl/ ) , combined with the
cfssl_trust ( https://github.com/cloudflare/cfssl_trust ) package, is
designed to help you build appropriate paths for a wide variety of clients,
and is meant to be fairly turnkey, so CAs can easily help their customers
determine 'ideal' configurations based on their real-world usages.

As for Google's PKI, I can't really answer any questions there, because I
have zero involvement in it. Perhaps Ryan Hurst can share his plans there -
he's certainly deeply knowledgable in this space for the design. That said,
I think it's reasonable to question if transitioning to a 4K root /is/
desirable from a broad community, but I suspect I'm just poking a
crypto-debate there where everyone will have opinions. This goes back to
the clear user benefits question.

On Mon, Aug 5, 2019 at 12:11 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  in each para of my response>
>
>
>
> Ryan,
>
>
>
> Note: I changed the name of the thread 

RE: How to use Cross Certificates to support Root rollover

[Doug Beattie via dev-security-policy]

 

Ryan,

 

Note: I changed the name of the thread because this is a great discussion about 
root roll-over and isn’t really related to the Entrust Root inclusion request.

 

In theory Cross certificates are simple, but I’ve found that in practice they 
are difficult to manage and use.

 

First, it would be a good idea to agree on the definition of a Cross 
Certificate.  The BRs define it as: A certificate that is used to establish a 
trust relationship between two Root CAs.

 

Does that align with your definition?  I ask because you used the term Cross 
signed intermediate, so it seems you may be using a difference definition than 
the one in the BRs.  Are you proposing this type of approach where the Issuer 
of the SSL certificate could be one of 2 different CAs (have same keys and 
Subject Name but are signed by different roots)?

SSL – Intermediate CA 1 – Legacy Root

SSL – Cross Intermediate CA 2 – New Root

 

I thought a cross certificate chain needed to look like this

SSL – Intermediate CA 1 (signed by new root) – Cross cert  – Legacy Root

 

My discussion is focused on the BR definition, so there could be advantages to 
creating multiple intermediate signed CAs which I haven’t considered yet.  What 
definition/approach were you assuming?

 

See responses in-line below

 

From: Doug Beattie  
Sent: Monday, August 5, 2019 7:29 AM
To: Doug Beattie 
Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion Request

 

 

On Mon, Aug 5, 2019 at 7:12 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Friday, August 2, 2019 1:49 PM
To: Doug Beattie mailto:doug.beat...@globalsign.com> >
Cc: r...@sleevi.com  ; Bruce mailto:bruce.mor...@entrust.com> >; mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Entrust Root Certification Authority - G4 Inclusion Request

On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

Ryan,

GlobalSign has been thinking along these lines, but it's not clear how
browsers build their path when a cross certificate is presented to them in
the TLS handshake.

Excellent! Happy to help in any way to make that possible and easier :)

 

 

DB: I knew you would  

 

Can you explain how chrome (windows and Android)  builds a path when a cross
certificate is delivered?  What about the case when the OS (Microsoft
specifically) has cached the cross certificate, is it different?

 It's unclear the objective of the question. That is, are you trying to figure 
out what happens with both paths are valid, or how it handles edge cases, etc?

 

 

DB: We have some customers that mandate a complete SHA-256 chain, including the 
root.  We had been using our older SHA-1 Root (R1) and recently moved to our 
newer SHA-265 root, (R3).  We now can deliver certificates issued with SHA-256 
at all levels, great!  In order to support some legacy applications that didn’t 
have R3 embedded, we created a cross certificate R1-R3.  You can get it here 

 .

 

DB: The customer came back and said, hey, it still chains to R1, what’s up?  
Oh, it’s because the client has the cross certificate cached, don’t worry about 
that, some users will see the chain up to R1 and others to R3.  Hmm, not good 
they say.

 

DB: Anyway, no way around that now (unless you have some other tricks)  I went 
and looked at the links to the MS article and noticed that when the quality of 
the certificates in the chain is the same, then it prefers certificates that 
have a later NotBefore date (I presume this means issued more recently).  Our 
R1-R3 cross was issued in 2018 and the Root R3 was issued in 2009.  When the 
issuing CA is validated it has 2 paths it can follow, 

1) Root R3, issued in 2009, or 

2) the Cross certificate, issued in 2018.  

Even though the path is longer, it uses the cross certificate which chains to 
R1 (SHA-1) because of the not-before date.

 

DB: Does this mean we should have created the cross certificate with the same 
date as the  R3 root (2009)?  

How else can we have clients prefer the shorter higher security SHA-256 chain?  

Perhaps this is means that we need to change the definition of a Cross 
certificate from being a Root to Root chain.

 

DB: Even if this specific web site didn’t configure the extra certificate (the 
R1-R3 cross certificate) into their configuration, the end users may have 
picked it up somewhere else and have it cached so their specific chain goes: 
SSL, Intermediate CA, R1-R3 Cross certificate, Root R1

 

DB: They are stuck with inconsistent user experience and levels of “security” 
for their website. 

 

 

 

 

At present (and this is changing), Chrome uses the CryptoAPI implementation, 
which is the same as IE, Edge, and other Windows applications.

You can read 

Re: How to use Cross Certificates to support Root rollover

[Ryan Sleevi via dev-security-policy]

Hi Doug,

Unfortunately, it looks like your approach to replying inline completely
destroyed the formatting. I'm unable to follow or determine your responses,
based on your mail client.

You can see both as rich text [1] and plain text [2] that your formatting
makes your responses illegible, to the point I'm unable to engage.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/WaniySf02vI/bhYROh9bEwAJ
[2]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg12285.html


On Mon, Aug 5, 2019 at 10:03 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan,
>
>
>
> Note: I changed the name of the thread because this is a great discussion
> about root roll-over and isn’t really related to the Entrust Root inclusion
> request.
>
>
>
> In theory Cross certificates are simple, but I’ve found that in practice
> they are difficult to manage and use.
>
>
>
> First, it would be a good idea to agree on the definition of a Cross
> Certificate.  The BRs define it as: A certificate that is used to establish
> a trust relationship between two Root CAs.
>
>
>
> Does that align with your definition?  I ask because you used the term
> Cross signed intermediate, so it seems you may be using a difference
> definition than the one in the BRs.  Are you proposing this type of
> approach where the Issuer of the SSL certificate could be one of 2
> different CAs (have same keys and Subject Name but are signed by different
> roots)?
>
> SSL – Intermediate CA 1 – Legacy Root
>
> SSL – Cross Intermediate CA 2 – New Root
>
>
>
> I thought a cross certificate chain needed to look like this
>
> SSL – Intermediate CA 1 (signed by new root) – Cross cert  – Legacy
> Root
>
>
>
> My discussion is focused on the BR definition, so there could be
> advantages to creating multiple intermediate signed CAs which I haven’t
> considered yet.  What definition/approach were you assuming?
>
>
>
> See responses in-line below
>
>
>
> From: Doug Beattie 
> Sent: Monday, August 5, 2019 7:29 AM
> To: Doug Beattie 
> Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion
> Request
>
>
>
>
>
> On Mon, Aug 5, 2019 at 7:12 AM Doug Beattie   > wrote:
>
> From: Ryan Sleevi mailto:r...@sleevi.com> >
> Sent: Friday, August 2, 2019 1:49 PM
> To: Doug Beattie  doug.beat...@globalsign.com> >
> Cc: r...@sleevi.com  ; Bruce <
> bruce.mor...@entrust.com  >;
> mozilla-dev-security-policy   >
> Subject: Re: Entrust Root Certification Authority - G4 Inclusion Request
>
> On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie   > wrote:
>
> Ryan,
>
> GlobalSign has been thinking along these lines, but it's not clear how
> browsers build their path when a cross certificate is presented to them in
> the TLS handshake.
>
> Excellent! Happy to help in any way to make that possible and easier :)
>
>  I knew you would 
>
> Can you explain how chrome (windows and Android)  builds a path when a
> cross
> certificate is delivered?  What about the case when the OS (Microsoft
> specifically) has cached the cross certificate, is it different?
>
>  It's unclear the objective of the question. That is, are you trying to
> figure out what happens with both paths are valid, or how it handles edge
> cases, etc?
>
> We have some customers that mandate a complete SHA-256 chain, including
> the root.  We had been using our older SHA-1 Root (R1) and recently moved
> to our newer SHA-265 root, (R3).  We now can deliver certificates issued
> with SHA-256 at all levels, great!  In order to support some legacy
> applications that didn’t have R3 embedded, we created a cross certificate
> R1-R3.  You can get it here <
> https://support.globalsign.com/customer/en/portal/articles/2960968-globalsign-cross-certificates>
> .
>
>
>
> The customer came back and said, hey, it still chains to R1, what’s up?
> Oh, it’s because the client has the cross certificate cached, don’t worry
> about that, some users will see the chain up to R1 and others to R3.  Hmm,
> not good they say.
>
>
>
> Anyway, no way around that now (unless you have some other tricks)  I went
> and looked at the links to the MS article and noticed that when the quality
> of the certificates in the chain is the same, then it prefers certificates
> that have a later NotBefore date (I presume this means issued more
> recently).  Our R1-R3 cross was issued in 2018 and the Root R3 was issued
> in 2009.  When the issuing CA is validated it has 2 paths it can follow,
>
> 1) Root R3, issued in 2009, or
>
> 2) the Cross certificate, issued in 2018.
>
> Even though the path is longer, it uses the cross certificate which chains
> to R1 (SHA-1) because of the not-before date.
>
>
>
> Does this mean we should have created the cross certificate with the same
> date as the  R3 root 

Re: How to use Cross Certificates to support Root rollover

[Jakob Bohm via dev-security-policy]

One note:

As a company that actively supports users with old operating systems and
OS-provided root stores, we have been deliberately including your R1-R3
cross, and are battling problems with a few really old platforms that
plain don't support any certs currently available.  This isn't just
being overcautious about hypothetical compatibility, it's ongoing work
to keep compatibility with a specific list of platforms.

Oh, and as for chain selection, it is important to distinguish between
client and server behaviour.  Ideally, servers would send a compatible
collection while clients would use the first or best valid chain (thus
ending their search when hitting a trusted root DN with matching key).
The AIA-pointing-to-cross trick may work for many GUI browsers, thus
making it useful for servers that only care about those browsers, while
other servers could just continue to send the cross directly.


On 05/08/2019 16:02, Doug Beattie wrote:

Ryan,

...


We have some customers that mandate a complete SHA-256 chain, including the root.  We 
had been using our older SHA-1 Root (R1) and recently moved to our newer SHA-265 
root, (R3).  We now can deliver certificates issued with SHA-256 at all levels, 
great!  In order to support some legacy applications that didn’t have R3 embedded, we 
created a cross certificate R1-R3.  You can get it here 

 .

  


The customer came back and said, hey, it still chains to R1, what’s up?  Oh, 
it’s because the client has the cross certificate cached, don’t worry about 
that, some users will see the chain up to R1 and others to R3.  Hmm, not good 
they say.


Even if this specific web site didn’t configure the extra certificate (the 
R1-R3 cross certificate) into their configuration, the end users may have 
picked it up somewhere else and have it cached so their specific chain goes: 
SSL, Intermediate CA, R1-R3 Cross certificate, Root R1




In a




They are stuck with inconsistent user experience and levels of “security” for 
their website.

  

  

  


At present (and this is changing), Chrome uses the CryptoAPI implementation, 
which is the same as IE, Edge, and other Windows applications.

You can read a little bit about Microsoft's logic here:

- 
https://blogs.technet.microsoft.com/pki/2010/05/12/certificate-path-validation-in-bridge-ca-and-cross-certification-environments/

And a little about how the IIS server selects which intermediates to include in 
the TLS handshake here:

- 
https://support.microsoft.com/en-us/help/2831004/certificate-validation-fails-when-a-certificate-has-multiple-trusted-c

The "short answer" is that, assuming both are trusted, either path is valid, 
and the preference for which path is going to be dictated by the path score, how you can 
influence that path score, and how ties are broken between similarly-scoring certificates.

It’s not clear how a CA can influence the path so the “most secure” or “newest” 
one.  Since CAs want to rollover to newer, “better” roots, how do we limit 
clients from continuing to use the older one during the transition?  Is 
creating a cross certificate with a not-before that is equal to or predates the 
new Root permitted?  Is it the only way we can be sure that the new path is 
selected?  Do most/all other web clients also follow this same logic?  Sorry, 
for all the questions.

  

  


   * increases TLS handshake packet sizes (or extra packet?), and
   * increases the certificate path from 3 to 4 certificates (SSL, issuing
CA, Cross certificate, Root), which increases the path validation time and
is typically seen as a competitive disadvantage

  


I'm surprised and encouraged to hear CAs think about client performance. That 
certainly doesn't align with how their customers are actually deploying things, based 
on what I've seen from the httparchive.org   data 
(suboptimal chains requiring AIA, junk stapled OCSP responses, CAs putting entire 
chains in OCSP responses).

It’s not really the answer I expected, but OK.  Since we don’t control how the 
web sites are configured it’s not clear how CAs can improve this (except for 
your last example).

  


Assuming some CAs want to provide certificates with optimal performance 
characteristics (ECDSA, shorter chains, smaller certificate size, etc.) it 
seems passing down an extra certificate in the handshake isn’t the best 
approach.  Maybe it’s so far in the noise it’s irrelevant.

  


As a practical matter, there are understandably tradeoffs. Yet you can allow 
your customers the control to optimize for their use case and make the decision 
best for them, which helps localize some of those tradeoffs. For example, when 
you (the CA) is first rolling out such a new root, you're right that your 
customers will likely want to include the cross-signed version back to the 
existing root within root stores. Yet as root stores update (which, in 

How to use Cross Certificates to support Root rollover

[Doug Beattie via dev-security-policy]

Ryan,

 

Note: I changed the name of the thread because this is a great discussion about 
root roll-over and isn’t really related to the Entrust Root inclusion request.

 

In theory Cross certificates are simple, but I’ve found that in practice they 
are difficult to manage and use.

 

First, it would be a good idea to agree on the definition of a Cross 
Certificate.  The BRs define it as: A certificate that is used to establish a 
trust relationship between two Root CAs.

 

Does that align with your definition?  I ask because you used the term Cross 
signed intermediate, so it seems you may be using a difference definition than 
the one in the BRs.  Are you proposing this type of approach where the Issuer 
of the SSL certificate could be one of 2 different CAs (have same keys and 
Subject Name but are signed by different roots)?

SSL – Intermediate CA 1 – Legacy Root

SSL – Cross Intermediate CA 2 – New Root

 

I thought a cross certificate chain needed to look like this

SSL – Intermediate CA 1 (signed by new root) – Cross cert  – Legacy Root

 

My discussion is focused on the BR definition, so there could be advantages to 
creating multiple intermediate signed CAs which I haven’t considered yet.  What 
definition/approach were you assuming?

 

See responses in-line below

 

From: Doug Beattie  
Sent: Monday, August 5, 2019 7:29 AM
To: Doug Beattie 
Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion Request

 

 

On Mon, Aug 5, 2019 at 7:12 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Friday, August 2, 2019 1:49 PM
To: Doug Beattie mailto:doug.beat...@globalsign.com> >
Cc: r...@sleevi.com  ; Bruce mailto:bruce.mor...@entrust.com> >; mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Entrust Root Certification Authority - G4 Inclusion Request

On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

Ryan,

GlobalSign has been thinking along these lines, but it's not clear how
browsers build their path when a cross certificate is presented to them in
the TLS handshake.

Excellent! Happy to help in any way to make that possible and easier :)

 I knew you would  

Can you explain how chrome (windows and Android)  builds a path when a cross
certificate is delivered?  What about the case when the OS (Microsoft
specifically) has cached the cross certificate, is it different?

 It's unclear the objective of the question. That is, are you trying to figure 
out what happens with both paths are valid, or how it handles edge cases, etc?

We have some customers that mandate a complete SHA-256 chain, including the 
root.  We had been using our older SHA-1 Root (R1) and recently moved to our 
newer SHA-265 root, (R3).  We now can deliver certificates issued with SHA-256 
at all levels, great!  In order to support some legacy applications that didn’t 
have R3 embedded, we created a cross certificate R1-R3.  You can get it here 

 .

 

The customer came back and said, hey, it still chains to R1, what’s up?  Oh, 
it’s because the client has the cross certificate cached, don’t worry about 
that, some users will see the chain up to R1 and others to R3.  Hmm, not good 
they say.

 

Anyway, no way around that now (unless you have some other tricks)  I went and 
looked at the links to the MS article and noticed that when the quality of the 
certificates in the chain is the same, then it prefers certificates that have a 
later NotBefore date (I presume this means issued more recently).  Our R1-R3 
cross was issued in 2018 and the Root R3 was issued in 2009.  When the issuing 
CA is validated it has 2 paths it can follow, 

1) Root R3, issued in 2009, or 

2) the Cross certificate, issued in 2018.  

Even though the path is longer, it uses the cross certificate which chains to 
R1 (SHA-1) because of the not-before date.

 

Does this mean we should have created the cross certificate with the same date 
as the  R3 root (2009)?  

How else can we have clients prefer the shorter higher security SHA-256 chain?  

Perhaps this is means that we need to change the definition of a Cross 
certificate from being a Root to Root chain.

 

Even if this specific web site didn’t configure the extra certificate (the 
R1-R3 cross certificate) into their configuration, the end users may have 
picked it up somewhere else and have it cached so their specific chain goes: 
SSL, Intermediate CA, R1-R3 Cross certificate, Root R1

 

They are stuck with inconsistent user experience and levels of “security” for 
their website. 

 

 

 

At present (and this is changing), Chrome uses the CryptoAPI implementation, 
which is the same as IE, Edge, and other Windows applications.

You can read a little bit about Microsoft's logic here:

-