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

[Mike Ounsworth <[e-mail]>]

Awesome.

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Russ Housley
Sent: Tuesday, May 23, 2023 1:28 PM
To: Tim Hollebeek <[e-mail]>
Cc: Seo Suchan <[e-mail]>; LAMPS <[e-mail]>
Subject: 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=[e-mail]<mailto:tim.hollebeek=[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Sunday, May 21, 2023 1:16 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Cc: Seo Suchan <[e-mail]<mailto:[e-mail]>>; LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00

Mike:

Interesting


RFC6960, section “4.2.2.2.1<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc6960*section-4.2.2.2.1__;Iw!!FJ-Y8qCqXTj2!bi4AP-jeHViS93BjOd8QnyeP4SNKwkRxB41odNjHI9eRADjzQrv6bxRkdoqg26cVEf1o0ymsz-zvssr8LsCiZYw0OHYB$>.  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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!bi4AP-jeHViS93BjOd8QnyeP4SNKwkRxB41odNjHI9eRADjzQrv6bxRkdoqg26cVEf1o0ymsz-zvssr8LsCiZf8_jufn$>

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.