Re: [certid] What security does SRV-ID add when DNS-ID will always match?

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

On 3/30/11 10:17 PM, Matt McCutchen wrote:
> On Wed, 2011-03-30 at 15:49 +0200, Peter Saint-Andre wrote:
>> You're right. Jeff and I looked at this issue in detail and worked with
>> our sponsoring AD (Alexey Melnikov) to address it during AUTH48. This
>> was a bit challenging because we wanted to keep the changeset as small
>> as possible. Although we considered more significant modifications, we
>> ended up doing two things in Section 6.2.1 (which defines the rules for
>> constructing a list of reference identifiers)...
>>
>> 1. Changed MUST to SHOULD for DNS-ID:
>>
>> ###
>>
>>   Using the combination of fully qualified DNS domain name(s) and
>>   application service type, the client constructs a list of reference
>>   identifiers in accordance with the following rules:
>>
>>   o  The list SHOULD include a DNS-ID.  A reference identifier of type
>>      DNS-ID can be directly constructed from a fully qualified DNS
>>      domain name that is (a) contained in or securely derived from the
>>      inputs (i.e., the source domain), or (b) explicitly associated
>>      with the source domain by means of user configuration (i.e., a
>>      derived domain).
>>
>> ###
>>
>> 2. Added a paragraph clarifying the need for the change from MUST to SHOULD:
>>
>> ###
>>
>>      Which identifier types a client includes in its list of reference
>>      identifiers is a matter of local policy.  For example, in certain
>>      deployment environments, a client that is built to connect only to
>>      a particular kind of service (e.g., only IM services) might be
>>      configured to accept as valid only certificates that include an
>>      SRV-ID for that application service type; in this case, the client
>>      would include only SRV-IDs matching the application service type
>>      in its list of reference identifiers (not, for example, DNS-IDs).
>>      By contrast, a more lenient client (even one built to connect only
>>      to a particular kind of service) might include both SRV-IDs and
>>      DNS-IDs in its list of reference identifiers.
>>
>> ###
> 
> Unfortunately, this change does not solve the problem.  Consider the
> following three client behaviors with respect to presented identifiers:
> 
> 1. Accept only an SRV-ID.
> 2. Accept an SRV-ID or a DNS-ID.
> 3. Accept a SRV-ID, or accept a DNS-ID if there are no SRV-IDs.
> 
> Both the old and new versions of the spec allow #1 and #2, but there is
> no way consistent with the spec to achieve #3 because the first sentence
> of section 6.2.1 requires that the reference identifier list be
> independent the presented identifier list.  And #3 is what is required
> for existing applications that use DNS-IDs to transition smoothly to
> SRV-IDs and achieve the highest level of security supported by both
> sides.

I think that this is a matter of local policy -- a client could prefer
SRV-IDs yet still accept DNS-IDs, and as far as I can see that behavior
is not expressly forbidden by the spec.

However, in order to explicitly specify that the client's behavior would
be modified based on what the server presents, we would have needed to
change the entire processing model from what I call the inclusion
approach (if there is an identifier type that you might want to check
then you simply include it in the list of reference identifiers) to what
I call the conditional approach (the client's processing is conditioned
on the presented identifiers that it finds in the server's certificate).
Although Jeff and I considered making that change, the spec has always
been based on the inclusion approach, so modifying it to use the
conditional approach would have necessitated a very significant rewrite
at this late stage in the lifecycle. Jeff and I, and our responsible AD,
were simply not comfortable with performing such major surgery during
AUTH48.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/