Hi Dan, Response below...
> If I recall previous discussions > correctly, the major concern was that we didn't want to get in a > situation where in order to use a key management protocol all parties > were *required* to obtain certificates signed by a formal Certificate > Authority. > > DY> So I think the *intent* of the requirement - as I understand it - > is still important to capture. What about merging R12 and R-CERTS by > simply replacing the "CA-issued" with "3rd-party-signed", as in: > > R-CERTS: If the media security key management protocol > employs certificates, it MUST be able to make use of both > self-signed and 3rd-party-signed certificates. > > DY> Or is that muddying things up even more? Yes :) The issue here is that "self-signed" certificates and "3rd-party-issued" certificates are indistinguishable -- in order to be an issuer for a certificate (including itself!) a certificate MUST be a CA certificate, so all self-signed certs are CA certs. And that means that there's no technical means to distinguish between "self-signed" certs and "3rd-party-issued" certs, so any protocol that tried to would be non-sensical regardless of this requirement. Really, the issue of which parties are trusted sign certificates is an issue of local authorization policy, not of protocol design. Regardless of the data items carried in the protocol, it is up to the communicating peers to decide which certificates are acceptable and which aren't. That means that this requirement has no effect as a selector among protocols (no protocol would violate it), and it creates precisely the confusion that you have described, namely that the question of which certificates are authorized signers is one of protocol design, not local policy. This is why I think that the requirement should just be removed: It's a no-op technically, and it creates confusion. --Richard _______________________________________________ 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
