Subject: Re: OCSP I-Ds going forward

From: [email-masked] (Peter Gutmann)
Date: Wed, 27 Nov 2002 19:22:26 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:

>                                             However, two CAs
>     might have the same DN and be certified under different
>     branches of a certification tree.

There is a special name for a PKI of this kind.  It's called "Broken" or
"Defective".

It is not the job of OCSP to fix defective PKIs.

>IssuerAndSerialNumber used alone does not work.

You'd better quickly tell the S/MIME guys that the universal cert ID they've
been using for 10+ years doesn't work then.  Since it's been deployed to
almost every desktop on the planet (via Outlook, Netscape, etc etc), it'll
come as quite a shock to them.

I'm sure all the other standards authors and implementors will also be quite
surprised to find that the IDs they've been using for years don't work.

>Now, let me also explain why using certHash alone does not work: it cannot
>work when the OCSP responder is *only* using CRLs, since certHash cannot be
>computed in that case (there is simply no access to the full certificate !).

But it works just fine when the responder also uses cert hashes.

>Since clients are ignorant of the information used by the OCSP responder in
>the back office, they MUST always provide an unambiguous reference.

Actually few clients are ignorant of who they're talking to (I can't say *all*
clients are, but the deployments I know of, the clients know exactly who/what
the responder is and is capable of).  In cases like this, you don't need a
great pile of gobbledigook, just a simple, standard ID.

To explain the purpose behind the pseudo-draft:

Originally I posted it to point out my exasperation at the fact that after
2(?) years of work on this, OCSPv2 still hadn't quite managed to do a
cut&paste reference to a few widely-used cert IDs from other standards.
However, having now received private mail from a few people with similar
sentiments, I'll go ahead and post it as a real draft.  It's only a little
informational thing, so people can use that while they wait a few more years
until OCSPv2 in its infinite perfection and slendor finally appears.

Since it wasn't meant as a real draft, I'll go through and clean it up a bit
to make it publishable.  One thing which someone pointed out is that the IDs
should really be a SEQUENCE rather than a CHOICE, so that the responder can
choose which it wants to use if the client supplies more than one ID.  For
example, one tinkertoy device I know of (and whose developers better not be on
this list :-) uses the certHash (that's the example I used which populates a
pre-generated ID with a fixed hash value, because it can't do anything else),
whereas others may be able to supply more ID values.  The new text is attached
at the end of this message.

Someone also took me to task over the validity of my HHGTG reference.  For
those not familiar with it, asking Eddie the Shipboard Computer for tea
produces something almost, but not quite, entirely unlike what was asked for,
now matter how many times you ask for it.  Their opinion was that this was
more like watching the Golgafrinchans trying to invent the wheel.  After some
consideration I agree with this point of view.

Peter (arrghh!  All I want is a standard cert ID to use with OCSP queries.
       How hard can that possibly be, it's something that every other
       cert-using standard has had sorted out for years).

-- Snip --

2. SensibleIdentifier

This OCSP extension is used to identify the certificate being queried in a
simple, straightforward, and standard manner.  When a compliant
implementations encounters a request containing this identifier, it SHOULD
ignore whatever gobbledigook may be present in the OCSP reqCert field (it's
hard to tell what this will be, since it changes at random on every draft) and
use the SensibleIdentifier instead.

id-pkix-sensibleIdentifier OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 3029 3 1 4 }

SensibleIdentifier ::= SEQUENCE {
    issuerSerial      IssuerandSerialNumber,
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    certificate       Certificate OPTIONAL,
    certHash          OCTET STRING OPTIONAL,
    ...
    }

2.1. SensibleIdentifier usage

The identifier is composed of a sequence of values, not all of which need to
be provided.  The sole mandatory identifier is the issuer and serial number
combination, because of its wide deployment and acceptance via S/MIME and
because the combination of issuer DN and certificate serial number allows CRL-
based responders to locate the certificate.

The remaining values are optional and may be provided for the responder to use
on an opportunistic basis.  In cases where the client is aware that the
responder will utilise a particular identifier or requires certain properties
(for example those of the keyIdentifier), they are encouraged to use the
appropriate ID.  Conversely, if the client capabilities or bandwidth are
limited, unneeded fields may be omitted.

