Subject: [Netconf] Updating RFC 5539: Server Identity

From: Mohamad Badra <[email-masked]>
Date: Sat, 7 Apr 2012 17:40:50 +0200

Dear All,

One point I forgot to include to my presentation during last IETF is the
server identity. In fact, RFC6125 specifies recommended procedures for
representing and verifying application service identity in certificates
intended for use in application protocols employing TLS.

I would propose updating parts of Section 3.1. of
draft-badra-netconf-rfc5539bis as follows:

REPLACE:

   Matching is performed according to the rules below (following the
   example of [RFC4642 <http://tools.ietf.org/html/rfc4642>]):

   o  The client MUST use the server hostname it used to open the
      connection (or the hostname specified in the TLS "server_name"
      extension [RFC5246 <http://tools.ietf.org/html/rfc5246>]) as the
value to compare against the server
      name as expressed in the server certificate.  The client MUST NOT
      use any form of the server hostname derived from an insecure
      remote source (e.g., insecure DNS lookup).  CNAME canonicalization
      is not done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it MUST be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the leftmost name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

   o  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.

WITH:

   Matching is performed according to the rules and guidelines defined
   in RFC6125.

Comments?
Best regards,
Badra