[Adium-devl] Ticket #8787 (XMPP cert checking)

[Peter Saint-Andre]

Shumon Huque wrote:
> On Wed, Feb 13, 2008 at 04:39:22PM -0700, Peter Saint-Andre wrote:
> 
>> But what is the user's JID? Is it deke at jabber.upenn.edu or is it
>> deke at upenn.edu? As far as I can see, your service is running on
>> jabber.upenn.edu:
> 
> Ah, sorry for not making that clear in my original message 
> (although it was implied by the _xmpp-client._tcp.upenn.edu
> SRV record). The JID is of the form "username at upenn.edu" and 
> the hostname of the jabber server is "jabber.upenn.edu".
>
>> $ telnet jabber.upenn.edu 5269
>> Trying 128.91.2.172...
>> Connected to jabber.upenn.edu.
>> Escape character is '^]'.
>>
>> So you have a cert for that service. The fact that an SRV record
>> redirects upenn.edu to jabber.upenn.edu is immaterial as far as the
>> certificates are concerned.
> 
> Well, if the revised spec ended up saying the cert has to match
> the domain-identifier in the JID, then it does matter. 

It will not say that. But it will say that if a c2s or s2s connection
for, say, gmail.com actually connects to talk.google.com then some human
user needs to explicitly approve of that (either via configuration or
policy). Exact wordsmithing still to be worked out. :)

> I was
> suggesting that it would have undesirable security properties
> if other non jabber services were located at the domain name
> corresponding to the JID domain-identifier. We'd like to deploy
> certificates corresponding to the actual hostnames of the servers.
> 
>>> Perhaps the best compromise is:
>>>
>>>   1. If the client software explicitly specifies the server hostname
>>>      to connect to, use that hostname in the certificate check.
>>>   2. If not, use the domain identifier portion of the JID.
>>>
>>> That way, we could use option (1) and avoid certificate check
>>> warnings, and satisfy our security concerns.
>> I think that's what we had agreed to earlier in the thread. The specs
>> don't say that yet, though.
> 
> Excellent. Thanks for clarifying that. It wasn't entirely clear to me 
> that this consensus had been reached. And it addresses my concerns!

Super. I'll add that to rfc3920bis in the next version:

http://tools.ietf.org/html/draft-saintandre-rfc3920bis

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080213/18be8e80/attachment.bin>