[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

[Corey Bonnell]

*	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.

 

It is relevant, as I believe the rationale that all CAs are also technically capable as CRL issuers was used to prohibit the issuance of CRL issuer certificates in SC-62.

 

*	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.

 

There would need to be an allowance for the issuance of CRL issuer certificates added to the BRs to make this possible. Given that the issuance of such certificates will be banned on the SC-62 effective date, it seems reasonable to similarly prohibit the generation of indirect CRLs in SC-63. Of course, SC-63 is Ryan’s ballot, so I’d be interested in hearing his thoughts on the use of indirect CRLs in the WebPKI.

 

Thanks,

Corey 

 

From: Aaron Gable <aaron at letsencrypt.org> 
Sent: Friday, April 28, 2023 1:20 PM
To: Corey Bonnell <Corey.Bonnell at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Ryan Dickson <ryandickson at google.com>
Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

 

On Thu, Apr 27, 2023 at 11:58 AM Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> > wrote:

Hi Aaron,

*	2. The prohibition on "indirect CRLs".

 

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?).

 

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.

 

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.

 

 

*	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.

 

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.

 

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.

 

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.

 

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 :)

 

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230501/a4ab8290/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230501/a4ab8290/attachment-0001.p7s>