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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 15 Jul 2005 10:54:19 -0700

Adjusted again:

       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 and 
                   -- TD-TRUSTED-CERTIFIERS. 
          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: Martin Rex [mailto:[email-masked]] 
Sent: Friday, July 15, 2005 10:25 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: What's in a Name - nearing the end?

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

Liqiang wrote:
> 
> 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 Hutzelman <[email-masked]>
Date: Fri, 15 Jul 2005 14:20:12 -0400

>                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.

I support this.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 17 Jul 2005 21:54:25 -0400

>>                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.

Larry is updating -27 to reflect this version of the text.  Unless there 
are objections in WGLC, I think we can consider this (finally) resolved.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 17 Jul 2005 21:58:14 -0400

>>                    -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.

This was tickets 836, 864, 865, and 866.
I have merged these into a single ticket, which is #866.
As noted previously, Larry is applying this version to pkinit-27, which 
will be submitted shortly.  Once I see it published, I will mark this 
ticket resolved.

-- Jeff