[I'm not entirely happy with that any more, since it breaks the dump-a-
 certhash-in-a-prebuilt-query model.  This also breaks the requirement that
 "The responder SHOULD include the identifier used in its signed response to
 allow the client to verify that the correct identifier has been used" since
 the issuerAndSerialNumber may not be available at the responder.
 Suggestions?]

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 27 Nov 2002 09:22:17 -0500

Peter,

You are, of course, correct.  I'm just surprised to see an ideological
principle being articulated by a pragmatist such as yourself.

One problem, even within a centrally-administered PKI such as the DoD's,
is that there are advocates for putting local (non-unique) distinguished
names in certificates.  Unfortunately, what are two local contexts one
month can become a single context with colliding DNs the next, so if a
PKI is to remain un-broken when that happens, it must ensure not only
its own name uniqueness but the uniqueness of all other PKIs with which
any RP might expect it to interoperate.

X.509 provides the tools (name constraints) to enforce uniqueness across
cooperating but independent PKIs.  But how many of the CAs in just the
Microsoft and Netscape trust lists subscribe to the idea that they
must cooperate to the extent of using DNs only from a global
DIT?  To avoid defective PKIs, there must be a global namespace even
though there will never be a Global Directory.

I can think of only one way that that might happen: require every CA
that wants to join the "Unbroken PKI" to have an RFC 2247 (DC)
distinguished name instead of the old C=x, O=y.

Do you think that's likely to happen?
Do you think there's a different coordination mechanism that's likely
  to happen?
Do you really think OCSP (and S/MIME) should just shrug their shoulders
  and say "not my problem"?

Dave

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 27 Nov 2002 09:24:08 -0800

Peter,

I agree with your views re: issuerAndSerialNumber.  In general,
since this is an IETF WG after all, we should be first focused
on supporting other IETF work that relies on PKI and PKIX.
Conversely, I think it only fair that the consituency Denis'
formulation addresses deserves WG consideration as well.  That's
why, in the draft-ietf-pkix-ocsp-core-00.txt document I recently
sent to Internet Drafts there's

ReqCert ::= CHOICE {
   certID                    CertID,
   issuerSerial              [0] IssuerAndSerialNumber,
   fullCert                  [1] FullCertificate,
   certIdWithSignature       [2] CertIdWithSignature }

Perhaps, as you say, it should be SEQUENCE.  The only issue I
have with that is that to my recollection and understanding of
ASN.1 details the above CHOICE allows backwards interoperability
with v1 envirionments via use of the CertID choice because
there's no change in ASN.1 type tags in that instance.  I'm no
ASN.1 expert.  I mostly fake it from worked examples.  But might
the following achieve both objectives?

ReqCert ::= CHOICE {
   certID                    CertID,
   other                     [0] SEQUENCE . . . }

Meanwhile I'm putting the finishing touches on the Servives and
Extensions document (i.e. draft-ietf-pkix-ocsp-services-00.txt).
That delay is mostly a systems engineering matter of parsing
through the DPV/DPD requirements in RFC3379 to ensure
compliance.

With any luck at all, this work will bring a degree of coherence
and closure to our invention of this wheel.

Mike

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 27 Nov 2002 14:31:06 -0500

Michael,

Please include the certHash choice alternative or optional component of
this type in the OCSP solution. Others depend on this alternative in the
definition as an easy means of identifying a certificate. And please use
OCTET STRING instead of BIT STRING or REAL or some other
type for this value.

This from http://www.normos.org/ietf/rfc/rfc2634.txt in 1999

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

