> -----Original Message----- > From: Dean Willis [mailto:[email protected]] > Sent: Tuesday, March 31, 2009 12:53 PM > > Here's how I understand it to work: > > If the signing cert is [email protected] instead of domain.com, then the > middlebox would need to work with a CA to mint a cert having that full > name. A more typical scenario would have the middlebox use a cert with > name "domain.com". The verifying node can tell the difference.
Not as I read 4474. The verifier will be getting a From AoR of [email protected], and a cert for domain.com. That passes the verification check. The verifier had no idea that the original cert was for "[email protected]", because it won't be downloading that cert, because the Identity-Info header would have been changed to point to the domain-wide cert, and the signature would have been recalculated using the domain-wide cert. (assuming a middlebox in the domain wanted to do this) Again, this isn't really a problem - presumably you trust your own domain. I was just pointing out that the protected portion of this is domain-to-domain, not end-to-end. Most people are fine with that, as am I. -hadriel _______________________________________________ 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
