Re: MSRP-ACM compatibility

Hi, 

>>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.

Chapter 4.1.2, which belongs to the comedia part of the ACM draft, does
refer to RFC4572, so my assumption so far has been that "using the
comedia part" would also include RFC4572 for TLS.

So, when talking about comedia, I guess we need to separate between
"using the comedia part" (which, for TLS, includes the fingerprint
attribute) and "using just the connection-direction parts of comedia".

And, even without the fingerprint, you still have the TLS collision
issue if both endpoints are "active".

>>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 to anotherfoobar.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.

Why doesn't the relay need to get the certificate information in legacy
MSRP then? I don't think we can assume that the relay belongs to the
same domain as both endpoints, can we?

I have a feeling that I am missing some piece of the puzzle here, and I
appologise for that, but I am still trying to figure out this is
specific to ACM :)

>>THIRD, if a fingerprint is to be provided to/from the relay when an  
>>MSRP message 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 think people should be allowed to participate in discussions and idea
brainstorming without automatically being "accused" of supporting
specific solutions :)

>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.)

As said before, I don't think this is about "one vendor".

Regards,

Christer