Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00

PROPOSED ERRATA for RFC 6960, Section 4.2.2.2.1

OLD:

   - A CA may specify that an OCSP client can trust a responder for the
     lifetime of the responder's certificate.  The CA does so by
     including the extension id-pkix-ocsp-nocheck.  This SHOULD be a
     non-critical extension.  The value of the extension SHALL be NULL.
     CAs issuing such a certificate should realize that a compromise of
     the responder's key is as serious as the compromise of a CA key
     used to sign CRLs, at least for the validity period of this
     certificate.  CAs may choose to issue this type of certificate with
     a very short lifetime and renew it frequently.

     id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

NEW:

   - A CA may specify that an OCSP client can trust a responder for the
     lifetime of the responder's certificate.  The CA does so by
     including the extension id-pkix-ocsp-nocheck.  This SHOULD be a
     non-critical extension.  The value of the extension SHALL be NULL.
     CAs issuing such a certificate should realize that a compromise of
     the responder's key is as serious as the compromise of a CA key
     used to sign CRLs, at least for the validity period of this
     certificate.  CAs may choose to issue this type of certificate with
     a very short lifetime and renew it frequently.

     id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

    A CA MUST NOT include the extension id-pkix-ocsp-nocheck in a
    certificate issued to an entity other than an OCSP Responder.

Russ

> On May 23, 2023, at 11:34 AM, Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote:
> 
> Would it be useful to clearly and explicitly state this unstated assumption somewhere, perhaps in an errata?
>  
> “id-pkix-ocsp-nocheck SHALL NOT appear in a certificate unless that certificate is a delegated OCSP responder” would probably be a good thing to have stated somewhere. 
>  
> I suppose it could be added to the CABF BRs as well.  They have the same bug (the BRs require nocheck in delegated OCSP responders, but don’t prohibit it elsewhere).
>  
> -Tim
>  
> From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> On Behalf Of Russ Housley
> Sent: Sunday, May 21, 2023 1:16 PM
> To: Mike Ounsworth <Mike.Ounsworth@entrust.com <mailto:Mike.Ounsworth@entrust.com>>
> Cc: Seo Suchan <tjtncks@gmail.com <mailto:tjtncks@gmail.com>>; LAMPS <spasm@ietf.org <mailto:spasm@ietf.org>>
> Subject: Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00
>  
> Mike:
>  
> Interesting
>  
> RFC6960, section “4.2.2.2.1 <https://www.rfc-editor.org/rfc/rfc6960#section-4.2.2.2.1>.  Revocation Checking of an Authorized Responder”
>  
> “A CA may specify that an OCSP client can trust a responder for the
>      lifetime of the responder's certificate.  The CA does so by
>      including the extension id-pkix-ocsp-nocheck”
>  
> Are you allowed to put an id-pkix-ocsp-nocheck extension in end entity certs? If so, what does that mean?
>  
> My reading of the description is that id-pkix-ocsp-nocheck should only appear in a certificate issued to an OCSP responder.
>  
> Russ
>  
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org <mailto:Spasm@ietf.org>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>