With respect to the proposed text for R-CERTS, I agree with Dean that this doesn't seem like a requirement on protocols, but on how protocols are operated. The set of trust anchors that peers choose is an operating policy choice of those peers, not an issue of protocol. Perhaps you could put some operating recommendations in the explanatory section, but I don't think this issue belongs in the requirements for the protocol.
One minor technical issue with the explanatory text: Both parties don't need to trust the same trust anchor, but each peer has to have a trust anchor that can be used to validate the other. --RLB Eric Rescorla wrote: > 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. > - 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. > > -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 > > _______________________________________________ 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
