> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: Freitag, 18. April 2008 22:42 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; [EMAIL PROTECTED] > Subject: [Sip] What 4474 signs part-3 [was: Proposal to > Revise RFC 4474] > > ... > > So... I propose that once again the originator of the request > be given an option: it can sign the MIME body, or not, based > on its preference. This can be done in another parameter or > param value of the Identity-Info header, similar to the > Contact one proposed in part-2 of this thread; and again this > parameter does not need to be signed itself because forging > it or removing it implicitly breaks the signature calc > anyway. The authenticator can likewise decide if it wants to > accept a request with this parameter or not.
I think the flexibility of elements covered by a (RFC4474bis) signature is an interesting idea. RFC 4474 shall be applied for different scenarios and therefore the set of elements which needs to be signed vary. For the protection of the DTLS-SRTP fingerprint only a few elements need to be signed. However, the flexibility causes also some interoperability issues like B expected header field x to be signed whereas A doesn't sign it. The risk exists that both parties fall back to the least common denominator (all mandatory elements), which is not applicable resp. secure for all intended scenarios. So it could be useful to define some RFC4474 signature profiles. These profiles are also extendable for future use cases without a need to revise RFC4474bis again. Kai > > The semantics of this are such that the authenticator is > saying "me.com verified user [EMAIL PROTECTED] generated this > request with these To, From, and Date, but not necessarily > the SDP." This would be useful for spam avoidance, but not > much more. (just as 4474 arguably is) > If a srtp fingerprint is also signed, then it means a lot more. > > Alternatively, we could just recommend that such an > originator simply send offerless-Invite's, since that is > perfectly legal in 4474 and avoids this issue. But somehow I > don't think that would be such a good idea. ;) > > -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 > _______________________________________________ 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
