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 <douglas.beat...@gmail.com>
Sent: Monday, August 5, 2019 7:29 AM
To: Doug Beattie <doug.beat...@globalsign.com>
Subject: Re: FW: Entrust Root Certification Authority - G4 Inclusion Request
On Mon, Aug 5, 2019 at 7:12 AM Doug Beattie <doug.beat...@globalsign.com
<mailto:doug.beat...@globalsign.com> > wrote:
From: Ryan Sleevi <r...@sleevi.com <mailto:r...@sleevi.com> >
Sent: Friday, August 2, 2019 1:49 PM
To: Doug Beattie <doug.beat...@globalsign.com
<mailto:doug.beat...@globalsign.com> >
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Bruce <bruce.mor...@entrust.com
<mailto:bruce.mor...@entrust.com> >; mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org
<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 <doug.beat...@globalsign.com
<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
<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 (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:
-
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 <http://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 the case
of browsers, can be quite fast), your customer could chose to begin omitting
that intermediate, and rely on intermediate preloading (Firefox) or AIA
(everyone else). In this model, the AIA for your 'issuing intermediate' would
point to a URL that contained your cross-signed intermediate, which would then
allow them to build the path to the legacy root. Clients with your new root
would build and prefer the shorter path, because they'd have a trust anchor
matching that (root, key) combination, while legacy clients could still build
the legacy path.
Can you explain the logic in your last statement above about AIA? What is the
Issuing Intermediate in this example, is it the one that is signed by the new
root but has an AIA pointing to the cross certificate? Interesting – I never
thought about including a certIssuer link in a AIA of a CA that was signed by a
root.
Your last statement (building the shorter path) doesn’t seem to be how Chrome
does it, or at least that is not how the Chrome certificate viewer displays the
chain, as discussed above (unless you’re assuming the not-before dates are
adjusted to be identical)
Yea, this is the hard part. We’re assuming the web server operator understands
this and is capable of making the tradeoffs you outlined above. Generally they
want the CA to tell them how to install the certificate.
When we change the roots under which we issue SSL certificates, we need to say:
If you’re not sure if you need the complete interoperability of the old root,
then install the cross certificate. Even if we say the old root has support for
a few legacy platforms that are no longer in meaningful use so you should be OK
without them (Android 1-2, FF 3.0 and earlier, Mozilla 1-2, Safari 1-3, etc.)
they are likely to install the cross certificate just to be safe. While we
can provide them the pros and cons, they don’t want to think about this and
just want to install their certificate and move forward without impacting any
current or possible visitors.
I’m curious how Google would handle this. At what point will you start using
the Google "GTS Root R1” created in 2016 with a cross certificate back to your
current Root? It uses 4K and SHA 384 vs. 2K and SHA-1 in your current root, so
there seem to be clear advantages for using it.
Do you view these as meaningful issues? Do you know of any CAs that have
taken this approach?
Definitely! I don't want to sound dismissive of these issues, but I do want to
suggest it's good if we as an industry start tackling these a bit head-on. I'm
particularly keen to understand more about how and when we can 'sunset' roots.
For example, if the desire is to introduce a new root in order to transition to
stronger cryptography, I'd like to understand more about how and when clients
get the 'strong' chain or the 'weaker' chain and how that selection may change
over time. I'm understanding to 4K roots - while I'd rather we were in a world
where 2K roots were viable because we were rotating roots more frequently
(hence the above), 4K roots may make sense given the pragmatic realities that
these end up being used much longer than anticipated. If that's the case,
though, it's reasonable to think we'd retire roots <4K, and it's reasonable to
think we don't need multiple 4K roots. That's why I wanted to flesh out these
considerations and have that discussion, because I'm not sure that just
allowing folks to select '2K vs 4K' for a particular CA really helps move the
needle far enough in user benefit (it does, somewhat, but not as much as 'all
4K', for example)
My understanding is that both Symantec / DigiCert and Sectigo have pursued
paths like this, and can speak more. ISRG / Let's Encrypt pursued something
similar-but-different, but which had the functional goal of reducing their
dependency on the IdenTrust root in favor of the ISRG root.
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
