Re: [Add] Potential erratum in RFC 8484

[Russ Housley <[e-mail]>]

Martin:

> In Section 10, the following text is wrong:
> 
>> The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers or Authority Information Access (AIA) for Certificate Revocation List (CRL) fetching (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.  
> 
> The OCSP part is fine, but the AIA piece is whacky.
> 
> For context, there are three different ways (to my knowledge) that a client might make outbound connections in order to validate or build a certification path.
> 
> 1. CRL - this is a simple fetch of CRLs from the designated location.  This rarely happens any more as it is grossly inefficient, but it could happen in theory.  
> 
> 2. OCSP - this is an OCSP query for the status of a certificate.
> 
> 3.  AIA chasing - this is where the TLS handshake doesn't include the full set of certificates required to validate the end-entity certificate, but the certificate includes a URL for that certificate.
> 
> AIA itself is a multi-purpose field.  It can include multiple elements, one of which is the identity of an OCSP responder (the same one used in (2) above) and the other being the one used in (3).  It does not include CRL distribution points, as the text implies.

Agree.  In the referenced text, AIA provides the location of the OCSP responder, and CRL Distribution Points extension provides the locations the CRL (or in rare cases the multiple CRLs for different scopes) can be obtained.

> Corrected text might read like:
> 
>> The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers, Certificate Revocation List (CRL) distribution points (see Section 4.2.1.13 of [RFC5280]), or Authority Information Access (AIA) to retrieve issuer certificates (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.
> 
> Or the version without CRLs:
> 
>> The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers or Authority Information Access (AIA) to retrieve issuer certificates (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen.
> 
> It's a little embarrassing to note this error given how active I was in drafting the original text.  In my defense, I found a version of this error in the -05 draft, so it evaded notice for quite some time.

There are non-Web PKI situations where CRLs are used.  So, I prefer the first alternative.

Russ