[Standards] XMPP Certificate checking algorithm
justin-keyword-jabber.093179 at affinix.com
Thu Feb 21 20:58:03 UTC 2008
On Thursday 21 February 2008 9:49 am, Peter Saint-Andre wrote:
> I've had a chance to read RFC 4985 (sometimes travel is a good thing!).
> Here is my understanding...
> According to this spec, a certificate presented by an XMPP service would
> include an SRVName, i.e. an object identifier (OID) of id-on-dnsSRV,
> where the SRVName takes the following form:
> So what does this mean in practice?
> First let's take Shumon's example of upenn.edu, which resolves via SRV
> to jabber.upenn.edu. In this case, the certificate would include an
> SRVName of _xmpp.jabber.upenn.edu, which would help the connecting
> client (or server) to know that jabber.upenn.edu is the authorized
> domain for connecting to the canonical XMPP service at upenn.edu (e.g.,
> thus knowing that the DNS SRV lookup did not return poisoned results).
This is not my understanding.
If I resolve SRV for _xmpp-client._tcp.upenn.edu and receive
jabber.attacker.com as a result, and then I connect to jabber.attacker.com
and receive a certificate containing SRVName of
_xmpp-client.jabber.attacker.com, then I don't see the security improvement.
I was trying to reach upenn.edu, and only the DNS reply is claiming any
relationship between jabber.attacker.com and upenn.edu.
The RFC could probably be better worded, but what got out of it was that an
SRVName of _xmpp.upenn.edu would be present in the received certificate.
This would allow me to validate that the remote system is authorized to act
as upenn.edu for XMPP.
> > How should the certificate be validated if it does not include a CN or
> > dnsName and the validating application does not understand xmppAddr? And
> > will a responsible CA even issue certificates without a CN? I know that
> > the XMPP ICA / StartCom won't do that.
> If we go down this path, then:
> 1. I think that we probably want to deprecate use of the id-on-xmppAddr
> OID in server certificates, since the SRVName meets our needs (this
> would not apply to clients).
> 2. I think that we probably want to deprecate use of the dnsName form in
> server certificates.
RFC 4985 was released yesterday. Let's not deprecate the current standard
until some CAs actually support it, yeah? :)
> 3. I don't think we can tell CAs not to include a Common Name, since
> many CAs probably have a policy that a certificate needs to include a CN
> (as mentioned, I know this is true of StartCom, which is the root CA for
> the XMPP ICA). However, I think we can specify that the relying party
> (connecting client or server) must not treat the CN as a domain name for
> purposes of certificate validation (even if it says something like
> "jabber.org" or "upenn.edu"). In other words, the Common Name should be
> a human-friendly name like "The Jabber.org Project" or "The University
> of Pennsylvania", which is not used for certificate validation.
Yes. CN fields should be present for descriptive purposes. Using them for
domain validation has been deprecated for almost 8 years (of course, everyone
still relies on them for domain validation.. you can see how fast the
security industry moves).
> Open issue: should wee allow a certificate to contain multiple instances
> of the SRVName? This seems advisable, since the result of an SRV lookup
> can include multiple domain names. In this case, we need to specify the
> matching rules (e.g., if any one domain matches then the relying party
> should consider the certificate to be valid).
Assuming I haven't misread the RFC, you'd want multiple but for a different
reason: allowing a single server machine to act for many domains or protocols
with the same certificate.
More information about the Standards