RE: Kerberos name constraints I-D

["Paul Rabinovich" <[e-mail]>]

	Stefan,

	Now I see where misunderstanding may have come from. The quoted
text from Section 4 tries to convey that a relying party will realize
that the name constraint is an "exact full name constraint" if it sees
(*in the name constraint*) a non-empty SEQUENCE (i.e., if the SEQUENCE
*in the name constraint* is empty, it's a realm-name match). I will
correct the wording in the next version.

	Cheers,
	PR

Paul Rabinovich | Software Architect | EXOSTAR LLC
13530 Dulles Technology Dr., Suite 200, Herndon, VA 20171

PH +1.703.793.7808 | FAX [phone]


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Thursday, September 20, 2007 3:02 PM
To: Paul Rabinovich; [e-mail]
Subject: RE: Kerberos name constraints I-D

Not as I read your document.

Yes you are safe when it is only a matter of the realm name.
However.

Section 4 states:

   A relying party recognizes an exact full name match constraint when
   the value of the name-string field of the type PrincipalName is set
   to a non-empty SEQUENCE.


Section 5 states:

5.2.  rfc822Name Name Constraint

   If present, an rfc822Name name constraint SHOULD be applied to all
   asserted Kerberos names with the name-type field of the type
   PrincipalName set to NT-SMTP-NAME.  To satisfy the constraint the
   asserted Kerberos name's name-string field MUST be a SEQUENCE with a
   single element that matches the rfc822Name in the name constraint
   according to the rules of RFC 3280 [2].


But. IF "asserted Kerberos name's name-string field MUST be a SEQUENCE
with a single element that matches the rfc822Name" Then the name-string
value is not an empty sequence, hence exact full name match applies
according to section 4.

It doesn't seem to add up


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Paul Rabinovich [mailto:[e-mail]]
> Sent: den 20 september 2007 11:46
> To: Stefan Santesson; [e-mail]
> Subject: RE: Kerberos name constraints I-D
>
>
>         Stefan,
>
>         To explain Section 4/5 relationship: let's say the EE cert
> asserts the Kerb name ("EXAMPLE.COM", (NT-SRV-HST, ("telnet",
> "foo.example.com"))). Somewhere up the chain there could be two
> constraints:
>
> Section 4: ("Kerb. name constraint", ("EXAMPLE.COM", (NT-UNKNOWN,
())))
> [exact realm name match; satisfied]
> Section 5: ("dNSName constraint", "example.com") [DNS domain match
> applied to "foo.example.com"; satisfied]
>
>         So the asserted name is valid if both name constraints are
> satisfied.
>
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Thursday, September 20, 2007 1:53 PM
> To: Paul Rabinovich; [e-mail]
> Subject: RE: Kerberos name constraints I-D
>
> In line;
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Paul Rabinovich [mailto:[e-mail]]
> > Sent: den 20 september 2007 06:17
> > To: Stefan Santesson; [e-mail]
> > Subject: RE: Kerberos name constraints I-D
> >
> >
> >         Stefan,
> >
> >         Thank you for your feedback. My comments are inline below.
> >
> >         Best regards,
> >         PR
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[e-mail]]
> > Sent: Tuesday, September 18, 2007 6:57 PM
> > To: Paul Rabinovich; [e-mail]
> > Subject: RE: Kerberos name constraints I-D
> >
> > Hi Paul,
> >
> > Thank you for posting the draft.
> >
> > I have looked through it and I have several minor comments on the
> > introduction I may recap in a later e-mail. I'll provide some more
> > general thoughts here:
> >
> > I general I think the technical approach is reasonable. However I'm
a
> > bit confused about whether section 4.2 is contradicting section 5 or
> > not.
> > Section 4.2. impose exact match full name match in all cases when
the
> > PrincipalName is a non-empty sequence, at the same time section 5
> seems
> > to suggest some other constraint rules if certain name types are
> being
> > used. This feels contradicting to me.
> >
> > <pr> Section 4 describes the newly-defined Kerberos name
constraints.
> > Section 5 describes how *other* name constraints currently defined
by
> > RFC 3280 should/may be applied to Kerberos names *in addition* to
the
> > Section 4 constraints. I'm actually inclined against this idea
(using
> > other constraints) but wanted to get feedback from others. </pr>
> >
>
> I'm still confused. How can you apply any constraints in addition to
> those described in section 4. Isn't it either or. You have to either
> apply the section 4 general rule OR the section 5 applicable rule,
> unless they are the same. When should you follow section 4 and when
> should you follow section 5?
>
>
> > The document is not clear on case matching, i.e. in what aspects
> > matching is case sensitive or not.
> >
> > <pr> I think Section 4 constraints should use RFC 4120's definitions
> of
> > name equivalence (which is case-sensitive).
>
> Fine, I just think it should be written out.
>
> > Section 5, assuming it's
> > left in the proposal/standard, should use the rules of the
> > corresponding
> > name type (e.g., a dNSName constraint applied to a Kerberos name
> > containing a DNS name in the principal name component will use
> dNSName
> > matching rules). </pr>
> >
>
> But then again I need to know when I apply section 4 rules or section
5
> rules. As it is now I don't
>
>
> > The document does not disclose the fact that KerberosString is an
> > IA5String (ASCII) and as such there are no direct I18N issues.
> > However. If one of the attributes expressed in an X.500 style name
> > would
> > originally be UTF8 with international characters. How would that be
> > handled in this situation. Is this described anywhere? and would it
> > affect name constraining?
> >
> > <pr> I need to think this one over, and will get to you on this
> > shortly.
> > </pr>
> >
> > The document clearly has leading sections being introduction,
> followed
> > by a normative specification. It would be better IMO if the leading
> > sections were bundled into one introduction section, possibly with
> > subsections.
> >
> > 5.1 talks about service names. FYI there is a new RFC defining a
> > Service
> > Name SubjAltName with name constraining rules (RFC 4985). Would that
> be
> > a relevant reference?
> >
> > <pr> I've read the RFC. It is related in the sense that it discusses
> > another type of names/name constraints. As I understand it, services
> in
> > RFC 4985 are DNS SRV services, and their name space is different
from
> > Kerberos service names (although I would imagine in theory they may
> > represent the same service). I won't mind including it as an
> > informative
> > reference. </pr>
> >
>
> Yes RFC 4985 only address DNS RR type service names. Only include it
if
> you think it makes any sense. I seems from your description that it
> does
> not.
>
>
>
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]] On Behalf Of Paul Rabinovich
> > > Sent: den 17 september 2007 09:06
> > > To: [e-mail]
> > > Subject: Kerberos name constraints I-D
> > >
> > >
> > >       Hello,
> > >
> > >       Attached, please, find the 0th draft of the I-D
> > > "Constraining Kerberos Names in X.509 Certificates". The I-D was
> not
> > > included in the Kerberos WG Charter. The chairs recommended that I
> do
> > > an individual submission. Since it concerns both Kerberos and PKI,
> > I'd
> > > like to solicit feedback from the PKIX WG.
> > >       There are a couple of issues I'd like to draw your attention
> > > to:
> > >
> > > 1) "Other" name constraints applicable to Kerberos names: (a) Is
it
> > > even a good idea to apply one type of name constraint to a name of
> a
> > > different type (RFC 3280 does not do this - with one exception for
> > > backward compatibility);
> > > (b) issuing CAs may label names as NT-PRINCIPAL or some such to
> > > circumvent these name constraints; (c) RFC 4120 is ambiguous about
> > > certain Kerberos names (e.g., NT-SMTP-NAME: Name in the form of an
> > SMTP
> > > e-mail name (e.g.,
> > > [e-mail]): is it always an RFC 822 name or it only looks
> like
> > > one?
> > > The same is true for NT-SRV-XHST and X.500 names, etc.)
> > > 2) I'm concerned about ambiguity of name encodings. E.g., in an
> > NT-SRV-
> > > XHST what is the encoding of the name-string field? Is it a left-
> to-
> > > right DN or right-to-left? I'd like to make sure the encoding
issue
> > is
> > > unambiguously resolved for all name types.
> > > 3) In RFC 4120: is it true that domain-style realm names never
> start
> > > with "."; it should be true but it's not stated there.
> > > 4) How are X500-style realm names encoded?
> > > 5) Should we do any pattern matching for "other"-style real names?
> My
> > > draft talks only about exact realm name match for them.
> > >
> > > I appreciate all feedback.
> > >
> > > Best regards,
> > > PR
> > >
> > > Paul Rabinovich | Software Architect | EXOSTAR LLC 13530 Dulles
> > > Technology Dr., Suite 200, Herndon, VA 20171 PH +1.703.793.7808 |
> FAX
> > > +1.703.793.7741