> On 7/17/08 7:23 PM, Dean Willis wrote: > > > > ------- > > I've been informed that despite what I incorrectly thought, > > transitive signing doesn't require any modification to RFC 4474. > > > > The 4474 spec requires that the subject of the cert used to sign > > correspond to the domain of the From. This is different from > > requiring that the common names match. So any SBC can re-sign > > anything at any time and break nothing, at the expense of > some crypto > > work. > > > > So, let's say [EMAIL PROTECTED] calls [EMAIL PROTECTED] Nostrum's AS > > might sign Adam's INVITE. Cisco's SBC might verify the signature, > > munge the fields, mint itself a cert with a subject of > "nostrum.com" > > (using its well-known Cisco CA key to sign that cert!) , and then > > sign the request (replacing the Nostrum signature) using the new > > cert. Then [EMAIL PROTECTED] would verify Cisco's signature, and > > transitive trust is created. Of course this doesn't say anything > > about why Michael should trust that signature, although in this > > simplest case the rationale is obvious. But for a 3rd service > > provider "in the middle", it is much less obvious. > > ------ > > > > I hastily typed "using its well known Nostrum CA key" instead of > > "using its well known Cisco CA key" in the last paragraph. > I knew what > > I meant, I just typed the wrong word. Sorry. > > > > This (as corrected) AFAIK cryptographically works. But it > doesn't work > > any better than P-Asserted-Identity and TLS. It still lacks a > > reversible chain-of-trust that is visible to the end user. > > > > I suppose the advantage is that, in the absence of an evil > > crypto-mangling SBC, you'd still get the benefit of > end-to-end (or at > > least authentication server to verifier) RFC 4474, which > MIGHT involve > > less transitive trust. But that doesn't seem too useful to > me. I think > > it would be much better to just patch RFC 4474 to work > through the SBC. > > > The key difference is that one merely requires an explanation of how > things can be made to work;
Publishing a document that describes how RFC4474 is expected to work with SBCs would be very valuable. Such a document is long overdue. -d > the other requires development of Another > Way To Do The Same Thing, which (in protocols) is pretty much > always a > bad thing -- to be reasonably interoperable, implementations > are forced > to implement both (or all of) the defined mechanisms. > > /a > _______________________________________________ > 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
