Hi, (speaking as a technical contributor)
> [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. Do we need to be clear about when (i.e. for what usages) this translation needs to be done? Is this necessary before string comparisons, for example? > > 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. shouldn't we make the ability to disable wildcards a MUST-implement, so we can be sure the strong-security option will be available if an operator wants to disable them for security reasons? That would seem to be consistent with BCP61. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
