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