Re: [certid] open issue: wildcards in component fragments

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

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.

###