At Mon, 5 May 2008 15:48:30 -0700, Dan Wing wrote: At Mon, 5 May 2008 15:48:30 -0700, Dan Wing wrote: > * R-CERTS now reads: > > The media security key management protocol MUST NOT constrain > the set of trust anchors that a peer can use to validate > certificates used in the protocol.
I don't mean to be difficult, but I don't think that this actually captures the relevant issue particularly well. One of the primary reasons why the RTPSEC work got started was that it became clear that one could not safely assume that end-users would have certificates which were verifiable by others. If we could assume that, then life would be a lot simpler. For instance, we could have ubiquitous S/MIME and use S/MIME signatures instead of RFC 4474. For that matter, we could use DTLS-SRTP without any screwing around with fingerprints, just based on the certificates. So, I don't think the requirement is that the protocol not constrain the set of trust anchors. [Honestly, I'm not really sure what that means. Does HTTPS meet this requirement?] Without trying to wordsmith it, I would say that the requirement is that the protocol be secure even if the users do not have credentials attested to by *any* trust anchor.[0] That is what the relevant distinction is between self-signed and third-party certificates. -Ekr [0] Incidentally, one of Dan's messages stated that he believed that IBE would be consistent with R-12. I suppose that might be technically true, but I think it pretty clearly does not meet the spirit of the requirement. In order to use an IBE system, the user has to get a private key from the PKG. This is just as inconvenient as what we are trying to avoid with this requirement, namely forcing the user to deal with the CA/PKG. _______________________________________________ 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
