[certid] regarding re-use

[Peter Saint-Andre <[e-mail]>]

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 <[e-mail]>
To: Douglas Stebila <[e-mail]>
CC: =JeffH <[e-mail]>,
[e-mail], The IESG <[e-mail]>,
[e-mail], [e-mail]

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.