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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
