Re: [lamps] WGLC for draft-ietf-lamps-norevavail

[Corey Bonnell <[e-mail]>]

Hi Russ,

*	I would be glad to add some text that points out that they are similar, but I do not think that we should do anything to disrupt the way that OCSP ecosystem is working.  Thus, id-ce-noRevAvail is not a substitute for id-pkix-ocsp-nocheck, but it could be used in addition to id-pkix-ocsp-nocheck.

 

Sounds good to me.

 

*	The certification path validation algorithm does not look for revocation of trust anchors, so I do not really see a benefit to putting id-ce-noRevAvail in a self-signed root certificate.

 

A bit of a corner case, but I was thinking of scenarios where the root CA issues itself another root certificate. Certificate-consuming applications implementing the path validation algorithm would accept one of the “root” certificates as a valid intermediate certificate in the path. In this case, the revocation status of the “intermediate” certificate would be queried by the algorithm.

 

Thanks,

Corey

 

From: Spasm <[e-mail]> On Behalf Of Russ Housley
Sent: Wednesday, January 24, 2024 9:42 AM
To: Corey Bonnell <[e-mail]>
Cc: SPASM <[e-mail]>
Subject: Re: [lamps] WGLC for draft-ietf-lamps-norevavail

 

Corey:





I reviewed the draft and think it’s ready. Two non-blocking comments:

 

It would be good to specify how this extension differs from id-pkix-ocsp-nocheck. I *think* the difference is that id-pkix-ocsp-nocheck is appropriate for inclusion in OCSP delegated responder certificates but inappropriate in any other certificate type, whereas id-ce-noRevAvail is appropriate in any end-entity certificate type. This raises the question whether id-ce-noRevAvail is an appropriate substitute for id-pkix-ocsp-nocheck in an OCSP delegated responder certificate. If this document doesn’t address this difference, then perhaps it can be addressed if/when RFC 6960-bis happens.

 

I would be glad to add some text that points out that they are similar, but I do not think that we should do anything to disrupt the way that OCSP ecosystem is working.  Thus, id-ce-noRevAvail is not a substitute for id-pkix-ocsp-nocheck, but it could be used in addition to id-pkix-ocsp-nocheck.





It’s interesting that the ITU-T corrigendum permitting the inclusion of id-ce-noRevAvail in public key certificates constrained this allowance to end-entity certificates. This seems like a potentially useful extension to include in root certificates, as it would be an explicit indicator that revocation information is not available as opposed to the (implicit) signal that no information is available by virtue of the absence of any revocation pointer extension(s).

 

The certification path validation algorithm does not look for revocation of trust anchors, so I do not really see a benefit to putting id-ce-noRevAvail in a self-signed root certificate.

 

Russ