> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Harrington > Sent: Wednesday, September 03, 2008 1:38 PM > To: 'syslog' > Subject: Re: [Syslog] Need your > inputonfinalissuesondraft-ietf-syslog-transport-tls > > 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? > [Joe] Yes, I think this section is missing some context: "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."
> > 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. > [Joe] In many cases this policy is left up to the CA as to whether to issue certificates of this type or not, however it has been pointed out on the list that there is a concern that the syslog administrator may not control the CA and may have some different policies than the CA. In this case a control would be necessary. I'd be ok with changing this to a MUST (or a SHOULD). > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
