From nobody Thu Nov 6 07:06:43 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42141A8931 for ; Thu, 6 Nov 2014 07:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ0GGcHZt5-H for ; Thu, 6 Nov 2014 07:06:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCEA1A8AA8 for ; Thu, 6 Nov 2014 07:06:37 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA6F6a4o088203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2014 09:06:37 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <20141031001605.A02DC181C86@rfc-editor.org> Date: Thu, 6 Nov 2014 09:06:36 -0600 X-Mao-Original-Outgoing-Id: 436979195.959076-cf63a35090c4945956d1d7c5ede68600 Content-Transfer-Encoding: quoted-printable Message-Id: <1DF3C2B9-A331-4A18-8B10-A82B74AA72C2@nostrum.com> References: <20141031001605.A02DC181C86@rfc-editor.org> To: XMPP Working Group X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/lNykKVvygxGpK9lNBCOqVXtsw7I Subject: Re: [xmpp] RFC 7395 on An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 15:06:39 -0000 Yay! Many thanks to the authors and all who contributed. Ben. > On Oct 30, 2014, at 7:16 PM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7395 >=20 > Title: An Extensible Messaging and Presence=20 > Protocol (XMPP) Subprotocol for WebSocket=20 > Author: L. Stout, Ed., > J. Moffitt, > E. Cestari > Status: Standards Track > Stream: IETF > Date: October 2014 > Mailbox: lance@andyet.net,=20 > jack@metajack.im,=20 > eric@cstar.io > Pages: 18 > Characters: 36795 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-xmpp-websocket-10.txt >=20 > URL: https://www.rfc-editor.org/rfc/rfc7395.txt >=20 > This document defines a binding for the Extensible Messaging and > Presence Protocol (XMPP) over a WebSocket transport layer. A > WebSocket binding for XMPP provides higher performance than the > current HTTP binding for XMPP. >=20 > This document is a product of the Extensible Messaging and Presence = Protocol Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Thu Nov 6 19:53:44 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7D01A014A for ; Thu, 6 Nov 2014 19:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8RQge0azZo4 for ; Thu, 6 Nov 2014 19:53:41 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461F91A0147 for ; Thu, 6 Nov 2014 19:53:41 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id rp18so4286001iec.26 for ; Thu, 06 Nov 2014 19:53:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8/C62ij9IeZCdIYGN+OuX3gMa2o25/VDHCUQGCDylNc=; b=H8CJcygFwWQN3qRV5B7Qrh7PuigrWcSr81gz79s7qzhT+FI112dcoPCMyS4ZBWKXJq r8lLynC5+myhuQuywVs7GfJoaI+1NGdOrJEPxAQLQu+UP04UQZIROYic/g3DQFxXH1Tz OK7sf9yu+nGQt8xs++Be/widFnVRccsJlOGB5jtiZg1Ue6UnyDOQTqooOFWtGbx1/lcG glQ/MA+z+FyXyd7gdUAGYLZ8pMDH9VKwJsC6LoBD68jTiqmLOi9+fdbzqjOzJFr/aA4x ry3VLWMNf1ffKDVZBRw6/i2ZnMZecRaSDNzb2yvYFRlcwTXwaU4cOBOBPIbNIjKvME/7 6R0w== X-Gm-Message-State: ALoCoQmAcodAPm3gDK/66NEcgiMGMMXxqb16mvXAKK+Hivpj+eAEJGBwatlg31vrXN0fv+oF0Cni X-Received: by 10.107.29.197 with SMTP id d188mr9806278iod.57.1415332420350; Thu, 06 Nov 2014 19:53:40 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id i1sm183746igg.21.2014.11.06.19.53.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 19:53:39 -0800 (PST) Message-ID: <545C4241.2030901@andyet.net> Date: Thu, 06 Nov 2014 20:53:37 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Philipp Hancke , xmpp@ietf.org References: <544B5C48.6070107@goodadvice.pages.de> In-Reply-To: <544B5C48.6070107@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/2HyN7uS5IOXJfWZXcYXxHA2WcW0 Cc: draft-ietf-xmpp-posh.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 03:53:43 -0000 On 10/25/14, 2:16 AM, Philipp Hancke wrote: > Am 14.10.2014 01:17, schrieb Ben Campbell: >> (Oops, messed up the authors' address the first time. Apologies for >> the duplicate.) >> >> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The >> draft is available at the following URL: >> >> http://tools.ietf.org/html/draft-ietf-xmpp-posh-02 >> >> The WGLC will conclude on 27 October, 2014. Please send your comments >> to the authors and the XMPP mailing list. > > minor editorial stuff: > > While this approach was developed for use in the Extensible > > Messaging and Presence Protocol (XMPP) as a Domain Name > > Association prooftype, it can be applied to any non-HTTP > > "Domain Name Association (DNA) prooftype" (as done at the end of the > introduction)? > > section 1: > > The product managers in your company are pushing you > > bugging you? :-) > > section 3.2: > > The client performs an HTTPS GET for the URL > > HTTPS GET _request_ for the URL? Ack. Thanks for the suggestions. :-) Peter From nobody Thu Nov 6 20:43:25 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03841A0147 for ; Thu, 6 Nov 2014 19:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co28pgkl2dmG for ; Thu, 6 Nov 2014 19:49:50 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E52D31A013B for ; Thu, 6 Nov 2014 19:49:49 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3074220701; Thu, 6 Nov 2014 20:55:40 -0700 (MST) Message-ID: <545C4159.6000404@stpeter.im> Date: Thu, 06 Nov 2014 20:49:45 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Philipp Hancke , XMPP Working Group References: <544B622A.9050807@goodadvice.pages.de> In-Reply-To: <544B622A.9050807@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HgMjfSG8edWH6kPjcSaopfkCjbI X-Mailman-Approved-At: Thu, 06 Nov 2014 20:43:22 -0800 Cc: draft-ietf-xmpp-posh.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 03:49:51 -0000 On 10/25/14, 2:41 AM, Philipp Hancke wrote: > Am 14.10.2014 01:17, schrieb Ben Campbell: >> (Oops, messed up the authors' address the first time. Apologies for >> the duplicate.) >> >> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The >> draft is available at the following URL: >> >> http://tools.ietf.org/html/draft-ietf-xmpp-posh-02 >> >> The WGLC will conclude on 27 October, 2014. Please send your comments >> to the authors and the XMPP mailing list. > > In several places, "Server identity" and "TLS client" are used, e.g. > > Server identity checking (see [RFC6125]) involves three different > > aspects: > [...] > > a TLS client SHOULD consider the delegation invalid. > > I think this is not the "TLS client" but the "POSH client" and the "Peer > Identity". The main use case is when an xmpp s2s-server uses POSH to > verify an incoming connection. Initially I was resistant to your suggestion (preferring something like "POSH-aware TLS client"), but I see your point about incoming connections so it makes sense to me that we modify the terminology. > section 5: > The TLS client SHOULD perform all POSH retrievals > before opening any socket connections to the application > protocol server. > (ed: extra whitespace before that sentence) > > SHOULD is too strong here. I see it as a fallback rather and would only > do POSH when not finding a proper identity. This would mean that > sometimes, POSH is used without need. > I suspect this makes it easier to use POSH as part of the TLS handshake > rather than as an application layer check. > > This is also not possible for the s2s scenario where POSH may be > triggered by an incoming > somekeywhichwouldnotbeused > which would happen after and after the TLS handshake itself > is done. > > Should be easy to fix though. Yes, Matt and I will do some wordsmithing. Peter From nobody Fri Nov 7 08:03:43 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD21A01A8 for ; Fri, 7 Nov 2014 08:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baqONs-rY3yc for ; Fri, 7 Nov 2014 08:03:34 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C84D1A3BA0 for ; Fri, 7 Nov 2014 08:03:34 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h3so13021317igd.14 for ; Fri, 07 Nov 2014 08:03:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j4hlmqxA/Dx5f6pOesZPBypFAuIqkGzHlkYsHsAKTGg=; b=j+kle7rY2UWripbNCVr8/C0ndagBq2ZF0evFle0N/76daQU0WL4AaHQHZa++ncMyUf 1Su8MGRejezBzxq6mw8+YWdkX+Ebvz6P4awdLU1lhfz2XmF+7hMXOHE6SDbdDUA27X2t BGGm9qjaC3ImsUWgUL6zvFHDuM50tyjBc+lCGXJXXA3pjeH7uww7IxGS0r04Rt5Ss+7U 2dIMHW0KLRDsC4NVinvDpEXn25iskIbLu1fu/jRDnWtYemuPI7vexTggqJNeibtRQXOk D2AdtzMdteaQz7tOnTinnVNgg1S3vC3I5l/aX07imARJ+VYvnZzFG7WlRvHkMjG1EVyL viSA== X-Gm-Message-State: ALoCoQndhMfWL1LINToDnzCbTiu2CNnILf68NodQvLMNov/GOj7OhSR0xvcFR5kEgYtHKR13sICG X-Received: by 10.107.154.144 with SMTP id c138mr13981768ioe.11.1415376213498; Fri, 07 Nov 2014 08:03:33 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id kb7sm819740igb.16.2014.11.07.08.03.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 08:03:32 -0800 (PST) Message-ID: <545CED53.2060807@andyet.net> Date: Fri, 07 Nov 2014 09:03:31 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Philipp Hancke , XMPP Working Group References: <544B622A.9050807@goodadvice.pages.de> <545C4159.6000404@stpeter.im> In-Reply-To: <545C4159.6000404@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/06Y-r5IkaGt57z-8JQepDcHwD50 Cc: draft-ietf-xmpp-posh.all@tools.ietf.org Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:03:37 -0000 On 11/6/14, 8:49 PM, Peter Saint-Andre wrote: > On 10/25/14, 2:41 AM, Philipp Hancke wrote: > >> section 5: >> The TLS client SHOULD perform all POSH retrievals >> before opening any socket connections to the application >> protocol server. >> (ed: extra whitespace before that sentence) >> >> SHOULD is too strong here. I see it as a fallback rather and would only >> do POSH when not finding a proper identity. This would mean that >> sometimes, POSH is used without need. >> I suspect this makes it easier to use POSH as part of the TLS handshake >> rather than as an application layer check. >> >> This is also not possible for the s2s scenario where POSH may be >> triggered by an incoming >> somekeywhichwouldnotbeused >> which would happen after and after the TLS handshake itself >> is done. >> >> Should be easy to fix though. > > Yes, Matt and I will do some wordsmithing. I propose the following: In cases where the POSH client initiates an application-layer connection, the client SHOULD perform all POSH retrievals before initiating a connection (naturally this is not possible in cases where the POSH client receives an application-layer connection). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Nov 11 19:34:51 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1D1ACD3B for ; Tue, 11 Nov 2014 19:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNCGfHMqO_DA for ; Tue, 11 Nov 2014 19:34:48 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE841A9132 for ; Tue, 11 Nov 2014 19:34:47 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h3so2243633igd.1 for ; Tue, 11 Nov 2014 19:34:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=twuNSPL+4PDevzogdvoW++x7yrv0t6p/h+zjU2dn0pg=; b=CVqm7CUp4S7TJU1YdlAna4jbtcamnXlIpwp1l+yi4TApmueOcz/DCHr1bS9nUeKU4N +z6bB4H1SLsrujlRCFfvIqgPNwvblr+Ggt8sZ8TMZsPeiFLydMRw5vjlk9pKzjNHC+4A 1cMO+IDdC0EKxnm1EPPgdSxl4rfwvq+ZT/WwHv053I4oICmaWkldEKOhaelEnoQ8AFVh uSG+7jqaDXDurTiNSSlYLemqn/JMXfzkfIze+KhpSnvgfSudZq//G9UhZehAMSfZNsNd sP3fATGvLsVfrV1GA5vhwiYYBZ3ll9dunrdZYxLKH3Q+W1A2WFQOCY4OeD1qa1UAEWxy lBMQ== X-Gm-Message-State: ALoCoQngyTtRVjNjLt79zKUSQ27wDZRYDzHPVeO+byshW9dusU/E/nkWWl6aBkyxtpH+I6HVl0Wg X-Received: by 10.42.74.136 with SMTP id w8mr46500440icj.11.1415763287304; Tue, 11 Nov 2014 19:34:47 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id y8sm7237830igl.0.2014.11.11.19.34.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 19:34:46 -0800 (PST) Message-ID: <5462D556.8040400@andyet.net> Date: Tue, 11 Nov 2014 20:34:46 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <20141112033353.13684.68712.idtracker@ietfa.amsl.com> In-Reply-To: <20141112033353.13684.68712.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141112033353.13684.68712.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/J0GR8tMrep9-GrAC4G7ChvvPgAY Subject: [xmpp] Fwd: New Version Notification for draft-ietf-uta-xmpp-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 03:34:50 -0000 FYI. -------- Original Message -------- Subject: New Version Notification for draft-ietf-uta-xmpp-03.txt Date: Tue, 11 Nov 2014 19:33:53 -0800 From: internet-drafts@ietf.org To: Peter Saint-Andre , Peter Saint-Andre , me@thijsalkema.de , Thijs Alkemade A new version of I-D, draft-ietf-uta-xmpp-03.txt has been successfully submitted by Peter Saint-Andre and posted to the IETF repository. Name: draft-ietf-uta-xmpp Revision: 03 Title: Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) Document date: 2014-11-11 Group: uta Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-ietf-uta-xmpp-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/ Htmlized: http://tools.ietf.org/html/draft-ietf-uta-xmpp-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-uta-xmpp-03 Abstract: This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Nov 12 03:47:14 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12121A88B2 for ; Wed, 12 Nov 2014 03:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-2ZZg21NSFI for ; Wed, 12 Nov 2014 03:47:12 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292EE1A883E for ; Wed, 12 Nov 2014 03:47:12 -0800 (PST) Received: by mail-oi0-f44.google.com with SMTP id h136so8483078oig.17 for ; Wed, 12 Nov 2014 03:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5QatdzsU3uwAOnyLcDWVnAxKMLgMWCh5eAPFyEJSDq4=; b=U2aHFNDR/gkL9YNF+3zKXpetERD2UUc+oJ8DUutWsR8pCD8/fOmsJuz8BHSUTmTBkA NC48TmUk1ssdGm532lYbqjtUD4XXCH6SHV9z/FiaPqkicoqCFO/gl7HaA8JUF2vDiSQA M8JE7OycZYbow1T1qMqpoLQI2/dpM4X8lCg78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5QatdzsU3uwAOnyLcDWVnAxKMLgMWCh5eAPFyEJSDq4=; b=OiTnNhth6i1PAD3frDUEcKL7DHh0nDGW4ZeDlUqO3q5d3uwCneKJLjXuuNHr7d8NDx yY1LVEm9eYIttGYYz+frYDjXNXLCFJG8rWdCAZ1EihP46SEXGi9DhgMg9v2VFM4+zKlO ENlUlCm38BPawVL6SkdUyCIIPH8B8unRMRz+OpOy0CgKxZ0MG9gcTaT0AM8B401r0Pkh 4WVAOsTf7VpZXj8ESXU2nmRp2Of98LKjasynnGvTlu1IaQM/FZamimsuifaq6t4YYZ5L RX6SR2oP6UK4i3dv7fx+sa/q1Jggw/46BqjSOI3pYuVYajBGMmuaU7OOBPjx37skCMVk f4pg== X-Gm-Message-State: ALoCoQk5jN0CxIF3aKj6Hs94p2wSARw+Qq7ImLN732cv1bvxdGJbWNbAGL8qKnRvldwbRbk0aXpz MIME-Version: 1.0 X-Received: by 10.60.132.176 with SMTP id ov16mr37741979oeb.11.1415792831278; Wed, 12 Nov 2014 03:47:11 -0800 (PST) Received: by 10.60.155.103 with HTTP; Wed, 12 Nov 2014 03:47:11 -0800 (PST) In-Reply-To: <5462D556.8040400@andyet.net> References: <20141112033353.13684.68712.idtracker@ietfa.amsl.com> <5462D556.8040400@andyet.net> Date: Wed, 12 Nov 2014 11:47:11 +0000 Message-ID: From: Dave Cridland To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=047d7b472492c8d3810507a7f4f6 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/0KHvzOVisBnJ3ycNB8-8nRKCd4s Cc: XMPP Working Group Subject: Re: [xmpp] Fwd: New Version Notification for draft-ietf-uta-xmpp-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 11:47:14 -0000 --047d7b472492c8d3810507a7f4f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lightning review: 1) =C2=A73.3 - I don't understand why session tickets would be bad compared= to session ids? 2) Should there be a discussion about recommended SAN types? RFC 6120 currently says the only MTI is xmppAddr; RFC 6125 gives no MTI as I understand it. 3) If so, should we discuss wildcard resolution? Or not? RFC 5280 says wildcard resolution is within the scope of the application rather than TLS/PKIX itself. 4) Finally, there's two different protocols in XMPP - C2S and S2S. It might be good to explicitly note the different requirements on these (the draft says C2S clients MUST authenticate servers, for example). On 12 November 2014 03:34, Peter Saint-Andre - &yet wrote: > FYI. > > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-uta-xmpp-03.txt > Date: Tue, 11 Nov 2014 19:33:53 -0800 > From: internet-drafts@ietf.org > To: Peter Saint-Andre , Peter Saint-Andre < > peter@andyet.com>, me@thijsalkema.de , Thijs Alkemade = < > me@thijsalkema.de> > > > A new version of I-D, draft-ietf-uta-xmpp-03.txt > has been successfully submitted by Peter Saint-Andre and posted to the > IETF repository. > > Name: draft-ietf-uta-xmpp > Revision: 03 > Title: Use of Transport Layer Security (TLS) in the Extensible > Messaging and Presence Protocol (XMPP) > Document date: 2014-11-11 > Group: uta > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-ietf-uta-xmpp-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/ > Htmlized: http://tools.ietf.org/html/draft-ietf-uta-xmpp-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-uta-xmpp-03 > > Abstract: > This document provides recommendations for the use of Transport Layer > Security (TLS) in the Extensible Messaging and Presence Protocol > (XMPP). This document updates RFC 6120. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --047d7b472492c8d3810507a7f4f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lightning review:

