Let's Encrypt New Intermediate Certificates

[Phil Porada]

All,

In 2024 Q1, Let's Encrypt plans to issue new intermediate keys and certificates. The exact date and time is to be determined. Most ACME clients will automatically configure new intermediate certificates, so no subscriber action should be needed.

Motivation
Previously in 2020, Let’s Encrypt issued six new certificates: one root (ISRG Root X2), four intermediates, and one cross-sign. Those new certificates were part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making overall certificate sizes smaller. The existing R3, R4, E1, and E2 intermediate certificates are now more than halfway through their 5 year validity period, so it is time to issue new intermediates to replace them.

New Keys and Certificates
These new intermediates will differ from our previous batch in four ways:

1. We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2 each. We plan to automatically rotate issuance between multiple intermediates for improved redundancy.
2. We will be shortening their validity period from 5 years to 3 years, to reflect our commitment to issue new intermediates every 2 years.
3. They will use SHA256 to compute their Subject Key Identifiers instead of SHA1.
4. They will only contain the Baseline Requirements Domain Validated Reserved Certificate Policy Identifier (OID 2.23.140.1.2.1).

The five RSA intermediates will be issued from ISRG Root X1, and the five ECDSA intermediates will be issued from ISRG Root X2. In addition, the five ECDSA intermediates will be cross-signed by ISRG Root X1, to allow efficient chain-building even for clients which do not yet have ISRG Root X2 in their trust stores.

In Summary
We will be generating 10 new intermediate keys.

• 5x 2048 bit RSA keys
• 5x P-384 ECDSA keys

We will be issuing 15 certificates, each with a validity period of 3 years.

• 5x RSA intermediate certificates signed by ISRG Root X1
• 5x ECDSA intermediate certificates signed by  ISRG Root X2
• 5x ECDSA intermediate certificates cross-signed from ISRG Root X1

A demo of this upcoming ceremony, and many of our historical ceremonies, can be found here. You can view the example intermediate certificate PEM and text output here. Please assist us in reviewing these outputs for compliance and correctness. Let us know if you see any errors or oddities that our linting has missed.

Thank you!

[Corey Bonnell]

Hi Phil,

I am wondering about the rationale for switching the hash algorithm used for generating SKIs. If the full SHA-256 hash of the subjectPublicKey is used as the SKI value, then the intermediate certificate and end-entity certificate will each be 12 octets larger (256-bit SHA-256 hash vs. 160-bit SHA-1 hash).

 

If the rationale is to move away from all use of SHA-1 (even in non-security relevant contexts), then I’d recommend looking at section 2 of RFC 7093 [1]. One of the methods the RFC prescribes is using the 160 leftmost bits of the SHA-256 hash of the subjectPublicKey as the SKI value. This allows the CA to replace the use of SHA-1 with SHA-256 without incurring any certificate size increase. Namely, chains will be 24 octets smaller than they would be if the full SHA-256 hash were used.

 

Thanks,

Corey

 

[1] https://datatracker.ietf.org/doc/html/rfc7093#section-2

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACpGwJZOLVQUw_XsEjuMjPgbW0QbnLKu6KboZ68nLSXEY0G4zA%40mail.gmail.com.

[Peter Gutmann]

'Corey Bonnell' via dev-secur...@mozilla.org writes:

>I am wondering about the rationale for switching the hash algorithm used for
>generating SKIs. If the full SHA-256 hash of the subjectPublicKey is used as
>the SKI value, then the intermediate certificate and end-entity certificate
>will each be 12 octets larger (256-bit SHA-256 hash vs. 160-bit SHA-1 hash).

And in particular the sKID is an implicit value, not an explicit value.  In
other words it can be anything that works for the CA, not explicitly a hash of
the public key with a specific algorithm, although that's a very common way to
create it.

In terms of the announcement:

  They will use SHA256 to compute their Subject Key Identifiers instead of SHA1.

while that sort of implies use of the full hash, it could actually be
anything, just using SHA256 instead of SHA1 at some step of the process.

Peter.

[Phil Porada]

That's a good idea Corey. I've made a change to boulder to use that method for end-entity certificates and have updated the ceremony-demos output. We were indeed on a path to using the full SHA-256 hash. Thanks!

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB62511ED00308FF7E72E6B40AEE85A%40SY4PR01MB6251.ausprd01.prod.outlook.com.

[Hanno Böck]

On Mon, 4 Dec 2023 14:20:34 -0500
"'Phil Porada' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

