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

[Thierry Moreau <thierry.moreau at connotech.com>]

Eric Rescorla wrote:

> 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.

It's not the server behavior that would benefit from a document 
clarification, it's the client's behavior. If the CertificateRequest 
message contains an empty list of distinguished names, it is valid for 
the client entity to send EITHER 1) a self-signed security certificate 
or 2) any certificate holding a public key it controls. The document 
ambiguity, as it stands, is whether 2) is allowed in the two drafts as 
it is in the bare DTLS.

> > 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.

It would allow a server to announce its preferred trusted CAs 
(fulfilling R-EXISTING) *AND* its willingness to accept "auto-issued" 
certificates. An EE having (genuine) certificates from CA-1 and CA-2 
would select among these two per server expressed preferences. I guess 
you see the point.

But admittedly, I can't speak much for the SIP application area.

Regards,


--

- Thierry Moreau

_______________________________________________
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