[Standards] XMPP Certificate checking algorithm
stpeter at stpeter.im
Fri Mar 21 20:54:07 UTC 2008
Justin Karneges wrote:
> 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.
You are correct, I think.
>>> 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? :)
Ok, deprecate it eventually. :)
>> 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).
OK we'll add some text about that.
>> 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.
I was assuming you'd return things like xmpp3.upenn.edu or whatever, so
what I proposed was incorrect and should be ignored.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards