Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Aug 2005 21:32:18 -0700

Good start.

I suggest the following changes to your text:

   permittedSubtrees MUST be present and excludedSubtrees MUST be
absent.
   
   The semantics for the KRB5Principal in the permittedSubtrees field is
defined as follows:
 
   The realm part of id-pksan otherName name constraint is treated just
like
   normal dNSname name constraints (see [RFC3280] section 4.2.1.11),
   except that realm matching is case sensitive; 

   If the principalName of a
   id-pksan otherName name constraint has name-type as NT-UNKNOWN and
zero name-string elements, the CA may
   issue certificates with any KRB5Principal that matches the realm name
   but is not a KDC certificate. 

   if the principalName of a
   id-pksan otherName name constraint has name-type as NT-SRV-INST and
   one component containing "krbtgt", the CA may issue KDC
   certificates for any realms that match the realm name.

   any other id-pksan otherName name contraints are not defined in this
   specification.
 
Note that a CA certificate can only have one instance of the name
constraints extension. So this definition could mean that we can not
have a CA issue client certs and KDC certs at the same time.

The above text can go to a separate section in the main body. The
following text can continue to stay in the security consideration
sections.

   In order to trust a KDC certificate that is certified by a CA as a
   KDC certificate for a target realm (for example, by asserting the TGS
   name of that Kerberos realm as an id-pksan SAN and/or restricting the
   certificate usage by using the id-pkkdcekuoid EKU, as described in
   Section 3.2.4), the client MUST verify that the KDC certificate's
   issuing CA is authorized to issue KDC certificates for that target
   realm.  Otherwise, the binding between the KDC certificate and the
   KDC of the target realm is not established.

   How to validate this authorization is a matter of local policy.
   However, absent careful consideration of alternatives that provide
   such validation, implementations SHOULD support configuration of
   specific sets of intermediate CAs and trust anchors, one of which
   must be on the KDC certificate's certification path [RFC3280]; and
   local policy SHOULD constrain for which realms the CAs are allowed to

   issue KDC certificates.

because this text only talks about client configuration, not the PKI
configuration.

Paul/Stefan/Nico, comments?

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, August 31, 2005 8:39 PM
To: Paul Leach
Cc: Jeffrey Hutzelman; Liqiang(Larry) Zhu; Stefan Santesson; Sam
Hartman; [email-masked]; [email-masked]
Subject: Re: CONSENSUS CALL: KDC certs part 1

On Wed, Aug 31, 2005 at 06:30:22PM -0700, Paul Leach wrote:
> I think it should be incumbent on an RFC which defines a new name
form,
> for which it would be useful to have name constraints, to also define
> the name constraint matching rules.

I think that's right.  But first I'd like to know if there's any
technical reason why couldn't do it.

I think we can just say:

   The realm part of KRB5Principal name constraints is treated just like
   normal DNS name name constraints (see [RFC3280] section 4.2.1.11),
   except that realm matching is case sensitive; the principalName of a
   KRB5Principal name constraint MUST have its name-type set to
   NT-UNKNOWN and zero name-string elements (meaning that the CA may
   issue certificates with any KRB5Principal that meets the realm name
   constraint and which is not a KDC certificate), or NT-SRV-INST and
   one component, "krbtgt" (meaning that the CA may issue KDC
   certificates for any realms that match the realm name constraint).

Or we could simplify and apply name constraints only to TGS princ names.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 23:42:56 -0500

>    permittedSubtrees MUST be present and excludedSubtrees MUST be

Why?

> have a CA issue client certs and KDC certs at the same time.

I don't agree.  First, I'm not sure about the first part, second, a
value of type NameConstraints can contain several permitted and excluded
GeneralSubtrees, and the ones that match on KRB5Principals of type
NT-UNKNOWN would not (as I would have it) match TGS names, and...

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Aug 2005 22:12:25 -0700

> Why? 
 
this is because your text seemed to imply permittedSubtrees, and I believe it would be fine to limit 
name constraints to permittedSubtrees only in this ID, to reduce complexity.
 
if you need excludedSubtrees too, you need to modify the text  a bit.

> I don't agree.  First, I'm not sure about the first part 
 
section 4.2 of RFC 3280, it says 
 
 A certificate MUST NOT include more than
   one instance of a particular extension.
 
>  the ones that match on KRB5Principals of type
well have you noticed that the two name constraints are mutually excusively.

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Wed 8/31/2005 9:42 PM
To: Liqiang(Larry) Zhu
Cc: Paul Leach; Jeffrey Hutzelman; Stefan Santesson; Sam Hartman; [email-masked]; [email-masked]
Subject: Re: CONSENSUS CALL: KDC certs part 1

Why?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Sep 2005 00:19:19 -0500

> if you need excludedSubtrees too, you need to modify the text  a bit.

If we want to reduce complexity then we can allow implementors to ignore
name constraints provided that local policy mechanisms exist to provide
control over what CAs can issue what KDC certs.

Consider an implementation that is pluggable with respect to matching
rules for name constraints on AnotherName etc.  What you propose would
add complexity, rather than remove it.

>    one instance of a particular extension.

Ok.

> well have you noticed that the two name constraints are mutually excusively.

?

It's clear that NameConstraints's subtrees are SEQUENCEs and so should
allow for what I'm proposing.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Aug 2005 22:23:31 -0700

> allow for what I'm proposing.

sure, but your text does not allow that, because KDC cert name constraints and client principal name constraints are mutually exclusive in your text, it does have to be that way.

also, I should have add "when domain style realms are used", also I notice that the client principal name constraints do not work with referrals, aka nt-enterprise-princial name type, but I can fix these.

Ok.

?