Subject: RE: Do we need KRB5PrincipalName name constraints in PKINIT

From: "Paul Leach" <[email-masked]>
Date: Wed, 7 Sep 2005 10:25:22 -0700

I disagree that it is out of scope to talk about name constraints -- a
security considerations section should discuss all the relevant and
significant things needed to do a secure implementation and deployment.

I will also reiterate that either the PKI or local policy MUST apply
name constraints when there is more than one CA issuing KDC certs (and
the CAs are run by orgs that don't fully trust one another). Absent an
applicability statement that says PKINIT shouldn't be used in such a
situation, that seems to make it our responsibility to say how such
restrictions work.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 13:47:03 -0400

On Wednesday, September 07, 2005 Paul Leach <[email-masked]> 
wrote:

<wg chair hat on>

> A number of people on the list thought that we really should define one.

Well, I've seen you say this over and over again.  One person does not make 
a consensus of the WG.  If there are other people who feel that it is 
essential to define name constraints for KRB5PrincipalName in the core 
PKINIT document, please speak up.  The same goes, of course, for those who 
feel it is not essential.

> significant things needed to do a secure implementation and deployment.

It is not out of scope to mention name constraints.
It is out of scope to change or override the requirements of RFC3280.

<wg chair hat off>

And it is inappropriate to say that they SHOULD be used, because

- MUST (and SHOULD) are for implementors
- SHOULD means "do this unless you have a very good reason not to", which
  is not the same thing as "do it if your deployment situation calls for it"

> situation, that seems to make it our responsibility to say how such

The client MUST apply name constraints if they are present in the cert.  It 
cannot apply them if they are not present in the cert.

BTW, I disagree that it is at all relevant how many CA's there are or 
whether their operators trust each other.  The question is which CA's (or 
their operators) are trusted by the _client_ to issue certs for which 
KDC's.  And yes, if there is a CA that is trusted by the client to issue 
certs for some KDC's but not for others, then it must not accept certs 
issued by that CA for KDC's for which it does not trust that CA to issue 
certs.  However, name constraints are not the only way to implement such a 
policy.  For example, relatively simple configuration can be used to 
indicate which trust anchors are used for which realms.  (for the 
CS.CMU.EDU realm, use anchor X; for the ANDREW.CMU.EDU realm, use anchor Y; 
for the ATHENA.MIT.EDU realm, use anchor Z).

By all means, propose text that requires that clients actually have and 
implement policy about which CA's are trusted for which realms.  But please 
do not assert either here or in proposed text that the only way to 
accomplish this is by use of the name constraints extension, or that it is 
impossible to define suitable policy if we fail to define name constraints.

-- Jeff