Subject: RE: CONSENSUS CALL: KDC certs part 1

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

Nicolas Williams wrote:
> But we still have the problem that we
> either can't apply name constraints to id-pksan or we have to explain
> how.

Name constraints are defined to partition a name space; this mechanism
appears to be useful when the name space is allocated hierarchically.

Kerberos realms, however, are not hierarchical in general (except domain
style realm names); that means we do not have a name space to partition.
For example, one can not assume there is any relationship between
NTDEV.MICROSOFT.COM and NTTEST.NTDEV.MICROSOFT.COM.

Therefore I would tend to suggest it is misleading, therefore not
helpful to define generic name constraints for id-pksan otherName. 

Paul pointed out that there are scenarios where the notion of name
constraints would be helpful, but it appears to me we have a
type-mismatch between id-pksan otherName and name constraints. We could
propose new new name constraints for ik-pksan otherName when the realm
name is a domain style realm name, but it does not strike me as the
right thing to do by requiring the CA to support this new extension and
the client to process them in order to deploy PKINIT. 

For now I tend suggest it is sufficient to have a local policy table
that specifies for which realms a CA is allowed to issue KDC
certificate.

Note that even if we have invented new name constraints for id-pksan
otherName, the client still need to be configured in order to trust the
name constraints in the CA's certificates.

-- Larry

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

On Wed, Aug 31, 2005 at 12:33:25AM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, August 30, 2005 23:10:54 -0500 Nicolas Williams 
> <[email-masked]> wrote:
> 
> >On Tue, Aug 30, 2005 at 11:31:53AM +0100, Stefan Santesson wrote:
> >>I have no problem with this approach in principle.
> >>
> >>However, I have a little problem with "SHOULD use name constraints"
> >>
> >>Name constraints is a protective measure by a CA and not by a
client.
> >>The client MUST "use" any name constraints present in the validated
> >>path. A CA however only applies name constraints when it is relevant
> >>(When it does not fully control or trust cross certified CAs)
> >
> >PKINIT is a very special PKI application though.  I think the client
> >really does want to apply/verify name constraints in the cert chain
of a
> >KDC cert because the KDC cert is a like a CA cert and the client has
to
> >talk the KDC.  Otherwise PKINIT clients will need more configuration,
in
> >a large PKI, than just trust anchors.
> 
> I'm afraid you're not making any sense.  The question of whether to
pay 
> attention to name constraints is not up to us, or to the PKINIT
client. 
> The name constraints extension MUST be critical, and verifiers MUST
check 
> them.  These requirements come from RFC3280.

I misread something Stefan wrote.  But we still have the problem that we
either can't apply name constraints to id-pksan or we have to explain
how.  Looking at RFC3280 it does seem like we could specify how to apply
name constraints to id-pksan.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Aug 2005 17:02:09 -0400

> appears to be useful when the name space is allocated hierarchically.

<wg chair hat off>

I think you're generalizing too much from the constraint forms that 3280 
actually specifies.  Just because the name types for which they define 
constraints happen to be heirarchical does not mean that all constraints 
must be heirarchical.  That is not how I would expect constraints for 
KRB5PrincipalName to work.

<wg chair hat on>

Anyway, much of this is moot.  The question of a name constraint form for 
KRB5PrincipalName was raised in the past, and we decided not to attempt to 
specify such a form in the core PKINIT document.  I'd be happy to see 
someone produce a _separate document_ describing such a constraint form, if 
someone wants to do it and if Sam agrees that work is within our charter. 
However, let's get PKINIT done first.

One more time...

- RFC3280 specifies that verifiers MUST process name constraints if they
  are present.  This is not up to client implementors and it is not up
  to us.  Amending RFC3280 is out of scope for this working group.  Since
  we already require that clients verify certificates according to RFC3280,
  no further text on this question is required.

- Stefan's original text suggested that CA's MAY use name constraints in
  the certs they issue.  As I said before, this is true whether we say it
  or not.  The only reason to say it is to suggest that they actually do
  so.  We can do that or not, but <wg chair hat off> since there is not
  yet a name constraint form defined for KRB5PrincipalName, it seems like
  a not-very-useful suggestion at this time. <wg chair hat on>

Let's get this wrapped up, folks.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 20:19:25 -0500

> NTDEV.MICROSOFT.COM and NTTEST.NTDEV.MICROSOFT.COM.

Domain-style realm names are pretty much all we have.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 20:21:55 -0500

>  a not-very-useful suggestion at this time. <wg chair hat on>

If we won't define name constraints for KRB5PrincipalName (even though
it seems like all it would take is a sentence or two, just like RFC3280
does for various SANs) then I think that suggestion needs to go.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Aug 2005 21:38:18 -0400

On Wednesday, August 31, 2005 08:21:55 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>  (even though
> does for various SANs)

The problem is that Kerberos principal names are rather more complex than 
any of the other name forms for which matching rules are defined in 
RFC3280.  Which means we'd have to spend some time coming up on a syntax 
and matching semantics we call can agree on.  At a minimum, I'd want to be 
able to specify constraints like

- Any krbtgt instance in any realm
- Any single-component principal in a specified realm
- Any principal in a specified realm, with any number of components
- A host-based SPN for a specific service and any host
- A host-based SPN for any service on a specific host
- A domain-based SPN for a specific service and domain and any host
- A domain-based SPN for a specific service and any domain and host
- A domain-based SPN for any service and host with a specific domain
- Only a specific principal name

So, this gets sort of complicated.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 22:13:59 -0500

> able to specify constraints like

Here we only care about KDC certs, and therefore only about realm names,
domain-style ones, which makes the task fairly easy.