And this from http://www.normos.org/ietf/rfc/rfc3126.txt September 2001

   OtherCertID ::= SEQUENCE {
        otherCertHash            OtherHash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   OtherHash ::= CHOICE {
       sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
       otherHash OtherHashAlgAndValue
   }

   OtherHashValue ::= OCTET STRING

   OtherHashAlgAndValue ::= SEQUENCE {
     hashAlgorithm  AlgorithmIdentifier,
     hashValue      OtherHashValue
   }

The later is what is now used in X9.73 CMS, soon to be
published. It is the only choice alternative supported in
OASIS XCBF and X9.84.

Phil

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 27 Nov 2002 11:37:11 -0800

Phil,

Thanks for the attention.  I will put this into what is quickly
becoming core-01.  By the way, is my ASN.1 reasoning correct?

Mike

> -----Original Message-----
> From: Phillip H. Griffin [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 11:31 AM
> To: Michael Myers
> Cc: Peter Gutmann; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: OCSP I-Ds going forward
>
>
> Michael,
>
> And this from
> http://www.normos.org/ietf/rfc/rfc3126.txt September 2001
>

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 27 Nov 2002 16:37:45 -0500

Michael,

Also, ...

> SNIP

>> there's no change in ASN.1 type tags in that instance.  
>
Yes, you can add new tagged choice alternatives without impacting the
existing encodings. Each tag must be unique for the ASN.1 to be valid.
Often, uniqueness can be achieved most easily using context specific
tagging such as [0], [1], and [2] shown above.

>> I'm no
This would work too for the certID choice alternative to be undisturbed,
but this adds an additional layer of tagging for the issuerSerial 
alternative.

Phil

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 27 Nov 2002 23:12:03 +0100 (CET)

In message <[email-masked]> on Wed, 27 Nov 2002 09:22:17 -0500, "David P. Kemp" <[email-masked]> said:

dpkemp> One problem, even within a centrally-administered PKI such as
dpkemp> the DoD's, is that there are advocates for putting local
dpkemp> (non-unique) distinguished names in certificates.
dpkemp> Unfortunately, what are two local contexts one month can
dpkemp> become a single context with colliding DNs the next, so if a
dpkemp> PKI is to remain un-broken when that happens, it must ensure
dpkemp> not only its own name uniqueness but the uniqueness of all
dpkemp> other PKIs with which any RP might expect it to interoperate.

Let's make it really easy: as far as I understand how a PKI built upon
X.500 (that is, where X.509 certificates are used), if there are two
separate entities having the same DN, you have a problem (to put it
kindly.  Peter is more accurate when saying "broken").  I can see
that as a reason to actually use RDNs like ST= and L=.

And this doesn't just become a problem for OCSP, it becomes a problem
any time you want to do path construction and validation that has a
higher complexity that checking among a bunch of certificate that
happen to be in a local database or in memory.

dpkemp> X.509 provides the tools (name constraints) to enforce
dpkemp> uniqueness across cooperating but independent PKIs.  But how
dpkemp> many of the CAs in just the Microsoft and Netscape trust lists
dpkemp> subscribe to the idea that they must cooperate to the extent
dpkemp> of using DNs only from a global DIT? 

I just took a quick peek at the list of roots in IE, and I saw no
conflicts (although some DNs are horrible).  I would believe that
anyone who can read and understand what a PKI is supposed to look like
will choose a DN that has a great chance of being unique in a global
namespace.  I think that would fall within the concept of self-
preservation.

dpkemp> I can think of only one way that that might happen: require every CA
dpkemp> that wants to join the "Unbroken PKI" to have an RFC 2247 (DC)
dpkemp> distinguished name instead of the old C=x, O=y.

Or use L=, ST= and so on.  Someone with a name like C=x, O=y is rather
bold, or big enough to warrant such a DN.

dpkemp> Do you really think OCSP (and S/MIME) should just shrug their shoulders
dpkemp>   and say "not my problem"?

Yes.

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Khaja Ahmed" <[email-masked]>
Date: Wed, 27 Nov 2002 21:03:44 -0800

> dpkemp> (non-unique) distinguished names in certificates.

I wonder if these advocates are just trying to see if the boys are awake and
paying attention :-)  Jokes aside if there is a case to be made for allowing
this, I would love to see it made on the list.

Absent that, in the spirit of warnings not to pour hot coffee in your lap or
immerse printers in water we should consider explicitly prohibiting this
behavior.  i.e. we PKIX should make uniqueness of CA DNs in a hierarchy a
MUST.  Conformant applications and services also should be required to have
unique CA DNs in their trust list.  Something for the authors of the new
2527 to consider would be addition of some language covering this.

Khaja

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Wednesday, November 27, 2002 2:12 PM
> To: [email-masked]
> Cc: [email-masked]
> In message <[email-masked]> on
> Wed, 27 Nov 2002 09:22:17 -0500, "David P. Kemp"
> <[email-masked]> said:
>