Subject: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Nov 2020 02:19:51 -0500

Hi LAMPS folks--

Alexey mentioned to me the other day that there might be an X.509v3
extension with the semantics "do not bother checking CRLs (or OCSP?) for
this certificate"

I looked for it, but i couldn't find it.  Can someone identify it for
me?

Regards,

        --dkg

---

From: Matt Palmer <[email-masked]>
Date: Wed, 11 Nov 2020 19:36:52 +1100

> I looked for it, but i couldn't find it.  Can someone identify it for

He may be thinking of id-pkix-ocsp-nocheck, from RFC6960 (s4.2.2.2.1).

- Matt

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Nov 2020 11:07:43 -0500

> On Nov 11, 2020, at 3:36 AM, Matt Palmer <[email-masked]> wrote:
> 

That is used to avoid asking an OCSP responder about it's own certificate.

I suspect Alexey was talking about id-ce-noRevAvail from RFC 3281:

      name           id-ce-noRevAvail
      OID            { id-ce 56 }
      syntax         NULL (i.e. '0500'H is the DER encoding)
      criticality    MUST be FALSE

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Nov 2020 22:57:36 -0500

> That is used to avoid asking an OCSP responder about it's own certificate.

Thanks for the suggestion, Matt!

Russ, are you saying that it would be inappropriate to use it in a
certificate that is not for an OCSP responder?  The semantics do seem
appropriate (as a non-critical extension) for these sample certs, as
there will be no OCSP responder available.

>       criticality    MUST be FALSE

looks like this was defined in "ITU-T Recommendation X.509: The
Directory - Public-Key and Attribute Certificate Frameworks", the
current version of which is at
https://www.itu.int/rec/T-REC-X.509-201910-I/en, but paywalled.

It looks like RFC 3281 (and its successor RFC 5755) both suggest that
id-ce-noRevAvail is appropriate only for Attribute Certificates (ACs).
But all three of these certs are Public Key Certificates (PKCs).  That
seems at least as inappropriate as applying id-pkix-ocsp-nocheck to a
non-OCSP responder.

Maybe i just want to include both extensions in each of the certs, since
the semantics look right (there is neither a CRL endpoint nor an OCSP
responder).  So i'd just ignore the context of both of these pieces of
documentation.

Sound right?

      --dkg

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Nov 2020 09:55:27 -0500

> On Nov 11, 2020, at 10:57 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Correct, but it does not say that no CRL is available.

> https://www.itu.int/rec/T-REC-X.509-201910-I/en, but paywalled.

You are right, it is for attribute certificates.

X.509 says:  This extension shall not be included in public-key certificates or in attribute certificates issued to AAs.

> responder).  So i'd just ignore the context of both of these pieces of

We do not seems to have an extension equivalent to id-ce-noRevAvail for public-key certificates.  With the move toward short lived  public-key certificates, we should probably work with ITU-T to allow its use in any certificate.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Nov 2020 23:36:05 -0500

Alexey, given the discussion in this thread about id-ce-noRevAvail and
id-pkix-ocsp-nocheck, i'm not sure what you would specifically recommend
for the sample certificates.  Can you give me more specific information
about the failures that you saw while experimenting with those certs,
and let me (and the list?) know what extensions you'd like to see set on
the sample S/MIME certificates?

           --dkg