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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 25 October 2010 13:43 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 F42273A69B1; Mon, 25 Oct 2010 06:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level:
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Ea58pvSfPCGg; Mon, 25 Oct 2010 06:43:43 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0337D3A6A1B; Mon, 25 Oct 2010 06:42:29 -0700 (PDT)
Received: from squire.local (dsl-179-124.dynamic-dsl.frii.net [216.17.179.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0F6E40D1E; Mon, 25 Oct 2010 07:51:18 -0600 (MDT)
Message-ID: <4CC5897C.3080600@stpeter.im>
Date: Mon, 25 Oct 2010 07:43:24 -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.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Philipp Hancke <fippo@mail.symlynx.com>
References: <4CBF3310.8060801@stpeter.im> <4CBF56A9.1090503@mail.symlynx.com> <4CC5747E.4080006@stpeter.im>
In-Reply-To: <4CC5747E.4080006@stpeter.im>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070907080005080102010206"
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, 25 Oct 2010 13:43:44 -0000

On 10/25/10 6:13 AM, Peter Saint-Andre wrote:
> On 10/20/10 2:52 PM, Philipp Hancke wrote:
>> There is a minor problem with that from the XMPP-s2s POV: it does not
>> (explicitly) cover the case where a server verifies the identity of a
>> peer server (see rfc3920bis 6.2.4 or the s2s section of XEP 0178 for
>> details).
>>
>> AFAICS, the only difference is that the reference identifier is supplied
>> by the peer instead of being constructed as described in section 4.2.
>>
>> Therefore, I'd propose adding the following note to the end of section 4.1:
>> Note: Some application protocols such as XMPP perform the procedure
>> described in this section when verifiying a server identity in a
>> certificate presented by a TLS client. By this, and in contrast to the
>> procedure described in the next subsection, the reference identifier is
>> supplied by the peer (TLS client). Except for this and the inverted
>> client-server role, the verification process remains unchanged.
> 
> Thanks for the proposed text. I suggest the following tweaks:
> 
>    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 an
>    application client when verifying a client-to-server (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
>    thereore the reference identifier is in essence supplied by the
>    peer server (e.g., as triggered by a request to send a message from
>    an associated with the peer server to an 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.

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

###

/psa