Re: francois' comments and why RFC4474 not used in the field

> > Strong identity makes it *harder* to build a phone-tapping 
> system.   
> > This
> > hop-by-hop signing thing that you are describing above, and Jon  
> > described at
> > the microphone, is transitive trust with extra CPU horsepower and  
> > something
> > you could fight better in a lawsuit when you learned that a 
> service  
> > provider
> > lied.  I don't see a service provider getting very interested in the
> > additional capex, opex, and business risk of doing such signing,  
> > especially
> > compared to the three proposals on the table which require 
> the service
> > provider do _no_ signing and no stronger attestation than today  
> > (same business
> > risk as today).
> 
> 
> You misunderstand the hop-by-hop signing approach I described. By  
> adding signatures, rather than replacing them, the original 
> media and  
> DTLS key identifier properties are preserved. The stack of 
> signatures  
> and new SDPs provide an audit chain for figuring out what 
> happened and  
> for a basis of transitive trust where end-to-end trust is not  
> existent, but do not impede the ability for end-to-end when the  
> endpoints have that capability.

You are right, I had misunderstood.  Your proposal is different
from the proposal that Jon described at the microphone.  However,
it would disclose the entire path which SP's appear reluctant to
do -- else they would not remove Via headers (I understand most
SPs, using SBCs, remove Via headers).

-d


_______________________________________________
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