Re: [certid] [xmpp] accommodating server-to-server
Peter Saint-Andre <stpeter@stpeter.im> Tue, 09 November 2010 22:01 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 7A2C83A68B2; Tue, 9 Nov 2010 14:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level:
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088,
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 ayJsusmUXbI4;
Tue, 9 Nov 2010 14:01:51 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com
(Postfix) with ESMTP id 7949A3A6891; Tue, 9 Nov 2010 14:01:51 -0800 (PST)
Received: from dhcp-429b.meeting.ietf.org (dhcp-429b.meeting.ietf.org
[130.129.66.155]) (Authenticated sender: stpeter) by stpeter.im (Postfix)
with ESMTPSA id B265640BB9; Tue, 9 Nov 2010 15:11:30 -0700 (MST)
Message-ID: <4CD9C4E4.4030603@stpeter.im>
Date: Wed, 10 Nov 2010 06:02:12 +0800
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.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Philipp Hancke <fippo@mail.symlynx.com>
References: <4CD47814.3010508@KingsMountain.com>
<4CD913FA.2070308@mail.symlynx.com>
In-Reply-To: <4CD913FA.2070308@mail.symlynx.com>
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="------------ms070503030600020206030406"
Cc: certid@ietf.org, xmpp@ietf.org
Subject: Re: [certid] [xmpp] accommodating server-to-server
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, 09 Nov 2010 22:01:52 -0000
On 11/9/10 5:27 PM, Philipp Hancke wrote: > Hi Jeff, > [...] >> To me, what Peter wrote in the proposed "Note:" is confusing because it >> is labeling an entity as a "TLS client" that is not a TLS client in the >> TLS protocol sense -- it is playing the TLS server role, and is only >> behaving as a "TLS client" would in the sense of verifying the entity at >> the other end of the incoming connection. > > From the TLS protocol level both occurences of "client" should have been > "server", yes. > >> In this case we ostensibly have the "peer server" -- legitimately acting >> as a TLS client -- presenting its certificate during the TLS handshake, >> and thus the application service is obliged to perform the same checks >> on the peer server's asserted identity, as an actual TLS client performs >> on asserted app service identity. >> >> yes? > > Exactly. > >> If so, it seems we're linguistically standing on our heads here trying >> to shoehorn the notion of "verification of client identity (by the app >> service)" into section 4 "Verification of Service Identity". > > Yes. > >> I propose that we need to perhaps have a separate section for the former >> and figure out how to refactor the more detailed section 4 subsections >> such that we don't have to needlessly repeat text. > > You might split this in such a way that you describe how to get the > certificate and reference identifiers first (which is slightly different > for client and server) and then the process of validation for a given > certificate and a given reference identifiers (which no longer depends > on whether a client or a server is doing that). Essentially, that means > replacing most occurences of "client" with "verifying entity". > > However, I am not sure if this really going to improve readability for > anyone that is not looking for xmpp-s2s :-/ Right, which is why I think it's better to put this in 3920bis. Peter -- Peter Saint-Andre https://stpeter.im/
- Re: [certid] accommodating server-to-server (was:… =JeffH
- Re: [certid] accommodating server-to-server (was:… Peter Saint-Andre
- Re: [certid] [xmpp] accommodating server-to-serve… Philipp Hancke
- Re: [certid] [xmpp] accommodating server-to-server Peter Saint-Andre
- Re: [certid] accommodating server-to-server (was:… =JeffH