This might be of interest regarding re-use of the server-id-check document...
/psa -------- Original Message -------- Subject: Re: Peter Saint-Andre's DISCUSS on draft-igoe-secsh-x509v3-06 Date: Tue, 07 Dec 2010 08:22:25 -0700 From: Peter Saint-Andre <[email protected]> To: Douglas Stebila <[email protected]> CC: =JeffH <[email protected]>, [email protected], The IESG <[email protected]>, [email protected], [email protected] That's helpful regarding certificate issuance, but it doesn't say how the client is to perform comparisons. As you can see from the I-D I pointed you to, there are subtleties involved, such as internationalized domain names (IDNs) and so-called wildcard certificates (e.g., *.example.com). I didn't know the topic could be so interesting until I took over editorship of that document. :) To compare identifiers of type dNSName, I suggest that you read http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-11 if you haven't had a chance to do so yet, so that you have context for my proposed text, which 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 the subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] 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 is a DNS domain name, the server's identity MUST be checked using the rules specified in [TLS-CERTS]. Support for the DNS-ID identifier type is REQUIRED in client and server software implementations. Certification authorities that issue certificates for use by Secure Shell servers MUST 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 MUST 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. ### See draft-saintandre-tls-server-id-check for the relevant terminology, and draft-ietf-xmpp-3920bis (Section 13.7.1.2.1) for a similar re-use of the server-id-check document. I've borrowed the IP address text from an earlier version of the server-id-check document (in later versions we focused the document only on DNS domain names and pulled out coverage of IP addresses): http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02#section-3.2.2 Naturally, YMMV and I welcome your thoughts on this approach. (I've cc'd my co-author on the server-id-check document to keep him in the loop as well.) Peter On 12/6/10 7:16 AM, Douglas Stebila wrote: > Thank you for the suggestion. What do you think of the following > change? > > For the purposes of server authentication, it is RECOMMENDED that the > subjectAlternativeName X.509v3 extension [RFC5280, Section 4.2.1.6] > 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. Additional > mechanisms mappings between certificates and host names are OPTIONAL > and are left as an implementation and configuration issue for > implementers and system administrators. > > Douglas > > On 2010-Dec-1, at 12:14 PM, Peter Saint-Andre wrote: > >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> Section 4 states: >> >> 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. >> >> Leaving this up to software implementers and service operators >> seems shortsighted. For the sake of interoperability and improved >> security, I think it would be good to specify rules for checking >> the identity of hostnames asserted by the server (if the client >> does not check the server's identity, how can it be said to have >> authenticated the server?). It might be appropriate to cite >> draft-saintandre-tls-server-id-check or to borrow some text from >> that document.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
