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

[Michael StJohns <[e-mail]>]

Suspenders and belt suggests that you may also want to indicate what a 
relying party should do if it receives a non-compliant certificate.

E.g. if I'm offered a cert with the no-check extension, but without the 
id-kp-OCSPSigning what do I do - treat it as a bad certificate, or just 
ignore the extension? Maybe:

"If a certificate does not include the id-kp-OCSPSigning EKU, an 
included id-pkix-ocsp-nocheck extension may be safely ignored by a 
relying party."

Mike


On 5/23/2023 3:32 PM, Mike Ounsworth wrote:
>
> Lol, soapbox indeed.
>
> But that’s fine, right?
>
> id-kp-OCSPSigning without id-pkix-ocsp-nocheck is fine (ocsp-nocheck 
> is one of several mechanisms suggested in 4.2.2.2.1.)
>
> id-pkix-ocsp-nocheck without id-kp-OCSPSigning is NOT FINE.
>
> ---
>
> *Mike*Ounsworth
>
> *From:* Spasm <[e-mail]> *On Behalf Of * Russ Housley
> *Sent:* Tuesday, May 23, 2023 2:26 PM
> *To:* Mike Ounsworth <[e-mail]>
> *Cc:* Tim Hollebeek <[e-mail]>; Seo Suchan 
> <[e-mail]>; LAMPS <[e-mail]>
> *Subject:* Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00
>
> Mike:
>
> I thought about the linkage between the nocheck extension and the OCSP 
> Signing EKU.  I agree that there should not be any certificate that 
> has no check that does not also have the OCSP Signing EKU.  However, 
> given the way that some implementations handle EKU constraints one 
> might find the OCSP Signing EKU without the nocheck extension.
>
> Russ
>
> P.S. Soapbox: 
> https://www.ietf.org/archive/id/draft-housley-spasm-eku-constraints-03.txt 
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-housley-spasm-eku-constraints-03.txt__;!!FJ-Y8qCqXTj2!bHnj-4YuoIQLG222sxpwt8cJKmL-XozMT9e_LDYk8VRyYa5Cmj_i53A0OeQK5_K_2lVsq-hsweeI5AdseIhf-hFREKHp$>
>
>
>
>     On May 23, 2023, at 2:59 PM, Mike Ounsworth
>     <[e-mail]> wrote:
>
>     Also, and this is commentary on the proposed errata: how does a
>     client enforce this? Should we be more precise about what “an OCSP
>     Responder” is? Like
>
>     “A CA MUST NOT include the extension id-pkix-ocsp-nocheck in a
>
>      certificate issued to an entity other than an OCSP Responder (ie
>     that contains the id-kp-OCSPSigning EKU).”
>
>     ?
>
>     ---
>
>     *Mike*Ounsworth
>
>     *From:*Mike Ounsworth <Mike.Ounsworth=[e-mail]>
>     *Sent:*Tuesday, May 23, 2023 1:52 PM
>     *To:*Mike Ounsworth <[e-mail]>; Russ Housley
>     <[e-mail]>; Tim Hollebeek <[e-mail]>
>     *Cc:*Seo Suchan <[e-mail]>; LAMPS <[e-mail]>
>     *Subject:*RE: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00
>
>     I’m curious for Tim to present this change at CA/B and see if
>     anyone freaks out that this will break their super clever use of
>     that extension.
>
>     ---
>
>     *Mike*Ounsworth
>
>     *From:*Spasm <[e-mail]>*On Behalf Of*Mike Ounsworth
>     *Sent:*Tuesday, May 23, 2023 1:50 PM
>     *To:*Russ Housley <[e-mail]>; Tim Hollebeek
>     <[e-mail]>
>     *Cc:*Seo Suchan <[e-mail]>; LAMPS <[e-mail]>
>     *Subject:*Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00
>
>     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]> 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]>*On Behalf Of*Russ Housley
>         *Sent:*Sunday, May 21, 2023 1:16 PM
>         *To:*Mike Ounsworth <[e-mail]>
>         *Cc:*Seo Suchan <[e-mail]>; LAMPS <[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./
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm