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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 14 Jul 2005 23:42:41 -0400

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 15 Jul 2005 07:51:38 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> So, here is strawman 3:
> Field                    Name       IssuerAndSerial
> SubjectKeyIdentifier For

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Jul 2005 09:40:09 -0500

> had to be conditional on the presence of the value in the certificate in

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.

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Jul 2005 17:06:26 +0200 (MET DST)

> software wants to be unfriendly, let it. I don't care too strongly about it

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Jul 2005 17:12:05 +0200 (MET DST)

> 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

---

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

>  back to just "REQUIRED", with no other changes.

Agreed.

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

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

> compromise would be nice...

I support this list.

Jeffrey Altman