> > > > That's an interesting proposal. I didn't get if your intention is to > > sign both headers (From header with E.164 and > 'email-identity' header) > > or only the email-based one. > > For the purposes of my straw-man, you can assume (a) we have resolved > all problems with signing E.164s in From, or you can assume > (b) we have > not resolved any problem with signing E.164 in From -- either way, my > proposal still provides benefit: the called party can use the email- > style address to establish end-to-end identity with the calling party, > and can use that to establish an end-to-end SRTP session (using a > mechanism similar to your draft or the Wing/Kaplan draft). > Let's explore your proposal further regarding the problems discussed in the other two threads (sorry for mixing the email threads now, but it is close related to the migration proposal):
First problem: Weak PSTN numbers Proposal - Don't include the E.164 number in the signature if it was received from the PSTN (certificate fingerprint is still protected and bound to the email-style SIP URI of SIP Gateway provided in 'email-identity') - Include the E.164 number in the signature if not received from the PSTN That's independent from the concrete signing mechanism except that RFC 4474 does not cover the new header field Second problem: SBC traversal - If both identity information are signed it conflicts with SBCs modifying SDP information and therefore need to change the domain part of the SIP URI in the From header as well - If only the email-identity information is signed (by the Wing/Kaplan or Fischer draft), intermediary SBCs should not break the signature. However, the E.164 number has PSTN security level only as assumed above, but email-style is bound to certificate fingerprint and signed An straw man extension to your proposal, which mitigates the SBC traversal problem is to create two signatures. One signing the email-identity including the certificate fingerprint and which is protected end-to-end. The other one covering the From header field and which might re-newed during traversal by intermediaries. The disadvantage are for sure two signing processes. Kai _______________________________________________ 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
