On 9/13/10 11:05 AM, Dave Cridland wrote: > On Mon Sep 13 17:52:59 2010, Shumon Huque wrote: >> Yes, but whether they are actually "current" best practices is >> debatable. I certainly would like them to become best practices. >> For example I don't believe any existing commercial CAs issue >> certificates with the SRVName or URI SAN name forms. >> >> > They do, I've seen sRVName SANs in some XMPP server certificates. > > >> > Do we have evidence that any existing >> > certification authorities issue certificates containing both an SRVname >> > for the source domain (e.g., example.com) and dNSName for the target >> > domain (e.g., apphosting.example.net)? Do we have evidence that any >> > existing application clients perform such checks? If not, I would >> > consider such complications to be out of scope for this I-D. >> >> I think the question is whether we have examples of applications >> that need to verify "combinations" of subjectaltname name forms in >> certificates. Stefan says there are, but so far no-one has offered >> up any public specifications of such apps. So, I think until we >> have them, I agree we can defer considerations of them to future >> documents. >> >> I think it's reasonable for this draft to consider multiple identity >> types in certificates (eg. common name, dNSName, SRVName) with the >> current matching rules of ANY. This might be needed to gradually >> transition an app from validating a host specific identity to an >> application specific identity. The current draft allows this. >> >> > Isode M-Link will check xmppAddr and dNSName (and I'll add in sRVName > soonish, and possibly URI). If no SANs of a supported type exist, then > it will fall back to a CN match. > > It will not check the dNSName against the result of a SRV DNS lookup, > ever, nor will it check a dNSName if it has already found a matching > xmppAddr (nor vice-versa). As such it's not checking combinations of SANs. > > Looking at the draft, it seems to read that I should check dNSName > first, and then, only if this matches, check xmppAddr or sRVName. This > seems odd - sRVName and xmppAddr (and URI) all contain a superset of the > data contained, so why look at dNSName if a more specific match exists? Earlier versions of this draft had somewhat elaborate rules about ordering of reference identifiers. Those rules were removed in -09 because folks on the certid@xxxxxxxx list argued persuasively that they were not necessary because "first match wins" is good enough. Naturally, an implementation might have a preference order of reference identifiers, but such an order is not mandated by this I-D. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf