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(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf