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

[Aaron Gable]

On Thu, Apr 27, 2023 at 11:58 AM Corey Bonnell <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/20230428/91b9fa93/attachment.html>