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

[Eric Rescorla <ekr at networkresonance.com>]

At Fri, 25 Jul 2008 11:13:22 -0500,
Thierry Moreau wrote:
> 
> 
> 
> 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.

I don't think it's ambigous, but I'll try to add some clarifying
text.


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

Yes, this seems to me to be of relatively modest value. In any
case, this is a feature which could easily be added at some point
in the future if such a fake CA ever existed.

-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