What's in a Name - nearing the end?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What's in a Name - nearing the end?

Jeffrey Hutzelman


OK; I'm about to propose a third strawman.  First, a recap...

*** Strawman 1
My original strawman looked like this:

Field                    Name      IssuerAndSerial  SubjectKeyIdentifier
TD-TRUSTED-CERTIFIERS    REQUIRED  RECOMMENDED      REQUIRED
TD-INVALID-CERTIFICATES  REQUIRED  REQUIRED         OPTIONAL
AD-INITIAL-VERIFIED-CAS  REQUIRED  OPTIONAL         OPTIONAL


*** Strawman 2
Discussion revealed that not all certifiates had to have a subject DN,
or a SubjectKeyIdentifier.  So any case where these were to be REQUIRED
had to be conditional on the presence of the value in the certificate in
question.

In the TD-TRUSTED-CERTIFIERS case, making both fields "REQUIRED if..."
would have meant there could be a situation in which the container could
be completely empty.  Therefore, it was suggested that IssuerAndSerialNumber
could be made REQUIRED in this case, and then SubjectKeyIdentifier could
become "RECOMMENDED if...".

These changes lead to the second strawman:

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


*** Strawman 3
Now we have a bunch more discussion...

* For TD-TRUSTED-CERTIFIERS:
  Not much discussion here, except that it was pointed out that these
  are always CA's, and certificates for CA's are required to always have
  a subject DN.  So it is apparently not necessary after all to make the
  subject DN be "REQUIRED if..." here; it can simply be REQUIRED.

  I believe Nico reiterated the need in this case to have both a Name
  for displaying to a client (so he can go ask for a CA), and either an
  IssuerAndSerialNumber or SubjectKeyIdentifier in order for software to
  actually find the required certificate if it is already present in some
  certificate store.  I have seen no arguments against this idea.

  For my third strawman, the "REQUIRED if..." on this line will change
  back to just "REQUIRED", with no other changes.

* For TD-INVALID-CERTIFICATES:
  Larry pointed out that this field can only refer to certs which were
  sent by the client, and so we can assume the client has any cert which
  is mentioned here.  He therefore suggested that in this TD, only
  IssuerAndSerialNumber should be required.  Nico proposed allowing
  either IssuerAndSerialNumber or SubjectKeyIdentifier, but could not
  come up with a situation in which the latter would be required.

  Martin reiterated his comments about requiring the KDC to include the
  Name in order to better facilitiate troubleshooting.  The problem is
  basically that clients will have to do more work in order to turn the
  IssuerAndSerialNumber into something useful to display to a user, and
  many of them simply won't bother to do anything.

  As an individual, I'm on the fence.  From a purely technical standpoint,
  I can see that it is possible to make the protocol work without including
  a subject DN here.  However, I find Martin's argument pretty compelling,
  particularly based on my own experience troubleshooting authentication
  problems and on the crappy error reporting I see in existing applications
  which use X.509 certificates.

  My impressions:
  Martin feels a lot more strongly about this than Larry does.
  I'm on the fence, but leaning slightly in Martin's favor.
  Nico seems to be neutral.  No one else has said anything.

  So for my third strawman, I'm inclined to leave both subject DN and
  IssuerAndSerialNumber as REQUIRED, with the former conditional on its
  presence in the certificate (since for a leaf cert, it can be absent).

* For AD-INITIAL-VERIFIED-CAS:
  There were two discussions on this point.  One was related to confirming
  this this item would only ever refer to CA's and not leaf certs, and thus
  every cert could be assumed to contain a subject DN.  This requires no
  change to the proposed requirements.

  The other issue was related to the possibility of compressing out the
  issuer DN part of IssuerAndSerialNumber, by assuming that one could
  simply look at the previous entry's subject DN.  After some discussion,
  this idea appears to have been dropped.


So, here is strawman 3:
Field                    Name       IssuerAndSerial  SubjectKeyIdentifier
For
TD-TRUSTED-CERTIFIERS    REQUIRED   REQUIRED         RECOMMENDED*
TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
(*) If present in certificate


Emprical evidence suggests to me that we are converging, with the only
significant open issue being the one of whether to require a subject DN
in TD-INVALID-CERTIFICATES (assuming one is present in the cert).  Some
compromise would be nice...


-- Jeff


Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand

