On Jul 14, 2008, at 2:11 PM, Adam Roach wrote:
On 7/14/08 11:24 AM, Dean Willis wrote:On Jul 13, 2008, at 1:05 PM, Hadriel Kaplan wrote:-----Original Message----- From: Dean Willis [mailto:dean.willis at softarmor.com] no, but garden.eden.com could could sign an identity header with a From: of adam at nostrum.com.Not according to 4474. The cert domain and From domain must match.But that part COULD be changed, if one adequately described other acceptance rules. One could potentially also "compound @" so we have an @nostrum defined in the context of @eden. Something like a signed uunet route.Of you could express it cryptographically. Well-Known-Root signs @eden; @eden signs @nostrum. Recipient can examine the cert and determine whether they trust the chain.
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 adam at nostrum.com calls mat at cisco.com. 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 Nostrum CA key to sign that cert!) , and then sign the request (replacing the Nostrum signature) using the new cert. Then mat at cisco.com 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.
This is apparently how some people intended RFC 4474 to be used. It's much looser cert-matching than we're specifying in draft-ietf-sip-certs.
Am I alone in being made nervous by this approach? It seems that I could, for example, use the well-known (hah!) softarmor CA cert to forge INVITES from our ADs, and unless you just happened to know that softarmor shouldn't be signing for Cisco and Neustar you're likely to believe me. After all, you believed the signature when I called you myself. Now, it does make it easier to track me down later . . . is that good enough?
-- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip