> -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 13, 2008 10:15 AM > To: Dan York > Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; 'Fries, > Steffen (CT)'; 'Dean Willis' > Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05 > > At Tue, 13 May 2008 08:38:33 -0400, > Dan York wrote: > > > > > > > Dan, > > > > > The wordsmithing task falls to me, I suppose. > > > > > > Here is another straw man, which I think captures your sentence > > > above your signature and your [0] comment: > > > > > > R-CERTS: > > > > > > The media security key management protocol MUST NOT require > > > using a trust anchor to validate credentials (e.g., a > > > certificate) or to obtain credentials (e.g., a private key) > > > used in the protocol. > > > > Your wordsmithing is fine by me. I also liked the discussion you > > included in section 4.9 which explains the rationale for this > > requirement more. > > > > 4.9. Certificates > > > > The discussion in this section relates > to R-CERTS. > > > > On the Internet and on some private > networks, validating another > > peer's certificate is often done > through a trust anchor -- a list of > > Certificate Authorities that are > trusted. It can be difficult or > > expensive for a peer to obtain these > certificates. In all cases, > > both parties to the call would need to > trust the same trust anchor > > (i.e., "certificate authority"). For > these reasons, it is important > > that authentication mechanisms that > utilize trust anchors not rely > > exclusively on such Certificate > Authority-issued certificates, but > > to > > also allow self-signed certificates. By > allowing the use of such > > self-signed certificates, an > out-of-band mechanism (e.g., manual > > configuration) can be used to trust a > peer's certificate. > > I was sort of OK with Dan's original text, though I probably > would have > wordsmithed it differently, but I don't agree with this > discussion at all. > Any certificate system can in principle be used with self-signed certs > by doing SSH-style fingerprint exchange. The question is whether there > is a practical deployment model that actually supports this. > > > Consider two examples, both using TLS: > > - HTTPS in the majority of cases is incompatible with manual > establishment > of peer credentials. You connect to a lot of different Web > servers and > it's not practical to obtain their certificates out of band.
But sometimes you have to. And, fortunately, almost every HTTPS-capable client allows you to accept a certificate that isn't signed by a CA that the HTTPS client trusts. For example, Firefox 3.0b5 complains about both of these certificates for different reasons: https://www.softarmor.com https://www.verisign.net > - IMAP over TLS is compatible with manual establishment of > peer credentials > because you connect with only one or two servers and you > already share > a shared secret (the password) so it's at least in > principle possible > to record their cert fingerprint. This is also why SSH works. > > So, this isn't fundamentally an issue of protocol encoding (as Richard > has observed) but rather of the context in which the protocol > is embedded. > > > So, I would rewrite this section as follows: > > On the Internet and on some private networks, validating another > peer's certificate is often done through a trust anchor -- a list > of Certificate Authorities that are trusted. It can be difficult > or expensive for a peer to obtain these certificates. In all > cases, both parties to the call would need to trust the same > trust anchor (i.e., "certificate authority"). For these reasons, > it is important that the media plane key management protocol > offer a mechanism that allows end-users who have no prior > association to authenticate to each other without acquiring > credentials from a third party trust point. Note that this does > not rule out mechanisms in which servers have certificates and > attest to the identities of end-users. > > And since I'm in the writing business, I would adjust R-CERTS > as follows: > > The media security key management protocol MUST NOT require > that end-users obtain credentials (certificates or private > keys) from a third-party trust anchor. Thanks. I will wait a few days for additional comments. -d _______________________________________________ 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