> 1. We will be generating 5 RSA and 5 ECDSA intermediates, instead

> of 2 each. We plan to automatically rotate issuance between multiple
> intermediates for improved redundancy.

I'm curious what exactly that means. Do you mean you will basically
pick an intermediate at random and an ACME user will have no way of
knowing previously which intermediate one will get?

I expect that there are likely plenty of LE users out there that have
setups where the certificate is dynamically generated, but the
intermediate configured statically. (I know I have such setups myself,
with the expectation that a new intermediate is rare enough and I'll
always learn about it in advance, so I can react manually.)

Now, I'm not necessarily saying that this is a reason not to do it. If
LEs intention is that for improved agility they don't want to support
setups that cannot handle constantly changing intermediates, that's
understandable.

However, you should expect that this will create some problems, and
probably an increased amount of support requests once you start doing
this. Given that browsers cache intermediates, such errors can be hard
to debug ("it does not work in this device/browser, but in this one
everything is fine"). Tools like ssllabs detect these issues, but this
stuff is often confusing for people not deeply familiar with TLS+WebPKI.

--
Hanno Böck
https://hboeck.de/

[Aaron Gable]

On Tue, Dec 5, 2023, 12:35 Hanno Böck <ha...@hboeck.de> wrote:

On Mon, 4 Dec 2023 14:20:34 -0500
"'Phil Porada' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

>    1. We will be generating 5 RSA and 5 ECDSA intermediates, instead
> of 2 each. We plan to automatically rotate issuance between multiple
>    intermediates for improved redundancy.

I'm curious what exactly that means. Do you mean you will basically
pick an intermediate at random and an ACME user will have no way of
knowing previously which intermediate one will get?

Yes. In practice, it might be something like "which data center issues the certificate determines which intermediate is used", but ACME requests are routed to data centers non-deterministically so it's effectively the same thing.

I expect that there are likely plenty of LE users out there that have
setups where the certificate is dynamically generated, but the
intermediate configured statically. (I know I have such setups myself,
with the expectation that a new intermediate is rare enough and I'll
always learn about it in advance, so I can react manually.)

Also yes, we're very aware of this possibility. This is in fact a large part of why we're making this change: it's a mechanical way of discouraging/preventing intermediate pinning. We went through this recently with the change to the R3 and E1 intermediates, and although some people had to make changes to accommodate the new intermediates, there were relatively few breakages. We expect to handle a similar level of support requests this time, but with the advantage that (in theory) we'll never have to do so again during future intermediate transitions.

For what it's worth, the intermediate *shouldn't* need to be configured statically in any ACME setup, since it is provided in the same file as the newly issued certificate itself at the end of issuance.

Aaron

[Matthew Hardeman]

Also yes, we're very aware of this possibility. This is in fact a large part of why we're making this change: it's a mechanical way of discouraging/preventing intermediate pinning. We went through this recently with the change to the R3 and E1 intermediates, and although some people had to make changes to accommodate the new intermediates, there were relatively few breakages. We expect to handle a similar level of support requests this time, but with the advantage that (in theory) we'll never have to do so again during future intermediate transitions.

For what it's worth, the intermediate *shouldn't* need to be configured statically in any ACME setup, since it is provided in the same file as the newly issued certificate itself at the end of issuance.

There do exist some exotic platforms where a trust-list-matching root anchor, an intermediate issuer/chain, and the leaf cert all need to be provided in separate files or in various concatenated combinations.  In other environments, there needs to be a pfx/pkcs12 file with the full chain including the trust-anchor-root to be incorporated as a single chained cert/key object.

Ultimately, the right place to fix all of that is at the ACME client / cert deployment tooling.

[Jeffrey Walton]

On Tue, Dec 5, 2023 at 4:45 PM 'Aaron Gable' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:

> On Tue, Dec 5, 2023, 12:35 Hanno Böck <ha...@hboeck.de> wrote:
>>

>> [...]

>> I expect that there are likely plenty of LE users out there that have
>> setups where the certificate is dynamically generated, but the
>> intermediate configured statically. (I know I have such setups myself,
>> with the expectation that a new intermediate is rare enough and I'll
>> always learn about it in advance, so I can react manually.)
>
> Also yes, we're very aware of this possibility. This is in fact a large part of why we're making this change: it's a mechanical way of discouraging/preventing intermediate pinning.

Key continuity is a much better security property than what key
rotation provides. Loss of key continuity exposed Diginotar. Why would
LE discourage it?

Stepping back, I'm not thrilled LE is trying to set a policy for me. I
should make my own policy decisions.

> We went through this recently with the change to the R3 and E1 intermediates, and although some people had to make changes to accommodate the new intermediates, there were relatively few breakages. We expect to handle a similar level of support requests this time, but with the advantage that (in theory) we'll never have to do so again during future intermediate transitions.

What advantages?

> For what it's worth, the intermediate *shouldn't* need to be configured statically in any ACME setup, since it is provided in the same file as the newly issued certificate itself at the end of issuance.

Hmmm... We use Apache, SSLCertificateChainFile and SSLCertificateFile.
LE is just creating more work for us.

We're a free software project. I guess beggars can't be too choosy...

Jeff

[Aaron Gable]

On Tue, Dec 5, 2023 at 2:30 PM Jeffrey Walton <nolo...@gmail.com> wrote:

Key continuity is a much better security property than what key
rotation provides. Loss of key continuity exposed Diginotar. Why would
LE discourage it?

This is contrary to the current industry consensus. Root programs are moving to limit CA lifetimes: Mozilla recently instituted a policy that root key material will not be trusted for more than 15 years, and Chrome has announced their desire to limit root certificates to 7 years and intermediate certificates to 3 years. We prefer to be proactive, and also prefer to have a buffer between our practices and the strictest requirements, so we are shortening our intermediate lifetimes now.

Note also that, while Google did detect the fraudulent diginotar *.google.com certificate thanks to HPKP key pinning, it was the root key that was pinned, not an intermediate. And at the time, we didn't yet have certificate transparency logs, let alone browsers enforcing the presence of SCTs.

 

What advantages?

Today, every time we switch to new intermediates we have to deal with the problem Hanno Böck described -- breakages because people have setups that assume our intermediates will be static. This happens regularly, because intermediates expire. Switching to a system where the intermediates are changing constantly forces clients to be able to properly use the intermediate which actually issued the new certificate, rather than making assumptions about that intermediate. This will prevent similar breakages when we issue the next batch of intermediates.

Basically, we're trading a slightly higher expected breakage / support load during this intermediate transition for drastically lower breakage during all future intermediate transitions.

Hmmm... We use Apache, SSLCertificateChainFile and SSLCertificateFile.
LE is just creating more work for us.

To the best of my knowledge, there are multiple ACME clients that can populate Apache's SSLCertificateChainFile from the intermediate provided along with the certificate at the end of the ACME issuance flow.

Thanks,

Aaron

[Peter Gutmann]

'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> writes:

>This is contrary to the current industry consensus.

Just doing a sanity check here, key continuity has been a core feature of SSH
security for close to thirty years, and was finally adopted for PKI use as
well after a string of highly-public CA failures. Are you saying that the
consensus among all? most? CAs is that actively breaking key continuity/
pinning is a good idea, or is this just a Let's Encrypt thing? Just trying to
get an idea of how widespread this is.

Peter.

[Filippo Valsorda]

Not answering for Aaron, but I can confirm as a relying party that my understanding of the WebPKI industry consensus is that the benefits of key and certificate agility in this PKI outweigh those of key continuity. I commend Let's Encrypt for taking the support load hit to move the client tooling ecosystem forward, as they have been always doing.

The comparison to SSH does not sound apt, as a TOFU model is fundamentally different from one where clients have regularly updated trusted root anchors. I am not sure what you mean by key continuity being adopted for PKI use, given the demise of HPKE now five years ago, but I'll point out that SSH supports certificates which are deployed regularly by large enterprises in a way that allows key flexibility.

[Peter Gutmann]

Filippo Valsorda <fil...@ml.filippo.io> writes:

>I am not sure what you mean by key continuity being adopted for PKI use

I meant the use of certificate pinning, so trusting the known-good cert you've
seen before and, like SSH when a key changes, triggering an alert if it
changes.

Peter.

[Aaron Gable]

On Wednesday, December 6, 2023 at 5:27:11 AM UTC-8 Peter Gutmann wrote:

I meant the use of certificate pinning, so trusting the known-good cert you've seen before

 

If a client or relying party wants to enforce key continuity, they still can. If they want continuity of a CA key operated by their certificate authority, they can pin the root key. If they want continuity of a key lower in the hierarchy, they can do their own key management and pin their site's end-entity key. This change does not break key continuity in general.

On Tuesday, December 5, 2023 at 5:56:20 PM UTC-8 Peter Gutmann wrote:

Just trying to get an idea of how widespread this is.

Amazon Trust Services already issues from unpredictable intermediates, and they provide the same advice in their announcement: pinning roots is better than pinning intermediates. And I'll reiterate that various Root Programs are moving towards enforcing short intermediate lifetimes, so this idea is not just restricted to CAs.

Finally, there are many aspects of the new certificates (policy OIDs, naming, cross-signing the ECDSA intermediates, etc) which have not yet been discussed on this thread. If you have thoughts or concerns about any of those, please chime in!

Thanks,

Aaron

[Jeffrey Walton]

On Wed, Dec 6, 2023 at 12:45 PM Aaron Gable <aa...@letsencrypt.org> wrote:
>
> On Wednesday, December 6, 2023 at 5:27:11 AM UTC-8 Peter Gutmann wrote:
>
> I meant the use of certificate pinning, so trusting the known-good cert you've seen before
>
> If a client or relying party wants to enforce key continuity, they still can. If they want continuity of a CA key operated by their certificate authority, they can pin the root key. If they want continuity of a key lower in the hierarchy, they can do their own key management and pin their site's end-entity key. This change does not break key continuity in general.
>
> On Tuesday, December 5, 2023 at 5:56:20 PM UTC-8 Peter Gutmann wrote:
>
> Just trying to get an idea of how widespread this is.
>
> Amazon Trust Services already issues from unpredictable intermediates, and they provide the same advice in their announcement: pinning roots is better than pinning intermediates. And I'll reiterate that various Root Programs are moving towards enforcing short intermediate lifetimes, so this idea is not just restricted to CAs.

Pinning a root seems the least wise strategy to me. Pinning a root
confers the broadest amount of trust. Trimming the tree, and pinning
as close to the end-entity as possible, like the intermediate used to
issue the end-entity cert, seems like a better idea. Pinning the
intermediate, and removing unneeded limbs from the tree is consistent
with the Saltzer and Schroeder's principle of least privilege, and it
reduces the attack surface.

But under this scheme, we cannot pin an intermediate used to issue the
end-entity certificate because the intermediate is a moving target. I
don't see how that's a win for the security team.

> Finally, there are many aspects of the new certificates (policy OIDs, naming, cross-signing the ECDSA intermediates, etc) which have not yet been discussed on this thread. If you have thoughts or concerns about any of those, please chime in!

Jeff

[Ryan Hurst]

In WebPKI, "key continuity" has resulted in numerous outages, some of which are effectively non-recoverable. Overall, we have learned that the global and distributed nature of WebPKI demands agility.

Ryan

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB6251D5B575FFD8981ACC72A6EE84A%40SY4PR01MB6251.ausprd01.prod.outlook.com.

[Amir Omidi (aaomidi)]

> Pinning the intermediate, and removing unneeded limbs from the tree is consistent with the Saltzer and Schroeder's principle of least privilege, and it reduces the attack surface.

Maybe? But keep in mind that roots are kept offline. As in, these keys are kept in a safe, in a locked room with various ACLs. An intermediate doesn't, and can't have the same levels of security around it. When (not if) an intermediate is pwned, revoked, etc, you'll end up DoSing the systems that have had an intermediate pinned.

> But under this scheme, we cannot pin an intermediate used to issue the end-entity certificate because the intermediate is a moving target. I don't see how that's a win for the security team

What is the answer to the security team if the intermediate you had pinned to got revoked?

I think these principals of pinning intermediates make a lot of sense when speaking about PrivatePKI where one entity controls the full lifecycle, but with PublicPKI it needs to elevate security principals for, well, the public. Sometimes these security principals can be in contrast of what a power user would be handling. In other words, communal & public strengthening in security might lead to subjective/objective decrease in security for the folks who know what they're doing.

[Matt Palmer]

On Wed, Dec 06, 2023 at 01:19:28PM -0500, Jeffrey Walton wrote:
> On Wed, Dec 6, 2023 at 12:45 PM Aaron Gable <aa...@letsencrypt.org> wrote:
> > On Wednesday, December 6, 2023 at 5:27:11 AM UTC-8 Peter Gutmann wrote:
> > I meant the use of certificate pinning, so trusting the known-good cert you've seen before
> >
> > If a client or relying party wants to enforce key continuity, they still can. If they want continuity of a CA key operated by their certificate authority, they can pin the root key. If they want continuity of a key lower in the hierarchy, they can do their own key management and pin their site's end-entity key. This change does not break key continuity in general.
> >
> > On Tuesday, December 5, 2023 at 5:56:20 PM UTC-8 Peter Gutmann wrote:
> >
> > Just trying to get an idea of how widespread this is.
> >
> > Amazon Trust Services already issues from unpredictable intermediates, and they provide the same advice in their announcement: pinning roots is better than pinning intermediates. And I'll reiterate that various Root Programs are moving towards enforcing short intermediate lifetimes, so this idea is not just restricted to CAs.
>
> Pinning a root seems the least wise strategy to me. Pinning a root
> confers the broadest amount of trust. Trimming the tree, and pinning
> as close to the end-entity as possible, like the intermediate used to
> issue the end-entity cert, seems like a better idea. Pinning the
> intermediate, and removing unneeded limbs from the tree is consistent
> with the Saltzer and Schroeder's principle of least privilege, and it
> reduces the attack surface.

Pinning an intermediate of a root whose hierarchy is entirely controlled by
a single organisation doesn't reduce privilege, as far as I can discern.
Can you explain the privilege level that is being meaningfully restricted by
pinning an intermediate rather than the root, in the case of Let's Encrypt?

- Matt

[Matt Palmer]

Trusting a *cert* you've seen before and popping up a warning when it
changes seems like an absolutely terribad idea, given certs are designed to
expire. Trusting the *key* underlying the cert, and having the user perform
an action when the key changes, is arguably better (at least keys don't
*have* to change, by Root Store policy, on a regular basis) but the closest
thing to that I can think of to that is HPKP[1], but that's not a TOFU key
scheme, but is instead the site declaring which key(s) are valid for itself.
When has "true" cert/key TOFU been deployed in a WebPKI context?

- Matt

[1] which Chrome nuked some years ago, IE, Edge, and Safari never
implemented, and which is default-off in Firefox, according to
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

[Antonios Chariton]

Hello everyone,

I’d also like to jump in the conversation and say that I believe Let’s Encrypt’s move here is good, in my opinion, and will lead to an overall increase in security for the entire ecosystem.

When they began operations, back when certificates weren’t free, I remember asking them what their challenge validation IP addresses were, so I could implement some logic involving them. Their response back then was that they don’t publish that list, so they can maintain agility, and avoid ossification. Although it made my life a little bit more difficult at the time, I am grateful they did this after all those years. The pros clearly outweighed the cons in the long run.

I am confident that this decision is going to lead to similar results: a few people are going to be a little bit inconvenienced today, maybe a few things will break, but it’s for the overall good.

This has happened many times in the WebPKI’s history:

Cloudflare made HTTPS broadly available and free, but they required ECDSA. Due to them sticking to this for the Free plans, and only using RSA for the more expensive offerings, we now have broad ECDSA support across all devices, such as computers, mobile phones, IoT, etc. They knew things would break, but they also knew that was the only way to move forward.

Let’s Encrypt’s (and other CAs’) Root Migrations also highlighted an important problem: we need all devices to have upgradeable trust anchors. Shipping a trust store and then having no ability to update this is not a smart move, and the opposite increases security on many fronts: cryptographic agility, inclusion and removal of CAs based on practices, etc.

I know everyone’s busy, and they have important things to do, which is respectable, but sometimes asking for an exception just shouldn’t be possible or granted. Especially if that “exception” is keeping everyone else back. I’ve personally seen exception requests for prolonging X.509 certificates’ lifetime, I guess with magic or time machines…

Regarding key pinning, as the others expressed before me, this is an outdated practice that we now understand was not the best idea. Especially at the browsers. For mobile applications, that’s recommended or practiced, but it’s a different landscape. I still see multiple solutions there. For example, Signal, the popular messaging app, is using a self-signed certificate, bypassing WebPKI entirely. For users of the WebPKI, there are three main models:

1) Pin the leaf (key)

