On Fri, Mar 21, 2008 at 03:04:49PM -0600, Peter Saint-Andre wrote:
> Shumon Huque wrote:
> > Any comments on the following server certificate checking
> > algorithm?
> >
> > 1. (If implementation understands RFC4985) look for RFC4985 style
> > service identity in an otherName field (of type OID id-on-dnsSRV).
> > The expected identity should be:
> >
> > _xmpp-client.DOMAIN for client-server connections
> > _xmpp-server.DOMAIN for server-server connections
>
> Yes, you're right, it's _xmpp-client and _xmpp-server (not _xmpp).
> >
> > where DOMAIN is the JID domain.
>
> What do you mean by "JID domain"?
Ah, I mean the "domain" in the following ABNF from RFC 3920:
jid = [ node "@" ] domain [ "/" resource ]
Also described as the "Domain Identifier" in Section 3.2.
> > 2. Look for expected server identity (either JID domain or
> > explicitly configured server hostname) in:
> >
> > a. subjectAltName otherName field of type id-on-xmppAddr
>
> But I think we deprecate this for servers, so at least it should go
> after your (b).
Sure, that sounds reasonable.
> > b. subjectAltName dNSName field
> > c. subject DN's Common Name field
>
> Do we really want to check the CN? It's been deprecated for years.
I included it mainly for backwards compatibility. I'm sure
there are many (most?) certificates out there that include the
domain name only in the CN. I've seen quite a few other protocol
specs mention that the use of CN is permitted although discouraged
in favor of dNSName. 3920bis could do something similar.
> > Wildcard name matches could be allowed in (b) and (c).
>
> Yes.
>
> > After seeing Peter's note about the approved sieve notify
> > mechanism, it just occurred to me that another approach to
> > identify service names might be to use the xmpp uri scheme.
> > Has anyone considered this before?
>
> I don't think so.
>
> > In that case, you could just use the subjectAltName's existing
> > uniformResourceIdentifier field to store JID strings prepended
> > with "xmpp:".
>
> Back in the old days (RFC 3920) we didn't have an XMPP URI scheme.
>
> > Are there any advantages to this approach? It seems to have all
> > the functionality of id-on-xmppAddr without needing a special
> > otherName type. It provides the ability to specify client identities
> > which RFC4985 does not, if client certificate based authentication
> > is used. On the other hand, RFC4985 is able to differentiate the
> > c2s and s2s identities, which may be important, and more naturally
> > maps to their SRV records.
>
> I think I like the SRV approach better.
>
> Peter
Yes, I think I like the SRV approach also.
--Shumon.