Jeffrey Hutzelman <[hidden email]> writes:

> So, here is strawman 3:
> Field                    Name       IssuerAndSerial
> SubjectKeyIdentifier For
> TD-TRUSTED-CERTIFIERS    REQUIRED   REQUIRED         RECOMMENDED*
> TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
> AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
> (*) If present in certificate
>
>
> Emprical evidence suggests to me that we are converging, with the only
> significant open issue being the one of whether to require a subject DN
> in TD-INVALID-CERTIFICATES (assuming one is present in the cert).  Some
> compromise would be nice...
I would like to see Name changed to RECOMMENDED or OPTIONAL, if the
software wants to be unfriendly, let it. I don't care too strongly about it
though.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman
Updated proposal, please review:

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 OPTIONAL,
                   -- 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.
                   -- MUST be present if subjectKeyIdentifier is absent.
          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.
          ...
       }

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Love Hörnquist Åstrand
Sent: Thursday, July 14, 2005 10:52 PM
To: Jeffrey Hutzelman
Cc: [hidden email]
Subject: Re: What's in a Name - nearing the end?


Jeffrey Hutzelman <[hidden email]> writes:

> So, here is strawman 3:
> Field                    Name       IssuerAndSerial
> SubjectKeyIdentifier For
> TD-TRUSTED-CERTIFIERS    REQUIRED   REQUIRED         RECOMMENDED*
> TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
> AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
> (*) If present in certificate
>
>
> Emprical evidence suggests to me that we are converging, with the only
> significant open issue being the one of whether to require a subject DN
> in TD-INVALID-CERTIFICATES (assuming one is present in the cert).  Some
> compromise would be nice...

I would like to see Name changed to RECOMMENDED or OPTIONAL, if the
software wants to be unfriendly, let it. I don't care too strongly about it
though.

Love



Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Thursday, July 14, 2005 11:09:01 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> Updated proposal, please review:
> REPLACE with:
>
>
>        TrustedCA ::= SEQUENCE {
>           caName                  [0] IMPLICIT OCTET STRING OPTIONAL,
>                    -- 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.
>                    -- MUST be present if subjectKeyIdentifier is absent.
>           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.
>           ...
>        }


That doesn't say the same thing as strawman 3:

- It does not indicate that caName is REQUIRED when there is a subject DN
  present in the certificate

- It does not indicate that issuerAndSerialNumber is REQUIRED for
  TD-INVALID-CERTIFICATES

- For TD-TRUSTED-CERTIFIERS, it permits issuerAndSerialNumber to be
  omitted if subjectKeyIdentifier is given.  I don't object to that
  approach, but it is not what strawman 3 says.

Also, a couple of other comments...
I think all three fields should be IMPLICIT; that saves us at least two
octets of encoding per field per TrustedCA.  And, I think the "caName"
field is poorly named, and likely to confuse someone into thinking they
should put the issuer DN there, even though the spec does not say that.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman

Good points:

Adjusted:

       TrustedCA ::= SEQUENCE {
          subject                 [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies a CA by the CA's distinguished subject
                   -- name.
                   -- REQUIRED when there is a subject DN present in the
                   -- CA's certificate.
          issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a CA's certificate.  
                   -- 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 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.
          ...
       }

> - It does not indicate that issuerAndSerialNumber is REQUIRED for
>  TD-INVALID-CERTIFICATES

TD-INVALID-CERTIFICATES can contain leaf certificates, therefore would it be awkward to call it TrustedCA?


-----Original Message-----
From: Jeffrey Hutzelman [mailto:[hidden email]]
Sent: Thursday, July 14, 2005 11:20 PM
To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
Cc: [hidden email]
Subject: RE: What's in a Name - nearing the end?



On Thursday, July 14, 2005 11:09:01 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> Updated proposal, please review:
> REPLACE with:
>
>
>        TrustedCA ::= SEQUENCE {
>           caName                  [0] IMPLICIT OCTET STRING OPTIONAL,
>                    -- 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.
>                    -- MUST be present if subjectKeyIdentifier is absent.
>           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.
>           ...
>        }


That doesn't say the same thing as strawman 3:

- It does not indicate that caName is REQUIRED when there is a subject DN
  present in the certificate

- It does not indicate that issuerAndSerialNumber is REQUIRED for
  TD-INVALID-CERTIFICATES

- For TD-TRUSTED-CERTIFIERS, it permits issuerAndSerialNumber to be
  omitted if subjectKeyIdentifier is given.  I don't object to that
  approach, but it is not what strawman 3 says.

Also, a couple of other comments...
I think all three fields should be IMPLICIT; that saves us at least two
octets of encoding per field per TrustedCA.  And, I think the "caName"
field is poorly named, and likely to confuse someone into thinking they
should put the issuer DN there, even though the spec does not say that.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Thursday, July 14, 2005 11:32:42 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

>
> Good points:
>
> Adjusted:
>
>        TrustedCA ::= SEQUENCE {
>           subject                 [0] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a PKIX type Name encoded according to
>                    -- [RFC3280].
>                    -- Identifies a CA by the CA's distinguished subject
>                    -- name.
>                    -- REQUIRED when there is a subject DN present in the
>                    -- CA's certificate.
>           issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a CMS type IssuerAndSerialNumber encoded
>                    -- according to [RFC3852].
>                    -- Identifies a CA's certificate.
>                    -- 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 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.
>           ...
>        }
>
>> - It does not indicate that issuerAndSerialNumber is REQUIRED for
>>  TD-INVALID-CERTIFICATES
>
> TD-INVALID-CERTIFICATES can contain leaf certificates, therefore would it
> be awkward to call it TrustedCA?

Well, yes, it is awkward to call the structure TrustedCA when it is used
for other than trusted certifiers.  That's true even if we don't use this
type for TD-INVALID-CERTIFICATES, since AD-INITIAL-VERIFIED-CAS are not
"trusted" CA's; they're just CA's.

My answer would be to rename the structure, rather than making up a
completely separate but substantially similar type for TD-INVALID-CERTS.
But it doesn't really bother me to do it that way, if you prefer.


Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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.

Comments?

-- Larry





-----Original Message-----
From: Jeffrey Hutzelman [mailto:[hidden email]]
Sent: Thursday, July 14, 2005 11:46 PM
To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
Cc: [hidden email]
Subject: RE: What's in a Name - nearing the end?



On Thursday, July 14, 2005 11:32:42 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

>
> Good points:
>
> Adjusted:
>
>        TrustedCA ::= SEQUENCE {
>           subject                 [0] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a PKIX type Name encoded according to
>                    -- [RFC3280].
>                    -- Identifies a CA by the CA's distinguished subject
>                    -- name.
>                    -- REQUIRED when there is a subject DN present in the
>                    -- CA's certificate.
>           issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
>                    -- Contains a CMS type IssuerAndSerialNumber encoded
>                    -- according to [RFC3852].
>                    -- Identifies a CA's certificate.
>                    -- 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 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.
>           ...
>        }
>
>> - It does not indicate that issuerAndSerialNumber is REQUIRED for
>>  TD-INVALID-CERTIFICATES
>
> TD-INVALID-CERTIFICATES can contain leaf certificates, therefore would it
> be awkward to call it TrustedCA?

Well, yes, it is awkward to call the structure TrustedCA when it is used
for other than trusted certifiers.  That's true even if we don't use this
type for TD-INVALID-CERTIFICATES, since AD-INITIAL-VERIFIED-CAS are not
"trusted" CA's; they're just CA's.

My answer would be to rename the structure, rather than making up a
completely separate but substantially similar type for TD-INVALID-CERTS.
But it doesn't really bother me to do it that way, if you prefer.


Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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:[hidden email]]
Sent: Friday, July 15, 2005 12:25 AM
To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
Cc: [hidden email]
Subject: RE: What's in a Name - nearing the end?



On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
In reply to this post by Jeffrey Hutzelman
On Thu, Jul 14, 2005 at 11:42:41PM -0400, Jeffrey Hutzelman wrote:
> Discussion revealed that not all certifiates had to have a subject DN,
> or a SubjectKeyIdentifier.  So any case where these were to be REQUIRED
> had to be conditional on the presence of the value in the certificate in
> question.

But all CA certs have DNs, so the only cert we need worry about that may
not have a DN is the leaf cert and guess what -- we don't need any
particularly special ID for it as there can only be one.


Reply | Threaded
Open this post in threaded view
|

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

Martin Rex
In reply to this post by Love Hörnquist Åstrand
I think this is the only solution that would really help a client:

> > So, here is strawman 3:
> > Field                    Name       IssuerAndSerial
> > SubjectKeyIdentifier For
> > TD-TRUSTED-CERTIFIERS    REQUIRED   REQUIRED         RECOMMENDED*
> > TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
> > AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
> > (*) If present in certificate
> >
> > Emprical evidence suggests to me that we are converging, with the only
> > significant open issue being the one of whether to require a subject DN
> > in TD-INVALID-CERTIFICATES (assuming one is present in the cert).  Some
> > compromise would be nice...
>
> I would like to see Name changed to RECOMMENDED or OPTIONAL, if the
> software wants to be unfriendly, let it. I don't care too strongly about it
> though.

Where is you problem with REQUIRing name (if present in the cert)?

If it is not required, we could just leave it out, because the
client will not be able to use the exact same parsing and
error handling logic.  We can only save the client the necessary code
to find the cert locally and extract the subjectDN if we REQUIRE
the server to send the DName (if it exists in the certificate).


Really, if we use the same format for transfering this information,
it will simplify the code that creates this PDU on the KDC and
simplify the parser on the client side.

  KDC:  in: List of certs
  Client: out: list of subjectDNs

Concerning the end-entity certs with empty subject DNs:
I wouldn't mind if the client's error message did not print out a
name if the certificate had an empty subjectDN.  Personally I think
it is not a good idea to issue certificates without subjectDN, even
though the spec permits it.

(I'm wondering how certificates with an empty DN are created. :)
 Most keypairs start with a self-signed certificate, but a self-signed
 certificate with an empty DN would have an empty issuer -- which
 makes it invalid cert...  And are PKCS#10 requests with an empty
 subjectName are permitted at all?)


-Martin


Reply | Threaded
Open this post in threaded view
|

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

Martin Rex
In reply to this post by Nicolas Williams
Nicolas Williams wrote:

>
> On Thu, Jul 14, 2005 at 11:42:41PM -0400, Jeffrey Hutzelman wrote:
> > Discussion revealed that not all certifiates had to have a subject DN,
> > or a SubjectKeyIdentifier.  So any case where these were to be REQUIRED
> > had to be conditional on the presence of the value in the certificate in
> > question.
>
> But all CA certs have DNs, so the only cert we need worry about that may
> not have a DN is the leaf cert and guess what -- we don't need any
> particularly special ID for it as there can only be one.

Yup, it is not just common sense, it's also required in the spec(s):

RFC3280, Section 4.1.2.6  Subject

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

-Martin


Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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: [hidden email]
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:[hidden email]]
Sent: Friday, July 15, 2005 12:25 AM
To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
Cc: [hidden email]
Subject: RE: What's in a Name - nearing the end?



On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman
In reply to this post by Jeffrey Hutzelman
Jeffrey Hutzelman wrote:

> *** Strawman 3
> Now we have a bunch more discussion...
>
> * For TD-TRUSTED-CERTIFIERS:
>  Not much discussion here, except that it was pointed out that these
>  are always CA's, and certificates for CA's are required to always have
>  a subject DN.  So it is apparently not necessary after all to make the
>  subject DN be "REQUIRED if..." here; it can simply be REQUIRED.
>
>  I believe Nico reiterated the need in this case to have both a Name
>  for displaying to a client (so he can go ask for a CA), and either an
>  IssuerAndSerialNumber or SubjectKeyIdentifier in order for software to
>  actually find the required certificate if it is already present in some
>  certificate store.  I have seen no arguments against this idea.
>
>  For my third strawman, the "REQUIRED if..." on this line will change
>  back to just "REQUIRED", with no other changes.
Agreed.

