RFC Errata
Found 4 records.
Status: Reported (3)
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: 5654
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen Friel
Date Reported: 2019-03-13
Section 7.4 says:
A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name.
It should say:
A more recent approach, formally specified in [TLS-EXT], is for the client to use the TLS "Server Name Indication" (SNI) extension when sending the client_hello message, stipulating the DNS domain name it desires or expects of the service. The service can then return the appropriate certificate in its Certificate message, and that certificate can represent a single DNS domain name. The client SHOULD include the "source domain" in the SNI extension and SHOULD NOT include the “derived domain”.
Notes:
There is nothing wrong with the text, however its missing some clarifying text.
When a client discovers a service using SRV, when it is doing TLS it should include the "source domain" in the SNI extension and SHOULD NOT include the “derived domain” in SNI. Now, this is obviously the correct thing to do. However, it doesnt explicitly state this anywhere in the RFC, or in RFC6066.
Errata ID: 5673
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael James
Date Reported: 2019-03-25
Throughout the document, when it says:
If the certificate will be used for only a single type of application service, then the service provider is encouraged to request a certificate that includes a DNS-ID and, if appropriate for the application service type, an SRV-ID or URI-ID that limits the deployment scope of the certificate to only the defined application service type.
It should say:
If the certificate will be used for only a single type of application service, the service provider is encouraged to request a certificate that includes a DNS-ID and, if appropriate for the application service type, an SRV-ID or URI-ID that limits the deployment scope of the certificate to only the defined application service type.
Notes:
All the sentences in the RFC (not just the one above) are written as pseudo code using IF...THEN. Normative English sentence structure the IF is a Conjunction for a Subordinating Clause. The THEN after the comma should be dropped to start the subject or main clause of the sentence.
Errata ID: 6325
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2020-11-06
Section 10.2 says:
[X.520] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The
Directory: Selected attribute types", ITU-
T Recommendation X.509, ISO Standard 9594-6,
August 2005.
It should say:
[X.520] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The
Directory: Selected attribute types", ITU-
T Recommendation X.520, ISO Standard 9594-6,
August 2005.
Notes:
Selected attribute types is X.520 not X.509
Status: Held for Document Update (1)
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