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.
On Wed, Dec 6, 2023 at 1:19 PM Jeffrey Walton <[email protected]> wrote: > On Wed, Dec 6, 2023 at 12:45 PM Aaron Gable <[email protected]> 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 > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAGkh42JOgMruha-5C7R%2BoN3kvdiJE3gh4%3DDspm2Z%3DNRhgJNxhA%40mail.gmail.com.
