Subject: OCSP identifiers

From: Rich Salz <[email-masked]>
Date: Wed, 15 Nov 2000 20:45:25 -0500

Be careful of sending the entire cert in a status or validity query.  At a
previous employer it became pretty clear (with a patent attorney) that this
violated a patent held by Micali. No, I don't remember the number. But it was
a good thing that the OCSP syntax changed from the -02 draft. :)

As for what identifiers to use, I always thought that requiring the issuer's
cert was onerous, and that sending the hash "for space reasons" was a bogus
argument. I further agree with Gutmann that it required weird indices on the
part of many implementors.

I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to
the point and unique.
	/r$

---

From: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 10:20:58 +0100

> I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to

Rich, you're damn right! But this would be too easy... (Sigh! ;-)

Ciao, Michael.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 11:14:11 +0100

Rich,

> I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to

Not always unique. :-(

... in case of an issuing key compromise. This is not important for queries
about current certificates, but may be important as soon as the query would
be for a certificate which was valid in the past. But the problem could be
twisted in another way: should we really allow to query the status of a
certificate in the past ? If we don't we avoid the problem, and, in such a
case, I agree with you.

Denis

---

From: Rich Salz <[email-masked]>
Date: Thu, 16 Nov 2000 08:32:14 -0500

> Not always unique. :-(
> 
> .. in case of an issuing key compromise.

So what kind of identifier *is* unique in the case of issuer compromise?
The hash of the (subject) cert, provided your query is about a time *before*
the compromise, of course.  Gee, it sure would be convenient if I could ask
about a cert, the issuer, and so on all the way up the chain with a single
query.  Anyone given thought to doing that? :)

Sorry, bad joke.
	/r$

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Thu, 16 Nov 2000 15:08:05 +0100

>certificate in the past ? If we don't we avoid the problem, and, in such a

In my opinion it would be a pity to loose possibility of validating 
certificates back in time.

Nada

> >         /r$

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director,   Entegrity Solutions AB
office: + 46 8 477 77 37,   cell: + 46 70 495 09 03,    fax: + 46 8 477 77 31

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 16:37:16 +0100

Rich, Simon and Mike,

This is a response to you and Simon (Tardell), but also a message for Mike.

> The hash of the (subject) cert, 

No exactly. More precisely : CA name + issuerKeyHash + certicate serial
number + certhash

> provided your query is about a time *before* the compromise, of course.  

This sentence raises an important point. This case may happen, in
particular, if the server is providing information beyond the expiry of the
certificate. In such case (see section 4.4.4  Archive Cutoff) it would be
rather dangerous to use a response, unless the hash of the cert is also
used. But this case would apply, in general, as soon as an issuing key is
compromised.

The server would have to choose between two options:

1° use the certhash, so that certhash comparisons can be done. This means
that the OCSP server would have to know the hash of every certificate. This
precludes to have this service CRL-based, since CRLs do not contain the hash
of each certificate; or 

2° do not use certhash, and apply a fall back solution (similar to, but
different from, the one described in section 2.7): "An OCSP responder MUST
know that a particular CA's private key has been compromised. In such a
case, it MUST return the "revocation status unknown" state for all
certificates issued by that CA." 

Some text additions both in the main sections and the security consideration
section would be appropriate.

> Gee, it sure would be convenient if I could ask

:-)

It is half a joke. 

All the chain up, the hash of each CA certificate would be to be considered
as well. However, starting a thread on that topic, would be, for the time
being, too time consuming for me, so I will not elaborate more.  

Denis