Re: [Uta] wrt draft-ietf-uta-email-tls-certs

[=JeffH <[e-mail]>]

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