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

[Matt McCutchen <[e-mail]>]

On Thu, 2011-03-31 at 00:36 +0200, Peter Saint-Andre wrote:
> On 3/31/11 12:00 AM, Matt McCutchen wrote:
> > On Wed, 2011-03-30 at 23:51 +0200, Peter Saint-Andre wrote:
> >> On 3/30/11 11:45 PM, Matt McCutchen wrote:
> >>> 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. 
> >>
> >> Ah, I see the confusion. MUST has been changed to SHOULD in order to be
> >> consistent with what I have called the inclusion approach.
> > 
> > I'm not referring to the change in the document.  I meant that the goal
> > of accepting a DNS-ID in the case that the certificate contains no
> > SRV-IDs is impossible to achieve unless the (fixed) list of reference
> > identifiers contains a DNS-ID.
> 
> You are right that, on the inclusion approach, including a DNS-ID in the
> list of reference identifiers is the only way to achieve the behavior
> you desire.

My claim was that including a DNS-ID in the list of reference
identifiers is a necessary condition.  My question of whether the
behavior is actually consistent with the spec stands.

> However, in order for the client to vary its behavior based
> on the identifiers presented by the server, we would have needed to
> modify the spec to use the conditional approach. I'm sure you can
> understand that it was simply way too late to perform such major
> surgery, two months after IESG approval.

I have nothing more to say on this point except that I will trust your
judgment.  Congratulations on the publication of the RFC.  I look
forward to helping to resolve the issue in a future update, if that is
desired.

-- 
Matt