On 06/04/2008 5:01 AM, Pedro Melo wrote:
>
> On Jun 4, 2008, at 11:06 AM, Philipp Hancke wrote:
>
>> In example 4 (xep-220), you would generate the 'key' as
>>
>> { 'saramago.lit', ' ', 'pessoa.lit', ' ', 'therandomchallenge'}
>>
>> and then sign the resulting string with the pessoa.lit certificate.
>>
>> Then you send a (modified) dialback over the connection:
>> <db:result from='pessoa.lit' to='saramago.lit'>
>> somemarker;base-64-signature;base64-certificate-of-saramago
>> </db:result>
>>
>> If the remote server understands the crypto protocol and recognizes
>> the marker, it can reconstruct the message, verify the signature and
>> send the result (ex. 11).
>>
>> If the remote server does not understand the crypto protocol, it
>> will treat the key as an opaque string and try to verify it using
>> dialback.It's a good thing that we moved dialback out of rfc3920bis. :) > Nice. But the initial stream still needs to be addressed to the XMPP > host name and not the XMPP domain. And you have to do that before > receiving the <features> from the remote domain. And this is not > compatible with the current system. > > An alternative, we could also initiate the session as usual, from > pessoa.lit to saramago.lit, and announce this S2S multiplexing feature, > and it accepted, start the TLS handshake with the XMPP host name. This > would make it easier to deploy... Using this stream feature, we can > fallback to current s2s cleanly. Graceful fallback is a good thing, so if there is any way we can preserve it, I'm all in favor. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
