RFC Errata
RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011
Note: This RFC has been obsoleted by RFC 9525
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3090
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeff Hodges
Date Reported: 2012-01-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27
Section 6.4.3 says:
6.4.3. Checking of Wildcard Certificates
A client employing this specification's rules MAY match the reference
identifier against a presented identifier whose DNS domain name
portion contains the wildcard character '*' as part or all of a label
(following the description of labels and domain names in
[DNS-CONCEPTS]).
For information regarding the security characteristics of wildcard
certificates, see Section 7.2.
If a client matches the reference identifier against a presented
identifier whose DNS domain name portion contains the wildcard
character '*', the following rules apply:
1. The client SHOULD NOT attempt to match a presented identifier in
which the wildcard character comprises a label other than the
left-most label (e.g., do not match bar.*.example.net).
2. If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
3. The client MAY match a presented identifier in which the wildcard
character is not the only character of the label (e.g.,
baz*.example.net and *baz.example.net and b*z.example.net would
be taken to match baz1.example.net and foobaz.example.net and
buzz.example.net, respectively). However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard
character is embedded within an A-label or U-label [IDNA-DEFS] of
an internationalized domain name [IDNA-PROTO].
It should say:
[ no firm test suggestions just as yet, please see below ]
Notes:
RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier
section 6.4.3 does not specify how many labels must be in a wildcarded presented identifier. I.e., it leaves open the possibility that the following presented identifiers could be matched against actual domain names..
*
*.
*.com i.e. *.<fill in TLD here> e.g.: *.uk or *.co.uk
*U i.e. *<fill in portion of TLD here> e.g.: will match AU, EDU, CU
etc. etc.
If actual TLS/SSL implementations (e.g. web browsers) were to make valid matches as shown above, then someone could ostensibly obtain a cert (c.f. diginotar) for one of them and then go and MITM large swaths of domain name space.
Note that the discussion of wildcards in Section 7.2 of security considerations identifies the public suffix issue in passing, but only as one of a set of issues why the spec discourages use of wildcard certs.
Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".
Likely the approach will need to consist of a "SHOULD" declaration and some hand-waving about how "matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations."
PSA: This issue needs to be addressed, but doing so by means of an erratum is not the best way to go about having this conversation. Marking as "Hold For Document Update" to make sure we don't lose track of the issue. -- Peter Saint-Andre