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
Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: 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 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/
Ballot Text
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 certid@ietf.org 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).