[ietf-provreg] Text Proposal for the TLS Usage Profile

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Alexey sent me text to include in the 4934bis TLS Usage Profile.  How
does this look to everyone?

-Scott-
----------

If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks.  In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.

During the TLS negotiation, the EPP client MUST check its
understanding of the server hostname/IP address against the server's
identity as presented in the server Certificate message, in order to
prevent man-in-the-middle attacks.  In this section, the client's
understanding of the server's identity is called the "reference
identity".

Checking is performed according to the following rules and in the
specified order:

o  If the reference identity is a hostname:

   1.  If a subjectAltName extension of the dNSName [X509] type is
present
       in the server's certificate, then it SHOULD be used as the
       source of the server's identity.  Matching is performed as
       described in Section 7.2 of [RFC5280], with the exception that
       wildcard matching (see below) is allowed for dNSName type.  If
the
       certificate contains multiple names (e.g., more than one
       dNSName field), then a match with any one of the fields is
       considered acceptable.

       The '*' (ASCII 42) wildcard character is allowed in
subjectAltName
       values of type dNSName, and then only as the left-most (least
       significant) DNS label in that value.  This wildcard matches any
       left-most DNS label in the server name.  That is, the subject
       *.example.com matches the server names a.example.com and
       b.example.com, but does not match example.com or a.b.example.com.

   2.  The server's identity MAY also be verified by comparing the
       reference identity to the Common Name (CN) [RFC4519] value in
       the leaf Relative Distinguished Name (RDN) of the subjectName
       field of the server's certificate.  This comparison is
       performed using the rules for comparison of DNS names in
       bullet 1 above (including wildcard matching).  Although the use
of the Common Name
       value is existing practice, it is deprecated, and
       Certification Authorities are encouraged to provide
       subjectAltName values instead.  Note that the TLS
       implementation may represent DNs in certificates according to
       X.500 or other conventions.  For example, some X.500
       implementations order the RDNs in a DN using a left-to-right
       (most significant to least significant) convention instead of
       LDAP's right- to-left convention.

o  When the reference identity is an IP address, the iPAddress
   subjectAltName SHOULD be used by the client for comparison.
   In such case the reference identity MUST be
   converted to the "network byte order" octet string representation
   [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
   octet string will contain exactly four octets.  For IP Version 6, as
   specified in RFC 2460, the octet string will contain exactly sixteen
   octets.  This octet string is then compared against subjectAltName
   values of type iPAddress.  A match occurs if the reference identity
   octet string and value octet strings are identical.

If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients MAY give the user the opportunity to
continue with the EPP session in this case) or close the
transport connection and indicate that the server's identity is
suspect.  Automated clients SHOULD return or log an error indicating
that the server's identity is suspect and/or SHOULD close the
transport connection.  Automated clients MAY provide a configuration
setting that disables this check, but MUST provide a setting which
enables it.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se