> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
Behalf
> Of Juergen Schoenwaelder
> Sent: Friday, March 05, 2010 4:26 PM
> To: [email protected]
> Subject: Re: [Syslog] js review of draft-ietf-syslog-dtls-01.txt
> 
> 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 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. 

> /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
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog

Reply via email to