(as individual) On May 1, 2009, at 9:01 AM, Christer Holmberg wrote:
Hi,To make this interop with MSRP relays, we would need more work. Relays are not involved in the SIP signaling, so there's noopportunity forthem to send a fingerprint. We would need some way for endpoints toget fingerprints from the relays, and include them in the signaling.Just for my clarification: how is that related to routing based on c/m/a=path, and possibly having a B2BUA which may modify the address information of the ACM client's c/m/a=path?It's specific to the idea of having TLS cert fingerprints sent in SIP for each relay. It's only needed in case where a middlebox modified the path attribute to modify the IP addresses or host names in the MSRP uris, creating the certificate mismatch we have discussed.A few questions: FIRST, RFC4572 already defines the usage of the fingerprint attribute,so wouldn't your issue also apply if you ONLY use COMEDIA, with relays?
If you use COMEDIA-TLS, yes. Not if just use RFC4145, or follow _just_ the connection-direction parts of the ACM draft.
SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the IP address/ports are not used for the certificate. So, as long as both the ACM client/SBC belong to foobar.dom, and the MSRP client/relay belong toanotherfoobar.com, the SBC and relay can have the same certificate as the client behind them. Or?
As far as Hadriel's comment, it depends on what one puts _in_ the subjectAltName field. You _could_ put just an IP address in there, although I submit that would be a bad idea.
But to put your statement more generally: If the, sbc, or other intermediary has a subjectAltName entry that matches the authority part of a client's adjacent MSRP device (i.e. the next hop in the a=path attribute), then we're fine.
The problem is, the SBC is not likely to be in the same domain as _both_ endpoints. So from at least one endpoint's perspective, there's likely to be a mismatch.
THIRD, if a fingerprint is to be provided to/from the relay when an MSRPmessage is sent, I guess it could be sent as a To/From-path URI parameter. Getting the fingerprint to/from the relay BEFORE an MSRP message is sent is of course more tricky.
A URI parameter would seem to be the least syntactically invasive approach.
(Reminder--I'm writing as an individual, not as chair)By the way, please do not take my replies to indicate that I support the idea that the simple WG specifying how to use fingerprints with relays. I don't necessarily oppose it either, but the work group will need to decide if the value of the c-line addressing part of the ACM draft is sufficient to make it worth the additional work and complexity.
In particular, I am skeptical about doing non-trivial changes to make MSRP work better across proprietary intermediaries without some better description of what will and will not work in the general case (i.e. not just what will work with one vendor.)