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?
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf