<div dir="ltr"><div dir="ltr">On Thu, Apr 27, 2023 at 11:58 AM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-9140975051831530318"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-9140975051831530318WordSection1"><p class="MsoNormal">Hi Aaron,<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="m_-9140975051831530318MsoListParagraph" style="margin-left:0in">2. The prohibition on "indirect CRLs".<u></u><u></u></li></ul><p class="MsoNormal" style="margin-left:0.25in"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.25in">Every CA certificate in the WebPKI MUST assert the cRLSign key usage bit, so that CA is also a CRL issuer (RFC 5280, section 4.1.2.6 says “If the subject is a CRL issuer (e.g., the key usage extension, as discussed in Section 4.2.1.3, is present and the value of cRLSign is TRUE)”). Additionally, I don’t believe there’s currently any mechanism in use in the WebPKI to distribute CRL issuer certificates, so I thought it would be reasonable to propose explicitly prohibiting indirect CRLs (why allow something that cannot be consumed by commonly used RP software?).</p></div></div></div></blockquote><div><br></div><div>The CRL would point at its own issuer (the Delegated CRL Signer) via the Authority Information Access extension in the CRL itself. Additionally, each revoked certificate entry in the CRL would include the Certificate Issuer extension, pointing at the certificate's issuer. I admittedly do not know how many CRL consumers are capable of AIA chasing, but the mechanism is definitely there for them to use if they want to. RFC 5280 Section 5.1.1.3 specifies that CRL consumers MUST support checking when the cert and crl issuers are the same, and SHOULD support path-building when the cert and crl issuers are different.</div><div><br></div><div>The fact that every WebPKI CA is also a CRL issuer is irrelevant to this case -- the point would be that only "less valuable" (i.e. not technically capable of certificate issuance) key material would need to be transported between secure sites after ceremonies.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-9140975051831530318"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-9140975051831530318WordSection1"><p class="MsoNormal" style="margin-left:0.25in"><u></u><u></u></p><p class="MsoNormal" style="margin-left:0.25in"><u></u> <u></u></p><ul style="margin-top:0in" type="disc"><li class="m_-9140975051831530318MsoListParagraph" style="margin-left:0in">But Let's Encrypt has been considering the possibility of using delegated signers in order to keep separate sets of issuing intermediates in each secure site, but still have every site capable of providing revocation information on behalf of all issuing intermediates.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.25in">Would the root CA issue a CRL issuer certificate to issue CRLs on behalf of one or more intermediate CAs? Trying to envision how this would work without having to fetch a bunch of certificates to validate the CRL back to a trust anchor.</p></div></div></div></blockquote><div><br></div><div>The idea would be to generate a certificate which *only* has the cRLSign Key Usage. It would be issued directly from the intermediate, like a Delegated OCSP Responder. It would assert cA: false, and be technically incapable of doing anything except for creating CRLs.<br></div><div><br></div><div>To be clear, this is definitely just an idea we've been bouncing around so far. We haven't done research into its feasibility. There may be a restriction which means this idea wouldn't work anyway, and we just haven't thought of it yet.</div><div><br></div><div>And I think this is probably the least important of my three points, so I want to make sure the discussion doesn't focus solely on this :)</div><div><br></div><div>Aaron</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-9140975051831530318"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-9140975051831530318WordSection1"><p class="MsoNormal" style="margin-left:0.25in"><u></u></p></div></div></div></blockquote></div></div>