1) =C2=A73.3 - I don&= #39;t understand why session tickets would be bad compared to session ids?<= /div>

2) Should there be a discussion about recommended = SAN types? RFC 6120 currently says the only MTI is xmppAddr; RFC 6125 gives= no MTI as I understand it.

3) If so, should we di= scuss wildcard resolution? Or not? RFC 5280 says wildcard resolution is wit= hin the scope of the application rather than TLS/PKIX itself.
4) Finally, there's two different protocols in XMPP - C2S a= nd S2S. It might be good to explicitly note the different requirements on t= hese (the draft says C2S clients MUST authenticate servers, for example).

On 12 N= ovember 2014 03:34, Peter Saint-Andre - &yet <peter@andyet.net><= /span> wrote:
FYI.


-------- Original Message --------
Subject: New Version Notification for draft-ietf-uta-xmpp-03.txt
Date: Tue, 11 Nov 2014 19:33:53 -0800
From: interne= t-drafts@ietf.org
To: Peter Saint-Andre <peter@andyet.com>, Peter Saint-Andre <peter@andyet.com>, me@thijsalkema.de <me@thijsalkema.de>, Thij= s Alkemade <me@th= ijsalkema.de>


A new version of I-D, draft-ietf-uta-xmpp-03.txt
has been successfully submitted by Peter Saint-Andre and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-uta-xmpp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Use of Transport Layer Security (T= LS) in the Extensible Messaging and Presence Protocol (XMPP)
Document date:=C2=A0 2014-11-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uta
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL: http://www.ietf.org/internet-drafts/draft-iet= f-uta-xmpp-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.= org/doc/draft-ietf-uta-xmpp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/= draft-ietf-uta-xmpp-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.= org/rfcdiff?url2=3Ddraft-ietf-uta-xmpp-03

Abstract:
=C2=A0 =C2=A0This document provides recommendations for the use of Transpor= t Layer
=C2=A0 =C2=A0Security (TLS) in the Extensible Messaging and Presence Protoc= ol
=C2=A0 =C2=A0(XMPP).=C2=A0 This document updates RFC 6120.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--047d7b472492c8d3810507a7f4f6-- From nobody Thu Nov 13 15:08:59 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1BF1AE20A for ; Thu, 13 Nov 2014 15:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke4LjbCKcZLL for ; Thu, 13 Nov 2014 15:08:55 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385F41AE1FE for ; Thu, 13 Nov 2014 15:08:55 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id hn18so552168igb.3 for ; Thu, 13 Nov 2014 15:08:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=inmNX5SI2z+cRmEepT6cg3qjdE0UOt9c4vg7ic5mRGg=; b=M5/YUnY6leLDq9sz6SV9cSiwFbL/uXDYqnVLM3B/d4n7RcGAuPkfp39K5TdxnbtZfr 08PQZFJUipKPeHn5Cz9wX11yhM+Nz71UJa2Ag2a/wW8doSwLKWtoWER6/vabE4M19VmU 1uxzLD6+sMErRjI5xWe/InCtYBL+TGHbauz/s2Q0FenQIaqteYLXbrGKSdVvhVwxJrdm ZwJfEUHRrrDy05q6YtjqOg05gEh3XUBDEGs9ICJEbL8bRYF3nOxDplMULJxgbB6OKHi+ hiR3+burZe9dEP5fZkuYKXn7tWsjgt2fXbegB8hnNhAgSzC8D6cugFvnflk2BwHhjz+Q AKTw== X-Gm-Message-State: ALoCoQmiqXaFOaDESfSlbq9tTg2TUM810C/5sBW8jd/NBs7pOKKnXTItS7RHVLPj7FrMjFzP20jN X-Received: by 10.42.126.82 with SMTP id d18mr667824ics.54.1415920134666; Thu, 13 Nov 2014 15:08:54 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l7sm452862igf.11.2014.11.13.15.08.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 15:08:53 -0800 (PST) Message-ID: <54653A03.5010206@andyet.net> Date: Thu, 13 Nov 2014 16:08:51 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Cridland References: <20141112033353.13684.68712.idtracker@ietfa.amsl.com> <5462D556.8040400@andyet.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Ljnb0FjBuSJayNKmlTRbTI3gMds Cc: XMPP Working Group Subject: Re: [xmpp] Fwd: New Version Notification for draft-ietf-uta-xmpp-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:08:57 -0000 Hi Dave, thanks for the feedback. On 11/12/14, 4:47 AM, Dave Cridland wrote: > Lightning review: > > 1) §3.3 - I don't understand why session tickets would be bad compared > to session ids? I freely admit that I don't understand the effective difference between session IDs and session tickets for XMPP (or for TLS session resumption in general). To my meager brain, the differences are not explained well in the RFCs. Enlightenment would be appreciated. :-) > 2) Should there be a discussion about recommended SAN types? RFC 6120 > currently says the only MTI is xmppAddr; RFC 6125 gives no MTI as I > understand it. This is covered in §13.7.1.2.1 of RFC 6120. Perhaps a pointer to that section would be helpful? > 3) If so, should we discuss wildcard resolution? Or not? RFC 5280 says > wildcard resolution is within the scope of the application rather than > TLS/PKIX itself. That's also covered in the aforementioned section of RFC 6120. However, do we feel that it's time to revisit the text there? (BTW, Jeff Hodges and I tried to kill off wildcard certs entirely in RFC 6125 but weren't successful.) > 4) Finally, there's two different protocols in XMPP - C2S and S2S. It > might be good to explicitly note the different requirements on these > (the draft says C2S clients MUST authenticate servers, for example). And it doesn't say that servers need to authenticate peer servers over s2s, which implies that unauthenticated s2s connections are allowed. This is consistent with current practice. Are you suggesting that we change the recommendation (e.g., SHOULD or MUST authenticate for s2s) or at least make it explicit that unauthenticated s2s connections are allowed? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Nov 14 19:07:55 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D4A1A039A for ; Fri, 14 Nov 2014 19:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfYqd3FLJy6i for ; Fri, 14 Nov 2014 19:07:49 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59BA1A038A for ; Fri, 14 Nov 2014 19:07:49 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so2271698ier.14 for ; Fri, 14 Nov 2014 19:07:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h4NIO6KmhR2WpuAKJpHNXr09+EL6QYXzoKRG/0CsaAk=; b=KKgG32U8KJlyNprG3UiilmfeEv9SrJXpD7Dj24AMdgNtpZ+mnZ10L78eC/LR5Jlr2V xD8znNCoCLPuIJvLlQvRWnxavnqXfudAL/vrPzmhXRsu5nJeDTRG8xoYE3fKiNclBSnc hsfZ8VZDuIiJibVan/r7RoVw4EH2n9rOahEE667bLigQ2N8d38yEtc5A5Fv+LZyqyBGN lJdXsl0p0Ph1Dc+kVcrCPjOzcGzHDGyUG+jrGa6uRKH55GL/VqR/gYf3Jm5xeuXXtaQ+ Kc54GBKg15N+3+bjhhDT5o5c587lN1ab8fEutb+LueCyvt5owaQZ9Yx6CyQviKPMu6Ry g+3w== X-Gm-Message-State: ALoCoQkPOBJ/aYQT0GcgGV9e453+MHC+cXXBGh3he3PJ7LBuagy1kbTQRg40taMrKxHgZQ2Zf52U X-Received: by 10.107.138.131 with SMTP id c3mr9548340ioj.0.1416020869078; Fri, 14 Nov 2014 19:07:49 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l14sm225403ioi.31.2014.11.14.19.07.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 19:07:48 -0800 (PST) Message-ID: <5466C382.5070305@andyet.net> Date: Fri, 14 Nov 2014 20:07:46 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Cridland , Ben Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/6NjOXdS1vXmGRa7BeIVZRP3_0Oc Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 03:07:53 -0000 Hi Dave, our apologies for the delayed reply. On 10/14/14, 2:42 AM, Dave Cridland wrote: > On 14 October 2014 00:17, Ben Campbell > wrote: > > This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The > draft is available at the following URL: > > > 0) Abstract: > > The last sentence is problematic, because it's not clear that the XMPP > WG can make such a pronouncement. Perhaps "it can probably be applied". We're not saying that it SHOULD be so applied. > Also, it fails to explain why hosted HTTPS isn't a problem, but I > suspect I'll never understand that one. :-) It is a problem, and folks in that space would love to have a solution, but an HTTPS-based solution would work because it would be turtles all the way down. > I note that this Abstract is huge, and contains almost the same > information as the Introduction. Noted. The abstract could definitely be more concise! > 1) Introduction: > > I was under the impression that when this issue was first raised, the > problem was one of management of certificates rather than anything else > - that is, if you host 1,000 domains, you needed to have a certificate > for each of them in practise, and this meant handling 1,000 > certificates, each with different expiry dates etc. That is a problem, too. But I think the truly insuperable challenge is not being able to obtain such certificates in the first place. > Suggestion: After the existing three bullet points: > > o Even if your legal department is happy, this still means managing one > certificate for each customer across the infrastructure, contributing to > a large administrative load. Yep. > Though the same organization that raised this point seems perfectly > happy to do so for HTTP; as noted before, this is because of Strange > Things Beyond My Understanding. > > Finally, this section does not constitute a thought experiment, but an > illustrative story. I prefer the term 'fable'. > 3) Obtaining Verification Materials > > It would make things clearer if the term of art "source domain" were > briefly introduced, at least hinting at its meaning. While it's > mentioned in Terminology, because there is no typographic convention to > alert the reader that it is a term of art, it's difficult to spot it > immediately. As an alternative to calling it out, perhaps capitalizing > it (although it's not capitalized in RFC 6125)? > > I note that "end-entity certificate" is not called out explicitly, but > this is probably OK - though using it in the initial point 1's > parenthesis may help. "(in PKIX, this takes the form of a PKIX > end-entity certificate [RFC5280])." Noted in both cases. > In the second numbered list, there seems to be a dearth of metasyntactic > variables. The Foo client connecting to the foo domain to verify the Foo > service by looking for the foo token is almost awesomely unclear. Since > at this stage we have already established that the Source Domain > contains "foo", perhaps we could make this the "Bar" service, with > posh.bar.json - this also has the advantage that the Bar Service is very > familiar to a large proportion of the XMPP community. Heh, yes, that's bad. > Within this point 1, "foo.example.com " is > referred to as the "domain" - it is, I think, the Source Domain, and > would be clearer noted as such. Yes. > Finally, I think it's worthwhile stressing that although the ultimate > goal is to verify the certificate foo presents for the Bar service of > the Source Domain, the certificate presented by HTTPS is still validated > in isolation by traditional methods - that is, the HTTPS cert has to be > valid for the Source Domain. Indeed. This is assumed but not called out. It's really how all of this POSH stuff is bootstrapped in the first place. > 3.1) Source Domain Possesses PKIX Certificate Information > > I'll freely admit I'm not terribly keen on this being in JSON. It means > including a JSON library within XMPP; we've not needed one before. IMHO it was the least-worst solution, but I'll let my co-author speak to that more directly. > 3.3) Performing Verification > > a) This reads "You take a bunch of hashes and see if any match". Given > the example contains more than one hash function, which should be used? > Both? Whatever the client supports? I would say: whatever the client supports. > b) I've a nagging feeling that we should include Issuer and Serial > matches as well, in order to mitigate against hashes becoming weaker. I > suspect that hashing only the keying material (or using the SKI) might > be even better. Has this been run past someone who actually knows some > crypto (ie, someone other than me)? Given the ease of swapping out POSH files, it seems to me that the best defense here is to change your POSH file if you've been using a weak hash. It's not as if these are CA-issued certificates valid for years on end. > 4) Secure Delegation > > This text reads that we should match the "POSH certificate". This is > presumably a term of art, but used only in this section. Similarly "TLS > server" is used only once, here. There are two TLS servers at play here, > and it's unclear what a POSH certificate might be; given that the only > certificates discussed are not the JSON objects. Perhaps this would be better: The delegation from the source domain to the delegated domain can be considered secure if the credentials offered by the POSH server match the verification materials possessed by the client, regardless of how those materials are obtained. > 7) Alternates and Roll-over > > It appears that it is impossible to state something like a switch of > hosting using this mechanism; also I'd note that this same mechanism > might also be used if a hosting provider has multiple certificates. A hosting switch would presumably be handled by updating one's SRV records, not primarily by updating one's POSH data. > 8) Security Considerations > > Not really sure that the second paragraph belongs here. (Nor, actually, > am I sure it belongs anywhere in the document). This topic was raised during the POSH BoF a few IETF meetings ago, and we added the text to address the concern that we weren't using EST (Enrollment over Secure Transport = RFC 7030) or that we were offering a competing technology to EST. > Summary: > > Some more work required. Always. > I still would rather the earth swallowed this whole, really, and we did > these things properly. Matt and I both think that the long-term solution is DANE. However, we also realize that it will take a long time for DANE to be widely deployed, and in the meantime we're not checking server identities in a strong fashion. POSH is just a stopgap and hopefully will last only about as long as the career of the Spice Girls. :-) > I would be happier to go along with this if there > were any sign that large hosting providers in the XMPP world were at all > likely to deploy any kind of security at all, but this seems unlikely > because of the combination of this not being trivial, and there being > implementations which follow the strict rules of RFC 6120 and drop the > session if TLS is encountered with a non-matching certificate - yet > cheerfully connect if there's no TLS at all. Well, you have a point there. Unfortunately I can't claim that POSH will suddenly make people care about security if they don't care right now. > Still, rant over - if we're to do this, there's a few rough edges in the > specification, Yes, we'll clean those up. > and I'd appreciate knowing if the certificate identity > mechanism has been properly reviewed. IMHO the WG chairs might consider asking for an early or dedicated security review on that point. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Nov 21 16:27:18 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF5A1A90FF; Fri, 21 Nov 2014 16:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvv7JdTiRKEp; Fri, 21 Nov 2014 16:27:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B5F1A90F4; Fri, 21 Nov 2014 16:27:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141122002712.14692.61949.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 16:27:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/s33df3yFom12CLIyVROYgvJbe_8 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-16.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:27:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Author : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-16.txt Pages : 29 Date : 2014-11-21 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 21 16:33:05 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536651A90F8 for ; Fri, 21 Nov 2014 16:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvwSuOwR5_qM for ; Fri, 21 Nov 2014 16:33:02 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85BE1A90F9 for ; Fri, 21 Nov 2014 16:33:01 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so6001417ier.41 for ; Fri, 21 Nov 2014 16:33:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M2ySLcUkDj6QYn0rQHyr/ysJ8BGN8VqIzufJOTLmZ4I=; b=TFwxfuallgrc9ZlqRfQWyLin+oNfYSLtZgzoQ5kPqFGMvQV7PqvMFBGuEUVJ8oj8yu TdfYhaw3z3KCKPIYh57LBpbL1c5a+7KzxVzz71d7DrwllzHCTcmBEv+AJzugR0BD4Aym bQbiSADDjUcikCyOtQ9eaBifV3yxBMPTwYp/IETt0vNNkKGH8WtCxf6dlaQrbeXeUjZC lNcBwRGiD2zna5H0YAWQ722Qq+T0IwAT/ZWgeqR5JodM6XQsy7vOwzIiDodA9Rxls8JJ SqdaHOsZmH2H9/DfnC8zeLcYjf0+3VaRJamAFQEh47WSpT8Y8wfriYm1kGygFWcZgDBH 1Zxg== X-Gm-Message-State: ALoCoQm1kZDIkdKPGIUpCTUkTQRziRNXpjgjJZ71r/yKhUKbmNL9ld9FnEvzxHRj0M/LTHQLRJrT X-Received: by 10.50.2.38 with SMTP id 6mr970121igr.23.1416616381378; Fri, 21 Nov 2014 16:33:01 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id f9sm567656iod.24.2014.11.21.16.33.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 16:33:00 -0800 (PST) Message-ID: <546FD9BC.3070206@andyet.net> Date: Fri, 21 Nov 2014 17:33:00 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <546FD981.3060101@andyet.net> In-Reply-To: <546FD981.3060101@andyet.net> X-Forwarded-Message-Id: <546FD981.3060101@andyet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/n7ef1Xgr8l3P8RXI8z5AvbHS_MQ Subject: [xmpp] Fwd: revised framework, saslprepbis, nickname, 6122bis X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:33:04 -0000 FYI. -------- Original Message -------- Subject: revised framework, saslprepbis, nickname, 6122bis Date: Fri, 21 Nov 2014 17:32:01 -0700 From: Peter Saint-Andre - &yet To: precis@ietf.org I have completed a consistency check of the framework, saslprepbis, and nickname documents (along with 6122bis in the XMPP WG), and to the best of my ability I have addressed all feedback received on the list and during the recent PRECIS WG and HTTPAUTH WG sessions. I consider these documents ready to move forward and I ask that the PRECIS WG chairs and responsible area director process them with all due haste. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Nov 24 19:27:52 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556C41A1B9B for ; Mon, 24 Nov 2014 19:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi4jMDWA3gUV for ; Mon, 24 Nov 2014 19:27:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 609501A6FD5 for ; Mon, 24 Nov 2014 19:27:45 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A97C4169C; Mon, 24 Nov 2014 20:34:55 -0700 (MST) Message-ID: <5473F72F.5020608@stpeter.im> Date: Mon, 24 Nov 2014 20:27:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <54723B17.3090901@andyet.net> In-Reply-To: <54723B17.3090901@andyet.net> X-Forwarded-Message-Id: <54723B17.3090901@andyet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/_dKG_S5GYJ0xSEz4Tcb02r50r9A Subject: [xmpp] Fwd: username profile(s) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 03:27:51 -0000 FYI, I posted this to the PRECIS WG list yesterday. Comments are welcome there. -------- Original Message -------- Subject: username profile(s) Date: Sun, 23 Nov 2014 12:52:55 -0700 From: Peter Saint-Andre - &yet To: precis@ietf.org In draft-ietf-precis-saslprepbis we have a profile for usernames, which differs from the profile for localparts of JabberIDs defined in draft-ietf-xmpp-6122bis in only one respect: the localpart profile specifies case mapping whereas the username profile leaves decisions about case mapping vs. case preservation up to the using application. I am wondering whether it would make sense to define two username profiles in draft-ietf-precis-saslprepbis: one that uses case mapping (say, Usernamecasemapped) and one that uses case preservation (say, Usernamecasepreserved). This seems cleaner to me, and would avoid the need to define a separate profile in the XMPP specs (which might not be where future protocol designers would look for a username construct). Thoughts? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Nov 26 19:00:29 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8233A1A8739; Wed, 26 Nov 2014 19:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf9IK0BJ5ioT; Wed, 26 Nov 2014 19:00:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C81A86E2; Wed, 26 Nov 2014 19:00:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141127030026.16908.6768.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 19:00:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VT4_jjpLXtAmMI30t4U1MGQrmKY Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-17.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 03:00:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Author : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-17.txt Pages : 26 Date : 2014-11-26 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 27 12:45:24 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47151A01D6 for ; Thu, 27 Nov 2014 12:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVils5lPTGNP for ; Thu, 27 Nov 2014 12:45:21 -0800 (PST) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C80A1A0195 for ; Thu, 27 Nov 2014 12:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1417121120; bh=F0d7juaE6tcWuzsEMp41hes2Hx4wG2Lr0Lm1TFoKqQY=; h=Date:Subject:From:To:From:Subject; b=ad5bq9dLk5UufrQugCLNwZji4A3vCO01mzG2qG1YxFQLiLdF7ppqQ45UIGDgmntI7hW4FF45O76bFLvh3aETjyttFr3nXxt8HGZiz2GnaQwLYBnXb8nFV8uJgeDY9vG/JbGfpQBAbJQA726aTB4amlfDq6AfHH966j6CUFZQnpQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=att.net; b=f0zcJe5p7fB8c2THoGNcqkKnMGDRYpWSMNyjaiuw8jOBDgJNYkDcrGGAxg/rjMp3AB8piHiMG4FQGz21hHsXLXvWR5DbbMecaT/Xk37uEXTkyI+rzGkasl8B5WKpvXrJo1mgGeeMl9QvfbpVeEzEFkOVXyzPITQsBNxNJQBq76w=; Received: from [98.138.100.113] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2014 20:45:20 -0000 Received: from [98.138.226.30] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2014 20:45:20 -0000 Received: from [127.0.0.1] by smtp201.mail.ne1.yahoo.com with NNFMP; 27 Nov 2014 20:45:20 -0000 X-Yahoo-Newman-Id: 927946.37846.bm@smtp201.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YlJvbKsVM1nIbdPC_Uc7i8q9_QrLGLesoVLk5C8xo.Xer6b bcQ4Oa0peWLrXZj6ggfjpoXM2_4Xschz_rDAZSKmS1cqsja05Q7XOdhk5lZQ C_mz7sh_Boh11nlqGQpebWPnG6zQQO9e3HV2R4FvRJn9Dfgvu8NT.bQM_7i4 O_uWQaq6gWwg_oBbQTe91mDrcC08uXGPVEmt_B1zsjkbsM.pLUtgKP8onYqg _Q_P1jdyD5vYewpzFygIKhcp13tktH97shRbJK9BpUrQy_OLn0BfCJ_W.4Ia YEwK3Iq8YY_avPs1dcMrZ_5vmllpZG30NKv.XhDbazborPZZxeQJnvQZIeIw F1Xw3F6U4WTDQIb.CCGYbI7Sc.Q1slygwIPDwkdGvU1HUic5jTmOeOOVGHX3 bfZ2RrO3vOQq2Qgy6ApwGi6J_0d0urLsGThp_I0s.P24Q7o_y7xa_uccUZmR O3itmRmJ6mJ1yfBudE5QTM0vWIOCAiTZC_IZkqmy6zqpRBga3HalowDmxFbt UqLfF0odsbxKRmPCliGgfsKXG1xH4i9GU2D3mYRbfQ7u8Lg-- X-Yahoo-SMTP: FgT0pQ6swBC02lu0EpFl9dy00T1jF3TarDVnUaE- Date: Thu, 27 Nov 2014 15:44:36 -0500 Message-ID: Importance: normal From: mact-usa To: xmpp@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_34331913446180" Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/LoYdnhv0SitnsrMfcHHZmhQZtL0 Subject: [xmpp] IoT XEPs to enter review by ISO X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 20:45:22 -0000 ----_com.android.email_34331913446180 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VG8geG1wcCBtZW1iZXJzLAoKSW9UIFhFUHMgdXNlZCBpbiBJU08vSUVDL0lFRUUgUDIxNDUxLTEt NCB0byBlbnRlciBmb3JtYWwgcmV2aWV3IGFzIGFuIGludGVybmF0aW9uYWwgU2VtYW50aWMgV2Vi IDMuMCBzdGFuZGFyZCBmb3IgdGhlIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKQoKClNlbnQgZnJv bSBteSBULU1vYmlsZSA0RyBMVEUgRGV2aWNl ----_com.android.email_34331913446180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5UbyB4bXBwIG1lbWJlcnMs PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Jb1QgWEVQcyB1c2VkIGluIElTTy9JRUMvSUVFRSBQ MjE0NTEtMS00IHRvIGVudGVyIGZvcm1hbCByZXZpZXcgYXMgYW4gaW50ZXJuYXRpb25hbCBTZW1h bnRpYyBXZWIgMy4wIHN0YW5kYXJkIGZvciB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzIChJb1QpPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6OXB4O2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBteSBULU1vYmlsZSA0RyBMVEUgRGV2aWNl PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_34331913446180-- From nobody Thu Nov 27 12:52:18 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47691A01EC for ; Thu, 27 Nov 2014 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbqa81VMzKng for ; Thu, 27 Nov 2014 12:52:13 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A021A01C6 for ; Thu, 27 Nov 2014 12:52:13 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so4877978ieb.7 for ; Thu, 27 Nov 2014 12:52:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ngp2FnN/raWUrE59vnmAaaAWWX1GQiOxxlPCj2lXvmA=; b=FfPpb/BjIV/R95UkpaKrDzwDKVOKOn3EOKX/2SQ566LfhQc0ToCTGOeyJexxkP935c ad7/AEZo1iqe9YjKF1H30Gi3pv/82SJOPnENJT6EKjFcuP2Rmyyap6u0LV/wF4ZKwTyA e8izBvba6ZIqZ7O3BBZVhLdn8xPQ/RNWSLSSKWQBpq+8HF6aj+zClf7rtagyXZKSGdH9 e40KwGnQZzMxLAhSPtXNHhcMgs8RRT8JoEsdFjazvxO6aiEoKtSvjj0j70MJcSK+32TQ +Cc4VBSTdnm/r6rH41sQygvKiaqzODGeY3hozlOTDyJaKHFBlr+Sgwq1smFMI8yLrVku 5jFA== X-Gm-Message-State: ALoCoQnaRqBiPVBF433PLhBIQ2iGeZsWuic9ac9lLdYZC4ITcB4i9kz/rhg3Y9kHN4aZ0NTTXKx6 X-Received: by 10.50.6.112 with SMTP id z16mr29558503igz.43.1417121533100; Thu, 27 Nov 2014 12:52:13 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id s10sm4614352igr.2.2014.11.27.12.52.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 12:52:12 -0800 (PST) Message-ID: <54778EFB.5070000@andyet.net> Date: Thu, 27 Nov 2014 13:52:11 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: xmpp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/zlt49RcgpqLo32Uqa9Yh4dXiAXA Subject: Re: [xmpp] IoT XEPs to enter review by ISO X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 20:52:16 -0000 On 11/27/14, 1:44 PM, mact-usa wrote: > To xmpp members, > > IoT XEPs used in ISO/IEC/IEEE P21451-1-4 to enter formal review as an > international Semantic Web 3.0 standard for the Internet of Things (IoT) Hi William, It is the XMPP Standards Foundation (XSF), not the IETF's XMPP WG, that develops specifications in the XMPP Extension Protocol (XEP) series. Thus your message is off-topic here. I shall follow up separately, in my capacity as Executive Director of the XSF, regarding the use of XEPs in the ISO/IEC/IEEE standards process, because I am not sure about the import of your statement. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Nov 30 19:08:21 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890B21A034F for ; Sun, 30 Nov 2014 19:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRsK4vboq8RD for ; Sun, 30 Nov 2014 19:08:16 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ABE1A0163 for ; Sun, 30 Nov 2014 19:08:16 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so13820977igb.4 for ; Sun, 30 Nov 2014 19:08:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jc///eWOPlm40wqYVFsfPInRgRLXt1xq1OZVb2OOoWo=; b=A5IlP2EhGP8zFxx330ZX1hbkRtBY4Ev+6z/jdw6wY6RviEFlM45gZX4wgQ63f6dC4N rR3qffK4+ZLu0T76B1sO+VDx7PuqM9i76CmR0ZumAIiQVf7icqN71gzXizkZ4fSZGZfs tukSOjFns5JOwK0Xi0ZFZKGLgnOWwlT0Mfx8KHMT2cJVf550gml2AOVHlfo5bfqHLvvc EdT21uf6dke2zI2qT6w1uiXJPTc7OPzWZY3uMSI0KlQN7uYoxMbxx+A080MfPH6cuA2E bxqJcAXHl8M1N7lGSZx+/52nT2Og3lqDnR9DbkO2pzWXV13e205EqFeEQtGt75/H90z6 6TkQ== X-Gm-Message-State: ALoCoQnocGOjExq8MIvk3pxXHn5Fc1Yx135DlP2nXgMt4dk0OqS6RHWsO92oy0rRcEKfUNAa17n6 X-Received: by 10.50.127.241 with SMTP id nj17mr8372621igb.22.1417403295949; Sun, 30 Nov 2014 19:08:15 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id fy5sm14683576igd.3.2014.11.30.19.08.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 19:08:15 -0800 (PST) Message-ID: <547BDB9E.8000605@andyet.net> Date: Sun, 30 Nov 2014 20:08:14 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XMPP Working Group References: <547BDAA7.2030601@andyet.net> In-Reply-To: <547BDAA7.2030601@andyet.net> X-Forwarded-Message-Id: <547BDAA7.2030601@andyet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/dRwDXQIZQf0li0exQ_KiCAcuqUM Subject: [xmpp] Fwd: consolidating FreeformClass profiles? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 03:08:18 -0000 What do folks here think about this suggestion? -------- Original Message -------- Subject: consolidating FreeformClass profiles? Date: Sun, 30 Nov 2014 20:04:07 -0700 From: Peter Saint-Andre - &yet To: precis@ietf.org I think we've done a pretty good job of consolidating some of the IdentiferClass profiles, thanks to prodding from John Klensin. Now I'm wondering if we can prune the list of FreeformClass profiles. Currently we have: Password (draft-ietf-precis-saslprepbis) Resourcepart (draft-ietf-xmpp-6122bis) Nickname (draft-ietf-precis-nickname) The Password and Resourcepart profiles are similar: the main differences are use of the Bidi Rule and removal of leading and trailing whitespace in Resourcepart (the latter is more of a UI consideration and probably doesn't belong in the Resourcepart profile in the first place). I think we *might* be able to point to the Password profile from 6122bis and remove the Resourcepart profile (I'll need to post to the XMPP WG list about that). The "Password" name feels a bit strange in this context (I might prefer a more generic name like "OpaqueString"), but that's a nit. The Nickname profile is different enough in purpose and function that I think we'll need to keep it. Peter -- Peter Saint-Andre https://andyet.com/ -- Peter Saint-Andre https://andyet.com/