If you pin the key of the leaf certificate, and not the certificate itself, you can keep issuing with the same key if you’d like, or set of keys, and there’s no problem. You can always shoot yourself in the foot, but that it a risk you hopefully understand and accept.

2) Pin the Intermediate CA

If you do that, you don’t have the same security properties: now everyone who can issue Let’s Encrypt certificates will be able to get past the pin check, so what you’re effectively doing is limiting issuance to one CA only (maybe enforced with CAA too). That’s good, because I may only trust Let’s Encrypt, and no other CA, but:

3) Pin the Root CA

If you pin the Root, it’s true that it’s at a higher level, but for this case it’s no different: if Let’s Encrypt has 1 SubCA, like now, then pinning the Root or the SubCA is the same thing. You don’t lose or gain anything. As Amir said however, the SubCA carries the risk of being much more easily revocable, replaceable, shorter-lived. You’re setting yourself up for tighter monitoring, outages, incidents, etc.

To summarize, I would say that the benefits to the WebPKI are significant here, having the largest CA use dynamic chains, and it’s worth the small changes that will be needed here and there. It will position all of us for an improved and better WebPKI that can bring more trust and security to all connections. We’ll get to pay back some technical debt, and we’ll be more effective moving forward.

Maybe one day we can also get dynamic Roots too! :P

