Here is the text I will put in the revised draft for this section: 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 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 that which is allowed in subject names 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. Thanks, Joe > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of tom.petch > Sent: Wednesday, September 10, 2008 6:03 AM > To: [EMAIL PROTECTED]; Chris Lonvick (clonvick) > Cc: [email protected] > Subject: Re: [Syslog] revised 5.2 text : please comment was: > RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > 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 > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
