Subject: RE: What's in a Name?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 12 Jul 2005 13:01:51 -0700

The TD-TRUSTED-CERTIFIERS in -26 uses simply TrustedCA, which contains
the CA's DN, you can optionally include the serial #, or
subjectKeyIdentifier if you want to avoid using serial #s in Martin's
scenarios.

The TD-INVALID-CERTIFICATES contains only IssuerAndSerialNumber, and I
agree with you this is required.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Tuesday, July 12, 2005 12:53 PM
To: Liqiang(Larry) Zhu; [email-masked]
Cc: [email-masked]
Subject: RE: What's in a Name?

On Tuesday, July 12, 2005 12:20:18 PM -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> Jeffrey Hutzelman wrote:
>> However, both TD-TRUSTED-CERTIFIERS and TD-INVALID-CERTIFICATES need
> the
>> ability to uniquely identify a particular certificate, so for these
> cases > the IssuerAndSerialNumber needs to be REQUIRED.
>
> subjectKeyIdentifier is sufficient to identify the cert for all
> practical purposes.

Are you suggesting adding a subjectKeyIdentifier to the SEQUENCE?
Should this be REQUIRED instead of IssuerAndSerialNumber?
Or should both be REQUIRED?
Or should the requirement be "MUST have at least one"?

Or are you suggesting that IssuerAndSerialNumber be removed entirely?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jul 2005 16:50:47 -0400

> agree with you this is required.

We're not talking about -26.  These types have changed several times in the 
last several versions of the document, and not as the result of any WG 
consensus.  We are trying to determine what they _should_ look like, and 
then we'll update the document to match.

I don't care what TrustedCA looks like.  I care what TD-TRUSTED-CERTIFIERS, 
and TD-INVALID-CERTIFICATES, and ADInitialVerifiedCAs need to look like. 
Not what they look like in your latest reaction to an isolated comment, but 
what they need to look like based on a real consensus.

Personally, I think we can end up defining all of these the same way, and 
that it will be a lot more convenient to do so.  TrustedCA is a tool for 
doing that, but it is only a tool.  If it doesn't do what we need, we'll 
change it.  If it turns out we don't want to define all three lists the 
same way, then we may end up punting TrustedCA entirely.

So, let's go back a step...
I'm going to try to ask questions in more detail.  Answers from all parties 
are encouraged...

For TD-INVALID-CERTIFICATES:
- Do you agree that IssuerAndSerialNumber needs to be REQUIRED?
- Do you also agree with Martin that having a Name here can be useful?
- Does anyone object to making the Name at least RECOMMENDED?
- Does anyone object to making the Name be REQUIRED?
- Martin (or others), is making the Name RECOMMENDED sufficient?
- Does anyone believe this case needs some additional type, besides an
  IssuerAndSerialNumber or a Name?

For TD-TRUSTED-CERTIFIERS:
- Do you agree that we need to identify a specific trust anchor, and not
  just the DN of some root CA?  If we don't have agreement on this, then
  we need to resolve it before we can usefully talk about the rest.
- Do you agree one of IssuerAndSerialNumber or SubjectKeyIdentifier needs
  to be REQUIRED?
- Do you have a preference for which one is REQUIRED?  Why?
- Should the not-required one be RECOMMENDED or OPTIONAL or not present?
- Do you agree with Martin that having a Name here can be useful?
- Does anyone object to making the Name at least RECOMMENDED?
- Does anyone object to making the Name be REQUIRED?
- Martin (or others), is making the Name RECOMMENDED sufficient?
- Does anyone see a reason for a raw serial number?
- Does anyone believe this case needs some additional type, besides Name,
  IssuerAndSerialNumber, or SubjectKeyIdentifier?

For AD-INITIAL-VERIFIED-CAS:
- Do you agree a Name is sufficient, and should be REQUIRED?
- Do you agree with Nico that having an IssuerAndSerialNumber would be
  useful, in order to allow applications to do their own CRL lookups(*)?
- Should IssuerAndSerialNumber be REQUIRED, RECOMMENDED, OPTIONAL, ???
- Does anyone believe this case needs some additional type, besides Name,
  IssuerAndSerialNumber, or SubjectKeyIdentifier?

Given some answers to these questions, maybe we can reach convergence.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Jul 2005 16:24:58 -0500

> - Do you agree that IssuerAndSerialNumber needs to be REQUIRED?

That or SubjectKeyIdentifier.  Note though that leaf certs may not have
a SubjectKeyIdentifier.

> - Do you also agree with Martin that having a Name here can be useful?

Yes (where the client doesn't have the whole cert chain).

> - Does anyone object to making the Name at least RECOMMENDED?

No.

> - Does anyone object to making the Name be REQUIRED?

No.

> - Martin (or others), is making the Name RECOMMENDED sufficient?

I think so, but see no reason not to make it REQUIRED, and it should be
present where the client did not send the whole cert chain, which means
it's just as well to make it REQUIRED.

>  IssuerAndSerialNumber or a Name?

SubjectKeyIdentifier will do as well as IssuerAndSerialNumber, for CA
certs.

>  we need to resolve it before we can usefully talk about the rest.

Agreed.

> - Do you agree one of IssuerAndSerialNumber or SubjectKeyIdentifier needs

One, the other or both.  I don't care.

I assume that IssuerAndSerialNumber will typically be as unique as
SubjectKeyIdentifier, I also assume (correct me if I'm wrong) that in
practice it's isn't always possible to get a guarantee of uniqueness for
either, which is why I don't care.  But maybe I should care -- may it be
that self-signed CA trust anchor certs are more likely to have a unique
SubjectKeyIdentifier than a unique IssuerAndSerialNumber?

> - Do you have a preference for which one is REQUIRED?  Why?

Both?

> - Should the not-required one be RECOMMENDED or OPTIONAL or not present?

Don't know.

> - Do you agree with Martin that having a Name here can be useful?

Yes.

> - Does anyone object to making the Name at least RECOMMENDED?

No.

> - Does anyone object to making the Name be REQUIRED?

No.

> - Martin (or others), is making the Name RECOMMENDED sufficient?

I think so.

> - Does anyone see a reason for a raw serial number?

No.

>  IssuerAndSerialNumber, or SubjectKeyIdentifier?

No.

> - Do you agree a Name is sufficient, and should be REQUIRED?

Yes.

>  useful, in order to allow applications to do their own CRL lookups(*)?

I'm not sure that I agree :)  (see a post from me today on that).

> - Should IssuerAndSerialNumber be REQUIRED, RECOMMENDED, OPTIONAL, ???

Not present (see above).

>  IssuerAndSerialNumber, or SubjectKeyIdentifier?

No.

> Given some answers to these questions, maybe we can reach convergence.

That's a lot of questions...

Cheers,

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 13 Jul 2005 09:31:54 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I'm going to try to ask questions in more detail.  Answers from all
> parties are encouraged...

REQUIRE SubjectKeyIdentifier would be unwise given the use of today CA's.

IssuerAndSerialNumber or SubjectKeyIdentifier should be the items that is
used, any of those two uniquely indentifies the certificate. Name might be
used to be friendly to the user/sysadmin, but have not real use for the
protocol/implementations given its non-uniqueness.

Love