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

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 10 Sep 2005 05:06:47 +0100

Sam,

I think you misunderstand my intent.

My intent is not to suggest that dNSName by default work as a
placeholder for realm names, because it can't.

But that does not prevent dNSName name constraints from being useful to
support certain local client policies.

Say that the clients of an organization are configured (under certain
conditions) to require the realm name of the KDC to be "consistent" with
a present dNSName in the KDC certificate. "Consistent" could in this
example be that there is a successful caseIgnore match between the realm
name and the dNSName in the KDC certificate.

_IF_ this policy is enforced in all clients of an organization, then the
PKI of that organization could constrain accepted realms for KDCs by
applying name constraints to the dNSName SAN when cross certifying CAs.

But you are right that the usefulness of constraining on dNSName SAN is
totally dependent on the local policy deployed in clients and that the
issuing CAs also support the policy by including dNSNAmes in the KDC
certificates.

But despite that, I still think this is a valid use case to show how
name constraints can be used and enforced in line with local agreements
and policies.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 9 september 2005 12:44
> To: Stefan Santesson
> Cc: Paul Leach; Jeffrey Hutzelman; Liqiang(Larry) Zhu; Nicolas
Williams;
> [email-masked]; [email-masked]
> Subject: Re: Do we need KRB5PrincipalName name constraints in PKINIT
> 
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> 
> 
>     Stefan> In my mind, all that PKINIT reasonably can do is to point
>     Stefan> out the need for a client to determine that a CA issuing a
>     Stefan> KDC certificate is authorized to do so for a particular
>     Stefan> realm and at most provide an example of how you can use
>     Stefan> constraining of dNSname to support such client policy.
> 
> Speaking as an individual, I am uncomfortable with a dnsname
constraint
> because we are not
> suggesting that people use or support dnsnames to name their realms.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2005 16:39:23 +0200 (MET DST)

> applying name constraints to the dNSName SAN when cross certifying CAs.

I strongly dislike the use of the term "local policy" for both,
(1) an individual and independent client configuration
(2) and an an organization-scoped level.

because (1) is primarily to protect the client
and (2) is primarily to enslave client and enforce organization-level
"policies", and (2) always impairs the real security of the client
in some way.

Name constraints by their very nature are a means for CAs to protect
their business model and restrict the use of specific certs to specific
scenarios.  This might protect the CA from certain liabilities and
misappropriation of specific certs.  But it is entirely up to the CA
to add extensions to individual certs, and a model where the client
security relies on a CA never ever issuing a single cert without
a particular set of extensions is IMHO completely broken.

(Name) constraints don't really protect a client, however.
One may conceive such extensions as "security features" if the client
software offer only a very a primitive trust configurability, but
it really isn't (a security feature).

It is entirely up to the CA to add any such extension to every single
certificate they issue, and only one of the trusted CAs has issued
some certs without them in the past, then there is a gaping hole.

A client configuration which enumerates all trusted KDC certs and
their realms is the most secure and most reliable configuration,
the most simple to implement, and it's the configuration that is
the easiest to explain to (novice) admins and end-users, and
(as far as the PKINIT document is concerned) to PKINIT implementors.

-Martin