Re: wrt draft-ietf-uta-email-tls-certs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]