On Tue, 2006-03-21 at 18:00 +0800, Miao Fuyou wrote: > > > > Definitely no, a single connection will be used to deliver > > messages for multiple applications, so the ceritificate > > should be bound to the syslog sender and not any individual > > applications running on the sender. > > > > I infer from your sentence that "generic" certificate is not possible. Each > TLS connection is associated with only one certificate at most for each > direction. However, multiple app-name requires multiple certificate. It > conflicts TLS specification. Right?
right. > > > The question is how the receiver resolves the sender host, > > using reverse DNS? or it simply accepts any trusted > > certificates no matter what the name is. > > > > I don't think it is a problem, application should decide how to resolves the > sender host. If we are to propose that certificates should be bound to the name of the sender hosts, and receivers should check that the certificates contain a proper hostnames, then we need to propose what kind of information it needs to compare it to. Sure it can be a configuration item (e.g. client 10.10.10.10 should come with a certificate assigned to logsender.domain.com), but it is preferable to allow syslog connections from an unlisted set of hosts, (e.g. open to anyone with a valid certificate), in which case the configuration example I gave above does not apply. Receiver side certificates are easier, just like for servers in HTTPS, we have a hostname for them in the sender's configuration. So we either leave the SSL certificate binding undefined for the operators to decide, or we need to clarify how certificate is to be validated. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
