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