RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

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 GROUP
Area 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.

Report New Errata



Advanced Search