Protocol Action: '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)' to Proposed Standard (draft-saintandre-tls-server-id-check-14.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- '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)'
  (draft-saintandre-tls-server-id-check-14.txt) as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Alexey Melnikov.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/




Technical Summary
   Many application technologies enable secure communication between two
   entities by means of Internet Public Key Infrastructure Using X.509
   (PKIX) certificates in the context of Transport Layer Security (TLS).
   This document specifies procedures for representing and verifying the
   identity of application services in such interactions.

Working Group Summary

   This is not a WG document, however this document was extensively reviewed
   in the Apps Area (and in particular on [e-mail] mailing list), TLS and
   PKIX WGs. It was also presented in SAAG a couple of times.

   The document went to the first IETF LC in summer 2010. This raised awareness
   of the document and attracted many additional reviews.

   There were some discussions about the scope of this document, whether it should
   purely document what is implemented, or whether it should encourage better use
   of subjectAltNames. After many discussions on the Certid mailing the current
   document is leaning toward the latter.
   There were also some suggestions about support for IP addresses in subjectAltNames
   and description of use of self signed certificates, but Certid mailing list consensus
   was not to cover these topics in the document.

Document Quality

   XMPP (3092bis), draft-daboo-srv-email-05 (approved for publication) and 
   draft-igoe-secsh-x509v3 are referencing this document to describe TLS server
   certificate verification procedure. There are plans of making use of this document
   when updated IMAP/POP/SMTP procedure is specified.

   Also the document is describing best current practices for what to put into and
   how to verify TLS server certificates. While not all existing implementations comply
   with this spec, several implementations of it already exist.

Personnel

   Alexey Melnikov is the Responsible Area Director for this document.

RFC Editor Note

Section 1.8., paragraph 28:
>       Transport Layer Security [TLS] negotiation; in this specfication

s/specfication/specification/


Appendix A., paragraph 1:
>    recommendations in this specfication: email [EMAIL-SRV] and XMPP

s/specfication:/specification:/


Section 7.2., paragraph 1:
>          Implemenations MUST NOT match any form of wildcard, such as a

s/Implemenations/Implementations/

In Section 4.1, last paragraph, 1st sentence:

OLD:
   7.  Unless a specification that re-uses this one allows continued
       support for the wildcard character '*', the DNS domain name
       portion of a presented identifier SHOULD NOT contain the wildcard
       character, whether as the complete left-most label within the
       identifier (following the definition of "label" from [DNS], e.g.,
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       "*.example.com") or as a fragment thereof (e.g., *oo.example.com,
       f*o.example.com, or foo*.example.com).

NEW:
   7.  Unless a specification that re-uses this one allows continued
       support for the wildcard character '*', the DNS domain name
       portion of a presented identifier SHOULD NOT contain the wildcard
       character, whether as the complete left-most label within the
       identifier (following the description of labels and domain names
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       in [DNS-CONCEPTS], e.g.,
       ^^^^^^^^^^^^^^^^^
       "*.example.com") or as a fragment thereof (e.g., *oo.example.com,
       f*o.example.com, or foo*.example.com).

In Section 6.2.2, please replace the 1st sentence of the 2nd paragraph:

OLD:
   A mail user agent that is connecting via IMAP to the email service at
   "example.net" (resolved as "mail.example.net") might have four
   reference identifiers: SRV-IDs of "_imaps.example.net" and
   "_imaps.mail.example.net" (see [EMAIL-SRV]) and DNS-IDs of
   "example.net" and "mail.example.net".

NEW:
   A mail user agent that is connecting via IMAPS to the email service at
   "example.net" (resolved as "mail.example.net") might have five
   reference identifiers: SRV-IDs of "_imaps.example.net" (see [EMAIL-SRV]),
   DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, a CN-IDs
   of "example.net" and "mail.example.net".

In Section 6.4.3, 1st paragraph:

OLD:
   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 definition of "label" from [DNS-CONCEPTS]).
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^

NEW:
   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]).
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In Section 6.5, 1st paragraph, 1st sentence:

OLD:
   If a client supports checking of identifiers of type SRV-ID and
   URI-ID, it MUST also check the service type of the application
   service with which it communicates (in addition to checking the
   domain name as described above).

NEW:
   If a client supports checking of identifiers of type SRV-ID and/or
   URI-ID, and identifiers of those type(s) are included in the
   reference identifier list, then it MUST also check the service type
   of the application
   service with which it communicates (in addition to checking the
   domain name as described above).