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 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). _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
