Subject: RE: What's in a Name?

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

Jeff wrote:
> would have cases where the 
> Name is not sent (for example, if the cert has none).  

RFC 3280 says:

  " If
   the subject is a CA ... then
   the subject field MUST be populated with a non-empty distinguished
   name"

Should we consider the case where the subject DN is NOT present in the
CA certificate?

Again, I looped in Stefan to help to interpret the text in RFC3280.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Thursday, July 14, 2005 2:25 PM
To: Nicolas Williams; Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: What's in a Name?

On Thursday, July 14, 2005 03:29:34 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Thu, Jul 14, 2005 at 01:25:41PM -0700, Liqiang(Larry) Zhu wrote:
>> > TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
>>
>> Why the DN is required for TD-INVALID-CERTIFICATES? The client has
the
>> whole certificate, and can find out the name byitself.
>
> Agreed.  A CHOICE of SubjectKeyIdentifier or IssuerAndSerial should do
> for TD-INVALID-CERTIFICATES.

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

Larry, your latest proposal (and mine before it) would have cases where
the 
Name is not sent (for example, if the cert has none).  For this to work,

the name field has to be "OPTIONAL" in the ASN.1 sense.

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

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

-- Jeff

---

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

> Again, I looped in Stefan to help to interpret the text in RFC3280.

TD-INVALID-CERTIFICATES may refer to the client's leaf cert, which may have 
no subject DN.  Also, I think you, Nico, and I just agreed to allow 
omitting the name entirely for TD-INVALID-CERTIFIFCATES (I still want to 
hear at least from Martin on this issue).

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Jul 2005 01:04:11 +0200 (MET DST)

> hear at least from Martin on this issue).

OK, here we go.  :)

As I initially indicated, I suggested to include the subject DN because
this would make it fairly easy for (small footprint) clients to include
the certificate name in the error message.  I don't see that we save
anything significant by not sending the DName, but I can see how much
every client will have to spent in order to make up for this.

I think the name would be quite useful in the error message,
would make implementations much simpler and more robust,
and I don't expect a network bandwidth problem here.

Keep in mind that the KDC already has its hands on the correct
certificate, and it should be trivial for the KDC to retrieve
the subjectDN along with Issuer&Serial from that cert.

A lot of client code is notoriously bad at creating error messages,
and the more effort it takes to produce a good error message, the
more likely such code will not be implemented.  Keep in mind that
the client will know that it can NOT overcome this error -- so
using the issuer&serial from TD-INVALID-CERTIFICATES to find
the offending certificate locally and extract the name is all
pure error handling code -- the stuff that is skipped most often
when deadlines are coming.  Just look at MSIE -- when it comes
to SSL, you just don't get any useful error messages at all!

And I wasn't particularly happy with Larry's reply to the issue
of the KDC completing the certification path:

: From: "Liqiang(Larry) Zhu" <[email-masked]>
: Date: Mon, 21 Feb 2005 14:12:47 -0800
: Subject: RE: Pkinit-23 comments: InitialVerifiedCAs
:
: Martin wrote:
: > the KDC being allowed to add certificates for the path validation
: >(which the client didn't send, maybe because it didn't have them).
:
: The KDC is allowed to.
:
: > In case there is a validation error with one of those certs that the
: > KDC supplied, which error is the KDC going to send?
:
: Presumably the KDC won't use/have this invalid cert to start with.

Oh really?  Then we could save plenty of CPU time and skip the
entire certificate path validation -- knowing the certificates
exist would be sufficient!

:
: And KDC_ERR_CANT_VERIFY_CERTIFICATE should be returned if the KDC can
: not build a path.

As long as the KDC is allowed to add certificates to the path
validation, the path validation can definitely fail because of
an invalid signature on such a certificate and then we will receive
TD-INVALID-CERTIFICATES on the client and not know what cert
the KDC is refering to.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 Jul 2005 01:13:30 +0200 (MET DST)

> the subjectDN along with Issuer&Serial from that cert.

Actually, any sensible KDC implementation should be retrieving the
SubjectDN and include it in error log entries -- because end-entity
certificates are usually short-lived, and for efficiency they're
deleted sometime after they have expired -- and it would be a pretty
bad idea to write logs entries with only issuer&serial, because
in a year or more, it may no longer be possible to find the cert
anywhere in order to see to what entity it had been issued.

-Martin