Subject: RE: PKINIT-22 comments

From: "Paul Leach" <[email-masked]>
Date: Mon, 31 Jan 2005 13:39:20 -0800

I think you are overstating how onerous looking up the client's
intermediate certs will be. In non-PK modes, the KDC has an entry for
every user; attached to it is that user's symmetric key; to validate the
pre-auth or encrypt the AS_REQ, the KDC has to look up the user's entry
to get the key.

In a PK mode, it can look up the entry and find attached to it the
intermediate certs. The entry is a little bigger; the complexity is not
greater, as it is all in the lookup function, not what the function
returns.

Paul

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Jan 2005 15:47:55 -0600

> greater, as it is all in the lookup function, not what the function

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.

---

From: Martin Rex <[email-masked]>
Date: Mon, 31 Jan 2005 22:59:11 +0100 (MET)

> greater, as it is all in the lookup function, not what the function

I did mention that the KDC may already have the certs, so that
no lookup would be required.

But certainly I don't want to see a use of Microsoft KDCs mandated
for PKINIT...

What about sites/implementations that do not want to add certificates
into the KDC database, but rather have their trusted (special-purpose)
CA issue certificates with a Kerberos principal name in it?

Suppressing the forward certification path from the protocol message
is an optimization.  I think it is OK to permit a client to perform
the optimization if it knows reliably the Server supports it.

In the general case, the client should send the full certification path.

-Martin