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; 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
