Dan, I think your straw-man has it backwards. Local policy isn't subject to standardization, so you can't write a requirement on it. But what you can do is say that the protocol can't constrain local policy in certain ways (e.g., require certain keys to be trust anchors). See my email to Dan Y for a concrete suggestion for a rewording.
--Richard Dan Wing wrote: > > >> -----Original Message----- >> From: Richard Barnes [mailto:[EMAIL PROTECTED] >> Sent: Friday, May 02, 2008 6:19 AM >> To: Dan York >> Cc: Dan Wing; 'SIP IETF' >> Subject: Re: [Sip] R-CERTS in >> draft-ietf-sip-media-security-requirements >> >> 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. > > Yes, that is what we want R-CERTS to say. > > Firefox 3.0b5 can distinguish between the certificates signed by > https://www.softarmor.com and https://sourceforge.net, because > the first is signed by a CA that Firefox has never heard of > (ca.softarmor.com) and the second is signed by a CA that Firefox > has in its trust list (geotrust.com). > > On the wire, I agree it is impossible to tell if one or both > of those signers is on Firefox's trust list. > > What R-CERTS is trying to explain is that we don't want to *rely* > on a list of trusted CAs to be carried around. Rather, the text > is trying to say that we want implementations to allow building > their own list of trusted certificates. That is, we want the > protocol and the implementation to be able to do something > functionally similar to Firefox's dialog box that shows > the certificate and asks if you want to allow it, or allows > you to pre-load a configuration file with certificates you > trust, etc. -- doing so allows us to avoid relying on everyone > in the world using some a-priori-agreed upon list of "trusted CAs". > >> 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. > > Perhaps it should dictate local policy, somewhat along the lines > of: > > <strawman> > > R-CERTS: > > Local policy MUST permit a mechanism for an authorized party to > install trusted certificates. Local policy MAY also use > trusted CAs. > > </strawman> > > -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
