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

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

OK, if there are no issues with the text I'll roll this into a new
version of the document.

-Scott-

> -----Original Message-----
> From: Hollenbeck, Scott 
> Sent: Monday, April 20, 2009 8:49 AM
> To: ietf-provreg@cafax.se
> Subject: Text Proposal for the TLS Usage Profile
> 
> 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