[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. ###
- [certid] another example: GIST Peter Saint-Andre