> On Mon, 2011-01-17 at 11:57 -0800, =JeffH wrote:
> [...]
>
>> > - The examples of server certificates that include a SRV-ID (section
>> > 4.2) also include a DNS-ID
>> > - The server ID check succeeds if any reference identifier matches any
>> > presented identifier (section 6.3)
>> >
>> > it would appear that the DNS-IDs will always match, making the service
>> > types in the SRV-IDs irrelevant. Am I right?
>>
>> thx for the headsup, but I don't think so, see section 6.5...
>>
>> ###
>>
>> 6.5. Matching the Application Type Portion
>>
>>
>> If a client supports checking of identifiers of type SRV-ID and
>> URI-ID, it MUST also check the service type of the application
>> service with which it communicates (in addition to checking the
>> domain name as described above).
> [...]
>> ###
>
> Maybe I am misunderstanding how that section applies. Let's consider an
> example.
>
> Reference identifiers:
> 1. SRV-ID _imaps.example.net
> 2. DNS-ID example.net
However, according to 3d bullet of S6.3, the client would effectively do this
with #1..
1. _imaps.example.net => DNS domain name portion: "example.net"
service type portion: "imaps"
..before proceeding with seeking a match.
> Presented identifiers:
> 3. SRV-ID _xmpp-server.example.net
Also, the spec implies that the client would effectively do this with #3..
3. SRV-ID _xmpp-server.example.net => DNS domain name portion:
"example.net"
service type portion:
"xmpp-server"
(the spec could probably be more clear about this)
> 4. DNS-ID example.net
>
> The client checks each reference identifier against each presented
> identifier (section 6.3).
>
> #1 and #3: The service types differ, so no match.
> #1 and #4: One identifier specifies a service type and the other
> doesn't. The behavior in this case is not spelled out, but I would
> assume there is no match.
> #2 and #3: Ditto.
> #2 and #4: Neither identifier specifies service type, and the DNS names
> are the same. Is this a match? If so, we get the problem I originally
> described.
The matching details in this example isn't exactly what is intended by the spec
(but is perhaps not presented as clearly as it should be). I've added details
here..
#1 and #3: first, the DNS domain name portions "example.net" match. However,
the service type portions of "imaps" and "xmpp-server" don't match (we note in
the spec that one ought to ignore the "_" char in SRV-ID service type
portions). So #1 & #3 don't match.
#1 and #4: first, the DNS domain name portion "example.net" match, but #4
doesn't have a service type portion so no match.
#2 and #3: same as #1 and #4.
#2 and #4: the DNS domain name portions "example.net" match.
However, the "MUST" clause in S6.5 quoted above holds and thus this
match between #2 and #4 is insufficient on its own to declare a match.
> Are you saying that a client that "supports checking of identifiers of
> type SRV-ID and URI-ID" MUST NOT compare two DNS-IDs, because they do
> not contain the service type information that the client is required to
> check? If so, then in the following example:
>
> Reference identifiers:
> 1. SRV-ID _imaps.example.net
> 2. DNS-ID example.net
>
> Presented identifiers:
> 4. DNS-ID example.net
>
> we would get "no match", when it seems a match would be helpful for
> backward compatibility.
I think we may have intended to allow for the latter with the "SHOULD" clause
of the 2nd bullet of S6.2.1..
o If a server for the service type is typically discovered by means
of DNS SRV records, then the list SHOULD include an SRV-ID.
..i.e. if the client wishes to be more lenient in what presented idents it
checks against, it could leave the reference SRV-ID off it's list of reference
idents to use to check against the presented idents.
And so the resultant behavior is ambiguous given the way S6.5's "MUST" clause
is crafted where it says "If a client supports checking of identifiers of type
SRV-ID..."
It should probably say something like..
If a client supports checking of identifiers of type SRV-ID or
URI-ID, and identifiers of those type(s) are included in the
reference identifier list, then it MUST also check the service type...
so yes, good catch, thanks,
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
