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 On Wednesday, December 6, 2023 at 12:05:54 PM UTC-8 Amir Omidi (aaomidi) wrote: > > 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/9013689d-d267-4199-90b1-8b229285610bn%40mozilla.org.
