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:[EMAIL PROTECTED]
no, but garden.eden.com could could sign an identity header with a
From: of [EMAIL PROTECTED]
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 [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 Nostrum 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.
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
