----- Original Message ----- From: "Joseph Salowey (jsalowey)" <[email protected]> To: "Juergen Schoenwaelder" <[email protected]>; <[email protected]> Sent: Saturday, March 06, 2010 2:01 AM
> > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of Juergen Schoenwaelder > > Sent: Friday, March 05, 2010 4:26 PM > > On Mon, Feb 22, 2010 at 05:54:48PM +0100, Juergen Schoenwaelder wrote: > > > > > Both transport receiver and transport sender implementations MUST > > > provide means to generate a key pair and self-signed certificate > in > > > the case that a key pair and certificate are not available > through > > > another mechanism. > > > > > > I do not know the idea behind this requirement is or how I comply to > > > it. Is this expressing a requirement for the management interface of > > > the box? Or is the idea that this is used in some automated fashion > > > (which likely does not make sense but would be harmful if read this > > > way). > > > > This text seems to be unchanged in -02 and I still do not know how I > > implement this MUST. On Unix systems, people use tools such as openssl > > to create certificates etc. while a syslog implementation would > > typically links against a DTLS library and would not have itself a > > builtin option to create a self-signed certificate. So is this text > > putting up an implementation requirement that a syslog daemon must > > have a _built-in_ option to create a self-signed certificate? My > > concern is that key / certificate management is something pretty > > unrelated to the syslog over DTLS transport implementation itself and > > hence it is somewhat unclear how to implement the MUST. > > > [Joe] There was some discussion of this on the list. The conclusion was > that this was not a GUI requirement but could be met by a script to > generate a certificate an configure its use, which didn't see onerous to > implementers. The same text is in the syslog TLS RFC. The key point is "The same text is in the syslog TLS RFC. " We established consensus on this and got it accepted by all parties (IETF, IESG etc) so there needs to be a very good reason to change it, and I have not yet heard one. > > > The transport receiver and transport sender SHOULD provide > mechanisms > > > to record the end-entity certificate for the purpose of > correlating > > > it with the sent or received data. > > > > > > What is an end-entity certificate? And how do I correlate sent or > > > received data? > > > > The second part has been clarified in -02 but I still wonder what an > > "end entity certificate" is. Probably this is meant: > > > > The transport receiver and transport sender SHOULD provide > > mechanisms to record the certificate or certificate fingerprint of > > the remote endpoint for the purpose of correlating an identity with > > the sent or received data. > > > [Joe] End entity is RFC 5280 terminology. It refers to the owner of the > public key that is used in the authentication versus a certificate > authority that signs certificates. > > > > [...] Once the transport receiver gets a close_notify from the > > > transport sender, it MUST reply with a close_notify. > > > > > > Is it our job to define this? Does DTLS not specify how to handle > > > such DTLS alerts? > > > > I am still wondering why we need to specify this... > > > [Joe] This is the same text as we used in the syslog TLS document. That > being said it is likely redundant. The key point is "This is the same text as we used in the syslog TLS document. " We established consensus on this and got it accepted by all parties (IETF, IESG etc) so there needs to be a very good reason to change it, and I have not yet heard one. Tom Petch > > /js > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
