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