[certid] another example: GIST

Peter Saint-Andre <stpeter@stpeter.im> Tue, 20 April 2010 21:51 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D003A6970 for <certid@core3.amsl.com>; Tue, 20 Apr 2010 14:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OEu+bxwuFEB for <certid@core3.amsl.com>; Tue, 20 Apr 2010 14:51:54 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 92AA93A6937 for <certid@ietf.org>; Tue, 20 Apr 2010 14:51:53 -0700 (PDT)
Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C4C340E15 for <certid@ietf.org>; Tue, 20 Apr 2010 15:51:43 -0600 (MDT)
Message-ID: <4BCE21EF.8070906@stpeter.im>
Date: Tue, 20 Apr 2010 15:51:43 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000100010003050206080902"
Subject: [certid] another example: GIST
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 21:51:55 -0000

I just stumbled across another example of identity checking: the General
Internet Signalling Transport (GIST), which is in the RFC Editor queue.
See section 5.7.3.1 of draft-ietf-nsis-ntlp-20, reproduced below (where
reference [9] is RFC 5280).

###

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 Authorised Peer Database (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 identity 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 [9] 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.

###