On Mon, Mar 08, 2010 at 03:34:41PM +0100, tom.petch wrote: > ----- 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.
I am not convinced by the argument but I will shut up. > > > > 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. Same as above. It is just good to receive an answer to points raised. /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
