Switching the order of the 1st (wildcards) and 2nd (subjectaltname) bullets would IMHO make the flow more logical. Otherwise, looks good.
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
