Re: [Sip] DTLS Certificate Request vs Self-signed EE Certificates vs R-EXISTING

[Eric Rescorla <ekr at networkresonance.com>]

At Fri, 25 Jul 2008 09:56:53 -0500,
Thierry Moreau wrote:
> Anyway, my comment is about DTLS protocol compliance and the use of 
> self-signed certificates. Maybe there are things I don't see, but I 
> wonder if the envisioned use of self-signed certificates is compliant 
> with DTLS, even assuming the "legitimacy" of accepting self-signed 
> certificates without a strong trust base in the PKI spirit.

It's explicitly compliant with DTLS. Here's what RFC 4346 says about
certificates (S 1)

   the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.


> Here are the technical details. I assume the DTLS server protocol entity 
> "S" wishes to accept either "self-signed" EE certificates or 
> certificates issued by a couple of trusted CA (requirement R-EXISTING). 
> "S" would send a DTLS certificate request message containing either an 
> empty list of CA distinguished names (meaning "I accept any CA") of a 
> list of CA distinguished name (meaning "I trust these CAs"). In the 
> latter case, the DTLS client protocol entity "C" would not be allowed to 
> send a self-signed EE certificate. In the former case, "C" would be 
> allowed to send any certificate it has on hand, including a self-signed 
> EE certificate.

Yes, both of these are legal in this instance. The basic setting
is one in which any certificate is accepted, but implementations
could of course be configured to require 3rd party certificates.


> A)	State explicitly that the empty list of CA distinguished names (in 
> DTLS certificate request messages) option applies. It is then preferable 
> to describe the self-signed EE certificate as a special case of e.g. 
> "any X.509 security certificate holding a public key that the end entity 
> controls (of which the end entity controls the private key counterpart)".

I don't have a problem with indicating that the server should 
provide a compatible CertificateRequest message, but honestly
I think this is redundant, since DTLS/TLS specify how to construct
the CertificateREquest.


> B)	Specify a public domain private key value (i.e. breached, snake-oil, 
> meaningless ...) and a dummy CA distinguished name for the corresponding 
> public key and let the EE auto-issue an X.509 certificate under this CA 
> as a replacement of certificate self-signature.

I don't think this is that great an idea. The semantics of self-signed
certs are commonly understood and I don't think this adds much
value.

-Ekr
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip