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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Oct 2010 12:21:04 -0600

FYI.

-------- Original Message --------
Subject: [certid] Fwd: I-D
Action:draft-saintandre-tls-server-id-check-10.txt
Date: Wed, 20 Oct 2010 10:36:05 -0600
From: Peter Saint-Andre <[email-masked]>
To: IETF cert-based identity <[email-masked]>

Finally! The diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-10

-------- Original Message --------
Subject: I-D Action:draft-saintandre-tls-server-id-check-10.txt
Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Representation and Verification of Domain-Based
Application Service Identity within Internet Public Key Infrastructure
Using X.509 (PKIX) Certificates in the Context of Transport Layer
Security (TLS)
	Author(s)       : P. Saint-Andre, J. Hodges
	Filename        : draft-saintandre-tls-server-id-check-10.txt
	Pages           : 46
	Date            : 2010-10-20

Many application technologies enable a secure connection between two
entities by means of Internet Public Key Infrastructure Using X.509
(PKIX) certificates in the context of Transport Layer Security (TLS).
This document specifies best current practices for representing and
verifying the identity of application services in such interactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 20 Oct 2010 22:52:57 +0200

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.

cheers

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Oct 2010 06:13:50 -0600

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

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Oct 2010 07:43:24 -0600

>    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