Added a new Section 5.7.3.1 to define the algorithm used to check names against
the database of authorised peers, and noted in Section 9 that definition of
future channel security protocols must provide the same information.

New text in 5.7.3.1:

5.7.3.1.  Identity Checking in TLS

   After TLS authentication, a node MUST check the identity presented by
   the peer in order to avoid man-in-the-middle attacks, and verify that
   the peer is authorised to take part in signalling at the GIST layer.
   The authorisation check is carried out by comparing the presented
   identity with each APD entry in turn, as discussed in Section 4.4.2.
   This section defines the identity comparison algorithm for a single
   APD entry.

   For TLS authentication with X.509 certificates, an from the DNS
   namespace MUST be checked against each subjectAltName extension of
   type dNSName present in the certificate.  If no such extension is
   present, then the identity MUST be compared to the (most specific)
   Common Name in the Subject field of the certificate.  When matching
   DNS names against dNSName or Common Name fields, matching is case-
   insensitive.  Also, a "*" wildcard character MAY be used as the left-
   most name component in the certificate or identity in the APD.  For
   example, *.example.com in the APD would match certificates for
   a.example.com, foo.example.com, *.example.com, etc., but would not
   match example.com.  Similarly, a certificate for *.example.com would
   be valid for APD identities of a.example.com, foo.example.com,
   *.example.com, etc., but not example.com.

   Additionally, a node MUST verify the binding between the identity of
   the peer to which it connects and the public key presented by that
   peer.  Nodes SHOULD implement the algorithm in Section 6 of [11] for
   general certificate validation, but MAY supplement that algorithm
   with other validation methods that achieve equivalent levels of
   verification (such as comparing the server certificate against a
   local store of already-verified certificates and identity bindings).

   For TLS authentication with pre-shared keys, the identity in the
   psk_identity_hint (for the server identity, i.e. the Responding node)
   or psk_identity (for the client identity, i.e. the Querying node)
   MUST be compared to the identities in the APD.

Note that this issue only covers the (TLS-specific) name comparison algorithm.
Deciding whether a name is acceptable in the first place is a separate issue,
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue192.

From Sam Hartman:

The discussion of TLS needs to describe what names certificates need to use.

And from Russ Housely (in more detail):

The second paragraph of Section 5.7.3 deals with TLS authentication. However,
the paragraph does not indicate how to determine whether the identity in the
certificate is acceptable.  Some form of identity checking must be included for
the certificate to provide the expected authentication.