Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Paul Leach" <[email-masked]>
Date: Wed, 25 May 2005 16:11:21 -0700

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, May 25, 2005 6:12 PM
> To: Sam Hartman; [email-masked]
> Cc: Paul Leach; Liqiang(Larry) Zhu; [email-masked]; 
> Stefan Santesson
> Subject: Re: PKINIT-26 changes: identifying the kdc certificates

> To accomplish that, I think we need to REQUIRE that clients 
> accept a KDC's certificate only there is some indication that 
> it is intended for use with Kerberos.

I totally agree.

> I can think of several possible such indications:
> 
> - Presence of the pkinit KDC keyPurposeId
> - Presence of the pkinit KDC keyPurposeId or the any purpose ID
> - Presence of an appropriate KerberosPrincipalName SAN
> - Presence of stefan's proposed SRV SAN, with appropriate contents
> - Client has been pre-configured with the KDC's cert or public key
> - Some vendor-specific extension

The keyPurposeId by itself is insufficient -- there needs to be some
sort of name. Whereas, the KerberosPrincipalName SAN is both necessary
and sufficient. In the long run, I'd prefer to go in the SRV SAN
direction, since it works for more than just Kerberos, but there may be
timing issues as it wends its way toward standardization. So, for the
short run, I'd be satisfied with the KerberosPrincipalName SAN.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 May 2005 22:01:40 -0400

We seem to be binding two problems together that traditionally are not
bound together in RFC 3280.  I'm uncomfortable with our choice and if
we do this we need to have a clear justification for why.

1) Is this cert appropriate to use as a pkinit cert

2) Does this cert refer to the KDC who I as a client want to talk to.

I'm also concerned that this discussion is diverging rather than
converging.