Subject: RE: What's in a Name - nearing the end?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 15 Jul 2005 09:20:58 -0700

Folks, please comment on this proposal. ExternalPrincipalIdentifier is used by TD-INVALID-CERTIFICATES, TD-TRUSTED-CERTIFIERS and AD-INITIAL-VERIFIED-CA.

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Friday, July 15, 2005 12:29 AM
To: 'Jeffrey Hutzelman'; Love Hörnquist Åstrand
Cc: [email-masked]
Subject: RE: What's in a Name - nearing the end?

Added that too:

       ExternalPrincipalIdentifier ::= SEQUENCE {
          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies the certificate subject by the 
                   -- distinguished subject name.
                   -- REQUIRED when there is a distinguished subject name 
                   -- present in the certificate.
          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a CMS type IssuerAndSerialNumber encoded 
                   -- according to [RFC3852].
                   -- Identifies a certificate of the subject. 
                   -- REQUIRED for TD-INVALID-CERTIFICATES. 
                   -- For TD-TRUSTED-CERTIFIERS, this field is REQUIRED 
                   -- but can be omitted if the subjectKeyIdentifier field 
                   -- below is present. 
          subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
                   -- Identifies the subject'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.
                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
          ...
       }

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Friday, July 15, 2005 12:25 AM
To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
Cc: [email-masked]
Subject: RE: What's in a Name - nearing the end?

On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> Taking the least resistance path, TD-INVALID-CERTIFICATES,
> TD-TRUSTED-CERTIFIERS and AD-INITIAL-VERIFIED-CA shall all use
> ExternalPrincipalIdentifier.
>
>
>
>        ExternalPrincipalIdentifier ::= SEQUENCE {
>           subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a PKIX type Name encoded according to
>                    -- [RFC3280].
>                    -- Identifies the certificate subject by the
>                    -- distinguished subject name.
>                    -- REQUIRED when there is a distinguished subject name
>                    -- present in the certificate.
>           issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a CMS type IssuerAndSerialNumber encoded
>                    -- according to [RFC3852].
>                    -- Identifies a certificate of the subject.
>                    -- For TD-TRUSTED-CERTIFIERS, this is REQUIRED but can 
be
>                    -- omitted if the subjectKeyIdentifier field below is
>                    -- present.
>           subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Identifies the subject'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.
>           ...
>        }
>
> ExternalPrincipalIdentifier means it is not Kerberos principal.

This is still missing the bit about issuerAndSerialNumber being
REQUIRED for TD-INVALID-CERTIFICATES.  Otherwise, I believe this
matches my "strawman 3".  So hopefully if people are happy with one,
they'll be happy with the other.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Jul 2005 12:41:04 -0400

I support this specification of ExternalPrincipalIdentifier provided
that it matches the contents of strawman 3.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Jul 2005 19:25:23 +0200 (MET DST)

It is almost perfect.

It says that for TD-TRUSTED-CERTIFIERS the issuerAndSerialNumber
can be omitted -- which I don't like (and which differs from strawman3).

issuerAndSerialNumber is always sufficient to identify a CA-certificate
or a CA-signed certificate--which addresses the situation that the
client has the certificates available and can continue programmatically.

The subjectName is there to facilitate visualization of the error
for the client, in particular for situations where the client doesn't
have the certificate (which specifically means TD-TRUSTED-CERTIFIERS).

The subjectKeyIdentifier would only be necessary for the case where
you have several certificates with different keys from the same CA
with the same subjectDName (so that regular certificate chaining
based only on issuerName could fail).

Personally I think that allowing CAs to do stupid things like this
and trying to cover up for it by requiring subjectKeyIdentifiers
has added significant complexity while adding value that is as
close to zero as it can get.

And by trying to require subjectKeyIdentifier for reasonable CAs
as well, the stupid ones will not stand out as much.

But what does subjectKeyIdentifier really change?  It will cause
clients to receive the error "Untrusted CA" instead of "signature
validation failed" if the locally configured trust anchor/key of
a stupid CA differs from the key that signed an incoming certificate.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 15 Jul 2005 14:19:25 -0400

> can be omitted -- which I don't like (and which differs from strawman3).

You're right; it does.  I missed that in the latest version.

> based only on issuerName could fail).

It is important to remember that ultimately, a trust anchor is a public 
key, not a certificate.  The point of including a subjectKeyIdentifier 
would be to allow for cases where the same CA has multiple certificates 
with the same subject DN and key, but different serial numbers.  This would 
happen when a CA issues a new certificate for itself.

In such a situation, including a subjectKeyIdentifier allows a client to 
use any cert signed by that key, instead of only one signed by a particular 
certificate.  Probably the subjectKeyIdentifier should be included only if 
the KDC is actually willing to accept any cert signed by that key, instead 
of only ones issued with a particular cert.

I don't feel strongly about this; whatever others want to do is fine with 
me.