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"? > 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). > 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. > 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
