Subject: Re: What happened to the OCSPv2 draft?

From: [email-masked] (Peter Gutmann)
Date: Tue, 17 Sep 2002 20:45:49 +1200 (NZST)

Denis Pinkas <[email-masked]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,
>        serialNumber             CertificateSerialNumber
>   }

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

>>At this stage, given the work that has gone in OCSPv1, I don't think it is
>>worthwhile digging up this controversy again. The current option works fine
>>for OCSP as long as you aren't asking OCSP to also do path creation for you.
>>If you have already created one or more certificate chains, it isn't very
>>hard to figure out the CA's public key for any certificate in that chain.
>
>No. Precisely for the reverse argument that I have used : when you do not
>have already created one or more certificate chains, it is very hard to
>figure out the CA's public key for any certificate in that chain.

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 17 Sep 2002 12:48:36 +0200

Peter Gutmann wrote:
> look at the cert details.

Well, one of the problems with current fingerprint implementations is 
that some implementations use MD5 and some use SHA-1...

But this can be easily fixed by making use of SHA-1 mandatory.

> to work with and easy to get right.

+1

Ciao, Michael.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 14:17:00 +0200

Peter,

> Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?

This is the one defined in RFC 2634, so I would not qualify it as a
"nonstandard variation".

This structure is useful in some cases. See below.

> I can think of many situations in which (say) a

GeneralNames is defined in X.509 as:

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

> IssuerAndSerialNumber won't?

IssuerAndSerialNumber is defined in RFC 2630 as:

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer          Name,
        serialNumber    CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

Paul Hoffman, the editor, would certainly be in a better position to
respond. Since RFC 2634 was created after RFC 2630 there must be a good
reason.  

Let me try to explain. Let us assume that the DN of the CA only contains 
CN=OpenCA.

Let us assume that a certificate for OpenCA is issued by a CA with a DN 
that only contains CN=LawyersCA

Let us assume that another certificate for OpenCA is issued by a CA with 
a DN that only contains CN=NotariesCA
  
You got it: to make sure that you are referencing the right certificate, 
a sequence of DNs is needed, so that the names of the upper CAs can be
included.

The hash can tell you that you got a wrong certificate, but will not help
you to look for the good one.

I would agree that it is likely to be an exceptional case, but this gives
some flexibility.

Denis

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 17 Sep 2002 12:55:35 -0700

>respond. Since RFC 2634 was created after RFC 2630 there must be a good

They were issued at the same time. 2630 chose to continue importing 
"Name" from X.501; 2634 chose to import GeneralNames from PKIX.

2630 is obviously much more widely implemented than 2634.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 17 Sep 2002 16:21:10 -0400

Paul:

People complained about these imports.  The ASN.1 modules associated with 
the X.500 series of recommendations are considered harder to obtain.  They 
also have a much more complex import structure.  Due to this feedback from 
implementors, RFC 3369 (the son-of-rfc2630) imports from the PKIX ASN.1 
modules.

Russ

At 12:55 PM 9/17/2002 -0700, Paul Hoffman / IMC wrote:

>They were issued at the same time. 2630 chose to continue importing "Name" 
>from X.501; 2634 chose to import GeneralNames from PKIX.
>