RE: Kerberos name constraints I-D
"Paul Rabinovich" <Paul.Rabinovich@exostar.com> Thu, 20 September 2007 20:03 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSEy-0000sU-VR for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 16:03:14 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYSEt-0000g4-Gy for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 16:03:08 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8KIkF60063173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 11:46:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8KIkFWC063172; Thu, 20 Sep 2007 11:46:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from Netmail1.exostar.com (netmail1.exostar.com [208.47.83.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8KIkDwM063152 for <ietf-pkix@vpnc.org>; Thu, 20 Sep 2007 11:46:13 -0700 (MST) (envelope-from Paul.Rabinovich@exostar.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Kerberos name constraints I-D
Date: Thu, 20 Sep 2007 14:46:12 -0400
Message-ID: <0E2D64FCAEB5C5458A494DC28270548E06DA1064@Netmail1.exostar.com>
In-reply-to: <A15AC0FBACD3464E95961F7C0BCD1FF006A2704CA9@EA-EXMSG-C307.europe.corp.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Kerberos name constraints I-D
Thread-Index: Acf0m6FwQRhkNNIdQwKqenHbym7AfAEo9VDAAAA58KAAQSFGAAA4S0kAACIAlTAAASyqYA==
From: Paul Rabinovich <Paul.Rabinovich@exostar.com>
To: Stefan Santesson <stefans@microsoft.com>, ietf-pkix@vpnc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8KIkEwM063160
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2
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:stefans@microsoft.com] Sent: Thursday, September 20, 2007 1:53 PM To: Paul Rabinovich; ietf-pkix@vpnc.org Subject: RE: Kerberos name constraints I-D In line; Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Paul Rabinovich [mailto:Paul.Rabinovich@exostar.com] > Sent: den 20 september 2007 06:17 > To: Stefan Santesson; ietf-pkix@vpnc.org > 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:stefans@microsoft.com] > Sent: Tuesday, September 18, 2007 6:57 PM > To: Paul Rabinovich; ietf-pkix@vpnc.org > 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf- > > pkix@mail.imc.org] On Behalf Of Paul Rabinovich > > Sent: den 17 september 2007 09:06 > > To: ietf-pkix@vpnc.org > > 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., > > user@example.com): 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
- Kerberos name constraints I-D Paul Rabinovich
- RE: Kerberos name constraints I-D Stefan Santesson
- RE: Kerberos name constraints I-D Paul Rabinovich
- RE: Kerberos name constraints I-D Stefan Santesson
- RE: Kerberos name constraints I-D Paul Rabinovich
- RE: Kerberos name constraints I-D Stefan Santesson
- RE: Kerberos name constraints I-D Paul Rabinovich
- RE: Kerberos name constraints I-D Stefan Santesson