Thanks,
Antonis

[Kyle Hamilton]

X.509 has supported key continuity for quite a long time, by doing
self-issued rekeyed certificates for at least root CAs (which is why
subjectKeyIdentifier and authorityKeyIdentifier had to become a
thing).

What they're saying is that the applications that currently consume
the PKI (why is it just web browsers right now? Oh yeah, because the
name of the CABF literally says that "browsers" are the only consuming
entities with any kind of seat at the table) have decided to mandate
that root key material will have a maximum lifetime. This means that
those consuming applications won't implement X.509's key continuity
mechanism, even if the CAs themselves do self-issued certificates from
older/continuity key material.

(Mozilla has allowed root certificates which have been signed by
different keys to be embedded in their store before.)

I present no opinion as to whether this is an appropriate policy
decision. I honestly have no faith in Mozilla, Google, or Apple to
effectively manage their root processes in any useful way that doesn't
reinforce the browsers' stranglehold on PKIX issuers, and so I have
recused my voice from the discussion.

-Kyle H

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB62516AF55C8D8D82EC8A7083EE84A%40SY4PR01MB6251.ausprd01.prod.outlook.com.

[Kyle Hamilton]

So, https://addons.mozilla.org/en-US/firefox/addon/certwatch/ ?

Try using that for a while, and tell me how you think a normal user is
going to react to it.

