Subject: RE: KRB5PrincipalName name constraints in PKINIT

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 1 Sep 2005 13:27:27 -0700

Jeffrey Hutzelman wrote:
> If we wanted pattern matching within a component name, we'd have to do
> 
> something more complex; I'm not sure that's necessary, but I'm willing
to > hear comments from others on that.

This is necessary for NT-enterprise-principal name, but where are we for
the WGLC of the referrals draft?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, September 01, 2005 10:29 AM
To: Stefan Santesson; Liqiang(Larry) Zhu; Nicolas Williams
Cc: Paul Leach; Sam Hartman; [email-masked]; [email-masked];
Jeffrey Hutzelman
Subject: RE: KRB5PrincipalName name constraints in PKINIT

On Thursday, September 01, 2005 18:13:11 +0100 Stefan Santesson 
<[email-masked]> wrote:

> I'm not sure but from what I see in your examples I wander if you
> wouldn't be much better off if KRB5PrincipalName was defined just as
an
> IA5String (or UTFString) expressing principalName and realm in the one
> string format you use in your examples (Separated by "@").
>
> That would probably make name constraints definition and processing a
> lot easier.

I don't think so.  My examples use the traditional string-representation

syntax for Kerberos principal names, just to make it them easier to 
understand for discussion purposes.  The current definition of 
KRB5PrincipalName is consistent with the way principal names are 
represented on the wire in the rest of the Kerberos protocol.

> I think we agree in principle. My shortage of functionality is simply
> related to my lack of knowledge of conventions defined for name
> semantics in principalName. As long as these semantics are well
defined,
> they can be used in name constraining matching rules.
>
> The relative complex structure of KRB5PrincipalName does however
> complicate things since all fields are mandatory which creates problem
> when you want to allow any value without using wild card characters.

Well, I think we safely can give empty components and realm names
wildcard 
meaning, and similarly allow a zero-length list of components to mean
"any 
number of components" (alternately, we could make the PrincipalName part

optional, as you suggested).  If we wanted pattern matching within a 
component name, we'd have to do something more complex; I'm not sure
that's 
necessary, but I'm willing to hear comments from others on that.

Part of the problem is that while there are some widely-followed
principal 
naming conventions (host-based service names, and single-component names

for users, and two-component names like "jhutz/admin" for privileged or 
special-purpose principals), there may be other conventions in use at
some 
sites.  And we've already invented one new principal name since work on 
4120 began (the domain-based service name, which IIRC was actually 
orginially a Microsoft proposal); who's to say there won't be more?