> > c) Terminology is inconsistent and at variance with that of > RFC5280; I > > assume that this cannot be implemented without a familiarity with > > RFC5280 and that its terminology is thus the only one we should be > > using. > > > [Joe] I agree we should be in line with RFC 5280. Which > terminology do you think is inconsistent? > > <tp> > > 'type iPAddress' is an oxymoron and may raise hackles (does > mine - iPAddress is of type OCTET STRING:-) RFC5280 > classifies it as a field, name form, component but never type. > > 'type ipAddress' see above and in addition 'ipAddress' does not exist. > > 'subjectAltName' is an extension and is always referred to as such. > > 'SubjectAltName' is a type, I think that 'subjectAltName' is meant. > > 'Common Name' is not used in RFC5280, rather 'common name', > likewise 'subject distinguished name' is preferred to > 'Subject Distinguished Name'. > > As I said, I regard familiarity with RFC5280 to be a > prerequisite for this work, and so expect (some) readers of > this I-D to notice these differences, and think the less of > this I-D that they should exist. > [Joe] OK, thanks. Here is a revision of the text. It probably still needs some work, but hopefully it is in the right direction.
"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: 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. 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. 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. 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." > Tom Petch > </tp> > > > > ----- Original Message ----- > > From: "tom.petch" <[EMAIL PROTECTED]> > > To: "Chris Lonvick" <[EMAIL PROTECTED]>; <[email protected]> > > Sent: Thursday, August 28, 2008 6:15 PM > > Subject: Re: [Syslog] Need your input on final > > issuesondraft-ietf-syslog-transport-tls > <snip> > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
