> -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, September 01, 2008 8:27 AM > To: Joseph Salowey (jsalowey); Martin Schütte; [email protected] > Subject: RE: [Syslog] Need your input on finalissueson > draft-ietf-syslog-transport-tls > > <inline> > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Joseph Salowey (jsalowey) > > Sent: Thursday, August 28, 2008 7:59 AM > > To: Martin Schütte; [email protected] > > Subject: Re: [Syslog] Need your input on finalissueson draft-ietf- > > syslog-transport-tls > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte > > > Sent: Wednesday, August 27, 2008 10:04 PM > > > To: [email protected] > > > Subject: Re: [Syslog] Need your input on final issueson > > > draft-ietf-syslog-transport-tls > > > > > > Chris Lonvick schrieb: > > > > have comments, please send them in. If you read these and > > > agree with > > > > the changes, please comment to the WG list as well so > we know that > > > > we're getting an adequate review. > > > > > > Looks good to me. Only one question: > > > > > > > === 1 === > > > > The '*' (ASCII 42) wildcard character is allowed in > > > subjectAltName > > > > values of type dNSName (and in Common Name, if used), > > > and then only > > > > as the left-most (least significant) DNS label in > that value. > > > > This > > > > > > Is this a MAY or a MUST? > > > > > [Joe] I think it is a MUST or RECOMMENDED. Other > applications allow > > wildcards to appear in certificates so it might be surprising for > > deployers if it is not supported in Syslog TLS. > > Mhh... I'd say it should be a RECOMMENDED at most. Otherwise, > we are back to the policy decision discussion we had earlier > this year. > > As a side-note, I find it quite counter-productive to allow > this at all. IMHO "MAY" is even too strong. This opens up a > can of worms, which leads to non-identification of the remote > peer. So far, we had a very strong position that the peer's > *identity* must be known but "our" instance can decide > whether or not it accepts the peer's identity. With wildcards > inside the certificate, that choice is partly moved over to > the remote peer. If we make it a MUST, I already see users > asking for a way to "turn off accepting wildcard > certificates". So in my opinion this is a bad choice. > Comparing to other protocols makes only sense if the share > the same security concerns, and I think syslog's are quite > unique (as has been stressed several times before by others > on this list when it came to requesting support for anonymous > peers;)). > [Joe] Today, there are CA's that issue certificates with wildcards in the hostname. It would be good if Syslog implementations could be configured to work with these CA's. It is not required that this support always be enabled. Would the addition help:
"The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName (and in Common Name, if used), 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 SHOULD provide the ability to enable support for these types of wildcards within the host name in the certificate. " > Rauber > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
