Hi Alexey, >On 02/02/2016 00:54, =JeffH wrote: >> >> >> I was taking a look at wrt draft-ietf-uta-email-tls-certs and noted that >> it says this in Section 3.. >> >> [...] >> Matching is performed according >> to the rules specified in Section 6 of [RFC6125], including the >> relative order of matching of different identifier types, >> "certificate pinning" and the procedure on failure to match. The >> following inputs are used by the verification procedure used in >> [RFC6125]: >> >> [...] >> >> The rules and guidelines defined in [RFC6125] apply to an email >> server certificate, with the following supplemental rules: >> >> [...various supplemental rules to add to those defined in RFC6125.. ] >> >> >> ..thus I am curious as to why draft-ietf-uta-email-tls-certs does not >> officially update RFC6125 -- should it not (in addition to updating four >> other RFCs as it notes) ? > >"Supplemental rules" are inputs to RFC 6125 procedure (such as use of >wildcards, use of CN-ID, etc.). I don't think the document updates RFC >6125. If you think something better than "supplemental rules" should be >used in this context, please let me know. Hm, here's the relevant portion of section 3 of.. [1] https://tools.ietf.org/html/draft-ietf-uta-email-tls-certs-09#page-4 The rules and guidelines defined in [RFC6125] apply to an email server certificate, with the following supplemental rules: 1. Support for the DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]) is REQUIRED in Email client software implementations. 2. Support for the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) is REQUIRED for email client software implementations that support [RFC6186]. List of SRV-ID types for email services is specified in [RFC6186]. For the ManageSieve protocol the service name "sieve" is used. 3. URI-ID identifier type (subjectAltName of uniformResourceIdentifier type [RFC5280]) MUST NOT be used by clients for server verification, as URI-ID were not historically used for email. 4. For backward compatibility with deployed software CN-ID identifier type (CN attribute from the subject name, see [RFC6125]) MAY be used for server identity verification. 5. Email protocols allow use of certain wildcards in identifiers presented by email servers. The "*" wildcard character MAY be used as the left-most name component of DNS-ID or CN-ID in the certificate. For example, a DNS-ID of *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com. Note that the wildcard character MUST NOT be used as a fragment of the left-most name component (e.g., *oo.example.com, f*o.example.com, or foo*.example.com). The above rules #1 through #4 appear to map one-for-one to the four bulleted rules beginning at the bottom of RFC6125 p-23 (in section 6.2.1).. [2] http://tools.ietf.org/html/rfc6125#page-23 Using the combination of fully qualified DNS domain name(s) and application service type, the client constructs a list of reference identifiers in accordance with the following rules: o The list SHOULD include a DNS-ID. A reference identifier of type DNS-ID can be directly constructed from a fully qualified DNS domain name that is (a) contained in or securely derived from the inputs (i.e., the source domain), or (b) explicitly associated with the source domain by means of user configuration (i.e., a derived domain). o If a server for the application service type is typically discovered by means of DNS SRV records, then the list SHOULD include an SRV-ID. o If a server for the application service type is typically associated with a URI for security purposes (i.e., a formal protocol document specifies the use of URIs in server certificates), then the list SHOULD include a URI-ID. o The list MAY include a CN-ID, mainly for the sake of backward compatibility with deployed infrastructure. I note that the above rules #1 through #3 from [1] are the same overall rules as the above ones from RFC6125 [2] -- they have just been cast specifically for the email use case, and they specify "tighter" normative requirements than done in RFC6125 [2]. E.g., in the rule #1 CN-ID presence is REQUIRED, whereas in RFC6125 it SHOULD be present. Rule #2 is a REQUIRED vs. a SHOULD in RFC6125 [2], and rule #3 is a MUST NOT vs a SHOULD. Rule #4 is a wash: MAY corresponding to MAY in RFC6125 [2]. Rule #5 appears to map to RFC6125 section "6.4.3 Checking of Wildcard Certificates".. [3] http://tools.ietf.org/html/rfc6125#section-6.4.3 ..and profiles the latter in the sense that it (Rule #5) stipulates the wildcard character MUST NOT be used as a fragment of the left-most name component, where RFC6125 [3] stipulates a MAY. This seems to me to be clearly "updating" or "profiling" RFC6125 normative language, in the specific email use case. thanks, HTH, =JeffH