Kerberos name constraints I-D

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

	
	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 [phone]