Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt

Philipp Hancke <fippo@mail.symlynx.com> Mon, 01 November 2010 11:27 UTC

Return-Path: <fippo@mail.symlynx.com>
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 E44DB3A67E6; Mon, 1 Nov 2010 04:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 qx+t8h9i+CNN; Mon, 1 Nov 2010 04:27:44 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by core3.amsl.com (Postfix) with ESMTP id EB5FF3A67A6; Mon, 1 Nov 2010 04:27:43 -0700 (PDT)
Received: from [192.168.2.103] (p4FF0C925.dip.t-dialin.net [79.240.201.37]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oA1BSBkw026530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2010 12:28:12 +0100
Message-ID: <4CCEA426.8060003@mail.symlynx.com>
Date: Mon, 01 Nov 2010 12:27:34 +0100
From: Philipp Hancke <fippo@mail.symlynx.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CBF3310.8060801@stpeter.im> <4CBF56A9.1090503@mail.symlynx.com> <4CC5747E.4080006@stpeter.im> <4CC5897C.3080600@stpeter.im>
In-Reply-To: <4CC5897C.3080600@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: certid@ietf.org, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt
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: Mon, 01 Nov 2010 11:27:45 -0000

Peter Saint-Andre wrote:
[...]
> Oops, there were some typos and missing words. That's what I get for
> replying to email while eating breakfast at 6 AM. Corrected text:
>
> ###
>
>     Note:  In some application protocols, the procedure described in
>     this section can be performed by an application server acting as a
>     TLS client when verifying a server-to-server connection, not only by

s/TLS client/TLS server/

>     an application client when verifying a client-to-server connection
>     (e.g, this is true of XMPP).  In this case, the application server
>     verifies the identity of the peer server that is attempting to
>     connect and therefore the reference identifier is in essence
>     supplied by the peer server (e.g., as triggered by a request to send
>     a message from an entity associated with the peer server to an

I think it is not clear who is verifying (probably because both parties 
are for xmpp-s2s). What about:

In some application protocols, the procedure described in this section 
can also be performed by an application server when verifying a incoming 
[server-to-server?] connection from a peer, not only when verifying an 
outgoing connection (e.g., this is true for XMPP).
In this case, the application server, acting as a TLS server, verifies 
the identity of the TLS client and the reference identifier is in 
essence supplied by the peer [...]

[where the peer server is the TLS client]

>     entity associated with the application service).  Other than the
>     source of the reference identifier and the inverted roles of the TLS
>     client and TLS server, the verification process remains unchanged.

+1