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

[Matt McCutchen <[e-mail]>]

On Wed, 2011-03-30 at 23:00 +0200, Peter Saint-Andre wrote:
> 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.

"Prefer" is vague.  Specifically, I would like the client to accept a
DNS-ID if and only if the certificate contains no SRV-IDs.  How is this
accommodated within the framework of the spec?  Clearly the reference
identifier must contain a DNS-ID.  Somehow, this DNS-ID must be
considered to match the presented DNS-ID if and only if the certificate
contains no SRV-IDs.

Section 6.1 says:

   4.  When checking a reference identifier against a presented
       identifier, the client matches the source domain of the
       identifiers and, optionally, their application service type.

Is it within the meaning of "optionally" for the client to elect to
match the service type (thereby preventing two DNS-IDs from matching) if
and only if the certificate contains at least one SRV-ID?  Section 6.5
only describes service type matching in the context of identifiers that
contain service type information.  Is it legitimate to "match the
service type" solely as a means of preventing identifiers that do not
contain service type information from being used?

> 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.

Right.

> Jeff and I, and our responsible AD,
> were simply not comfortable with performing such major surgery during
> AUTH48.

Sure.  But the alternative is to release the spec with the issue
unresolved and potentially have to later deal with a mess of SRV-ID
clients that achieve suboptimal interoperability and/or security.  Do
you judge that the first evil is lesser?

Obviously I've put you in an awkward situation, which I regret.  That
said, I don't think I'm wrong to frame the decision this way.

-- 
Matt