Re: Review of draft-saintandre-tls-server-id-check

[Peter Saint-Andre <[e-mail]>]

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 [e-mail] 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/