> Why is this compression scheme likely to take off when there was no interest > in pursuing my proposal or that of Rob Straddling ten years ago?
Hi Phill. Our 2014 I-D [1] tackled CRL compression, whereas the new proposal [2] that Watson referred to tackles WebPKI Certificate compression. FWIW, whilst there was interest here in pursuing our proposal [3], Mozilla ultimately achieved the same result by implementing CRLite [4] instead. [1] https://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/ [2] https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1111613 [4] https://blog.mozilla.org/security/2020/01/09/crlite-part-2-end-to-end-design/ ________________________________ From: [email protected] <[email protected]> on behalf of Phillip Hallam-Baker <[email protected]> Sent: 30 July 2023 04:35 To: Watson Ladd <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Minimum issuance volume for established CAs? CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Which compression scheme is this? Why is this compression scheme likely to take off when there was no interest in pursuing my proposal or that of Rob Straddling ten years ago? I am not sure why the number of CAs would lead to issues either. Please explain. On Sat, Jul 29, 2023 at 11:31 PM Watson Ladd <[email protected]<mailto:[email protected]>> wrote: Dear DSP participants, Recently at the IETF a novel compression scheme for certificates was put forward. This compression scheme depends on a dictionary based on all CA certificates and intermediates. The presence of many small CAs expands this dictionary, and the benefit of small CAs is small. Small CAs have other costs: they are unlikely to have the resources to comply with more intrusive security measures or staff that can execute the tasks required when these measures fail. Meanwhile they have the same capacity to damage the security of the webPKI as much more well resourced ones. At the same time todays small CA is tomorrow's giant and refuge should we need to distrust a big CA. I'd like to propose that any CA that has existed for five or more years whose annual issuance volume is under 2,000 EE certs be distrusted. To avoid injuring subscribers this distrust is "mild": all existing issued certs are fine, and the entity can handle all but the BR validation for specified intermediate of a bigger CA. This prevents the user community of the CA from being left high and dry. I haven't counted how many would be affected. For clarity I think this should only be for TLS server auth mainly because that's the highest risk kind of CA. I realize this is an inevitably controversial proposal, (I called it a can of worms at the mic) but the guidelines already ask for a balancing task between the value to users and the risk posed by a CA. I don't think we should be afraid to put some numbers on. Sincerely, Watson Ladd -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a93695d0-d3a0-45a8-af55-7cbe0a81fd8dn%40mozilla.org<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a93695d0-d3a0-45a8-af55-7cbe0a81fd8dn%40mozilla.org?utm_medium=email&utm_source=footer>. -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwg2fj6pP-zmktoVPyifaWQ0mQTz3ZoMW4Ld358ScRWYKA%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwg2fj6pP-zmktoVPyifaWQ0mQTz3ZoMW4Ld358ScRWYKA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/MW4PR17MB47299CAC826286017540EDECAA08A%40MW4PR17MB4729.namprd17.prod.outlook.com.
