> 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. On Wednesday, December 6, 2023 at 1:21:30 PM UTC-5 Ryan Hurst wrote: > > 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 > > On Wed, Dec 6, 2023 at 5:27 AM Peter Gutmann <pgu...@cs.auckland.ac.nz> > wrote: > >> 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. >> >> -- >> 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 >> . >> > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/00ef2e2b-2f49-4db0-a3de-50144db52357n%40mozilla.org.
