Subject: Re: [lamps] The id-ce-noRevAvail extension

From: Mike Ounsworth <[email-masked]>
Date: Thu, 12 Nov 2020 23:45:19 +0000

> Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going to find the information?

I’m not an OCSP expert, but a certificate without an OCSP AIA may still have an OCSP response stapled in the protocol? I have no personal experience with such a deployment, but I could imagine closed-network PKIs where that makes sense. An id-ce-noRevAvail type cert extension would allow an RP to distinguish between maliciously omitted OCSP responses, and certs that are not intended to have them.

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <[email-masked]> On Behalf Of Ryan Sleevi
Sent: November 12, 2020 4:10 PM
To: Russ Housley <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; LAMPS <[email-masked]>; Erik Andersen <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________

On Thu, Nov 12, 2020 at 4:44 PM Russ Housley <mailto:[email-masked]> wrote:
It's not immediately obvious the value proposition of "affirmatively asserting no" vs the status quo of "definitively not asserting any information source", and under what processing model a client would find it useful or important to distinguish these cases.

The difference is the processing time it takes for the RP to try to find information when the CA knows in advance that there never will be any.

I'm sorry, I think you answered a different question than I was asking, so I'll try to rephrase it using your response. I'm not asking about "why would you use shortlived certificates", I'm trying to understand what you see as the steps the RP takes to "try to find information", if no references to such information are made available to the RP within the certificate.

Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going to find the information?

Is the assumption that the client will be performing LDAP directory checks based on the DN of the cert, as envisaged in X.509v1?
Is the assumption that the client is locally configured to support some local configuration that points to a repository with revocation?

In order for there to be steps that are skipped, there needs to be a statement of what steps are performed. We can "obviously" disable CRLs and OCSP by simply not providing such information in the certificate, so I was hoping you could articulate what other sources of information that might be used by a client where such an affirmative expression would be relevant and necessary.

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 13 Nov 2020 15:18:26 +0000

> I have heard about several application, not in the Web PKI, where a very short lived certificate is being used.  In one extreme case, a key is generated, certified, used for one signature, and destroyed.

I am also aware of a deployment like that; effectively creating one-time-use signing certificates by issuing them with a 60-second lifetime. (Whether it's a good design or not is another question, but the system is very much in use).

---
Mike Ounsworth | Office: +1 (613) 270-2873