On Wed, Dec 06, 2023 at 01:19:28PM -0500, Jeffrey Walton 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.
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 -- 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/46c50998-dca2-4ce6-99ac-538c202b9f30%40mtasv.net.
