RE: Kerberos name constraints I-D

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

	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>

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). 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>

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>

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