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

From: "Paul Leach" <[email-masked]>
Date: Wed, 25 May 2005 19:44:31 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, May 25, 2005 10:02 PM
> To: Paul Leach
> Cc: Jeffrey Hutzelman; [email-masked]; Liqiang(Larry) 
> Zhu; [email-masked]; Stefan Santesson
> Subject: Re: PKINIT-26 changes: identifying the kdc certificates
> 
> 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.

If it refers to a KDC and only a KDC (what else could the
KerberosPrincipalName with a cname of "krbtgt" refer to?) then use of an
EKU for item 1 is redundant. That's what makes this particular case
cause two traditionally separate problemns to be related.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 May 2005 23:02:29 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> If it refers to a KDC and only a KDC (what else could the
    Paul> KerberosPrincipalName with a cname of "krbtgt" refer to?)
    Paul> then use of an EKU for item 1 is redundant. That's what
    Paul> makes this particular case cause two traditionally separate
    Paul> problemns to be related.

Sure.  Redundancy however is not sufficient justification for relating
the two issues.  Consider the interactions between key usage and EKU.

If you claim something like CAs can generate the kerberos name but not
the EKU then I think you have a justification for relating the two
issues.

This isn't something I feel strongly about though.  I'd just like the
WG to carefully consider what it is doing and not be different than
other PK applications unless it needs to.