Subject: RE: What's in a Name?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 14 Jul 2005 13:25:41 -0700

> TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL

Why the DN is required for TD-INVALID-CERTIFICATES? The client has the
whole certificate, and can find out the name byitself.

I think the following makes more sense:

TD-INVALID-CERTIFICATES  N/A         REQUIRED         N/A

Put it together, the proposal would be:

OLD:

       TrustedCA ::= SEQUENCE {
          caName                  [0] IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies a CA by the CA's distinguished subject
                   -- name.
          certificateSerialNumber [1] INTEGER OPTIONAL,
                   -- Specifies the CA certificate's serial number.
                   -- The definition of the certificate serial number
                   -- is taken from X.509 [X.509-97].
          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
                   -- Identifies the CA's public key by a key
                   -- identifier.  When an X.509 certificate is
                   -- referenced, this key identifier matches the X.509
                   -- subjectKeyIdentifier extension value.  When other
                   -- certificate formats are referenced, the documents
                   -- that specify the certificate format and their use
                   -- with the CMS must include details on matching the
                   -- key identifier to the appropriate certificate
                   -- field.
          ...
       }

REPLACE with:

       TrustedCA ::= SEQUENCE {
          caName                  [0] IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].

                   -- Identifies a CA by the CA's distinguished subject
                   -- name.
          IssuerAndSerialNumber   [1] OCTET STRING OPTIONAL,
                   -- Contains a CMS type IssuerAndSerialNumber encoded 
                   -- according to [RFC3852].
                   -- Identifies a CA's certificate.  
                   -- This field is REQUIRED for 
                   -- TD-TRUSTED-CERTIFIERS but can be omitted
                   -- if the subjectKeyIdentifier field below is
present.
          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
                   -- Identifies the CA's public key by a key
                   -- identifier.  When an X.509 certificate is
                   -- referenced, this key identifier matches the X.509
                   -- subjectKeyIdentifier extension value.  When other
                   -- certificate formats are referenced, the documents
                   -- that specify the certificate format and their use
                   -- with the CMS must include details on matching the
                   -- key identifier to the appropriate certificate
                   -- field.
                   -- This field is RECOMMENDED for 
                   -- TD-TRUSTED-CERTIFIERS.
          ...
       }

Comments?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Wednesday, July 13, 2005 3:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: What's in a Name?

On Wednesday, July 13, 2005 11:48:50 PM +0200 Martin Rex 
<[email-masked]> wrote:

> Some CAs even do not issue certificates with the same subject name
> more than once, even to the same entity -- wasn't VeriSign denying
> this for S/Mime certificates?  And the way around was making a
> kind of serial number or enumerator part of the subject DName.

I'm not sure about the specific case you cite, but yes, I'm aware there
are 
CA's that behave this way.

> I do NOT think it is reasonable to exclude the majority of installed
> base PKI software and CAs by requiring a subjectKeyIdentifier,
> no matter what rfc3280 says about this, and for end entity
certificates
> the subjectKeyIdentifier is only a SHOULD in rfc3280.

I agree.

>> A new proposal, then:
>>
>> Field                    Name      IssuerAndSerial
SubjectKeyIdentifier
>> TD-TRUSTED-CERTIFIERS    REQUIRED  RECOMMENDED      REQUIRED
>> TD-INVALID-CERTIFICATES  REQUIRED  REQUIRED         OPTIONAL
>> AD-INITIAL-VERIFIED-CAS  REQUIRED  OPTIONAL         OPTIONAL
>>
>
> We should account for end-entity certs with empty subject name
> and CA certs without subjectKeyIdentifier and therefore
> say "REQUIRED if present in the certificate".

Yes.

> Although subjectKeyIdentifier is sufficient to distinguish among
> multiple certificates of the same entity (i.e. those with same subject
> name), it is useless if you do not have the certificate.

Right.  But in the TD-TRUSTED-CERTIFIERS case, you might actually have a

case where the keyid is the most useful identifier (because
IssuerAndSerial 
is too specific).  The point several have made about certs not always 
having a SubjectKeyIdentifier is well-taken; obviously this also needs
to 
become "... if present in the certificate".  I still think this should
be 
at least RECOMMENDED, but let's hear from the rest of the group.

> IssuerAndSerial will at least always give you the starting point
> where to start looking--although it may require human involvement
> and administrative overhead to actually obtain a certificate with
> just that information. :-)
>
> Since IssuerAndSerial are omni-present, it shouldn't be a burden to
> send it in the TD- cases, and I would suggest to require this
information
> (which would make it impossible that the container is empty).

That sounds good.

OK, so now we're at this state:
Field                    Name       IssuerAndSerial
SubjectKeyIdentifier
TD-TRUSTED-CERTIFIERS    REQUIRED*  REQUIRED         RECOMMENDED*
TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
(*) If present in certificate

In the AD- case I think we can safely assume the name is non-empty; if
not 
we need to make some change to keep the container from being empty.

> However I would appreciate if we put some words into the spec about
> the purpose of the information and how it is expected to be used
> by the receiver of the protocol unit/message.

I agree.  Does someone want to propose specific text?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Jul 2005 15:29:34 -0500

> whole certificate, and can find out the name byitself.

Agreed.  A CHOICE of SubjectKeyIdentifier or IssuerAndSerial should do
for TD-INVALID-CERTIFICATES.

...
>           IssuerAndSerialNumber   [1] OCTET STRING OPTIONAL,
            ^^^^^^^^^^^^^^^^^^^^^

I thought you wanted to avoid duplication of Names in the
AD-VERIFIED-CAs case, so this should just be a serial number.  Also,
nit: the first letter there must not be uppercase.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Jul 2005 15:30:26 -0500

> for TD-INVALID-CERTIFICATES.

Oops, I don't agree.

Sorry, I sent that out too quickly.

The Name should be there if the client didn't send the whole cert chain.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 14 Jul 2005 17:25:12 -0400

> for TD-INVALID-CERTIFICATES.

WG chair hat off:
Requring a "choice" in the semantic sense is fine.
A "CHOICE" in the ASN.1 sense is something I'd rather avoid, in faavor of 
separate fields, which allows both to be included if desired.

Larry, your latest proposal (and mine before it) would have cases where the 
Name is not sent (for example, if the cert has none).  For this to work, 
the name field has to be "OPTIONAL" in the ASN.1 sense.

The requirements language in the comments is incomplete.  Also, I don't 
think it belongs exclusively there; it also needs to be in the main text in 
the places where these lists are described.

Provided that TD-INVALID-CERTIFICATES only ever refers to certs sent by the 
client, I am fine with not requiring the name in that case.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Jul 2005 16:30:37 -0500

> client, I am fine with not requiring the name in that case.

Me too.