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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
