On Tue, Apr 21, 2020 at 8:24 AM Wojtek Porczyk <[email protected]> wrote:
> This statement, snipped from above: > > > This is exactly the sort of case CCADB is supremely positioned to solve, > > efficiently. In fact, all of these problems can be addressed by CCADB > > improvements, providing programmatically readable data while also making > > use of efficiencies and economies of scale. > > makes me curious: do you think CCADB could be leveraged to provide such > a list? To make it recommended (or even mandatory) to link to > CCADB-provided > query mechanism for such documents. To support embedding? No, the goal is to get stuff out, not add stuff. The CCADB absolutely could be the place for CAs to disclose the base URL for such a service, and some CAs already do approaches like this for providing supplemental details of revocation not covered by CRLs/OCSP, but that information doesn’t need to be conveyed in the certificate. The goal here should be moving to a model closer to Secondary Certs or DANE here, or the other drafts in IETF exploring compact certificate profiles, albeit without the CBOR nonsense, in making sure only the essential information is conveyed in band on every connection. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
