Yeees, I think so but ... Have we just introduced 'certificate subjects' where previously we have used 'subject names' eg as in the heading of this section? I assume that both refer to the same concept, in which case I would prefer 'than that which is allowed in subject names'.
Tom Petch ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, September 09, 2008 4:30 PM Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > Perhaps the text should be split to three bullets, describing the > normal case first, and special cases (wildcards in cert, wildcards > in local name) next? > > Like these (just rearranging the text, not changing the words): > > o Implementations MUST support matching the locally configured host > name against a dNSName in the subjectAltName extension field and > SHOULD support checking the name against the common name portion of > the subject distinguished name. > > o The '*' (ASCII 42) wildcard character is allowed in the dNSName of > the subjectAltName extension (and in common name, if used to store the > host name), and then only as the left-most (least significant) DNS > label in that value. This wildcard matches any left-most DNS label in > the server name. That is, the subject *.example.com matches the > server names a.example.com and b.example.com, but does not match > example.com or a.b.example.com. Implementations MUST support > wildcards in certificates as specified above, but MAY provide a > configuration option to disable them. > > o Locally configured names MAY contain the wildcard character to match > a range of values. The types of wildcards supported MAY be more > flexible than what is allowed in certificate subjects to make it > possible to support various policies for different environments. For > example, a policy could allow for a trust-root-based authorization > where all credentials issued by a particular CA trust root are > authorized. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Chris Lonvick [mailto:[EMAIL PROTECTED] > > Sent: 09 September, 2008 16:58 > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: [EMAIL PROTECTED]; [email protected] > > Subject: RE: [Syslog] revised 5.2 text : please comment was: > > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > Hi Pasi, > > > > On Tue, 9 Sep 2008, [EMAIL PROTECTED] wrote: > > > > > Switching the order of the 1st (wildcards) and 2nd (subjectaltname) > > > bullets would IMHO make the flow more logical. Otherwise, > > looks good. > > > > > > > I see your point but that would create a forward reference. > > The second > > bullet (subjectAltName) contains the line, "Locally configured > > names MAY contain the wildcard character to...". I'm > > thinking that the > > wildcard character should be defined before that. > > > > It could be swapped with a reference such as the following > > placed into the > > subjectAltName bullet, "Locally configured names MAY contain > > the wildcard > > character (see next bullet) to...". > > > > What does everyone think about this? > > > > Thanks, > > Chris > > > > > > > Best regards, > > > Pasi > > > > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] On Behalf Of ext Joseph > > >> Salowey (jsalowey) > > >> Sent: 06 September, 2008 01:11 > > >> To: Chris Lonvick (clonvick) > > >> Cc: syslog > > >> Subject: Re: [Syslog] revised 5.2 text : please comment was: > > >> RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > >> > > >> I added information on locally configured names with wildcards, > > >> clarified the ACE conversion is for comparison, and change > > >> the ordering > > >> of the bullets. I think this text should be pretty close now. > > >> > > >> Implementations MUST support certification path validation > > >> [RFC5280]. > > >> In addition they MUST support specifying the authorized > > >> peers using > > >> locally configured host names and matching the name against the > > >> certificate as follows. > > >> > > >> o The '*' (ASCII 42) wildcard character is allowed in > > >> the dNSName > > >> of > > >> the subjectAltName extension (and in common name, > > if used to > > >> store > > >> the host name), and then only as the left-most (least > > >> significant) > > >> DNS label in that value. This wildcard matches > > any left-most > > >> DNS > > >> label in the server name. That is, the subject > > *.example.com > > >> matches the server names a.example.com and > > b.example.com, but > > >> does > > >> not match example.com or a.b.example.com. > > Implementations MUST > > >> support wildcards in certificates as specified > > above, but MAY > > >> provide a configuration option to disable them. > > >> > > >> o Implementations MUST support matching the locally > > configured > > >> host > > >> name against a dNSName in the subjectAltName > > >> extension field and > > >> SHOULD support checking the name against the common > > >> name portion > > >> of > > >> the subject distinguished name. Locally configured > > names MAY > > >> contain > > >> the wildcard character to match a range of values. > > >> The types of > > >> > > >> wildcards supported MAY be more flexible than what is > > >> allowed in > > >> > > >> certificate subjects to make it possible to support various > > >> policies > > >> for different environments. For example, a policy > > could allow > > >> for a > > >> trust-root-based authorization where all credentials > > >> issued by a > > >> > > >> particular CA trust root are authorized. > > >> > > >> o If the locally configured name is an > > internationalized domain > > >> name, conforming implementations MUST convert it > > to the ASCII > > >> Compatible Encoding (ACE) format for performing > > >> comparisons as > > >> specified in Section 7 of RFC 5280. > > >> > > >> o Implementations MAY support matching a locally > > configured IP > > >> address against an iPAddress stored in the subjectAltName > > >> extension. In this case, the locally configured > > IP address is > > >> converted to an octet string as specified in RFC > > 5280, Section > > >> 4.2.1.6. A match occurs if this octet string is > > equal to the > > >> value > > >> of iPAddress in the subjectAltName extension. > > >> > > >> Cheers, > > >> > > >> Joe > > >> > > >>> -----Original Message----- > > >>> From: Chris Lonvick (clonvick) > > >>> Sent: Wednesday, September 03, 2008 1:44 PM > > >>> To: Joseph Salowey (jsalowey) > > >>> Cc: tom.petch; syslog > > >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] > > >>> Need your input on finalissuesondraft-ietf-syslog-transport-tls > > >>> > > >>> Hi, > > >>> > > >>> I'm going to take a stab at word smithing. I think there's > > >>> still some ambiguity in the section that Joe just proposed > > >>> and we may be able to resolve by putting in bullets. Please > > >>> look at this and give feedback. > > >>> > > >>> === > > >>> Implementations MUST support certification path > > >>> validation [RFC5280]. > > >>> In addition they MUST support specifying the authorized > > >>> peers using > > >>> locally configured host names and matching the name > > against the > > >>> certificate as follows. > > >>> o Implementations MUST support matching the locally > > >>> configured host > > >>> name against a dNSName in the subjectAltName > > >>> extension field and > > >>> SHOULD support checking the name against the common > > >>> name portion of > > >>> the subject distinguished name. > > >>> o Implementations MAY support matching a locally > > configured IP > > >>> address against an iPAddress stored in the subjectAltName > > >>> extension. In this case, the locally configured IP > > >> address is > > >>> converted to an octet string as specified in RFC > > >> 5280, Section > > >>> 4.2.1.6. A match occurs if this octet string is > > >>> equal to the value > > >>> of iPAddress in the subjectAltName extension. > > >>> o The '*' (ASCII 42) wildcard character is allowed in > > >>> the dNSName of > > >>> the subjectAltName extension (and in common name, if > > >>> used to store > > >>> the host name), and then only as the left-most (least > > >>> significant) > > >>> DNS label in that value. This wildcard matches any > > >>> left-most DNS > > >>> label in the server name. That is, the subject > > >> *.example.com > > >>> matches the server names a.example.com and > > >>> b.example.com, but does > > >>> not match example.com or a.b.example.com. > > >> Implementations MUST > > >>> support wildcards in certificates as specified > > >> above, but MAY > > >>> provide a configuration option to disable them. > > >>> o If the locally configured name is an > > >> internationalized domain > > >>> name, conforming implementations MUST convert it to > > >> the ASCII > > >>> Compatible Encoding (ACE) format as specified in > > >>> Section 7 of RFC > > >>> 5280. > > >>> > > >>> === > > >>> > > >>> Does this work for anyone? :-) > > >>> > > >>> Thanks, > > >>> Chris > > >>> > > >> _______________________________________________ > > >> Syslog mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/syslog > > >> > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
