Server authentication using X.509v3 certificates

[Douglas Stebila <douglas%stebila.ca@localhost>]

In the last call for draft-igoe-secsh-x509v3, Peter Saint-Andre has suggested that a more concrete mechanism be used for specifying how X.509v3 certificates map to server host names.  With his help, we have developed some suggested text, but would like the feedback of the SSH standardization community on whether this mechanism is appropriate.

The original text was:

>    For the purposes of server authentication, the mapping between
>    certificates and host names is left as an implementation and
>    configuration issue for implementers and system administrators.

The newly proposed text (with contributions from Peter) is:

> For the purposes of user authentication, the mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators.
> 
> For the purposes of server authentication, it is RECOMMENDED that implementations support the following mechanism mapping host names to certificates.  However, local policy MAY disable the mechanism or MAY impose additional constraints before considering a matching successful.  Furthermore, additional mechanisms mapping host names to certificates MAY be used and are left as implementation and configuration issues for implementers and system administrators.
> 
> The RECOMMENDED server authentication mechanism is as follows.  The subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] SHOULD be used to convey the server host name, using either dNSName entries or iPAddress entries to convey domain names or IP addresses as appropriate.  Multiple entries MAY be specified.  The following rules apply:
> 
> o  If the client's reference identifier (e.g., the host name typed by the client) is a DNS domain name, the server's identity SHOULD be checked using the rules specified in [TLS-CERTS].  Support for the DNS-ID identifier type is RECOMMENDED in client and server software implementations.  Certification authorities that issue certificates for use by Secure Shell servers SHOULD support the DNS-ID identifier type.  Service providers SHOULD include the DNS-ID identifier type in certificate requests.  The DNS-ID MAY contain the wildcard character '*' as the complete left-most label within the identifier.
> 
> o  If the client's reference identifier is an IP address as defined by [RFC791] or [RFC2460], the client SHOULD convert that address to the "network byte order" octet string representation and compare it against a subjectAltName entry of type iPAddress.  A match occurs if the octet strings are identifier for the reference identifier and any presented identifier.
> 
> [TLS-CERTS] http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-11