Subject: RE: PKINIT-22 comments

From: "Paul Leach" <[email-masked]>
Date: Mon, 31 Jan 2005 15:48:18 -0800

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Monday, January 31, 2005 1:48 PM
> To: Paul Leach
> 
> But imagine a "open" PK mode where the KDC will issue a TGT to anyone
> with: a) a valid cert for many, or any paths in a very large 
> PKI, b) a cname authorized, explicitly or otherwise, by their cert.
> 
> In this case the KDC might have to find a client cert's cert 
> chain, unless the client furnished it.

In this mode, the client would have to send all of the certs.

I think this is a valid mode, but clients will have to be configured for
it.

I also think this won't be anywhere near the most common mode, and we
shouldn't make all clients pay for it all the time.

I also think we would have to specify how the cname and crealm are
derived from the cert in order to make this work (so that CAs know what
kind of certs to issue to enable it), and I'm not aware that the spec
currently does this (or at least not well enough).

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2005 03:16:41 +0100 (MET)

I think you have it all backwards, Paul.

For interoperability, the cert with full chain must be included by
the client.  The KDC may not even have the leaf cert (which is much
easier to handle if the CA and the KDC are _NOT_ tightly integrated,
i.e. when the user gets a new cert for whatever reason.

Only if the KDC happens to have not only the users certificate,
but also all certificates from intermediate CAs in the KDC database,
then the optimization of the client not sending the full path
will not cause a PKINIT failure.  So if you can propose a means
for the client to reliably know the KDC has full access to those
certificates (read *NO* (directory) lookup of intermediate CA certs),
then such an optimization is OK for the PKINIT spec.

The client shouldn't guess about the KDCs capabilities; if it doesn't
know for sure that the KDC has access to those certs, it MUST send the
full path.

I consider is entirely inappropriate for PKINIT to require a KDC
to either store all those certs in the KDC database and retrieve
them from there or to have the KDC look them up in directories.

PKINIT should NOT mandate implementation characteristics from the KDC,
and it should be up to KDC implementors to design how the actual
mapping from user certificates into KDC database entries is performed.

Why should PKINIT preclude a mapping based on a subjectAltName extension
that does not require user certificates to be stored in the KDC database?

Just because Microsoft is (already) stuck with a particular design
shouldn't mean that we require their design and (KDC) complexity from
all other implementors.

-Martin

Paul Leach wrote:
> I think this is a valid mode, but clients will have to be configured for it.
>