Fine with me. Rainer
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Tuesday, September 16, 2008 12:44 AM > To: tom.petch; [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 > > 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 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
