Hi all, I have been silent so far on this topic, because I have not made my mind up yet. However, let me point you to some important fact:
APP-NAME would be e.g. "postfix", "kernel", "syslogd", ... So you have a potentially very large number of APP-NAMES all sent from the same syslogd. I think this does not make up for a good value that can be checked against in the cert. As I said: other than that, I do not yet have an opinion. Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Monday, March 20, 2006 4:58 PM > To: Miao Fuyou; Chris Lonvick (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Other syslog-tls Issues---Issue 1 and 2 > > Miao: > > > -----Original Message----- > > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > > Sent: Sunday, March 19, 2006 9:38 PM > > To: Chris Lonvick (clonvick); [EMAIL PROTECTED] > > Subject: [Syslog] Other syslog-tls Issues---Issue 1 and 2 > > > > > > [Issue 1]: Is it possible to use "generic certificate > for different > > host? > > Yes, this should not precluded. But it would be nice to make > the implications clear in security section. > > > The generic certificate is for specific application type. > > Could be specific to app type. Could be generic across other > aspect of commonality. For example, all hosts of a certain > type (say lab hosts). > > > [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- > > NAME(generic certificate)? > > I think any binding should be allowed. The default or > recommended one could be APP-NAME. > > I think we could communicate the type of binding in the cert > itself or make it completely configurable on hosts. > Communication of type of binding in cert can't be used for > security anyway, just for troubleshooting maybe. > > > APP-NAME binding makes authentication/ > > access control happens both in TLS handshake and Syslog message > > processing, is efficiency a problem? > > Not clear, what authentication is done on APP-NAME as part of > "Syslog message processing". > > Thanks, > Anton. > > > > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
