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

[Mike Ounsworth <[e-mail]>]

Deb,

> I would not use an extension that clearly states 'OCSP nocheck' for something that isn't OCSP.  It leads to confusion at a minimum.

I’m not the one petitioning here, but I’ll play devil’s advocate. I don’t think that’s quite the right argument. If I have an EE cert for which I know there is no OCSP info available and I want an extension to state that explicitly. That’s clearly OCSP-related, so why is “OCSP nocheck” not appropriate?

I was hoping that 6960 would have strong language about whether id-pkix-ocsp-nocheck is or is not allowed in EE certs, but didn’t find it.

---
Mike Ounsworth

From: Deb Cooley <[e-mail]>
Sent: Tuesday, May 23, 2023 6:25 AM
To: Mike Ounsworth <[e-mail]>
Subject: Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00

The fact that the extension says 'OCSP' in it  and is defined in the OCSP RFC should be enough of a clue.

I would not use an extension that clearly states 'OCSP nocheck' for something that isn't OCSP.  It leads to confusion at a minimum.  The spider web of RFCs is already confusing enough in this space.

Obviously only my opinion.
Deb

On Mon, May 22, 2023 at 3:02 PM Mike Ounsworth <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Deb,

> Please don't overload the OCSP no check extension.  That extension is only for OCSP certs to avoid a circular loop.    Not for end entity certificates.

My question is whether that is sufficiently well-stated in 6960?

---
Mike Ounsworth

From: Deb Cooley <[e-mail]<mailto:[e-mail]>>
Sent: Monday, May 22, 2023 2:01 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Seo Suchan <[e-mail]<mailto:[e-mail]>>
Cc: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-norevavail-00

I haven't read this whole chain, but my ears perked up when this extension was mentioned.

Please don't overload the OCSP no check extension.  That extension is only for OCSP certs to avoid a circular loop.    Not for end entity certificates.

Care needs to be taken here to avoid unintended consequences.  Jumping up to implement the first idea is seldom wise.

On Sun, May 21, 2023 at 1:16 PM Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:
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!eN1XFIDygllmXhilJYCiPQPWDVICeaJUQVQ_XzxdZXSelYUNxb11J1RK7WAkEQTyrVPJFpUwwRo-KH4NN3r4ikEP$>.  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!eN1XFIDygllmXhilJYCiPQPWDVICeaJUQVQ_XzxdZXSelYUNxb11J1RK7WAkEQTyrVPJFpUwwRo-KH4NN5nDwkC9$>
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.