> * For TD-INVALID-CERTIFICATES:
>  Larry pointed out that this field can only refer to certs which were
>  sent by the client, and so we can assume the client has any cert which
>  is mentioned here.  He therefore suggested that in this TD, only
>  IssuerAndSerialNumber should be required.  Nico proposed allowing
>  either IssuerAndSerialNumber or SubjectKeyIdentifier, but could not
>  come up with a situation in which the latter would be required.
>
>  Martin reiterated his comments about requiring the KDC to include the
>  Name in order to better facilitiate troubleshooting.  The problem is
>  basically that clients will have to do more work in order to turn the
>  IssuerAndSerialNumber into something useful to display to a user, and
>  many of them simply won't bother to do anything.
>
>  As an individual, I'm on the fence.  From a purely technical standpoint,
>  I can see that it is possible to make the protocol work without including
>  a subject DN here.  However, I find Martin's argument pretty compelling,
>  particularly based on my own experience troubleshooting authentication
>  problems and on the crappy error reporting I see in existing applications
>  which use X.509 certificates.
>
>  My impressions:
>  Martin feels a lot more strongly about this than Larry does.
>  I'm on the fence, but leaning slightly in Martin's favor.
>  Nico seems to be neutral.  No one else has said anything.
>
>  So for my third strawman, I'm inclined to leave both subject DN and
>  IssuerAndSerialNumber as REQUIRED, with the former conditional on its
>  presence in the certificate (since for a leaf cert, it can be absent).
I agree with Martin on this one.  Having spent too many hours trying to
debug authentication problems over a telephone or e-mail with end users,
anything we can do to make it easier for application developers and end
users should be done.   REQUIRED is appropriate unless someone has a
reason why this will cause harm.

> * For AD-INITIAL-VERIFIED-CAS:
>  There were two discussions on this point.  One was related to confirming
>  this this item would only ever refer to CA's and not leaf certs, and thus
>  every cert could be assumed to contain a subject DN.  This requires no
>  change to the proposed requirements.
>
>  The other issue was related to the possibility of compressing out the
>  issuer DN part of IssuerAndSerialNumber, by assuming that one could
>  simply look at the previous entry's subject DN.  After some discussion,
>  this idea appears to have been dropped.
The compression idea is useful provided that the ordering is guarranteed
but it is not critical to solving the problem.

>
> So, here is strawman 3:
> Field                    Name       IssuerAndSerial
> SubjectKeyIdentifier For
> TD-TRUSTED-CERTIFIERS    REQUIRED   REQUIRED         RECOMMENDED*
> TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
> AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
> (*) If present in certificate
>
>
> Emprical evidence suggests to me that we are converging, with the only
> significant open issue being the one of whether to require a subject DN
> in TD-INVALID-CERTIFICATES (assuming one is present in the cert).  Some
> compromise would be nice...
I support this list.

Jeffrey Altman


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman
In reply to this post by Larry Zhu
I support this specification of ExternalPrincipalIdentifier provided
that it matches the contents of strawman 3.

Jeffrey Altman

Liqiang(Larry) Zhu 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: [hidden email]
> 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.
>           ...
>        }
>

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex
In reply to this post by Larry Zhu
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: [hidden email]
> 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:[hidden email]]
> Sent: Friday, July 15, 2005 12:25 AM
> To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
> Cc: [hidden email]
> Subject: RE: What's in a Name - nearing the end?
>
>
>
> On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu"
> <[hidden email]> 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
>
>
>



Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Jeffrey Hutzelman
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:[hidden email]]
Sent: Friday, July 15, 2005 10:25 AM
To: Liqiang(Larry) Zhu
Cc: [hidden email]; [hidden email]; [hidden email]
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: [hidden email]
> 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:[hidden email]]
> Sent: Friday, July 15, 2005 12:25 AM
> To: Liqiang(Larry) Zhu; Love Hörnquist Åstrand
> Cc: [hidden email]
> Subject: RE: What's in a Name - nearing the end?
>
>
>
> On Friday, July 15, 2005 12:06:56 AM -0700 "Liqiang(Larry) Zhu"
> <[hidden email]> 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
>
>
>



Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Martin Rex


On Friday, July 15, 2005 07:25:23 PM +0200 Martin Rex <[hidden email]>
wrote:

> It says that for TD-TRUSTED-CERTIFIERS the issuerAndSerialNumber
> 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.


> 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).

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.



Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Larry Zhu


On Friday, July 15, 2005 10:54:19 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> 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.
>           ...
>        }


I support this.




Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Friday, July 15, 2005 02:20:12 PM -0400 Jeffrey Hutzelman
<[hidden email]> wrote:

>
>
> On Friday, July 15, 2005 10:54:19 AM -0700 "Liqiang(Larry) Zhu"
> <[hidden email]> wrote:
>
>> 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.
>>           ...
>>        }
>
>
> I support this.


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


12