Subject: RE: What's in a Name?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 13 Jul 2005 11:25:10 -0700

Also, we need to avoid including the issuer DN twice, for one reason, it
is fairly big; another reason is if you include two copies of the same
value, what if they do not match and how to match them?

<disclaimer>this seems to be handled in -26, hats-off</disclaimer>

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2005 11:13 AM
To: Nicolas Williams; Liqiang(Larry) Zhu
Cc: Chaskiel M Grundman; [email-masked]
Subject: Re: What's in a Name?

On Wednesday, July 13, 2005 01:02:40 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Wed, Jul 13, 2005 at 10:58:07AM -0700, Liqiang(Larry) Zhu wrote:
>> Nicolas Williams wrote:
>> > To me it seems reasonable.  A CHOICE perhaps?
>>
>> Not a CHOICE. We should allow the sender to include both, in order to
>> maximize interoperability.
>
> If that's what you want then both IssuerAndSerial MUST be present and
> SubjectKeyIdentifier MUST be present when the cert in question has
that
> extension.

I agree with Larry; this should not be a CHOICE; it should be two
separate 
items in the SEQUENCE.  Both of these should be "OPTIONAL" in the ASN.1 
sense, but I think that we need to REQUIRED (in RFC2119 sense) that at 
least one of them be present, because a Name is not sufficient to select
a 
correct certificate from among several which might belong to the same
CA.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 14:28:34 -0400

> <disclaimer>this seems to be handled in -26, hats-off</disclaimer>

No one suggested including the issuer DN twice.
The DN in IssuerAndSerialNumber is the issuer DN.
The only other Name we've been talking about would always be a subject DN

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 14:33:23 -0400

> <disclaimer>this seems to be handled in -26, hats-off</disclaimer>

I forgot to respond to this part.

-26 includes slots for a subject DN, a subjectKeyIdentifier, and a _bare_ 
serial number, without the issuer DN.  This doesn't solve anything.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Jul 2005 13:34:17 -0500

> <disclaimer>this seems to be handled in -26, hats-off</disclaimer>

Hmm, yes, it looks that way.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Jul 2005 13:34:45 -0500

> The only other Name we've been talking about would always be a subject DN

In AD-VERIFIED-CAs this means including Names twice....

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Jul 2005 13:35:21 -0500

> serial number, without the issuer DN.  This doesn't solve anything.

For AD-VERIFIED-CAs it does...

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 14:43:34 -0400

On Wednesday, July 13, 2005 01:35:21 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> -26 includes slots for a subject DN, a subjectKeyIdentifier, and a
>> _bare_  serial number, without the issuer DN.  This doesn't solve
>> anything.
>

Hrm.  Yes, I suppose it does, in that you have the whole chain and so can 
construct "IssuerAndSerialNumber" from this cert's serial number plus the 
DN of the previous cert.  Ugh.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Jul 2005 13:59:12 -0500

> DN of the previous cert.  Ugh.

Sure, constructing any of these values kinda suck -- but that's the
thing: this way you don't have to.  Certs don't come with
IssuerAndSerial -- they have an issuer (Name) and a serial number
(INTEGER).

Nico
--