On 10/12/10 7:03 AM, Matt McCutchen wrote: > On Mon, 2010-10-11 at 15:16 -0600, Peter Saint-Andre wrote: >> On 10/11/10 2:31 PM, Martin Rex wrote: >>> I strongly disagree. the -09 wording: >>> >>> The client MUST fail to match a presented identifier >>> in which the wildcard character is contained within a label fragment >>> (e.g., baz*.example.net is not allowed and MUST NOT be taken to match >>> baz1.example.net and baz2.example.net) >>> >>> attempts to invalidate rfc-2818 through the use of "MUST NOT". >> >> The next version (-10) will make it abundantly clear that this I-D does >> not (and does not intend to) override, supersede, update, or obsolete >> the rules for verifying server identity provided in specifications for >> existing application protocols. On this point, Jeff and I have added an >> applicability statement to our working copy, which we hope to release in >> the next day or two once we've checked it against all the issues that >> were raised during IETF Last Call. > > This seems possibly disingenuous to me. The tls-server-id-check > document may not itself update RFC 2818, but do you really intend that > RFC 2818 never be updated in the future to use the tls-server-id-check > rules? In view of the likelihood of such an update, it seems unhelpful > to claim now that compatibility with RFC 2818 isn't our problem.
Shall I quote the text in our working copy? ### 1.3. Applicability and Audience This document does not supersede the rules for certificate issuance or validation provided in [PKIX], which governs any certificate- related topic on which this document is silent (e.g., certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths). Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate. This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols, such as those mentioned under Appendix A. However, it is the intent of the authors that the best current practices described here can be referenced by future specifications, including updates to specifications for the aforementioned existing application protocols as collected under Appendix A, if the relevant technology communities agree to do so. It is also expected that this document will be updated or obsoleted in the future as best practices for issuance and verification of PKIX certificates continue to evolve through more widespread implementation and deployment of TLS-protected application services over the Internet. The primary audience for this document consists of application protocol designers, who might reference this document instead of defining their own rules for the representation and verification of application service identity. Secondarily, the audience consists of certification authorities, client developers, service providers, and other members of technology communities that might re-use or "profile" the recommendations in this document when defining certificate issuance policies, writing software algorithms for identity matching, generating certificate signing requests, etc. ### _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
