Subject: [Spasm] A generic ocsp-nocheck extension

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Nov 2016 12:24:34 +0100

Hi,

I know this group will probably not want to do this, but just asking for feedback in general

ETSI want to create a mechanism in X.509 certificates to declare that the certificate do not need to be checked for revocation which can be used in any certificate (not just OCSP certificates).

The basic idea is that this extension could be used in situations where the private key is kept under such control that such statement could be done and that the private key is destroyed when no longer used.

This could be the case for example in systems where the private key is generated, used once and then destroyed immediately, but the certificate could be valid for as long as it is needed to validate that one signature.

Any thought about this.
Is this a bad idea?
Could it ever be a task for lamps to define such extension?

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Nov 2016 13:17:09 +0000

https://tools.ietf.org/html/rfc5755#section-4.3.6

Just put that in a public key cert I guess.

S

On 10/11/16 11:24, Stefan Santesson wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Nov 2016 14:53:37 +0100

Hi Stephen,

This is close, but not there.
This extension states that there are no revocation information available.

My extension would not say that. In fact, in the case I’m talking about revocation information would be available in order to support legacy implementations.

My extension would just say: You don’t have to check the revocation information that is available, because this certificate has a private key that is protected against misuse, i.e. because it was destroyed before this certificate was even issued.

/Stefan

On 10/11/16 14:17, "Stephen Farrell" <[email-masked]> wrote:

    
    S

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 06:32:17 +0900

Stefan Santesson <[email-masked]> wrote:
    > My extension would just say: You don’t have to check the revocation
    > information that is available, because this certificate has a private
    > key that is protected against misuse, i.e. because it was destroyed
    > before this certificate was even issued.

Can you give us a real-life example of how this one-time signature key would
be used?

---

From: Michael Jenkins <[email-masked]>
Date: Sat, 12 Nov 2016 20:12:57 -0500

This sounds like a private-label extension; does it really call for
standardization?

In fact, I'd (my certificate-consuming application) would have to have a
VERY strong reason to trust that the private key had been handled in the
expected way, which sort of cries out for a small community of use.

On Thu, Nov 10, 2016 at 6:24 AM, Stefan Santesson <[email-masked]>
wrote:

> ETSI want to create a mechanism in X.509 certificates to declare that the
> certificate do not need to be checked for revocation which can be used in
> any certificate (not just OCSP certificates).
>
> The basic idea is that this extension could be used in situations where
> the private key is kept under such control that such statement could be
> done and that the private key is destroyed when no longer used.
>
> This could be the case for example in systems where the private key is
> generated, used once and then destroyed immediately, but the certificate
> could be valid for as long as it is needed to validate that one signature.
>
>
> Any thought about this.
> Is this a bad idea?

-- 
Mike Jenkins
[email-masked] - if you want me to read it only at my desk
[email-masked] - to read everywhere
443-634-3951

---

From: Russ Housley <[email-masked]>
Date: Sun, 13 Nov 2016 01:11:54 -0500

Stefan:

No revocation information is available.  Does the software need to know the reason that it is not being made available?  Is it sufficient for the CP to state the reason for humans?

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Nov 2016 06:13:14 +0000

I would think that this would allow specific apps to use generic PKI stacks.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Sean Leonard <[email-masked]>
Date: Mon, 14 Nov 2016 01:10:24 +0900

I am not convinced that this semantic change is worth writing a raft of code over, across the world’s crypto implementations.

Also, “private key compromise” is just one reason why a certificate might be revoked. Other reasons include that the privilege has been withdrawn (e.g., “stopped paying”), or the subject’s affiliation changed.

noRevAvail (RFC 5755 Section 4.3.6) is okay; it gets the same result that you are looking for anyway.

Another option is to issue a CRL with a nextUpdate date that is waaaay far in the future, namely, at least the valid notAfter date of the certificate.

Sean

> On Nov 10, 2016, at 10:53 PM, Stefan Santesson <[email-masked]> wrote:
> 
> Hi Stephen,
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 14 Nov 2016 09:54:00 +0100

Thanks for thoughts and questions,

I’ll try to address them all in one go:

Russ, 
As I said, the semantics asked for is NOT that there is no revocation information available.
The semantics discussed is a hint that revocation checking is not necessary.

This may not look like much difference but it is. If revocation is not available, then standard X.509 validators will fail.
With the discussed semantics that would not be the case. Those who are configured to always look for revocation data, would still find it.
The idea here is to allow systems to use the certificate, e.g. for signature validation, even when being off line.

The use case,
I have one specific use case and that is our signature services. They generate a new private key for each signature and validates the signer’s identity at the time of signing. The certificate is generated also at the time of signing. Once this is done, the private key is destroyed. Note that the certificate is not short lived, just the private key is.
Our certificates contains the authn context extension (RFC 7773) so revocation in general is handled on the authentication layer 

Why standardization?
Well, that I also ask myself. It is not my proposal to make this a standard.
But ETSI plans to do this as an EU standard in response to the EU regulation “eIDAS”.
I have so far been critical to the proposal, but if such extension should be standardized, I’d much rather have an IETF extension (made simple and to the point), than a possible over engineered European extension that I have to deal with.

This is why I turn to you.
Either for good arguments to not do this, or possible support for doing an IETF extension.

/Stefan 

On 13/11/16 17:10, "Spasm on behalf of Sean Leonard" <[email-masked] on behalf of [email-masked]> wrote:

    

    Sean