Subject: RE: What's in a Name?

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

Martin, you failed to mention that I asked this working group if we
could change the existing semantic of TD-INVALID-CERTIFIFCATES to
include certificates not sent by the client, there was no response to my
request. 

I would suggest sending such invalid certificate identifiers in a
separate entry of the TYPED-DATA: say
TD-INVALID-CERTIFIFCATES-NOT-SENT-BY-CLIENT. I doubt we need to
standardize that however.

-- larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, July 14, 2005 4:04 PM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [email-masked]; Stefan Santesson;
[email-masked]; [email-masked]
Subject: Re: What's in a Name?

Jeffrey Hutzelman wrote:
> 
> 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).

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: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 14 Jul 2005 19:44:54 -0400

> standardize that however.

That seems sort of silly.  Given that the most likely handling of 
TD-INVALID-CERTIFIATES is to complain at the user, why not allow it to 
include certs not sent by the client, and include a Name?  I'd expect this 
would make both KDC and client implementations simpler.

-- Jeff