Subject: Re: What happened to the OCSPv2 draft?

From: [email-masked] (Peter Gutmann)
Date: Wed, 18 Sep 2002 18:18:23 +1200

Denis Pinkas <[email-masked]> writes:

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

It's nonstandard in that even though there happens to be an RFC which mentions
it (which probably applies to about 75% of everything computer-related, in one
way or another), the standard that everyone uses is IssuerAndSerialNumber, not
IssuerSerial (that is, just because it's mentioned in some standard doesn't
make it "the standard", X9.31 vs.PKCS #1 is one of many, many examples).

>Let us assume that the DN of the CA only contains CN=OpenCA.
>[...]

Well, what I really meant wasn't "Is it possible to hypothesise a situation in
which it could in any way be concievable that IssuerSerial has any real use?"
but rather "Are there real-world situations where this nonstandard construct is
required?".

I strongly suspect the answer is a resounding "No", since if anyone were to
issue certs with incomplete issuer DNs as in the example you gave, civilisation
would collapse... or at least the part of it which depends on PKI would... well
OK, no-one would even notice, but in theory it would be bad.

So my problem with IssuerSerial is that its nonstandard form doesn't solve any
real-world problem, and it opens up a whole raft of new problems because no-one
knows what to do if it contains anything other than an IssuerAndSerialNumber
encoded in an incompatible format.  The result will be one of two things:

1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
   hacks wherever you have to convert it to the standard form.

2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
   interoperates because no-one knows what to do with it.

Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
which removes any ambiguity and uses the standard form.  Option (2)... well,
let's not go there.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 18 Sep 2002 11:41:59 +0200

> which removes any ambiguity and uses the standard form.  Option (2)... well,

I have to strongly agree with Peter here.

Ciao, Michael.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Sep 2002 11:54:40 +0200

Peter,

> OK, no-one would even notice, but in theory it would be bad.

:-)

> real-world problem, 

Since we do not have any name constraints for issuer names, a problem like
the one I described could happen, even if the name included additional
elements. The example was made very simple so that it could be easily
understood.

GeneralNames is defined in RFC 3280 (and X.509) as:

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

with:

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

So if the sequence is reduced to one element and the choice is the tag [4]
then it is easy to place a Name in that structure. I recognize that in most
cases, if the names of the CAs are well chosen, it will not be necessary 
to have more than one element.

Note also that RFC 3281 (maybe not yet a widely used standard) is defining
the issuer using:

            AttCertIssuer ::= CHOICE {
                 v1Form   GeneralNames,  -- MUST NOT be used in this
                                         -- profile
                 v2Form   [0] V2Form     -- v2 only
            }

            V2Form ::= SEQUENCE {
                 issuerName            GeneralNames  OPTIONAL,
                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                   -- issuerName MUST be present in this profile
                   -- baseCertificateID and objectDigestInfo MUST NOT
                   -- be present in this profile
            }

So, if we had to extend OCSPv2 to check the revocation status of an
Attribute Certificate, this would be quite easy to do.

RFC 3281 mandates only one GeneralName which MUST contain a non-empty 
distinguished name in the directoryName field.

:-)

Denis

> and it opens up a whole raft of new problems because no-one

---

From: Michael Ströder <[email-masked]>
Date: Wed, 18 Sep 2002 15:08:11 +0200

> distinguished name in the directoryName field.

So why use GeneralName at all?
Why use an flexible CHOICE data type and then restrict its use to a 
single variant?

=> either the restriction in RFC 3281 is wrong or using the GeneralName 
does not make sense.

If you want to use the flexibility of the CHOICE you have to define 
semantics of all options.

I often repeat this important security advice:
Keep things as simple as possible.

Ciao, Michael.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Sep 2002 15:48:14 +0200

Michael,

> => either the restriction in RFC 3281 is wrong or using the GeneralName

RFC 3281 is backwards compatible with ISO X.509. Since ISO X.509 was using
GeneralNames (see section 12.1 Attribute certificate structure) then 
RFC 3281 has done the same. Otherwise a defect report should be raised to 
ISO, ... which is something you could still do, through an ISO member. :-)

However, I wonder if ISO would accept to consider this as a "defect", 
since the syntax allows to do what you want (using a slightly more complex
encoding).

Denis