-Kyle H

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB6251D5B575FFD8981ACC72A6EE84A%40SY4PR01MB6251.ausprd01.prod.outlook.com.

[David Adrian]

There is no mechanism for pinning in the Web PKI. Pinning only makes sense in a subset of the situations in which the client and server are operated by the same entity. This is clearly not the case for Let's Encrypt users.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAH8yC8k8MKg9%2BucQx7fPYJDttuGNm0nt6DwEnkuBSO5bB5Mv5w%40mail.gmail.com.

[Jonathan Kozolchyk]

I'm thrilled to see Let's Encrypt go down this path. At Amazon we found the key to doing this was communication. In addition to our extensive reach outs, we ensured that customers had a temporary option to return to the old ICA with enough time to transition to the new ones before the old one expired.

We at Amazon Trust Services are happy to help Let's Encrypt with their communication plan or offer any advice we can from our experience doing this. We believe unequivocally that this is better for the internet and for our customers.

Amir is right wrt problems with ICA pinning. Intermediates are volatile, they're not under end user control. The baseline requirements prevent a CA creating a contractual agreement to use a specific ICA based on the revocation requirements.

Happy to help with this migration if we can offer guidance,

Jonathan Kozolchyk

Amazon Trust Services

[Peter Gutmann]

Aaron Gable <aa...@letsencrypt.org> writes:

>pinning roots is better than pinning intermediates. And I'll reiterate that
>various Root Programs are moving towards enforcing short intermediate
>lifetimes, so this idea is not just restricted to CAs.

Just a minor nit here, talking about "pinning roots" is a bit of an oxymoron
because they're hardcoded into the trust store and you can't choose to pin
them. If you want to give that any sort of name then perhaps it'd be
supergluing, but pinning, choosing to remember a certificate for future use,
it ain't.

In effect the use of dynamic intermediates kills pinning, because any ability
for the user to remember a known-good certificate for future use is made
impossible.

Peter.

[Dana Keeler]

Just a minor nit here, talking about "pinning roots" is a bit of an oxymoron
because they're hardcoded into the trust store and you can't choose to pin
them.

Maybe I'm misunderstanding what you're saying, but major browsers have had the ability to pin roots for about a decade.