RE: Kerberos name constraints I-D

[Stefan Santesson <[e-mail]>]

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.

The document is not clear on case matching, i.e. in what aspects matching is case sensitive or not.

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?

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?

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