From ietf-secretariat@ietf.org Tue Dec 4 13:15:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDB521F8BB0; Tue, 4 Dec 2012 13:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouM50SuuMFx0; Tue, 4 Dec 2012 13:15:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A621F8892; Tue, 4 Dec 2012 13:15:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204211546.17101.19087.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 13:15:46 -0800 Cc: salvatore.loreto@ericsson.com, webfinger@ietf.org, superuser@gmail.com, apps-discuss@ietf.org Subject: [webfinger] New Non-WG Mailing List: webfinger -- Discussion of the Webfinger protocol proposal in the Applications Area X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:15:47 -0000 A new IETF non-working group email list has been created. List address: webfinger@ietf.org Archive: http://www.ietf.org/mail-archive/web/webfinger/ To subscribe: https://www.ietf.org/mailman/listinfo/webfinger Purpose: Discussion of the Webfinger protocol proposal in the Applications = Area. For additional information, please contact the list administrators. From jasnell@gmail.com Tue Dec 4 13:48:49 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4621F8BC9 for ; Tue, 4 Dec 2012 13:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruWHjGavLKlP for ; Tue, 4 Dec 2012 13:48:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA9421F8BC8 for ; Tue, 4 Dec 2012 13:48:45 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3679472iaz.31 for ; Tue, 04 Dec 2012 13:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4STIXMwQXmkPpRge0cDEvxbaacmXMXrBPVyZIUNPHqA=; b=ww0ZhH0bye0Tty9xQX5GHk3n3pACE3aBj9Y0Y+89Q2TgwDsmwRgD9WXpHXmSEtIMao GbRfITZ+N6U+vBEfj8vhDnnqZGWYwrhszLvXJXpogKy0aSYs4phOHQ4Uq2E4DBoww0QS AgpnVPnvTY/oSbY96fJ9XutXeI98jYj/3A0ZVt/9/t99P5w5wFDi2vrDY8FNoRsFgDs4 SHZZIizsHn87Hvbyh0+VMOvPo1bhO9TZjuTKOI7PGCj/Zl9nEm3bbX2v/f4eCPDusnsl VSzAqZf1IITkDNFhqSiw0sGB9JoAVVmU5smCQoWbD2ZoVXZWNppCOpDK/813YqsYfQMc 5vHg== Received: by 10.50.159.229 with SMTP id xf5mr4411614igb.0.1354657725152; Tue, 04 Dec 2012 13:48:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Tue, 4 Dec 2012 13:48:24 -0800 (PST) From: James M Snell Date: Tue, 4 Dec 2012 13:48:24 -0800 Message-ID: To: webfinger@ietf.org Content-Type: multipart/alternative; boundary=14dae934071f7ffd6f04d00dd4bf Subject: [webfinger] Outstanding WF Security Concerns X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:48:49 -0000 --14dae934071f7ffd6f04d00dd4bf Content-Type: text/plain; charset=UTF-8 In the current draft -07 spec there are a handful of fairly important security issues that have yet to be dealt with. I summarized these in a separate note to Paul and the other authors while waiting for this new list to be set up and wanted to call them out here for discussion as well. 1. Potential Mixed-session hijack vulnerability When accessing an authenticated WebFinger service via HTTPS, there is a potential session-hijacking vulnerability if the returned JRD contains non-HTTPS URLs to the same domain as the WebFinger server and session cookies are not properly secured. As a best practice, if the JRD is served over a HTTPS connection, any links to the same domain contained within the JRD SHOULD also use HTTPS and server implementations need to make sure that all session cookies are properly secured against hijacking. (This issue is no different than your typical mixed-session vulnerability) 2. 3xx Redirects to insecure targets WebFinger explicitly allows a WebFinger server to redirect requests to a separate third party service provider. It does not, however, require the use of HTTPS with the redirected target. For example, imagine sending a GET request to: https://example.org/.well-known/webfinger?r... And getting back... HTTP/1.1 302 Found Location: http://example.net/wf?r=... The redirected request will no longer be protected, negating the point of using HTTPS in the first request and putting the client at risk. Redirects returned by the server for requests issued over HTTPS ought to be required to point to HTTPS secured URLs... e.g. HTTP/1.1 302 Found Location: https://example.net/wf?r=... 3. Also with regards to third party redirects, how is the client able to determine that the redirection was appropriately authorized by the original WF provider? If the server (or vulnerable intermediary) has been compromised, a client can be tricked into redirecting to a malicious server providing false information. If, for instance, a fake Identity Provider URL is provided, the client may not be capable of detecting the intrusion. Use of HTTPS will not prevent such attacks. One reliable solution is to require the use of cryptographic integrity checks on the JRD resource. That is, if Server A redirects to Server B, then the JRD provided by Server B needs to be signed by a key trusted by both Server A and the client. However it is done, the client needs to be able to determine that Server B is authorized by Server A to provide WebFinger data on it's behalf... a redirect served over HTTPS does not, by itself, provide sufficient assurance. 4. When a client sends an unauthorized WebFinger request for a resource, a 404 Not Found response needs to be returned to make such responses indistinguishable from requests for resources the service has no information about. - James --14dae934071f7ffd6f04d00dd4bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In the current draft -07 spec there a= re a handful of fairly important security issues that have yet to be dealt = with. I summarized these in a separate note to Paul and the other authors w= hile waiting for this new list to be set up and wanted to call them out her= e for discussion as well.=C2=A0

1. Potential Mixed-session hijack vulnerability

=C2=A0 =C2=A0When accessing an authenti= cated WebFinger service via HTTPS,
=C2=A0 =C2=A0there is a potentia= l session-hijacking vulnerability if the=C2=A0
=C2=A0 =C2=A0returned JRD contains non-HTTPS UR= Ls to the same domain as=C2=A0
=C2=A0 =C2=A0the WebFinger serve= r and session cookies are not properly=C2=A0
=C2=A0 =C2=A0secured. As a best practice, if the J= RD is served over a=C2=A0
=C2=A0 =C2=A0HTTPS connection, a= ny links to the same domain contained=C2=A0
=C2=A0 =C2=A0within the JRD SHOULD also use HTTPS a= nd server implementations
=C2=A0 =C2=A0need to make sure t= hat all session cookies are properly=C2=A0
=C2=A0 =C2=A0secured against hijacking. (This issue = is no different than=C2=A0
=C2=A0 =C2=A0your typical mixed-= session vulnerability)

2. 3xx Redir= ects to insecure targets

=C2=A0 =C2=A0WebFinger explicitly allows a WebF= inger server to redirect=C2=A0
=C2=A0 =C2=A0requests to a separate third party service provider= . It=C2=A0
=C2=A0 =C2=A0does not, however, = require the use of HTTPS with the redirected
=C2=A0 =C2=A0target.=C2=A0

=C2=A0 =C2=A0For ex= ample, imagine sending a GET request to:


=C2=A0 =C2=A0And getting back...

=C2=A0 =C2=A0 =C2= =A0HTTP/1.1 302 Found
=C2=A0 =C2=A0 =C2=A0Location: http://example.net/wf?r=3D...

<= font face=3D"courier new, monospace">=C2=A0 =C2=A0The redirected request wi= ll no longer be protected, negating=C2=A0
=C2=A0 =C2=A0the point of using = HTTPS in the first request and putting the
=C2=A0 =C2=A0client at risk.=C2=A0
=
=C2=A0 =C2=A0Redire= cts returned by the server for requests issued over HTTPS
= =C2=A0 =C2=A0ought to be required to = point to HTTPS secured URLs... e.g.

=C2=A0 =C2=A0 =C2=A0HTTP/1.1 302 Found
=C2=A0 =C2=A0 =C2=A0Location= : https://example.net/wf?r=3D.= ..

3. Also with regards to third party redirects,= =C2=A0how is the client=C2=A0
=C2=A0 =C2=A0able to determine that the redirection was appr= opriately=C2=A0
=C2=A0 =C2=A0authorized b= y the original WF provider? If the server (or=C2=A0
=C2=A0 =C2=A0vulnerable intermediary) has been compromised, = a client can be=C2=A0
=C2=A0 =C2=A0tricke= d into redirecting to a malicious server providing false=C2=A0
=C2=A0 =C2=A0information. If, for instance, a fake Identity = Provider URL is=C2=A0
=C2=A0 =C2=A0provid= ed, the client may not be capable of detecting the intrusion.=C2=A0<= /span>
=C2=A0 =C2=A0Use of HTTPS will not prevent such attacks. One= reliable=C2=A0
=C2=A0 =C2=A0solution is = to require the use of cryptographic integrity checks on=C2=A0=
=C2=A0 =C2=A0the JRD resource. That is, if Server A redirect= s to Server B, then=C2=A0
=C2=A0 =C2=A0th= e JRD provided by Server B needs to be signed by a key trusted by=C2=A0
=C2=A0 =C2=A0both Server A and the client. However it is don= e, the client needs
=C2=A0 =C2=A0to be ab= le to determine that Server B is authorized by Server A
=C2=A0 =C2=A0to provide WebFinger data on it's behalf...= a redirect served over
=C2=A0 =C2=A0HTTP= S does not, by itself, provide sufficient assurance.

4. When a client send= s an unauthorized WebFinger request for a=C2=A0
=C2=A0 =C2=A0resource, a 404 Not Found response needs to be = returned to make
=C2=A0 =C2=A0such respon= ses indistinguishable from requests for resources the
=C2=A0 =C2=A0service has no information about.=

- James
--14dae934071f7ffd6f04d00dd4bf-- From paulej@packetizer.com Tue Dec 4 17:51:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626921F860C for ; Tue, 4 Dec 2012 17:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY88WFWI7ZbZ for ; Tue, 4 Dec 2012 17:51:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B8D8B21F8607 for ; Tue, 4 Dec 2012 17:51:40 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB51padi030735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Dec 2012 20:51:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354672297; bh=v/pHksnK9UWIj4SQFQAejBHaCy5gdGD/a+BxX2lppws=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=MZsiH9x5GYoksKCqHKh1gve7lMe7CGd4T8HgQ+ApTFUrYTLXob8Thd6Evc3TWc6r9 v0z7D5Sq0+Ozh6d7c5ZKa8HoMXAV+x6zazFBzLGtHUZFC+PnZnMI1s9T+dDx5VSmsw zWFrAXcXhG6NrNFKhYBM7BqhkCEsRx6HfJq/e1Pw= From: "Paul E. Jones" To: "'Tim Bray'" References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> In-Reply-To: Date: Tue, 4 Dec 2012 20:51:39 -0500 Message-ID: <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EC7_01CDD261.28E06E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+0j97Q4pc5i9QzGvaMqVha4A3zQN31ACHArX7O0cCBLLDDgJtamDFAherj38BSfpTX5a3Y+MA Content-Language: en-us Cc: webfinger@ietf.org, 'Mike Jones' , 'James M Snell' , webfinger@googlegroups.com, 'Peter Saint-Andre' Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 01:51:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EC7_01CDD261.28E06E30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tim, =20 Perhaps we=E2=80=99re discussing different issues. With respect to = whether TLS is used to query the =E2=80=9Cwebfinger=E2=80=9D resource or = not, I understand there are people arguing both sides. I=E2=80=99m = personally neutral on that. =20 Where the discussion was going here was related to =E2=80=9Cwhere do = link relations in the webfinger response point?=E2=80=9D There is an = argument that we must also require that TLS be used for all link = relations. I disagree with that as a requirement since we=E2=80=99re = now talking about where a user stores his data (e.g., an avatar). If he = chooses to store that in Flickr or any $1/mo hosting provider should not = matter. Further, any client processing the WF response could see that = it is an =E2=80=9Chttp:=E2=80=9D URI and decide on a case-by-case basis = how to treat each link relation seen. =20 Paul =20 From: Tim Bray [mailto:twbray@google.com]=20 Sent: Tuesday, December 04, 2012 2:27 AM To: Paul E. Jones Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter = Saint-Andre Subject: Re: WebFinger 8 Input... =20 Paul, you can say this all you want, but there are coherent voices on = our mailing list saying that they really need something written into the = spec to give them assurance that they can use WF and it=E2=80=99ll = either go through TLS or it won=E2=80=99t happen. There are three = coherent come-backs to this: =20 - Always HTTPS - Some sort of normative parameterized behavior - Those people shouldn=E2=80=99t use WebFinger. =20 At some point, someone=E2=80=99s going to have to make a consensus call = on where the community stands. -T =20 On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones = wrote: James, =20 Keep in mind that WF is to allow users to share all kinds of information = about themselves. Services that need to be secure will use HTTPS. = Those that do not, won=E2=80=99t. =20 If I tell my WF service that my avatar is located at some http:// = location, then that=E2=80=99s the information the WF server should = return in responses. =20 If information needs better security, then the URL would be HTTPS. Any = IdP would utilize an https:// address. =20 In any case, the href value in WF can be any valid URI. Use or non-use = of TLS for these other resources to which WF refers is really outside = the scope of WF. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Tuesday, December 04, 2012 12:44 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre Subject: Re: WebFinger 8 Input... =20 =20 On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones = wrote: James, =20 What a WF resource points to should have nothing to do with whether WF = uses HTTPS or not. If I put my vcard out on the Internet accessible = only via http (which is presently the case), then that=E2=80=99s the way = it=E2=80=99s accessed. (Actually, the HTTPS version works on my domain, = but will redirect the client to the non-HTTPS version.) =20 Well... for a typical non-authenticated request to a WebFinger resource, = you're correct. There is an obvious risk, however, of introducing a = session hijacking vulnerability when using authenticated WebFinger = requests with an improperly secured server if the JRD provides non-https = links to the same domain. It would be dangerous for us to assume that = all relevant cookies provided on a given domain have been secured = properly. As a best practice, links provided to resources located on the = same domain should simply be required to use https as a way of erring on = the side of caution.=20 =20 =20 During a redirect, the redirection does not need to use the same scheme = if the group agrees to allowing HTTP. That said, I fully agree the = example in section 8 should show use of HTTPS just as a means of = encouragement. =20 =20 Issuing a https secured request to a WF endpoint that redirects to an = insecure third party location rather defeats the purpose of requiring = https for the first request, doesn't it? =20 - James =20 =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Monday, December 03, 2012 10:01 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre Subject: Re: WebFinger 8 Input... =20 Yep, as expected really. Take the various edits for what they are worth. = It was either this or try to go through all the multitude of threads and = provide input on each individual subject... this was by far the more = efficient option for me. I'll come up with a summary of the changes a = bit later on this evening. Most are purely editorial in nature, but = there are a few important technical items...=20 =20 For instance, when serving up a JRD over an HTTPS connection, and that = JRD contains link relations to resources hosted at the same domain as = the WebFinger service, there is a risk of a TLS-downgrade attack if = those link relations are not https urls... e.g. in the examples we see = things like "href": "http://example.com/foo" ... when it really ought to = be "href": "https://example.com/foo" ... =20 Similarly, if we are going to allow the use of 3xx redirects, then the = WebFinger server needs to make sure that the new target URL is using the = https scheme; i.e. instead of "Location: = http://example.net/webfinger?..." it needs to be "Location: = https://example.net/webfinger?..." =20 There are a few other bits scattered around. Once the kids are bathed = and off to bed I'll write up a summary. =20 Honestly, other than the need to control the flood of discussions = happening on the mailing list, I don't see any reason to rush this to = completion. Let's get a relatively stable draft out there and just let = it sit for a while so implementors can get more experience with it. =20 - James =20 On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones = wrote: James, =20 Wow, that=E2=80=99s a lot of changes. I=E2=80=99d personally like to = keep the terminology section the way it is. The word =E2=80=9Clink = relation=E2=80=9D is confusing to people who have not heard it, and = having that very brief statement is useful, I think. =20 Merging the =E2=80=9CIntroduction=E2=80=9D and = =E2=80=9COverview=E2=80=9D sections might be a good idea, but I recall = some time ago there was one section and it was suggested we split it = apart. What we would put in each, I=E2=80=99m not sure. It=E2=80=99s = definitely a bit overlapping at the moment. I=E2=80=99m OK with merging = those sections. =20 I really, really prefer to keep the examples in the main body. = They=E2=80=99re marked as non-normative, but being able to read those = before getting further in the document is very helpful to the reader the = first time they read the text. Heck, even if they=E2=80=99ve read it, = it=E2=80=99s nice to see examples right up front. Otherwise, the = reader=E2=80=99s headed is cloudy all the way through the text. =20 The header for Section 2 (=E2=80=9CTerminology=E2=80=9D) appears to have = been removed accidentally. =20 In section 8, there are bullet points for the IANA registration template = material. Those should not be there. =20 Don=E2=80=99t use =E2=80=9CURI=E2=80=9D before the instant messaging = address in the contact area. Email addresses are also URIs :-) I = wanted IM there. =20 Beyond that, the changes are so substantial that I=E2=80=99ll need time = to see exactly what they are. I tried to produce a meaningful diff, but = since the whole example section was moved, diff programs gets totally = confused. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Monday, December 03, 2012 8:38 PM To: webfinger@googlegroups.com; Paul Jones; Tim Bray Subject: WebFinger 8 Input... =20 Given that the recent WebFinger discussion has been flooding and = overwhelming the IETF appsawg mailing list I have left that mailing list = off the cc list until the new WF specific mailing list has been set up. = While reading through the latest version of the spec, I started to = collect a list of specific edits that I thought needed to be made. The = list became rather detailed so it ended up just being easier to draft up = a proposed new version. =20 I have checked it in to my personal github repo here... =20 http://goo.gl/IaQnm =20 The raw xml is here... =20 http://goo.gl/QcNCr =20 As always, feedback is definitely welcome. =20 - James =20 =20 =20 ------=_NextPart_000_0EC7_01CDD261.28E06E30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Tim,

 

Perhaps we=E2=80=99re discussing different issues.=C2=A0 With respect = to whether TLS is used to query the =E2=80=9Cwebfinger=E2=80=9D resource = or not, I understand there are people arguing both sides.=C2=A0 = I=E2=80=99m personally neutral on that.

 

Where the discussion was going here was related to =E2=80=9Cwhere do = link relations in the webfinger response point?=E2=80=9D=C2=A0 There is = an argument that we must also require that TLS be used for all link = relations.=C2=A0 I disagree with that as a requirement since = we=E2=80=99re now talking about where a user stores his data (e.g., an = avatar).=C2=A0 If he chooses to store that in Flickr or any $1/mo = hosting provider should not matter.=C2=A0 Further, any client processing = the WF response could see that it is an =E2=80=9Chttp:=E2=80=9D URI and = decide on a case-by-case basis how to treat each link relation = seen.

 

Paul

 

From:= = Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December = 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M = Snell; webfinger@googlegroups.com; Mike Jones; Peter = Saint-Andre
Subject: Re: WebFinger 8 = Input...

 

Paul, you = can say this all you want, but there are coherent voices on our mailing = list saying that they really need something written into the spec to = give them assurance that they can use WF and it=E2=80=99ll either go = through TLS or it won=E2=80=99t happen.  There are three coherent = come-backs to this:

 

- Always = HTTPS

- Some sort = of normative parameterized behavior

- Those = people shouldn=E2=80=99t use = WebFinger.

 

At some = point, someone=E2=80=99s going to have to make a consensus call on where = the community stands. -T

 

On Mon, Dec = 3, 2012 at 9:58 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

James,

 

Keep in mind that WF is to allow users to share all kinds of = information about themselves.  Services that need to be secure will = use HTTPS.  Those that do not, = won=E2=80=99t.

 

If I tell my WF service that my avatar is located at some http:// = location, then that=E2=80=99s the information the WF server should = return in responses.

 

If information needs better security, then the URL would be = HTTPS.  Any IdP would utilize an https:// = address.

 

In any case, the href value in WF can be any valid URI.  Use or = non-use of TLS for these other resources to which WF refers is really = outside the scope of WF.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, = December 04, 2012 12:44 AM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; = Peter Saint-Andre
Subject: Re: WebFinger 8 = Input...

 <= /o:p>

 <= /o:p>

On Mon, Dec = 3, 2012 at 7:28 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

James,

 

What a WF resource points to should have nothing to do with whether = WF uses HTTPS or not.  If I put my vcard out on the Internet = accessible only via http (which is presently the case), then = that=E2=80=99s the way it=E2=80=99s accessed.  (Actually, the HTTPS = version works on my domain, but will redirect the client to the = non-HTTPS version.)

 <= /o:p>

Well... for = a typical non-authenticated request to a WebFinger resource, you're = correct. There is an obvious risk, however, of introducing a session = hijacking vulnerability when using authenticated WebFinger requests with = an improperly secured server if the JRD provides non-https links to the = same domain. It would be dangerous for us to assume that all relevant = cookies provided on a given domain have been secured properly. As a best = practice, links provided to resources located on the same domain should = simply be required to use https as a way of erring on the side of = caution. 

 <= /o:p>

 

During a redirect, the redirection does not need to use the same = scheme if the group agrees to allowing HTTP.  That said, I fully = agree the example in section 8 should show use of HTTPS just as a means = of encouragement.

 

 <= /o:p>

Issuing a = https secured request to a WF endpoint that redirects to an insecure = third party location rather defeats the purpose of requiring https for = the first request, doesn't it?

 <= /o:p>

- = James

 <= /o:p>

 <= /o:p>

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, = December 03, 2012 10:01 PM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; = Peter Saint-Andre
Subject: Re: WebFinger 8 = Input...

 <= /o:p>

Yep, as expected really. Take the = various edits for what they are worth. It was either this or try to go = through all the multitude of threads and provide input on each = individual subject... this was by far the more efficient option for me. = I'll come up with a summary of the changes a bit later on this evening. = Most are purely editorial in nature, but there are a few important = technical items... 

 <= /o:p>

For instance, when serving up a JRD = over an HTTPS connection, and that JRD contains link relations to = resources hosted at the same domain as the WebFinger service, there is a = risk of a TLS-downgrade attack if those link relations are not https = urls... e.g. in the examples we see things like "href": = "http://example.com/foo" ... when it really = ought to be "href": "https://example.com/foo" = ...

 <= /o:p>

Similarly, if we are going to allow = the use of 3xx redirects, then the WebFinger server needs to make sure = that the new target URL is using the https scheme; i.e. instead of = "Location: http://example.net/webfinger?..." it needs to = be "Location: https://example.net/webfinger?..."=

 <= /o:p>

There are a few other bits scattered = around. Once the kids are bathed and off to bed I'll write up a = summary.

 <= /o:p>

Honestly, other than the need to = control the flood of discussions happening on the mailing list, I don't = see any reason to rush this to completion. Let's get a relatively stable = draft out there and just let it sit for a while so implementors can get = more experience with it.

 <= /o:p>

- = James

 <= /p>

On Mon, Dec = 3, 2012 at 6:45 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

James,

 

Wow, that=E2=80=99s a lot of changes.  I=E2=80=99d personally = like to keep the terminology section the way it is.  The word = =E2=80=9Clink relation=E2=80=9D is confusing to people who have not = heard it, and having that very brief statement is useful, I = think.

 

Merging the =E2=80=9CIntroduction=E2=80=9D and = =E2=80=9COverview=E2=80=9D sections might be a good idea, but I recall = some time ago there was one section and it was suggested we split it = apart.  What we would put in each, I=E2=80=99m not sure.  = It=E2=80=99s definitely a bit overlapping at the moment.  = I=E2=80=99m OK with merging those sections.

 

I really, really prefer to keep the examples in the main body. =  They=E2=80=99re marked as non-normative, but being able to read = those before getting further in the document is very helpful to the = reader the first time they read the text.  Heck, even if = they=E2=80=99ve read it, it=E2=80=99s nice to see examples right up = front.  Otherwise, the reader=E2=80=99s headed is cloudy all the = way through the text.

 

The header for Section 2 (=E2=80=9CTerminology=E2=80=9D) appears to = have been removed accidentally.

 

In section 8, there are bullet points for the IANA registration = template material.  Those should not be = there.

 

Don=E2=80=99t use =E2=80=9CURI=E2=80=9D before the instant messaging = address in the contact area.  Email addresses are also URIs = :-)  I wanted IM there.

 

Beyond that, the changes are so substantial that I=E2=80=99ll need = time to see exactly what they are.  I tried to produce a meaningful = diff, but since the whole example section was moved, diff programs gets = totally confused.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, = December 03, 2012 8:38 PM
To: webfinger@googlegroups.com; Paul Jones; Tim = Bray
Subject: WebFinger 8 = Input...

 <= /o:p>

Given that the recent WebFinger = discussion has been flooding and overwhelming the IETF appsawg mailing = list I have left that mailing list off the cc list until the new WF = specific mailing list has been set up. While reading through the latest = version of the spec, I started to collect a list of specific edits that = I thought needed to be made. The list became rather detailed so it ended = up just being easier to draft up a proposed new = version.

 <= /o:p>

I have checked it in to my personal = github repo here...

 <= /o:p>

 <= /o:p>

The raw xml is = here...

 <= /o:p>

 <= /o:p>

As always, feedback is definitely = welcome.

 <= /o:p>

- = James

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0EC7_01CDD261.28E06E30-- From jasnell@gmail.com Tue Dec 4 17:56:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B136E21F8A73 for ; Tue, 4 Dec 2012 17:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVQLRkUprSS2 for ; Tue, 4 Dec 2012 17:56:46 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id E23A621F88F9 for ; Tue, 4 Dec 2012 17:56:45 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so2844833iak.12 for ; Tue, 04 Dec 2012 17:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u7Uc8/krtJ/RvHkPfgqOyx7Z/5+JeZ9wKFL5ceL5hsE=; b=vXmul5euKCVtzhmGU4KOCZvAb5yLZPzy5I0aCi7qux6Q4PUbUWBQ0scCu0MAADLgwm j8uF8nAmBcpej5GtVwEcemalXgDQ/nb0hf7WKhkzOCtbUUjGgrKuwLomt/nNQeWKldj3 qzumCajb5ilYdvJsxVlV64icfvKPvC+u7jirjW3Ja7fzDW/yWkmkZD0w3U0SUmSnjpUL jYws0q36yJfizPj6GUzz1+kK/gUNwc9pXSDeuj55ejYZml4N/RaC+HpjE7XE5Ff49+MG /sVGo+Ws1StdjZzSyCQTQRGq17ODQ9w0W4zjHbXTiYEpdXqBPLz05gjKJM/x5zQSc6JE WZJw== Received: by 10.50.41.200 with SMTP id h8mr413943igl.0.1354672605357; Tue, 04 Dec 2012 17:56:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Tue, 4 Dec 2012 17:56:23 -0800 (PST) In-Reply-To: <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> From: James M Snell Date: Tue, 4 Dec 2012 17:56:23 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9340ad16de76104d0114ba8 Cc: webfinger@ietf.org, Tim Bray , "webfinger@googlegroups.com" , Peter Saint-Andre , Mike Jones Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 01:56:47 -0000 --14dae9340ad16de76104d0114ba8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear, I am NOT saying that all links in the document would need to use HTTPS. I'm saying that if requests to the Webfinger resource are authenticated, links to resources in the same domain as the WebFinger server need to use HTTPS or else we run the risk of a session hijack. That's a very different statement than "TLS be used for all link relations". In other words, if I send an authenticated request to https://example.net/.well-known/webfinger?resource=3Dfoo, and the JRD contains a link to an avatar image located on the same server, the link should be like https://example.net/images/foo-avatar.png. - James On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones wrote= : > Tim,**** > > ** ** > > Perhaps we=E2=80=99re discussing different issues. With respect to wheth= er TLS is > used to query the =E2=80=9Cwebfinger=E2=80=9D resource or not, I understa= nd there are > people arguing both sides. I=E2=80=99m personally neutral on that.**** > > ** ** > > Where the discussion was going here was related to =E2=80=9Cwhere do link > relations in the webfinger response point?=E2=80=9D There is an argument= that we > must also require that TLS be used for all link relations. I disagree wi= th > that as a requirement since we=E2=80=99re now talking about where a user = stores his > data (e.g., an avatar). If he chooses to store that in Flickr or any $1/= mo > hosting provider should not matter. Further, any client processing the W= F > response could see that it is an =E2=80=9Chttp:=E2=80=9D URI and decide o= n a case-by-case > basis how to treat each link relation seen.**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Tuesday, December 04, 2012 2:27 AM > *To:* Paul E. Jones > *Cc:* James M Snell; webfinger@googlegroups.com; Mike Jones; Peter > Saint-Andre > > *Subject:* Re: WebFinger 8 Input...**** > > ** ** > > Paul, you can say this all you want, but there are coherent voices on our > mailing list saying that they really need something written into the spec > to give them assurance that they can use WF and it=E2=80=99ll either go t= hrough TLS > or it won=E2=80=99t happen. There are three coherent come-backs to this:= **** > > ** ** > > - Always HTTPS**** > > - Some sort of normative parameterized behavior**** > > - Those people shouldn=E2=80=99t use WebFinger.**** > > ** ** > > At some point, someone=E2=80=99s going to have to make a consensus call o= n where > the community stands. -T**** > > ** ** > > On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > Keep in mind that WF is to allow users to share all kinds of information > about themselves. Services that need to be secure will use HTTPS. Those > that do not, won=E2=80=99t.**** > > **** > > If I tell my WF service that my avatar is located at some http://location= , then that=E2=80=99s the information the WF server should return in > responses.**** > > **** > > If information needs better security, then the URL would be HTTPS. Any > IdP would utilize an https:// address.**** > > **** > > In any case, the href value in WF can be any valid URI. Use or non-use o= f > TLS for these other resources to which WF refers is really outside the > scope of WF.**** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Tuesday, December 04, 2012 12:44 AM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input...**** > > **** > > **** > > On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > What a WF resource points to should have nothing to do with whether WF > uses HTTPS or not. If I put my vcard out on the Internet accessible only > via http (which is presently the case), then that=E2=80=99s the way it=E2= =80=99s accessed. > (Actually, the HTTPS version works on my domain, but will redirect the > client to the non-HTTPS version.)**** > > **** > > Well... for a typical non-authenticated request to a WebFinger resource, > you're correct. There is an obvious risk, however, of introducing a sessi= on > hijacking vulnerability when using authenticated WebFinger requests with = an > improperly secured server if the JRD provides non-https links to the same > domain. It would be dangerous for us to assume that all relevant cookies > provided on a given domain have been secured properly. As a best practice= , > links provided to resources located on the same domain should simply be > required to use https as a way of erring on the side of caution. **** > > **** > > **** > > During a redirect, the redirection does not need to use the same scheme i= f > the group agrees to allowing HTTP. That said, I fully agree the example = in > section 8 should show use of HTTPS just as a means of encouragement.**** > > **** > > **** > > Issuing a https secured request to a WF endpoint that redirects to an > insecure third party location rather defeats the purpose of requiring htt= ps > for the first request, doesn't it?**** > > **** > > - James**** > > **** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, December 03, 2012 10:01 PM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input...**** > > **** > > Yep, as expected really. Take the various edits for what they are worth. > It was either this or try to go through all the multitude of threads and > provide input on each individual subject... this was by far the more > efficient option for me. I'll come up with a summary of the changes a bit > later on this evening. Most are purely editorial in nature, but there are= a > few important technical items... **** > > **** > > For instance, when serving up a JRD over an HTTPS connection, and that JR= D > contains link relations to resources hosted at the same domain as the > WebFinger service, there is a risk of a TLS-downgrade attack if those lin= k > relations are not https urls... e.g. in the examples we see things like > "href": "http://example.com/foo" ... when it really ought to be "href": " > https://example.com/foo" ...**** > > **** > > Similarly, if we are going to allow the use of 3xx redirects, then the > WebFinger server needs to make sure that the new target URL is using the > https scheme; i.e. instead of "Location: http://example.net/webfinger?...= " > it needs to be "Location: https://example.net/webfinger?..."**** > > **** > > There are a few other bits scattered around. Once the kids are bathed and > off to bed I'll write up a summary.**** > > **** > > Honestly, other than the need to control the flood of discussions > happening on the mailing list, I don't see any reason to rush this to > completion. Let's get a relatively stable draft out there and just let it > sit for a while so implementors can get more experience with it.**** > > **** > > - James**** > > **** > > On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > Wow, that=E2=80=99s a lot of changes. I=E2=80=99d personally like to kee= p the terminology > section the way it is. The word =E2=80=9Clink relation=E2=80=9D is confu= sing to people who > have not heard it, and having that very brief statement is useful, I thin= k. > **** > > **** > > Merging the =E2=80=9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D= sections might be a good idea, > but I recall some time ago there was one section and it was suggested we > split it apart. What we would put in each, I=E2=80=99m not sure. It=E2= =80=99s definitely > a bit overlapping at the moment. I=E2=80=99m OK with merging those secti= ons.**** > > **** > > I really, really prefer to keep the examples in the main body. They=E2= =80=99re > marked as non-normative, but being able to read those before getting > further in the document is very helpful to the reader the first time they > read the text. Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice = to see examples > right up front. Otherwise, the reader=E2=80=99s headed is cloudy all the= way > through the text.**** > > **** > > The header for Section 2 (=E2=80=9CTerminology=E2=80=9D) appears to have = been removed > accidentally.**** > > **** > > In section 8, there are bullet points for the IANA registration template > material. Those should not be there.**** > > **** > > Don=E2=80=99t use =E2=80=9CURI=E2=80=9D before the instant messaging addr= ess in the contact area. > Email addresses are also URIs :-) I wanted IM there.**** > > **** > > Beyond that, the changes are so substantial that I=E2=80=99ll need time t= o see > exactly what they are. I tried to produce a meaningful diff, but since t= he > whole example section was moved, diff programs gets totally confused.**** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, December 03, 2012 8:38 PM > *To:* webfinger@googlegroups.com; Paul Jones; Tim Bray > *Subject:* WebFinger 8 Input...**** > > **** > > Given that the recent WebFinger discussion has been flooding and > overwhelming the IETF appsawg mailing list I have left that mailing list > off the cc list until the new WF specific mailing list has been set up. > While reading through the latest version of the spec, I started to collec= t > a list of specific edits that I thought needed to be made. The list becam= e > rather detailed so it ended up just being easier to draft up a proposed n= ew > version.**** > > **** > > I have checked it in to my personal github repo here...**** > > **** > > http://goo.gl/IaQnm**** > > **** > > The raw xml is here...**** > > **** > > http://goo.gl/QcNCr**** > > **** > > As always, feedback is definitely welcome.**** > > **** > > - James**** > > **** > > **** > > ** ** > --14dae9340ad16de76104d0114ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear, I am NOT saying that all = links in the document would need to use HTTPS. I'm saying that if reque= sts to the Webfinger resource are authenticated, links to resources in the = same domain as the WebFinger server need to use HTTPS or else we run the ri= sk of a session hijack. That's a very different statement than "TL= S be used for all link relations".=C2=A0

In other words, if I send an authenticated request to = https:= //example.net/.well-known/webfinger?resource=3Dfoo, and the JRD contain= s a link to an avatar image located on the same server, the link should be = like https://example.= net/images/foo-avatar.png.

- James

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jon= es <paulej@packetizer.com> wrote:

Tim,

=C2=A0

Perhaps we=E2=80=99= re discussing different issues.=C2=A0 With respect to whether TLS is used t= o query the =E2=80=9Cwebfinger=E2=80=9D resource or not, I understand there= are people arguing both sides.=C2=A0 I=E2=80=99m personally neutral on tha= t.

=C2=A0

Where the discussio= n was going here was related to =E2=80=9Cwhere do link relations in the web= finger response point?=E2=80=9D=C2=A0 There is an argument that we must als= o require that TLS be used for all link relations.=C2=A0 I disagree with th= at as a requirement since we=E2=80=99re now talking about where a user stor= es his data (e.g., an avatar).=C2=A0 If he chooses to store that in Flickr = or any $1/mo hosting provider should not matter.=C2=A0 Further, any client = processing the WF response could see that it is an =E2=80=9Chttp:=E2=80=9D = URI and decide on a case-by-case basis how to treat each link relation seen= .

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones=
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-= Andre


Subject: Re: WebFinger 8 Input...<= u>

=C2=A0

Paul= , you can say this all you want, but there are coherent voices on our maili= ng list saying that they really need something written into the spec to giv= e them assurance that they can use WF and it=E2=80=99ll either go through T= LS or it won=E2=80=99t happen. =C2=A0There are three coherent come-backs to= this:

=C2=A0

- Always HTTPS=

- Some sort of normative param= eterized behavior

- Those people shouldn=E2=80=99t use WebFinger.

=C2=A0

At some point, someone=E2=80= =99s going to have to make a consensus call on where the community stands. = -T

=C2=A0

=

On Mon, Dec 3, 2012 at 9:58 PM, Paul E. J= ones <paulej@= packetizer.com> wrote:

James,

=C2=A0

Keep in mind that WF is t= o allow users to share all kinds of information about themselves.=C2=A0 Ser= vices that need to be secure will use HTTPS.=C2=A0 Those that do not, won= =E2=80=99t.

=C2=A0

If I tell my WF ser= vice that my avatar is located at some http:// location, then that=E2=80=99= s the information the WF server should return in responses.

=C2=A0

If information need= s better security, then the URL would be HTTPS.=C2=A0 Any IdP would utilize= an https:// address.

=C2=A0

In any case, the hr= ef value in WF can be any valid URI. =C2=A0Use or non-use of TLS for these = other resources to which WF refers is really outside the scope of WF.

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jone= s
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e
Subject: Re: WebFinger 8 Input...

=C2=A0

=C2=A0

On Mon, Dec 3, 2012 a= t 7:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

What a WF resource points= to should have nothing to do with whether WF uses HTTPS or not.=C2=A0 If I= put my vcard out on the Internet accessible only via http (which is presen= tly the case), then that=E2=80=99s the way it=E2=80=99s accessed.=C2=A0 (Ac= tually, the HTTPS version works on my domain, but will redirect the client = to the non-HTTPS version.)

=C2=A0

=

Well... for a typical non-authenticated request to a= WebFinger resource, you're correct. There is an obvious risk, however,= of introducing a session hijacking vulnerability when using authenticated = WebFinger requests with an improperly secured server if the JRD provides no= n-https links to the same domain. It would be dangerous for us to assume th= at all relevant cookies provided on a given domain have been secured proper= ly. As a best practice, links provided to resources located on the same dom= ain should simply be required to use https as a way of erring on the side o= f caution.=C2=A0

=C2=A0

=C2=A0=

During a redir= ect, the redirection does not need to use the same scheme if the group agre= es to allowing HTTP.=C2=A0 That said, I fully agree the example in section = 8 should show use of HTTPS just as a means of encouragement.<= u>

=C2=A0

=C2=A0=

Issuing a https secured request to a WF endpoin= t that redirects to an insecure third party location rather defeats the pur= pose of requiring https for the first request, doesn't it?

=C2=A0

- James

=C2=A0

=C2=A0=

Paul<= /u>

=C2=A0

From:= James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones=
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre=
Subject: Re: WebFinger 8 Input...

=C2=A0

Yep, as expected= really. Take the various edits for what they are worth. It was either this= or try to go through all the multitude of threads and provide input on eac= h individual subject... this was by far the more efficient option for me. I= 'll come up with a summary of the changes a bit later on this evening. = Most are purely editorial in nature, but there are a few important technica= l items...=C2=A0

=C2=A0

For instance= , when serving up a JRD over an HTTPS connection, and that JRD contains lin= k relations to resources hosted at the same domain as the WebFinger service= , there is a risk of a TLS-downgrade attack if those link relations are not= https urls... e.g. in the examples we see things like "href": &q= uot;http://example.com= /foo" ... when it really ought to be "href": "https://example.com/foo" ...

=C2=A0

=C2=A0

There = are a few other bits scattered around. Once the kids are bathed and off to = bed I'll write up a summary.

=C2=A0

Honest= ly, other than the need to control the flood of discussions happening on th= e mailing list, I don't see any reason to rush this to completion. Let&= #39;s get a relatively stable draft out there and just let it sit for a whi= le so implementors can get more experience with it.

=C2=A0

- Jame= s

=C2=A0

On Mon, Dec 3, 2012 at = 6:45 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

Wow, that=E2=80=99s a lot= of changes.=C2=A0 I=E2=80=99d personally like to keep the terminology sect= ion the way it is.=C2=A0 The word =E2=80=9Clink relation=E2=80=9D is confus= ing to people who have not heard it, and having that very brief statement i= s useful, I think.

=C2=A0

Merging the =E2=80= =9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D sections might be a= good idea, but I recall some time ago there was one section and it was sug= gested we split it apart.=C2=A0 What we would put in each, I=E2=80=99m not = sure.=C2=A0 It=E2=80=99s definitely a bit overlapping at the moment.=C2=A0 = I=E2=80=99m OK with merging those sections.

=C2=A0

I really, really pr= efer to keep the examples in the main body. =C2=A0They=E2=80=99re marked as= non-normative, but being able to read those before getting further in the = document is very helpful to the reader the first time they read the text.= =C2=A0 Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice to see exam= ples right up front.=C2=A0 Otherwise, the reader=E2=80=99s headed is cloudy= all the way through the text.

=C2=A0

The header for Sect= ion 2 (=E2=80=9CTerminology=E2=80=9D) appears to have been removed accident= ally.

=C2=A0

In section 8, there= are bullet points for the IANA registration template material.=C2=A0 Those= should not be there.

=C2=A0

Don=E2=80=99t use = =E2=80=9CURI=E2=80=9D before the instant messaging address in the contact a= rea.=C2=A0 Email addresses are also URIs :-)=C2=A0 I wanted IM there.

=C2=A0

Beyond that, the ch= anges are so substantial that I=E2=80=99ll need time to see exactly what th= ey are.=C2=A0 I tried to produce a meaningful diff, but since the whole exa= mple section was moved, diff programs gets totally confused.<= u>

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.co= m; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...<= u>

=C2=A0

Given = that the recent WebFinger discussion has been flooding and overwhelming the= IETF appsawg mailing list I have left that mailing list off the cc list un= til the new WF specific mailing list has been set up. While reading through= the latest version of the spec, I started to collect a list of specific ed= its that I thought needed to be made. The list became rather detailed so it= ended up just being easier to draft up a proposed new version.

=C2=A0

I have check= ed it in to my personal github repo here...

<= div>

=C2=A0

=C2=A0=C2=A0http://goo.gl/IaQnm

=C2=A0

The raw xml is here...<= /u>

=C2=A0

=C2=A0=C2=A0http://goo.gl/QcNCr

=C2=A0

As always, feedback is = definitely welcome.

=C2=A0

- James

=C2=A0<= /u>

=C2=A0

=C2=A0


--14dae9340ad16de76104d0114ba8-- From jasnell@gmail.com Tue Dec 4 20:28:08 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61E221F8C08 for ; Tue, 4 Dec 2012 20:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.738 X-Spam-Level: X-Spam-Status: No, score=-3.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV5Wf65NWj1V for ; Tue, 4 Dec 2012 20:28:07 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A621F8C0A for ; Tue, 4 Dec 2012 20:28:06 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7970436ieb.31 for ; Tue, 04 Dec 2012 20:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1rzijuFj0onogPLpHhLBVKsY7IvKv93tSASNRnYSj1A=; b=Lr+aYNsslrZ3nrJoIYmULHbTUjBMMbmoEtAEJHa2Q/NJLfkgAqZvy4Qzd2f/nRpGot Tt80+kkme8YZm8a+9yVvjehJJlg36e9lsZ6QKfHA3UyTxmbdYIQCiSV95NR2WNtpcMYX KHOPaAGDTFWJHBID1ccz671gFHouqSKdVcoLgkXhEerSlURzE3HRWXBojv/Zzk294FSu O5xTS5uXX1Cw9PpGSeaj1RcKlpXY75BN/xurt9fdgA3lRB2H6N55Kn6ael6J1gU8WyVB NCvH7+hnKdTuL+iS87wLRRFQy8IPxnNpaIbE8hsuMsxXgpyMfN9mrbuNnxLB6qHyEXes OdJQ== MIME-Version: 1.0 Received: by 10.50.0.193 with SMTP id 1mr706729igg.0.1354681686427; Tue, 04 Dec 2012 20:28:06 -0800 (PST) Received: by 10.64.7.19 with HTTP; Tue, 4 Dec 2012 20:28:06 -0800 (PST) Received: by 10.64.7.19 with HTTP; Tue, 4 Dec 2012 20:28:06 -0800 (PST) In-Reply-To: References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> Date: Tue, 4 Dec 2012 20:28:06 -0800 Message-ID: From: James M Snell To: John Panzer Content-Type: multipart/alternative; boundary=e89a8f502f8eb4071704d01368a1 Cc: webfinger@ietf.org, Mike Jones , Tim Bray , Peter Saint-Andre , webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:28:09 -0000 --e89a8f502f8eb4071704d01368a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All good but entirely orthogonal to the issue I raised. This has nothing to do with what schemes are allowed in general and everything to do with a possible session hijack vulnerability. On Dec 4, 2012 8:25 PM, "John Panzer" wrote: > +1. Well, gopher is beyond the pale of course. > > data: would be particularly useful. > On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" wrote: > >> I agree that the webfinger response's links should be allowed to be any >> protocol, be it https://, http://, or gopher://. >> >> On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones wro= te: >> >>> Tim,**** >>> >>> ** ** >>> >>> Perhaps we=E2=80=99re discussing different issues. With respect to whe= ther TLS >>> is used to query the =E2=80=9Cwebfinger=E2=80=9D resource or not, I und= erstand there are >>> people arguing both sides. I=E2=80=99m personally neutral on that.**** >>> >>> ** ** >>> >>> Where the discussion was going here was related to =E2=80=9Cwhere do li= nk >>> relations in the webfinger response point?=E2=80=9D There is an argume= nt that we >>> must also require that TLS be used for all link relations. I disagree = with >>> that as a requirement since we=E2=80=99re now talking about where a use= r stores his >>> data (e.g., an avatar). If he chooses to store that in Flickr or any $= 1/mo >>> hosting provider should not matter. Further, any client processing the= WF >>> response could see that it is an =E2=80=9Chttp:=E2=80=9D URI and decide= on a case-by-case >>> basis how to treat each link relation seen.**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Tim Bray [mailto:twbray@google.com] >>> *Sent:* Tuesday, December 04, 2012 2:27 AM >>> *To:* Paul E. Jones >>> *Cc:* James M Snell; webfinger@googlegroups.com; Mike Jones; Peter >>> Saint-Andre >>> >>> *Subject:* Re: WebFinger 8 Input...**** >>> >>> ** ** >>> >>> Paul, you can say this all you want, but there are coherent voices on >>> our mailing list saying that they really need something written into th= e >>> spec to give them assurance that they can use WF and it=E2=80=99ll eith= er go >>> through TLS or it won=E2=80=99t happen. There are three coherent come-= backs to >>> this:**** >>> >>> ** ** >>> >>> - Always HTTPS**** >>> >>> - Some sort of normative parameterized behavior**** >>> >>> - Those people shouldn=E2=80=99t use WebFinger.**** >>> >>> ** ** >>> >>> At some point, someone=E2=80=99s going to have to make a consensus call= on where >>> the community stands. -T**** >>> >>> ** ** >>> >>> On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones >>> wrote:**** >>> >>> James,**** >>> >>> **** >>> >>> Keep in mind that WF is to allow users to share all kinds of informatio= n >>> about themselves. Services that need to be secure will use HTTPS. Tho= se >>> that do not, won=E2=80=99t.**** >>> >>> **** >>> >>> If I tell my WF service that my avatar is located at some http://locati= on, then that=E2=80=99s the information the WF server should return in >>> responses.**** >>> >>> **** >>> >>> If information needs better security, then the URL would be HTTPS. Any >>> IdP would utilize an https:// address.**** >>> >>> **** >>> >>> In any case, the href value in WF can be any valid URI. Use or non-use >>> of TLS for these other resources to which WF refers is really outside t= he >>> scope of WF.**** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> *From:* James M Snell [mailto:jasnell@gmail.com] >>> *Sent:* Tuesday, December 04, 2012 12:44 AM >>> *To:* Paul E. Jones >>> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter >>> Saint-Andre >>> *Subject:* Re: WebFinger 8 Input...**** >>> >>> **** >>> >>> **** >>> >>> On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones >>> wrote:**** >>> >>> James,**** >>> >>> **** >>> >>> What a WF resource points to should have nothing to do with whether WF >>> uses HTTPS or not. If I put my vcard out on the Internet accessible on= ly >>> via http (which is presently the case), then that=E2=80=99s the way it= =E2=80=99s accessed. >>> (Actually, the HTTPS version works on my domain, but will redirect the >>> client to the non-HTTPS version.)**** >>> >>> **** >>> >>> Well... for a typical non-authenticated request to a WebFinger resource= , >>> you're correct. There is an obvious risk, however, of introducing a ses= sion >>> hijacking vulnerability when using authenticated WebFinger requests wit= h an >>> improperly secured server if the JRD provides non-https links to the sa= me >>> domain. It would be dangerous for us to assume that all relevant cookie= s >>> provided on a given domain have been secured properly. As a best practi= ce, >>> links provided to resources located on the same domain should simply be >>> required to use https as a way of erring on the side of caution. **** >>> >>> **** >>> >>> **** >>> >>> During a redirect, the redirection does not need to use the same scheme >>> if the group agrees to allowing HTTP. That said, I fully agree the exa= mple >>> in section 8 should show use of HTTPS just as a means of encouragement.= * >>> *** >>> >>> **** >>> >>> **** >>> >>> Issuing a https secured request to a WF endpoint that redirects to an >>> insecure third party location rather defeats the purpose of requiring h= ttps >>> for the first request, doesn't it?**** >>> >>> **** >>> >>> - James**** >>> >>> **** >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> *From:* James M Snell [mailto:jasnell@gmail.com] >>> *Sent:* Monday, December 03, 2012 10:01 PM >>> *To:* Paul E. Jones >>> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter >>> Saint-Andre >>> *Subject:* Re: WebFinger 8 Input...**** >>> >>> **** >>> >>> Yep, as expected really. Take the various edits for what they are worth= . >>> It was either this or try to go through all the multitude of threads an= d >>> provide input on each individual subject... this was by far the more >>> efficient option for me. I'll come up with a summary of the changes a b= it >>> later on this evening. Most are purely editorial in nature, but there a= re a >>> few important technical items... **** >>> >>> **** >>> >>> For instance, when serving up a JRD over an HTTPS connection, and that >>> JRD contains link relations to resources hosted at the same domain as t= he >>> WebFinger service, there is a risk of a TLS-downgrade attack if those l= ink >>> relations are not https urls... e.g. in the examples we see things like >>> "href": "http://example.com/foo" ... when it really ought to be "href": >>> "https://example.com/foo" ...**** >>> >>> **** >>> >>> Similarly, if we are going to allow the use of 3xx redirects, then the >>> WebFinger server needs to make sure that the new target URL is using th= e >>> https scheme; i.e. instead of "Location: http://example.net/webfinger?.= .." >>> it needs to be "Location: https://example.net/webfinger?..."**** >>> >>> **** >>> >>> There are a few other bits scattered around. Once the kids are bathed >>> and off to bed I'll write up a summary.**** >>> >>> **** >>> >>> Honestly, other than the need to control the flood of discussions >>> happening on the mailing list, I don't see any reason to rush this to >>> completion. Let's get a relatively stable draft out there and just let = it >>> sit for a while so implementors can get more experience with it.**** >>> >>> **** >>> >>> - James**** >>> >>> **** >>> >>> On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones >>> wrote:**** >>> >>> James,**** >>> >>> **** >>> >>> Wow, that=E2=80=99s a lot of changes. I=E2=80=99d personally like to k= eep the >>> terminology section the way it is. The word =E2=80=9Clink relation=E2= =80=9D is confusing >>> to people who have not heard it, and having that very brief statement i= s >>> useful, I think.**** >>> >>> **** >>> >>> Merging the =E2=80=9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80= =9D sections might be a good idea, >>> but I recall some time ago there was one section and it was suggested w= e >>> split it apart. What we would put in each, I=E2=80=99m not sure. It= =E2=80=99s definitely >>> a bit overlapping at the moment. I=E2=80=99m OK with merging those sec= tions.*** >>> * >>> >>> **** >>> >>> I really, really prefer to keep the examples in the main body. They=E2= =80=99re >>> marked as non-normative, but being able to read those before getting >>> further in the document is very helpful to the reader the first time th= ey >>> read the text. Heck, even if they=E2=80=99ve read it, it=E2=80=99s nic= e to see examples >>> right up front. Otherwise, the reader=E2=80=99s headed is cloudy all t= he way >>> through the text.**** >>> >>> **** >>> >>> The header for Section 2 (=E2=80=9CTerminology=E2=80=9D) appears to hav= e been removed >>> accidentally.**** >>> >>> **** >>> >>> In section 8, there are bullet points for the IANA registration templat= e >>> material. Those should not be there.**** >>> >>> **** >>> >>> Don=E2=80=99t use =E2=80=9CURI=E2=80=9D before the instant messaging ad= dress in the contact >>> area. Email addresses are also URIs :-) I wanted IM there.**** >>> >>> **** >>> >>> Beyond that, the changes are so substantial that I=E2=80=99ll need time= to see >>> exactly what they are. I tried to produce a meaningful diff, but since= the >>> whole example section was moved, diff programs gets totally confused.**= * >>> * >>> >>> **** >>> >>> Paul**** >>> >>> **** >>> >>> *From:* James M Snell [mailto:jasnell@gmail.com] >>> *Sent:* Monday, December 03, 2012 8:38 PM >>> *To:* webfinger@googlegroups.com; Paul Jones; Tim Bray >>> *Subject:* WebFinger 8 Input...**** >>> >>> **** >>> >>> Given that the recent WebFinger discussion has been flooding and >>> overwhelming the IETF appsawg mailing list I have left that mailing lis= t >>> off the cc list until the new WF specific mailing list has been set up. >>> While reading through the latest version of the spec, I started to coll= ect >>> a list of specific edits that I thought needed to be made. The list bec= ame >>> rather detailed so it ended up just being easier to draft up a proposed= new >>> version.**** >>> >>> **** >>> >>> I have checked it in to my personal github repo here...**** >>> >>> **** >>> >>> http://goo.gl/IaQnm**** >>> >>> **** >>> >>> The raw xml is here...**** >>> >>> **** >>> >>> http://goo.gl/QcNCr**** >>> >>> **** >>> >>> As always, feedback is definitely welcome.**** >>> >>> **** >>> >>> - James**** >>> >>> **** >>> >>> **** >>> >>> ** ** >>> >> >> --e89a8f502f8eb4071704d01368a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

All good but entirely orthogonal to the issue I raised. This= has nothing to do with what schemes are allowed in general and everything = to do with a possible session hijack vulnerability.

On Dec 4, 2012 8:25 PM, "John Panzer" = <jpanzer@google.com> wrote:=

+1.=C2=A0 Well, gopher is beyond the pale of course.

data: would be particularly useful.

On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick&q= uot; <bradfitz@= google.com> wrote:
I agre= e that the webfinger response's links should be allowed to be any proto= col, be it https://, http://, or gopher://.

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

=C2=A0

Perhaps we=E2=80=99re discussing different= issues.=C2=A0 With respect to whether TLS is used to query the =E2=80=9Cwe= bfinger=E2=80=9D resource or not, I understand there are people arguing bot= h sides.=C2=A0 I=E2=80=99m personally neutral on that.=

=C2=A0

Where the discussio= n was going here was related to =E2=80=9Cwhere do link relations in the web= finger response point?=E2=80=9D=C2=A0 There is an argument that we must als= o require that TLS be used for all link relations.=C2=A0 I disagree with th= at as a requirement since we=E2=80=99re now talking about where a user stor= es his data (e.g., an avatar).=C2=A0 If he chooses to store that in Flickr = or any $1/mo hosting provider should not matter.=C2=A0 Further, any client = processing the WF response could see that it is an =E2=80=9Chttp:=E2=80=9D = URI and decide on a case-by-case basis how to treat each link relation seen= .

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones=
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-= Andre


Subject: Re: WebFinger 8 Input...

=C2=A0

Paul, you can say this all you want, but there ar= e coherent voices on our mailing list saying that they really need somethin= g written into the spec to give them assurance that they can use WF and it= =E2=80=99ll either go through TLS or it won=E2=80=99t happen. =C2=A0There a= re three coherent come-backs to this:

=C2=A0

- Always HTTPS=

- Some sort of normative param= eterized behavior

- Those people shouldn=E2=80=99t use WebFinger.

=C2=A0

At some point, someone=E2=80= =99s going to have to make a consensus call on where the community stands. = -T

=C2=A0

On Mon, Dec 3, 2012 at 9:58 PM,= Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

Keep in mind that WF is t= o allow users to share all kinds of information about themselves.=C2=A0 Ser= vices that need to be secure will use HTTPS.=C2=A0 Those that do not, won= =E2=80=99t.

=C2=A0

If I tell my WF ser= vice that my avatar is located at some http:// location, then that=E2=80=99= s the information the WF server should return in responses.

=C2=A0

If information need= s better security, then the URL would be HTTPS.=C2=A0 Any IdP would utilize= an https:// address.

=C2=A0

In any case, the hr= ef value in WF can be any valid URI. =C2=A0Use or non-use of TLS for these = other resources to which WF refers is really outside the scope of WF.

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jone= s
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e
Subject: Re: WebFinger 8 Input...

=C2=A0

=C2=A0

On Mon, Dec 3, 2012 a= t 7:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

What a WF resource points= to should have nothing to do with whether WF uses HTTPS or not.=C2=A0 If I= put my vcard out on the Internet accessible only via http (which is presen= tly the case), then that=E2=80=99s the way it=E2=80=99s accessed.=C2=A0 (Ac= tually, the HTTPS version works on my domain, but will redirect the client = to the non-HTTPS version.)

=C2=A0

=

Well... for a typical non-authenticated request to a= WebFinger resource, you're correct. There is an obvious risk, however,= of introducing a session hijacking vulnerability when using authenticated = WebFinger requests with an improperly secured server if the JRD provides no= n-https links to the same domain. It would be dangerous for us to assume th= at all relevant cookies provided on a given domain have been secured proper= ly. As a best practice, links provided to resources located on the same dom= ain should simply be required to use https as a way of erring on the side o= f caution.=C2=A0

=C2=A0

=C2=A0=

During a redir= ect, the redirection does not need to use the same scheme if the group agre= es to allowing HTTP.=C2=A0 That said, I fully agree the example in section = 8 should show use of HTTPS just as a means of encouragement.<= u>

=C2=A0

=C2=A0=

Issuing a https secured request to a WF endpoin= t that redirects to an insecure third party location rather defeats the pur= pose of requiring https for the first request, doesn't it?

=C2=A0

- James

=C2=A0

=C2=A0=

Paul<= /u>

=C2=A0

From:= James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones=
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre=
Subject: Re: WebFinger 8 Input...

=C2=A0

Yep, as expected= really. Take the various edits for what they are worth. It was either this= or try to go through all the multitude of threads and provide input on eac= h individual subject... this was by far the more efficient option for me. I= 'll come up with a summary of the changes a bit later on this evening. = Most are purely editorial in nature, but there are a few important technica= l items...=C2=A0

=C2=A0

For instance= , when serving up a JRD over an HTTPS connection, and that JRD contains lin= k relations to resources hosted at the same domain as the WebFinger service= , there is a risk of a TLS-downgrade attack if those link relations are not= https urls... e.g. in the examples we see things like "href": &q= uot;http://example.com= /foo" ... when it really ought to be "href": "https://example.com/foo" ...

=C2=A0

=C2=A0

There = are a few other bits scattered around. Once the kids are bathed and off to = bed I'll write up a summary.

=C2=A0

Honest= ly, other than the need to control the flood of discussions happening on th= e mailing list, I don't see any reason to rush this to completion. Let&= #39;s get a relatively stable draft out there and just let it sit for a whi= le so implementors can get more experience with it.

=C2=A0

- Jame= s

=C2=A0

On Mon, Dec 3, 2012 at = 6:45 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

Wow, that=E2=80=99s a lot= of changes.=C2=A0 I=E2=80=99d personally like to keep the terminology sect= ion the way it is.=C2=A0 The word =E2=80=9Clink relation=E2=80=9D is confus= ing to people who have not heard it, and having that very brief statement i= s useful, I think.

=C2=A0

Merging the =E2=80= =9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D sections might be a= good idea, but I recall some time ago there was one section and it was sug= gested we split it apart.=C2=A0 What we would put in each, I=E2=80=99m not = sure.=C2=A0 It=E2=80=99s definitely a bit overlapping at the moment.=C2=A0 = I=E2=80=99m OK with merging those sections.

=C2=A0

I really, really pr= efer to keep the examples in the main body. =C2=A0They=E2=80=99re marked as= non-normative, but being able to read those before getting further in the = document is very helpful to the reader the first time they read the text.= =C2=A0 Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice to see exam= ples right up front.=C2=A0 Otherwise, the reader=E2=80=99s headed is cloudy= all the way through the text.

=C2=A0

The header for Sect= ion 2 (=E2=80=9CTerminology=E2=80=9D) appears to have been removed accident= ally.

=C2=A0

In section 8, there= are bullet points for the IANA registration template material.=C2=A0 Those= should not be there.

=C2=A0

Don=E2=80=99t use = =E2=80=9CURI=E2=80=9D before the instant messaging address in the contact a= rea.=C2=A0 Email addresses are also URIs :-)=C2=A0 I wanted IM there.

=C2=A0

Beyond that, the ch= anges are so substantial that I=E2=80=99ll need time to see exactly what th= ey are.=C2=A0 I tried to produce a meaningful diff, but since the whole exa= mple section was moved, diff programs gets totally confused.<= u>

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.co= m; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...<= u>

=C2=A0

Given = that the recent WebFinger discussion has been flooding and overwhelming the= IETF appsawg mailing list I have left that mailing list off the cc list un= til the new WF specific mailing list has been set up. While reading through= the latest version of the spec, I started to collect a list of specific ed= its that I thought needed to be made. The list became rather detailed so it= ended up just being easier to draft up a proposed new version.

=C2=A0

I have check= ed it in to my personal github repo here...

<= div>

=C2=A0

=C2=A0=C2=A0http://goo.gl/IaQnm

=C2=A0

The raw xml is here...<= /u>

=C2=A0

=C2=A0=C2=A0http://goo.gl/QcNCr

=C2=A0

As always, feedback is = definitely welcome.

=C2=A0

- James

=C2=A0<= /u>

=C2=A0

=C2=A0


--e89a8f502f8eb4071704d01368a1-- From paulej@packetizer.com Tue Dec 4 20:53:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D5521F8BED for ; Tue, 4 Dec 2012 20:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dy4nh0wwFPw for ; Tue, 4 Dec 2012 20:53:42 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1560621F8BC1 for ; Tue, 4 Dec 2012 20:53:42 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB54reHC006054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Dec 2012 23:53:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354683220; bh=do3O8jqlsuEEZ1dqa0pSBbYDG9DQGZm/I8KpvfeLteI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U1fK8R6O+uZ5wyOBIVF+4AGrSpjka7io851Cs/ohQz5UG7FkSfNWRBOMs4DBaGtin l9mEOaazZ/PeSnHzguNgxQOAKC8YahlVdRaC0rHkUSjdHEqHg4Lycbwq9YYFbGnxEJ nTVmao99nyfKS3/LT1e8PVIt8ynOt4iWOoIZmdeA= From: "Paul E. Jones" To: "'Nick Jennings'" , References: <08e501cdd126$1ad6ce60$50846b20$@packetizer.com> <0bd101cdd19a$d3f59bf0$7be0d3d0$@packetizer.com> In-Reply-To: Date: Tue, 4 Dec 2012 23:53:43 -0500 Message-ID: <0f1b01cdd2a4$80c16580$82443080$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLG5ikawERVTngmuhW5Swaa7Q+GsgI3/5g1Ag8WQqQDdiGyhgHHV/nhlctP6aA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] Draft -07 mod proposal: Clean up "subject" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:53:43 -0000 Nick, > On Mon, Dec 3, 2012 at 10:11 PM, Paul E. Jones > wrote: > > Nick, > > > > Does the words "would be expected to be equivalent" cause the concern? > Should I make that "normally be equivalent"? > > Well I guess it would help to have some clarification on the > implications (if any) of differences in the subject. Are there reasons > the client library would want to check this and do something different > if there is a difference? The subject will properly identify the entity being queried. If a querying user provides a correct, but perhaps not the preferred normalized form or perhaps an identifier that has been updated or changed. It could also be safely ignored in favor of what the user provided. If the subject is different, nothing should break. The client should still accept the reply and use it. > > This is not a "forwarding", per se, but could inform the client that > additional or other information is available elsewhere. This was never > intended to a be a "forwarding" mechanism, though. The 3xx should do > that. > > > If you were using an email provider like gmail, or yahoo, but changed > your email address and wanted to forward to your new address, do you > think it's likely one of these big email providers would implement a way > for you to set up a 301 (or 307) redirect for all queries on your > account? I would guess no, so it seems more practical to have some > method of specifying this 'inline'. I would think it's highly unlikely that the big mail providers would be so kind as to provide any sort of forwarding service whatsoever. They certainly don't do it for email today (and that's well-defined), so I cannot expect they'll do it for WF. > In the JRD example you gave above, a WF client probably wouldn't > automatically issue a new request to the address based on that 'acct' > relation entry. So you'd loose quick-lookup functionality for all your > old interactions with your old email address. Possibly. For now, I'd only consider 3xx as the forwarding mechanism. We'll get to the "acct" link relation in another document and debate the merits there. > I know there's probably no chance of this being introduced to the spec > (having a standard way of specifying a forwarding account within the JRD > response) but thought I'd bring it up anyway as I think there's plenty > of use cases for it (ie. switching jobs, switching email providers, > switching from an @gmail.com account to an @[mydomainname] account, or > just having a few variations on the spelling of your name). I do think 3xx is the right way to do it, and that's in the spec. This mechanism requires nothing new for the client to implement to get forwarding benefits. Paul From laurentwalter.goix@telecomitalia.it Wed Dec 5 00:03:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3436C21F8C04 for ; Wed, 5 Dec 2012 00:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6smUamZA9yX for ; Wed, 5 Dec 2012 00:03:11 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5E821F85EA for ; Wed, 5 Dec 2012 00:03:10 -0800 (PST) Content-Type: multipart/mixed; boundary="_403647b9-28a8-4ad6-8e4a-8e6790e2ca52_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 5 Dec 2012 09:03:07 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 5 Dec 2012 09:03:07 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Wed, 5 Dec 2012 09:03:05 +0100 Thread-Topic: WebFinger 8 Input... Thread-Index: Ac3SvvW3Ig/kgX8tQcW8cMrlgAHOrQ== Message-ID: References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: Tim Bray , "webfinger@googlegroups.com" , Mike Jones , James M Snell , Peter Saint-Andre , "webfinger@ietf.org" Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:03:13 -0000 --_403647b9-28a8-4ad6-8e4a-8e6790e2ca52_ Content-Type: multipart/alternative; boundary="_000_B3651EE16E344DFBB0D9864F7B62B1D8telecomitaliait_" --_000_B3651EE16E344DFBB0D9864F7B62B1D8telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkIHRoYXQgaHR0cHMtb25seSBsaW5rIHJlbHMgKGV2ZW4gb24gaHR0cHMgd2YpIGlzIHRv byByZXN0cmljdGl2ZS4gSSBtYXkgaGF2ZSBtYW55IHB1YmxpYyBpbmZvIG91dCB0aGVyZSB0aGF0 IGRvIG5vdCByZXF1aXJlIGh0dHBzIChteSBhdmF0YXIgYXQgZmlyc3QpLiBQbHVzIHRoZXJlIGFy ZSBtYW55IGFyZ3VtZW50cyBmb3IgYW55IFVyaXM6IGRhdGE6IGlzIGEgZ29vZCBleGFtcGxlIGZv ciBteSBhdmF0YXIgYW5kIGF1dG8gY29uZmlndXJhdGlvbiBzY2VuYXJpb3MgbWF5IGludm9sdmUg b3RoZXIgc2NoZW1lcyBtYXliZSByZWxhdGVkIHRvIHRoZSBzY2hlbWUgcmVxdWVzdGVkIGluIHRo ZSByZXNvdXJjZSBwYXJhbSwgYnV0IG5vdCBvbmx5Lg0KDQpSZSBodHRwcyB2cyBodHRwIGFzIEkg bWVudGlvbmVkIGVhcmxpZXIgaW4gbWFueSBjYXNlcyBpbiBtb2JpbGUgbmV0d29ya3MgdGhlIHVz ZXIgaWRlbnRpdHkgY2FuIGJlIGlkZW50aWZpZWQgYnkgdGhlIG5ldHdvcmsgb25seSBvdmVyIGh0 dHAuIFRoaXMgZG9lc24ndCBwcmV2ZW50IGh0dHBzIHJlcXVlc3RzIGJ1dCB0eXBpY2FsbHkgcmVx dWlyZSBhbiBpbml0aWFsIHBsYWluIGh0dHAgcmVxdWVzdCwgdG8gY3JlYXRlIHNvbWUgc2Vzc2lv bi9jb29raWUgb24gdGhlIHNlcnZlciBzaWRlIGFuZCB0aGVuIHJlaXNzdWUgdGhlIHNhbWUgb3Zl ciBodHRwcy4gU29tZXRpbWVzIHNlbnNpYmxlIGluZm8gaXMgbm90IHBhc3NlZCBpbiB0aGUgZmly c3QgcXVlcnkvYW5zd2VyLiBVbHRpbWF0ZWx5IHRoZSBnb2FsIGlzIGh0dHBzIGluIHRoZXNlIGNh c2VzIGFzIHdlbGwgYnV0IHRoZSBzcGVjIHNob3VsZG4ndCBzYXkgdGhhdCBodHRwcyBtdXN0IGJl IGZpcnN0Lg0KDQoNCg0KTGUgNSBkw6ljLiAyMDEyIMOgIDA1OjMzLCAiSm9obiBQYW56ZXIiIDxq cGFuemVyQGdvb2dsZS5jb208bWFpbHRvOmpwYW56ZXJAZ29vZ2xlLmNvbT4+IGEgw6ljcml0IDoN Cg0KDQpOb3Qgb3J0aG9nb25hbCwgYXMgZGF0YTogdXJpcyBjYW4ndCBpbnRyb2R1Y2UgYSBoaWph Y2tpbmcgdnVsbmVyYWJpbGl0eSBhbmQgdGhleSBhcmUgdXNlZnVsIGZvciB0aGF0IHJlYXNvbiAo cGx1cyBsYXRlbmN5KS4gIFNvIHdlYiBmaW5nZXIgd291bGQgYmUgb3ZlciByZXN0cmljdGl2ZSBp ZiBpdCB3ZXJlIHRvIHNwZWNpZnkgaHR0cHMgb25seSBmb3IgZXhhbXBsZS4NCg0KT24gRGVjIDQs IDIwMTIgODoyOCBQTSwgIkphbWVzIE0gU25lbGwiIDxqYXNuZWxsQGdtYWlsLmNvbTxtYWlsdG86 amFzbmVsbEBnbWFpbC5jb20+PiB3cm90ZToNCg0KQWxsIGdvb2QgYnV0IGVudGlyZWx5IG9ydGhv Z29uYWwgdG8gdGhlIGlzc3VlIEkgcmFpc2VkLiBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGgg d2hhdCBzY2hlbWVzIGFyZSBhbGxvd2VkIGluIGdlbmVyYWwgYW5kIGV2ZXJ5dGhpbmcgdG8gZG8g d2l0aCBhIHBvc3NpYmxlIHNlc3Npb24gaGlqYWNrIHZ1bG5lcmFiaWxpdHkuDQoNCk9uIERlYyA0 LCAyMDEyIDg6MjUgUE0sICJKb2huIFBhbnplciIgPGpwYW56ZXJAZ29vZ2xlLmNvbTxtYWlsdG86 anBhbnplckBnb29nbGUuY29tPj4gd3JvdGU6DQoNCisxLiAgV2VsbCwgZ29waGVyIGlzIGJleW9u ZCB0aGUgcGFsZSBvZiBjb3Vyc2UuDQoNCmRhdGE6IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1c2Vm dWwuDQoNCk9uIERlYyA0LCAyMDEyIDg6MDUgUE0sICJCcmFkIEZpdHpwYXRyaWNrIiA8YnJhZGZp dHpAZ29vZ2xlLmNvbTxtYWlsdG86YnJhZGZpdHpAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSSBhZ3Jl ZSB0aGF0IHRoZSB3ZWJmaW5nZXIgcmVzcG9uc2UncyBsaW5rcyBzaG91bGQgYmUgYWxsb3dlZCB0 byBiZSBhbnkgcHJvdG9jb2wsIGJlIGl0IGh0dHBzOi8vLCBodHRwOi8vLCBvciBnb3BoZXI6Ly8u DQoNCk9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQgNTo1MSBQTSwgUGF1bCBFLiBKb25lcyA8cGF1bGVq QHBhY2tldGl6ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiB3cm90ZToNClRp bSwNCg0KUGVyaGFwcyB3ZeKAmXJlIGRpc2N1c3NpbmcgZGlmZmVyZW50IGlzc3Vlcy4gIFdpdGgg cmVzcGVjdCB0byB3aGV0aGVyIFRMUyBpcyB1c2VkIHRvIHF1ZXJ5IHRoZSDigJx3ZWJmaW5nZXLi gJ0gcmVzb3VyY2Ugb3Igbm90LCBJIHVuZGVyc3RhbmQgdGhlcmUgYXJlIHBlb3BsZSBhcmd1aW5n IGJvdGggc2lkZXMuICBJ4oCZbSBwZXJzb25hbGx5IG5ldXRyYWwgb24gdGhhdC4NCg0KV2hlcmUg dGhlIGRpc2N1c3Npb24gd2FzIGdvaW5nIGhlcmUgd2FzIHJlbGF0ZWQgdG8g4oCcd2hlcmUgZG8g bGluayByZWxhdGlvbnMgaW4gdGhlIHdlYmZpbmdlciByZXNwb25zZSBwb2ludD/igJ0gIFRoZXJl IGlzIGFuIGFyZ3VtZW50IHRoYXQgd2UgbXVzdCBhbHNvIHJlcXVpcmUgdGhhdCBUTFMgYmUgdXNl ZCBmb3IgYWxsIGxpbmsgcmVsYXRpb25zLiAgSSBkaXNhZ3JlZSB3aXRoIHRoYXQgYXMgYSByZXF1 aXJlbWVudCBzaW5jZSB3ZeKAmXJlIG5vdyB0YWxraW5nIGFib3V0IHdoZXJlIGEgdXNlciBzdG9y ZXMgaGlzIGRhdGEgKGUuZy4sIGFuIGF2YXRhcikuICBJZiBoZSBjaG9vc2VzIHRvIHN0b3JlIHRo YXQgaW4gRmxpY2tyIG9yIGFueSAkMS9tbyBob3N0aW5nIHByb3ZpZGVyIHNob3VsZCBub3QgbWF0 dGVyLiAgRnVydGhlciwgYW55IGNsaWVudCBwcm9jZXNzaW5nIHRoZSBXRiByZXNwb25zZSBjb3Vs ZCBzZWUgdGhhdCBpdCBpcyBhbiDigJxodHRwOuKAnSBVUkkgYW5kIGRlY2lkZSBvbiBhIGNhc2Ut YnktY2FzZSBiYXNpcyBob3cgdG8gdHJlYXQgZWFjaCBsaW5rIHJlbGF0aW9uIHNlZW4uDQoNClBh dWwNCg0KRnJvbTogVGltIEJyYXkgW21haWx0bzp0d2JyYXlAZ29vZ2xlLmNvbTxtYWlsdG86dHdi cmF5QGdvb2dsZS5jb20+XQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDQsIDIwMTIgMjoyNyBB TQ0KVG86IFBhdWwgRS4gSm9uZXMNCkNjOiBKYW1lcyBNIFNuZWxsOyB3ZWJmaW5nZXJAZ29vZ2xl Z3JvdXBzLmNvbTxtYWlsdG86d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb20+OyBNaWtlIEpvbmVz OyBQZXRlciBTYWludC1BbmRyZQ0KDQpTdWJqZWN0OiBSZTogV2ViRmluZ2VyIDggSW5wdXQuLi4N Cg0KUGF1bCwgeW91IGNhbiBzYXkgdGhpcyBhbGwgeW91IHdhbnQsIGJ1dCB0aGVyZSBhcmUgY29o ZXJlbnQgdm9pY2VzIG9uIG91ciBtYWlsaW5nIGxpc3Qgc2F5aW5nIHRoYXQgdGhleSByZWFsbHkg bmVlZCBzb21ldGhpbmcgd3JpdHRlbiBpbnRvIHRoZSBzcGVjIHRvIGdpdmUgdGhlbSBhc3N1cmFu Y2UgdGhhdCB0aGV5IGNhbiB1c2UgV0YgYW5kIGl04oCZbGwgZWl0aGVyIGdvIHRocm91Z2ggVExT IG9yIGl0IHdvbuKAmXQgaGFwcGVuLiAgVGhlcmUgYXJlIHRocmVlIGNvaGVyZW50IGNvbWUtYmFj a3MgdG8gdGhpczoNCg0KLSBBbHdheXMgSFRUUFMNCi0gU29tZSBzb3J0IG9mIG5vcm1hdGl2ZSBw YXJhbWV0ZXJpemVkIGJlaGF2aW9yDQotIFRob3NlIHBlb3BsZSBzaG91bGRu4oCZdCB1c2UgV2Vi RmluZ2VyLg0KDQpBdCBzb21lIHBvaW50LCBzb21lb25l4oCZcyBnb2luZyB0byBoYXZlIHRvIG1h a2UgYSBjb25zZW5zdXMgY2FsbCBvbiB3aGVyZSB0aGUgY29tbXVuaXR5IHN0YW5kcy4gLVQNCg0K T24gTW9uLCBEZWMgMywgMjAxMiBhdCA5OjU4IFBNLCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFj a2V0aXplci5jb208bWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbT4+IHdyb3RlOg0KSmFtZXMs DQoNCktlZXAgaW4gbWluZCB0aGF0IFdGIGlzIHRvIGFsbG93IHVzZXJzIHRvIHNoYXJlIGFsbCBr aW5kcyBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGVtc2VsdmVzLiAgU2VydmljZXMgdGhhdCBuZWVk IHRvIGJlIHNlY3VyZSB3aWxsIHVzZSBIVFRQUy4gIFRob3NlIHRoYXQgZG8gbm90LCB3b27igJl0 Lg0KDQpJZiBJIHRlbGwgbXkgV0Ygc2VydmljZSB0aGF0IG15IGF2YXRhciBpcyBsb2NhdGVkIGF0 IHNvbWUgaHR0cDovLyBsb2NhdGlvbiwgdGhlbiB0aGF04oCZcyB0aGUgaW5mb3JtYXRpb24gdGhl IFdGIHNlcnZlciBzaG91bGQgcmV0dXJuIGluIHJlc3BvbnNlcy4NCg0KSWYgaW5mb3JtYXRpb24g bmVlZHMgYmV0dGVyIHNlY3VyaXR5LCB0aGVuIHRoZSBVUkwgd291bGQgYmUgSFRUUFMuICBBbnkg SWRQIHdvdWxkIHV0aWxpemUgYW4gaHR0cHM6Ly8gYWRkcmVzcy4NCg0KSW4gYW55IGNhc2UsIHRo ZSBocmVmIHZhbHVlIGluIFdGIGNhbiBiZSBhbnkgdmFsaWQgVVJJLiAgVXNlIG9yIG5vbi11c2Ug b2YgVExTIGZvciB0aGVzZSBvdGhlciByZXNvdXJjZXMgdG8gd2hpY2ggV0YgcmVmZXJzIGlzIHJl YWxseSBvdXRzaWRlIHRoZSBzY29wZSBvZiBXRi4NCg0KUGF1bA0KDQpGcm9tOiBKYW1lcyBNIFNu ZWxsIFttYWlsdG86amFzbmVsbEBnbWFpbC5jb208bWFpbHRvOmphc25lbGxAZ21haWwuY29tPl0N ClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA0LCAyMDEyIDEyOjQ0IEFNDQpUbzogUGF1bCBFLiBK b25lcw0KQ2M6IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tPG1haWx0bzp3ZWJmaW5nZXJAZ29v Z2xlZ3JvdXBzLmNvbT47IFRpbSBCcmF5OyBNaWtlIEpvbmVzOyBQZXRlciBTYWludC1BbmRyZQ0K U3ViamVjdDogUmU6IFdlYkZpbmdlciA4IElucHV0Li4uDQoNCg0KT24gTW9uLCBEZWMgMywgMjAx MiBhdCA3OjI4IFBNLCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb208bWFpbHRv OnBhdWxlakBwYWNrZXRpemVyLmNvbT4+IHdyb3RlOg0KSmFtZXMsDQoNCldoYXQgYSBXRiByZXNv dXJjZSBwb2ludHMgdG8gc2hvdWxkIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHdoZXRoZXIgV0Yg dXNlcyBIVFRQUyBvciBub3QuICBJZiBJIHB1dCBteSB2Y2FyZCBvdXQgb24gdGhlIEludGVybmV0 IGFjY2Vzc2libGUgb25seSB2aWEgaHR0cCAod2hpY2ggaXMgcHJlc2VudGx5IHRoZSBjYXNlKSwg dGhlbiB0aGF04oCZcyB0aGUgd2F5IGl04oCZcyBhY2Nlc3NlZC4gIChBY3R1YWxseSwgdGhlIEhU VFBTIHZlcnNpb24gd29ya3Mgb24gbXkgZG9tYWluLCBidXQgd2lsbCByZWRpcmVjdCB0aGUgY2xp ZW50IHRvIHRoZSBub24tSFRUUFMgdmVyc2lvbi4pDQoNCldlbGwuLi4gZm9yIGEgdHlwaWNhbCBu b24tYXV0aGVudGljYXRlZCByZXF1ZXN0IHRvIGEgV2ViRmluZ2VyIHJlc291cmNlLCB5b3UncmUg Y29ycmVjdC4gVGhlcmUgaXMgYW4gb2J2aW91cyByaXNrLCBob3dldmVyLCBvZiBpbnRyb2R1Y2lu ZyBhIHNlc3Npb24gaGlqYWNraW5nIHZ1bG5lcmFiaWxpdHkgd2hlbiB1c2luZyBhdXRoZW50aWNh dGVkIFdlYkZpbmdlciByZXF1ZXN0cyB3aXRoIGFuIGltcHJvcGVybHkgc2VjdXJlZCBzZXJ2ZXIg aWYgdGhlIEpSRCBwcm92aWRlcyBub24taHR0cHMgbGlua3MgdG8gdGhlIHNhbWUgZG9tYWluLiBJ dCB3b3VsZCBiZSBkYW5nZXJvdXMgZm9yIHVzIHRvIGFzc3VtZSB0aGF0IGFsbCByZWxldmFudCBj b29raWVzIHByb3ZpZGVkIG9uIGEgZ2l2ZW4gZG9tYWluIGhhdmUgYmVlbiBzZWN1cmVkIHByb3Bl cmx5LiBBcyBhIGJlc3QgcHJhY3RpY2UsIGxpbmtzIHByb3ZpZGVkIHRvIHJlc291cmNlcyBsb2Nh dGVkIG9uIHRoZSBzYW1lIGRvbWFpbiBzaG91bGQgc2ltcGx5IGJlIHJlcXVpcmVkIHRvIHVzZSBo dHRwcyBhcyBhIHdheSBvZiBlcnJpbmcgb24gdGhlIHNpZGUgb2YgY2F1dGlvbi4NCg0KDQpEdXJp bmcgYSByZWRpcmVjdCwgdGhlIHJlZGlyZWN0aW9uIGRvZXMgbm90IG5lZWQgdG8gdXNlIHRoZSBz YW1lIHNjaGVtZSBpZiB0aGUgZ3JvdXAgYWdyZWVzIHRvIGFsbG93aW5nIEhUVFAuICBUaGF0IHNh aWQsIEkgZnVsbHkgYWdyZWUgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiA4IHNob3VsZCBzaG93IHVz ZSBvZiBIVFRQUyBqdXN0IGFzIGEgbWVhbnMgb2YgZW5jb3VyYWdlbWVudC4NCg0KDQpJc3N1aW5n IGEgaHR0cHMgc2VjdXJlZCByZXF1ZXN0IHRvIGEgV0YgZW5kcG9pbnQgdGhhdCByZWRpcmVjdHMg dG8gYW4gaW5zZWN1cmUgdGhpcmQgcGFydHkgbG9jYXRpb24gcmF0aGVyIGRlZmVhdHMgdGhlIHB1 cnBvc2Ugb2YgcmVxdWlyaW5nIGh0dHBzIGZvciB0aGUgZmlyc3QgcmVxdWVzdCwgZG9lc24ndCBp dD8NCg0KLSBKYW1lcw0KDQoNClBhdWwNCg0KRnJvbTogSmFtZXMgTSBTbmVsbCBbbWFpbHRvOmph c25lbGxAZ21haWwuY29tPG1haWx0bzpqYXNuZWxsQGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXks IERlY2VtYmVyIDAzLCAyMDEyIDEwOjAxIFBNDQpUbzogUGF1bCBFLiBKb25lcw0KQ2M6IHdlYmZp bmdlckBnb29nbGVncm91cHMuY29tPG1haWx0bzp3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbT47 IFRpbSBCcmF5OyBNaWtlIEpvbmVzOyBQZXRlciBTYWludC1BbmRyZQ0KU3ViamVjdDogUmU6IFdl YkZpbmdlciA4IElucHV0Li4uDQoNClllcCwgYXMgZXhwZWN0ZWQgcmVhbGx5LiBUYWtlIHRoZSB2 YXJpb3VzIGVkaXRzIGZvciB3aGF0IHRoZXkgYXJlIHdvcnRoLiBJdCB3YXMgZWl0aGVyIHRoaXMg b3IgdHJ5IHRvIGdvIHRocm91Z2ggYWxsIHRoZSBtdWx0aXR1ZGUgb2YgdGhyZWFkcyBhbmQgcHJv dmlkZSBpbnB1dCBvbiBlYWNoIGluZGl2aWR1YWwgc3ViamVjdC4uLiB0aGlzIHdhcyBieSBmYXIg dGhlIG1vcmUgZWZmaWNpZW50IG9wdGlvbiBmb3IgbWUuIEknbGwgY29tZSB1cCB3aXRoIGEgc3Vt bWFyeSBvZiB0aGUgY2hhbmdlcyBhIGJpdCBsYXRlciBvbiB0aGlzIGV2ZW5pbmcuIE1vc3QgYXJl IHB1cmVseSBlZGl0b3JpYWwgaW4gbmF0dXJlLCBidXQgdGhlcmUgYXJlIGEgZmV3IGltcG9ydGFu dCB0ZWNobmljYWwgaXRlbXMuLi4NCg0KRm9yIGluc3RhbmNlLCB3aGVuIHNlcnZpbmcgdXAgYSBK UkQgb3ZlciBhbiBIVFRQUyBjb25uZWN0aW9uLCBhbmQgdGhhdCBKUkQgY29udGFpbnMgbGluayBy ZWxhdGlvbnMgdG8gcmVzb3VyY2VzIGhvc3RlZCBhdCB0aGUgc2FtZSBkb21haW4gYXMgdGhlIFdl YkZpbmdlciBzZXJ2aWNlLCB0aGVyZSBpcyBhIHJpc2sgb2YgYSBUTFMtZG93bmdyYWRlIGF0dGFj ayBpZiB0aG9zZSBsaW5rIHJlbGF0aW9ucyBhcmUgbm90IGh0dHBzIHVybHMuLi4gZS5nLiBpbiB0 aGUgZXhhbXBsZXMgd2Ugc2VlIHRoaW5ncyBsaWtlICJocmVmIjogImh0dHA6Ly9leGFtcGxlLmNv bS9mb28iIC4uLiB3aGVuIGl0IHJlYWxseSBvdWdodCB0byBiZSAiaHJlZiI6ICJodHRwczovL2V4 YW1wbGUuY29tL2ZvbyIgLi4uDQoNClNpbWlsYXJseSwgaWYgd2UgYXJlIGdvaW5nIHRvIGFsbG93 IHRoZSB1c2Ugb2YgM3h4IHJlZGlyZWN0cywgdGhlbiB0aGUgV2ViRmluZ2VyIHNlcnZlciBuZWVk cyB0byBtYWtlIHN1cmUgdGhhdCB0aGUgbmV3IHRhcmdldCBVUkwgaXMgdXNpbmcgdGhlIGh0dHBz IHNjaGVtZTsgaS5lLiBpbnN0ZWFkIG9mICJMb2NhdGlvbjogaHR0cDovL2V4YW1wbGUubmV0L3dl YmZpbmdlcj8uLi4iIGl0IG5lZWRzIHRvIGJlICJMb2NhdGlvbjogaHR0cHM6Ly9leGFtcGxlLm5l dC93ZWJmaW5nZXI/Li4uIg0KDQpUaGVyZSBhcmUgYSBmZXcgb3RoZXIgYml0cyBzY2F0dGVyZWQg YXJvdW5kLiBPbmNlIHRoZSBraWRzIGFyZSBiYXRoZWQgYW5kIG9mZiB0byBiZWQgSSdsbCB3cml0 ZSB1cCBhIHN1bW1hcnkuDQoNCkhvbmVzdGx5LCBvdGhlciB0aGFuIHRoZSBuZWVkIHRvIGNvbnRy b2wgdGhlIGZsb29kIG9mIGRpc2N1c3Npb25zIGhhcHBlbmluZyBvbiB0aGUgbWFpbGluZyBsaXN0 LCBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHRvIHJ1c2ggdGhpcyB0byBjb21wbGV0aW9uLiBMZXQn cyBnZXQgYSByZWxhdGl2ZWx5IHN0YWJsZSBkcmFmdCBvdXQgdGhlcmUgYW5kIGp1c3QgbGV0IGl0 IHNpdCBmb3IgYSB3aGlsZSBzbyBpbXBsZW1lbnRvcnMgY2FuIGdldCBtb3JlIGV4cGVyaWVuY2Ug d2l0aCBpdC4NCg0KLSBKYW1lcw0KDQpPbiBNb24sIERlYyAzLCAyMDEyIGF0IDY6NDUgUE0sIFBh dWwgRS4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6 ZXIuY29tPj4gd3JvdGU6DQpKYW1lcywNCg0KV293LCB0aGF04oCZcyBhIGxvdCBvZiBjaGFuZ2Vz LiAgSeKAmWQgcGVyc29uYWxseSBsaWtlIHRvIGtlZXAgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24g dGhlIHdheSBpdCBpcy4gIFRoZSB3b3JkIOKAnGxpbmsgcmVsYXRpb27igJ0gaXMgY29uZnVzaW5n IHRvIHBlb3BsZSB3aG8gaGF2ZSBub3QgaGVhcmQgaXQsIGFuZCBoYXZpbmcgdGhhdCB2ZXJ5IGJy aWVmIHN0YXRlbWVudCBpcyB1c2VmdWwsIEkgdGhpbmsuDQoNCk1lcmdpbmcgdGhlIOKAnEludHJv ZHVjdGlvbuKAnSBhbmQg4oCcT3ZlcnZpZXfigJ0gc2VjdGlvbnMgbWlnaHQgYmUgYSBnb29kIGlk ZWEsIGJ1dCBJIHJlY2FsbCBzb21lIHRpbWUgYWdvIHRoZXJlIHdhcyBvbmUgc2VjdGlvbiBhbmQg aXQgd2FzIHN1Z2dlc3RlZCB3ZSBzcGxpdCBpdCBhcGFydC4gIFdoYXQgd2Ugd291bGQgcHV0IGlu IGVhY2gsIEnigJltIG5vdCBzdXJlLiAgSXTigJlzIGRlZmluaXRlbHkgYSBiaXQgb3ZlcmxhcHBp bmcgYXQgdGhlIG1vbWVudC4gIEnigJltIE9LIHdpdGggbWVyZ2luZyB0aG9zZSBzZWN0aW9ucy4N Cg0KSSByZWFsbHksIHJlYWxseSBwcmVmZXIgdG8ga2VlcCB0aGUgZXhhbXBsZXMgaW4gdGhlIG1h aW4gYm9keS4gIFRoZXnigJlyZSBtYXJrZWQgYXMgbm9uLW5vcm1hdGl2ZSwgYnV0IGJlaW5nIGFi bGUgdG8gcmVhZCB0aG9zZSBiZWZvcmUgZ2V0dGluZyBmdXJ0aGVyIGluIHRoZSBkb2N1bWVudCBp cyB2ZXJ5IGhlbHBmdWwgdG8gdGhlIHJlYWRlciB0aGUgZmlyc3QgdGltZSB0aGV5IHJlYWQgdGhl IHRleHQuICBIZWNrLCBldmVuIGlmIHRoZXnigJl2ZSByZWFkIGl0LCBpdOKAmXMgbmljZSB0byBz ZWUgZXhhbXBsZXMgcmlnaHQgdXAgZnJvbnQuICBPdGhlcndpc2UsIHRoZSByZWFkZXLigJlzIGhl YWRlZCBpcyBjbG91ZHkgYWxsIHRoZSB3YXkgdGhyb3VnaCB0aGUgdGV4dC4NCg0KVGhlIGhlYWRl ciBmb3IgU2VjdGlvbiAyICjigJxUZXJtaW5vbG9neeKAnSkgYXBwZWFycyB0byBoYXZlIGJlZW4g cmVtb3ZlZCBhY2NpZGVudGFsbHkuDQoNCkluIHNlY3Rpb24gOCwgdGhlcmUgYXJlIGJ1bGxldCBw b2ludHMgZm9yIHRoZSBJQU5BIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBtYXRlcmlhbC4gIFRob3Nl IHNob3VsZCBub3QgYmUgdGhlcmUuDQoNCkRvbuKAmXQgdXNlIOKAnFVSSeKAnSBiZWZvcmUgdGhl IGluc3RhbnQgbWVzc2FnaW5nIGFkZHJlc3MgaW4gdGhlIGNvbnRhY3QgYXJlYS4gIEVtYWlsIGFk ZHJlc3NlcyBhcmUgYWxzbyBVUklzIDotKSAgSSB3YW50ZWQgSU0gdGhlcmUuDQoNCkJleW9uZCB0 aGF0LCB0aGUgY2hhbmdlcyBhcmUgc28gc3Vic3RhbnRpYWwgdGhhdCBJ4oCZbGwgbmVlZCB0aW1l IHRvIHNlZSBleGFjdGx5IHdoYXQgdGhleSBhcmUuICBJIHRyaWVkIHRvIHByb2R1Y2UgYSBtZWFu aW5nZnVsIGRpZmYsIGJ1dCBzaW5jZSB0aGUgd2hvbGUgZXhhbXBsZSBzZWN0aW9uIHdhcyBtb3Zl ZCwgZGlmZiBwcm9ncmFtcyBnZXRzIHRvdGFsbHkgY29uZnVzZWQuDQoNClBhdWwNCg0KRnJvbTog SmFtZXMgTSBTbmVsbCBbbWFpbHRvOmphc25lbGxAZ21haWwuY29tPG1haWx0bzpqYXNuZWxsQGdt YWlsLmNvbT5dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEyIDg6MzggUE0NClRvOiB3 ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTxtYWlsdG86d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5j b20+OyBQYXVsIEpvbmVzOyBUaW0gQnJheQ0KU3ViamVjdDogV2ViRmluZ2VyIDggSW5wdXQuLi4N Cg0KR2l2ZW4gdGhhdCB0aGUgcmVjZW50IFdlYkZpbmdlciBkaXNjdXNzaW9uIGhhcyBiZWVuIGZs b29kaW5nIGFuZCBvdmVyd2hlbG1pbmcgdGhlIElFVEYgYXBwc2F3ZyBtYWlsaW5nIGxpc3QgSSBo YXZlIGxlZnQgdGhhdCBtYWlsaW5nIGxpc3Qgb2ZmIHRoZSBjYyBsaXN0IHVudGlsIHRoZSBuZXcg V0Ygc3BlY2lmaWMgbWFpbGluZyBsaXN0IGhhcyBiZWVuIHNldCB1cC4gV2hpbGUgcmVhZGluZyB0 aHJvdWdoIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgc3BlYywgSSBzdGFydGVkIHRvIGNvbGxl Y3QgYSBsaXN0IG9mIHNwZWNpZmljIGVkaXRzIHRoYXQgSSB0aG91Z2h0IG5lZWRlZCB0byBiZSBt YWRlLiBUaGUgbGlzdCBiZWNhbWUgcmF0aGVyIGRldGFpbGVkIHNvIGl0IGVuZGVkIHVwIGp1c3Qg YmVpbmcgZWFzaWVyIHRvIGRyYWZ0IHVwIGEgcHJvcG9zZWQgbmV3IHZlcnNpb24uDQoNCkkgaGF2 ZSBjaGVja2VkIGl0IGluIHRvIG15IHBlcnNvbmFsIGdpdGh1YiByZXBvIGhlcmUuLi4NCg0KICBo dHRwOi8vZ29vLmdsL0lhUW5tDQoNClRoZSByYXcgeG1sIGlzIGhlcmUuLi4NCg0KICBodHRwOi8v Z29vLmdsL1FjTkNyDQoNCkFzIGFsd2F5cywgZmVlZGJhY2sgaXMgZGVmaW5pdGVseSB3ZWxjb21l Lg0KDQotIEphbWVzDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlh bCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRh Y2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0K DQpbY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlz cGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNl c3NhcmlvLg0KDQo= --_000_B3651EE16E344DFBB0D9864F7B62B1D8telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkFncmVlZCB0aGF0IGh0dHBzLW9ubHkgbGluayByZWxzIChldmVuIG9uIGh0dHBzIHdmKSBp cyB0b28gcmVzdHJpY3RpdmUuIEkgbWF5IGhhdmUgbWFueSBwdWJsaWMgaW5mbyBvdXQgdGhlcmUg dGhhdCBkbyBub3QgcmVxdWlyZSBodHRwcyAobXkgYXZhdGFyIGF0IGZpcnN0KS4gUGx1cyB0aGVy ZSBhcmUgbWFueSBhcmd1bWVudHMgZm9yIGFueSBVcmlzOiBkYXRhOiBpcyBhIGdvb2QgZXhhbXBs ZSBmb3IgbXkgYXZhdGFyIGFuZCBhdXRvIGNvbmZpZ3VyYXRpb24NCiBzY2VuYXJpb3MgbWF5IGlu dm9sdmUgb3RoZXIgc2NoZW1lcyBtYXliZSByZWxhdGVkIHRvIHRoZSBzY2hlbWUgcmVxdWVzdGVk IGluIHRoZSByZXNvdXJjZSBwYXJhbSwgYnV0IG5vdCBvbmx5LjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UmUgaHR0cHMgdnMgaHR0cCBhcyBJIG1lbnRpb25lZCBlYXJsaWVyIGluIG1h bnkgY2FzZXMgaW4gbW9iaWxlIG5ldHdvcmtzIHRoZSB1c2VyIGlkZW50aXR5IGNhbiBiZSBpZGVu dGlmaWVkIGJ5IHRoZSBuZXR3b3JrIG9ubHkgb3ZlciBodHRwLiBUaGlzIGRvZXNuJ3QgcHJldmVu dCBodHRwcyByZXF1ZXN0cyBidXQgdHlwaWNhbGx5IHJlcXVpcmUgYW4gaW5pdGlhbCBwbGFpbiBo dHRwIHJlcXVlc3QsIHRvIGNyZWF0ZSBzb21lIHNlc3Npb24vY29va2llDQogb24gdGhlIHNlcnZl ciBzaWRlIGFuZCB0aGVuIHJlaXNzdWUgdGhlIHNhbWUgb3ZlciBodHRwcy4gU29tZXRpbWVzIHNl bnNpYmxlIGluZm8gaXMgbm90IHBhc3NlZCBpbiB0aGUgZmlyc3QgcXVlcnkvYW5zd2VyLiBVbHRp bWF0ZWx5IHRoZSBnb2FsIGlzIGh0dHBzIGluIHRoZXNlIGNhc2VzIGFzIHdlbGwgYnV0IHRoZSBz cGVjIHNob3VsZG4ndCBzYXkgdGhhdCBodHRwcyBtdXN0IGJlIGZpcnN0LjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPGJyPg0KTGUgNSBkw6ljLiAyMDEyIMOgIDA1OjMzLCAm cXVvdDtKb2huIFBhbnplciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpwYW56ZXJAZ29vZ2xl LmNvbSI+anBhbnplckBnb29nbGUuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8cCBkaXI9Imx0ciI+ Tm90IG9ydGhvZ29uYWwsIGFzIGRhdGE6IHVyaXMgY2FuJ3QgaW50cm9kdWNlIGEgaGlqYWNraW5n IHZ1bG5lcmFiaWxpdHkgYW5kIHRoZXkgYXJlIHVzZWZ1bCBmb3IgdGhhdCByZWFzb24gKHBsdXMg bGF0ZW5jeSkuJm5ic3A7IFNvIHdlYiBmaW5nZXIgd291bGQgYmUgb3ZlciByZXN0cmljdGl2ZSBp ZiBpdCB3ZXJlIHRvIHNwZWNpZnkgaHR0cHMgb25seSBmb3IgZXhhbXBsZS48L3A+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gRGVjIDQsIDIwMTIgODoyOCBQTSwgJnF1b3Q7SmFtZXMgTSBT bmVsbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc25lbGxAZ21haWwuY29tIj5qYXNuZWxs QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxwIGRpcj0ibHRyIj5BbGwg Z29vZCBidXQgZW50aXJlbHkgb3J0aG9nb25hbCB0byB0aGUgaXNzdWUgSSByYWlzZWQuIFRoaXMg aGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB3aGF0IHNjaGVtZXMgYXJlIGFsbG93ZWQgaW4gZ2VuZXJh bCBhbmQgZXZlcnl0aGluZyB0byBkbyB3aXRoIGEgcG9zc2libGUgc2Vzc2lvbiBoaWphY2sgdnVs bmVyYWJpbGl0eS4NCjwvcD4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBEZWMgNCwgMjAx MiA4OjI1IFBNLCAmcXVvdDtKb2huIFBhbnplciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpw YW56ZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpwYW56ZXJAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxwIGRpcj0ibHRyIj4mIzQzOzEuJm5ic3A7IFdlbGws IGdvcGhlciBpcyBiZXlvbmQgdGhlIHBhbGUgb2YgY291cnNlLjwvcD4NCjxwIGRpcj0ibHRyIj5k YXRhOiB3b3VsZCBiZSBwYXJ0aWN1bGFybHkgdXNlZnVsLjwvcD4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBEZWMgNCwgMjAxMiA4OjA1IFBNLCAmcXVvdDtCcmFkIEZpdHpwYXRyaWNrJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJhZGZpdHpAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJyYWRmaXR6QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRp b24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 MTBwdCI+SSBhZ3JlZSB0aGF0IHRoZSB3ZWJmaW5nZXIgcmVzcG9uc2UncyBsaW5rcyBzaG91bGQg YmUgYWxsb3dlZCB0byBiZSBhbnkgcHJvdG9jb2wsIGJlIGl0IGh0dHBzOi8vLCBodHRwOi8vLCBv ciBnb3BoZXI6Ly8uDQo8ZGl2Pg0KPGRpdj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gVHVlLCBEZWMgNCwgMjAxMiBhdCA1OjUxIFBNLCBQYXVsIEUuIEpvbmVzIDxzcGFuIGRpcj0i bHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tIiB0YXJnZXQ9 Il9ibGFuayI+cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlRpbSw8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxZjQ5N2QiPlBlcmhhcHMgd2XigJlyZSBkaXNjdXNzaW5nIGRpZmZlcmVudCBpc3N1 ZXMuJm5ic3A7IFdpdGggcmVzcGVjdCB0byB3aGV0aGVyIFRMUyBpcyB1c2VkIHRvIHF1ZXJ5IHRo ZSDigJx3ZWJmaW5nZXLigJ0gcmVzb3VyY2Ugb3Igbm90LCBJIHVuZGVyc3RhbmQgdGhlcmUgYXJl IHBlb3BsZSBhcmd1aW5nDQogYm90aCBzaWRlcy4mbmJzcDsgSeKAmW0gcGVyc29uYWxseSBuZXV0 cmFsIG9uIHRoYXQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5XaGVyZSB0aGUgZGlzY3Vzc2lvbiB3YXMgZ29p bmcgaGVyZSB3YXMgcmVsYXRlZCB0byDigJx3aGVyZSBkbyBsaW5rIHJlbGF0aW9ucyBpbiB0aGUg d2ViZmluZ2VyIHJlc3BvbnNlIHBvaW50P+KAnSZuYnNwOyBUaGVyZSBpcyBhbiBhcmd1bWVudCB0 aGF0IHdlIG11c3QgYWxzbyByZXF1aXJlDQogdGhhdCBUTFMgYmUgdXNlZCBmb3IgYWxsIGxpbmsg cmVsYXRpb25zLiZuYnNwOyBJIGRpc2FncmVlIHdpdGggdGhhdCBhcyBhIHJlcXVpcmVtZW50IHNp bmNlIHdl4oCZcmUgbm93IHRhbGtpbmcgYWJvdXQgd2hlcmUgYSB1c2VyIHN0b3JlcyBoaXMgZGF0 YSAoZS5nLiwgYW4gYXZhdGFyKS4mbmJzcDsgSWYgaGUgY2hvb3NlcyB0byBzdG9yZSB0aGF0IGlu IEZsaWNrciBvciBhbnkgJDEvbW8gaG9zdGluZyBwcm92aWRlciBzaG91bGQgbm90IG1hdHRlci4m bmJzcDsgRnVydGhlciwNCiBhbnkgY2xpZW50IHByb2Nlc3NpbmcgdGhlIFdGIHJlc3BvbnNlIGNv dWxkIHNlZSB0aGF0IGl0IGlzIGFuIOKAnGh0dHA64oCdIFVSSSBhbmQgZGVjaWRlIG9uIGEgY2Fz ZS1ieS1jYXNlIGJhc2lzIGhvdyB0byB0cmVhdCBlYWNoIGxpbmsgcmVsYXRpb24gc2Vlbi48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxZjQ5N2QiPlBhdWw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gVGltIEJyYXkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHdicmF5QGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj50d2JyYXlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMDQsIDIwMTIgMjoyNyBBTTxicj4NCjxiPlRvOjwv Yj4gUGF1bCBFLiBKb25lczxicj4NCjxiPkNjOjwvYj4gSmFtZXMgTSBTbmVsbDsgPGEgaHJlZj0i bWFpbHRvOndlYmZpbmdlckBnb29nbGVncm91cHMuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp3ZWJm aW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTwvYT47IE1pa2UgSm9uZXM7IFBldGVyIFNhaW50LUFuZHJl PC9zcGFuPjwvcD4NCjxkaXY+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBXZWJGaW5nZXIgOCBJ bnB1dC4uLjx1PjwvdT48dT48L3U+PC9kaXY+DQo8cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGF1bCwgeW91IGNhbiBz YXkgdGhpcyBhbGwgeW91IHdhbnQsIGJ1dCB0aGVyZSBhcmUgY29oZXJlbnQgdm9pY2VzIG9uIG91 ciBtYWlsaW5nIGxpc3Qgc2F5aW5nIHRoYXQgdGhleSByZWFsbHkgbmVlZCBzb21ldGhpbmcgd3Jp dHRlbiBpbnRvIHRoZSBzcGVjIHRvIGdpdmUgdGhlbSBhc3N1cmFuY2UgdGhhdA0KIHRoZXkgY2Fu IHVzZSBXRiBhbmQgaXTigJlsbCBlaXRoZXIgZ28gdGhyb3VnaCBUTFMgb3IgaXQgd29u4oCZdCBo YXBwZW4uICZuYnNwO1RoZXJlIGFyZSB0aHJlZSBjb2hlcmVudCBjb21lLWJhY2tzIHRvIHRoaXM6 PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPi0gQWx3YXlzIEhUVFBTPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBT b21lIHNvcnQgb2Ygbm9ybWF0aXZlIHBhcmFtZXRlcml6ZWQgYmVoYXZpb3I8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFRob3NlIHBlb3BsZSBzaG91bGRu4oCZdCB1c2UgV2ViRmlu Z2VyLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkF0IHNvbWUgcG9pbnQsIHNvbWVvbmXigJlzIGdvaW5nIHRvIGhh dmUgdG8gbWFrZSBhIGNvbnNlbnN1cyBjYWxsIG9uIHdoZXJlIHRoZSBjb21tdW5pdHkgc3RhbmRz LiAtVDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5PbiBNb24sIERlYyAzLCAyMDEyIGF0IDk6NTggUE0sIFBhdWwgRS4g Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iIHRhcmdldD0i X2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5KYW1lcyw8L3NwYW4+PHU+PC91Pjx1 PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2Qi PktlZXAgaW4gbWluZCB0aGF0IFdGIGlzIHRvIGFsbG93IHVzZXJzIHRvIHNoYXJlIGFsbCBraW5k cyBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGVtc2VsdmVzLiZuYnNwOyBTZXJ2aWNlcyB0aGF0IG5l ZWQgdG8gYmUgc2VjdXJlIHdpbGwgdXNlIEhUVFBTLiZuYnNwOyBUaG9zZSB0aGF0IGRvIG5vdCwN CiB3b27igJl0Ljwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+ PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SWYgSSB0ZWxsIG15IFdGIHNlcnZpY2UgdGhhdCBt eSBhdmF0YXIgaXMgbG9jYXRlZCBhdCBzb21lIGh0dHA6Ly8gbG9jYXRpb24sIHRoZW4gdGhhdOKA mXMgdGhlIGluZm9ybWF0aW9uIHRoZSBXRiBzZXJ2ZXIgc2hvdWxkIHJldHVybiBpbiByZXNwb25z ZXMuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+ PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMWY0OTdkIj5JZiBpbmZvcm1hdGlvbiBuZWVkcyBiZXR0ZXIgc2VjdXJpdHks IHRoZW4gdGhlIFVSTCB3b3VsZCBiZSBIVFRQUy4mbmJzcDsgQW55IElkUCB3b3VsZCB1dGlsaXpl IGFuIGh0dHBzOi8vIGFkZHJlc3MuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZu YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5JbiBhbnkgY2FzZSwgdGhlIGhy ZWYgdmFsdWUgaW4gV0YgY2FuIGJlIGFueSB2YWxpZCBVUkkuICZuYnNwO1VzZSBvciBub24tdXNl IG9mIFRMUyBmb3IgdGhlc2Ugb3RoZXIgcmVzb3VyY2VzIHRvIHdoaWNoIFdGIHJlZmVycyBpcyBy ZWFsbHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgV0YuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx ZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5QYXVsPC9zcGFu Pjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91Pjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbWVzIE0gU25l bGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5qYXNuZWxsQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgMDQsIDIwMTIgMTI6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFBhdWwgRS4gSm9uZXM8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPndlYmZpbmdlckBnb29nbGVncm91cHMuY29tPC9hPjsgVGltIEJy YXk7IE1pa2UgSm9uZXM7IFBldGVyIFNhaW50LUFuZHJlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBXZWJGaW5nZXIgOCBJbnB1dC4uLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyAzLCAyMDEyIGF0IDc6MjggUE0sIFBh dWwgRS4gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iIHRh cmdldD0iX2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+ PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkphbWVzLDwvc3Bhbj48dT48L3U+PHU+ PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+ V2hhdCBhIFdGIHJlc291cmNlIHBvaW50cyB0byBzaG91bGQgaGF2ZSBub3RoaW5nIHRvIGRvIHdp dGggd2hldGhlciBXRiB1c2VzIEhUVFBTIG9yIG5vdC4mbmJzcDsgSWYgSSBwdXQgbXkgdmNhcmQg b3V0IG9uIHRoZSBJbnRlcm5ldCBhY2Nlc3NpYmxlIG9ubHkgdmlhIGh0dHAgKHdoaWNoDQogaXMg cHJlc2VudGx5IHRoZSBjYXNlKSwgdGhlbiB0aGF04oCZcyB0aGUgd2F5IGl04oCZcyBhY2Nlc3Nl ZC4mbmJzcDsgKEFjdHVhbGx5LCB0aGUgSFRUUFMgdmVyc2lvbiB3b3JrcyBvbiBteSBkb21haW4s IGJ1dCB3aWxsIHJlZGlyZWN0IHRoZSBjbGllbnQgdG8gdGhlIG5vbi1IVFRQUyB2ZXJzaW9uLik8 L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2VsbC4uLiBmb3IgYSB0eXBpY2FsIG5vbi1hdXRoZW50aWNhdGVk IHJlcXVlc3QgdG8gYSBXZWJGaW5nZXIgcmVzb3VyY2UsIHlvdSdyZSBjb3JyZWN0LiBUaGVyZSBp cyBhbiBvYnZpb3VzIHJpc2ssIGhvd2V2ZXIsIG9mIGludHJvZHVjaW5nIGEgc2Vzc2lvbiBoaWph Y2tpbmcgdnVsbmVyYWJpbGl0eSB3aGVuIHVzaW5nIGF1dGhlbnRpY2F0ZWQgV2ViRmluZ2VyIHJl cXVlc3RzIHdpdGggYW4gaW1wcm9wZXJseQ0KIHNlY3VyZWQgc2VydmVyIGlmIHRoZSBKUkQgcHJv dmlkZXMgbm9uLWh0dHBzIGxpbmtzIHRvIHRoZSBzYW1lIGRvbWFpbi4gSXQgd291bGQgYmUgZGFu Z2Vyb3VzIGZvciB1cyB0byBhc3N1bWUgdGhhdCBhbGwgcmVsZXZhbnQgY29va2llcyBwcm92aWRl ZCBvbiBhIGdpdmVuIGRvbWFpbiBoYXZlIGJlZW4gc2VjdXJlZCBwcm9wZXJseS4gQXMgYSBiZXN0 IHByYWN0aWNlLCBsaW5rcyBwcm92aWRlZCB0byByZXNvdXJjZXMgbG9jYXRlZCBvbiB0aGUgc2Ft ZQ0KIGRvbWFpbiBzaG91bGQgc2ltcGx5IGJlIHJlcXVpcmVkIHRvIHVzZSBodHRwcyBhcyBhIHdh eSBvZiBlcnJpbmcgb24gdGhlIHNpZGUgb2YgY2F1dGlvbi4mbmJzcDs8dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48 L3U+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI2NjY2NjYyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMWY0OTdkIj5EdXJpbmcgYSByZWRpcmVjdCwgdGhlIHJlZGlyZWN0aW9uIGRvZXMgbm90 IG5lZWQgdG8gdXNlIHRoZSBzYW1lIHNjaGVtZSBpZiB0aGUgZ3JvdXAgYWdyZWVzIHRvIGFsbG93 aW5nIEhUVFAuJm5ic3A7IFRoYXQgc2FpZCwgSSBmdWxseSBhZ3JlZSB0aGUgZXhhbXBsZSBpbiBz ZWN0aW9uDQogOCBzaG91bGQgc2hvdyB1c2Ugb2YgSFRUUFMganVzdCBhcyBhIG1lYW5zIG9mIGVu Y291cmFnZW1lbnQuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bh bj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Jc3N1aW5nIGEgaHR0cHMgc2VjdXJlZCByZXF1 ZXN0IHRvIGEgV0YgZW5kcG9pbnQgdGhhdCByZWRpcmVjdHMgdG8gYW4gaW5zZWN1cmUgdGhpcmQg cGFydHkgbG9jYXRpb24gcmF0aGVyIGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2YgcmVxdWlyaW5nIGh0 dHBzIGZvciB0aGUgZmlyc3QgcmVxdWVzdCwgZG9lc24ndCBpdD88dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBKYW1lczx1PjwvdT48 dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+ PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNjY2NjY2MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5QYXVsPC9zcGFuPjx1 PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbWVzIE0gU25lbGwg W21haWx0bzo8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5qYXNuZWxsQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNl bWJlciAwMywgMjAxMiAxMDowMSBQTTxicj4NCjxiPlRvOjwvYj4gUGF1bCBFLiBKb25lczxicj4N CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlckBnb29nbGVncm91cHMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb208L2E+OyBUaW0gQnJheTsg TWlrZSBKb25lczsgUGV0ZXIgU2FpbnQtQW5kcmU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFdl YkZpbmdlciA4IElucHV0Li4uPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlllcCwgYXMgZXhwZWN0ZWQgcmVhbGx5LiBUYWtlIHRoZSB2 YXJpb3VzIGVkaXRzIGZvciB3aGF0IHRoZXkgYXJlIHdvcnRoLiBJdCB3YXMgZWl0aGVyIHRoaXMg b3IgdHJ5IHRvIGdvIHRocm91Z2ggYWxsIHRoZSBtdWx0aXR1ZGUgb2YgdGhyZWFkcyBhbmQgcHJv dmlkZSBpbnB1dCBvbiBlYWNoIGluZGl2aWR1YWwgc3ViamVjdC4uLiB0aGlzIHdhcw0KIGJ5IGZh ciB0aGUgbW9yZSBlZmZpY2llbnQgb3B0aW9uIGZvciBtZS4gSSdsbCBjb21lIHVwIHdpdGggYSBz dW1tYXJ5IG9mIHRoZSBjaGFuZ2VzIGEgYml0IGxhdGVyIG9uIHRoaXMgZXZlbmluZy4gTW9zdCBh cmUgcHVyZWx5IGVkaXRvcmlhbCBpbiBuYXR1cmUsIGJ1dCB0aGVyZSBhcmUgYSBmZXcgaW1wb3J0 YW50IHRlY2huaWNhbCBpdGVtcy4uLiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yIGluc3RhbmNlLCB3aGVuIHNlcnZpbmcgdXAgYSBK UkQgb3ZlciBhbiBIVFRQUyBjb25uZWN0aW9uLCBhbmQgdGhhdCBKUkQgY29udGFpbnMgbGluayBy ZWxhdGlvbnMgdG8gcmVzb3VyY2VzIGhvc3RlZCBhdCB0aGUgc2FtZSBkb21haW4gYXMgdGhlIFdl YkZpbmdlciBzZXJ2aWNlLCB0aGVyZSBpcyBhIHJpc2sgb2YgYSBUTFMtZG93bmdyYWRlDQogYXR0 YWNrIGlmIHRob3NlIGxpbmsgcmVsYXRpb25zIGFyZSBub3QgaHR0cHMgdXJscy4uLiBlLmcuIGlu IHRoZSBleGFtcGxlcyB3ZSBzZWUgdGhpbmdzIGxpa2UgJnF1b3Q7aHJlZiZxdW90OzogJnF1b3Q7 PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL2ZvbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9l eGFtcGxlLmNvbS9mb288L2E+JnF1b3Q7IC4uLiB3aGVuIGl0IHJlYWxseSBvdWdodCB0byBiZSAm cXVvdDtocmVmJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL2ZvbyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXhhbXBsZS5jb20vZm9vPC9hPiZxdW90Ow0KIC4uLjwv c3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U2ltaWxh cmx5LCBpZiB3ZSBhcmUgZ29pbmcgdG8gYWxsb3cgdGhlIHVzZSBvZiAzeHggcmVkaXJlY3RzLCB0 aGVuIHRoZSBXZWJGaW5nZXIgc2VydmVyIG5lZWRzIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBuZXcg dGFyZ2V0IFVSTCBpcyB1c2luZyB0aGUgaHR0cHMgc2NoZW1lOyBpLmUuIGluc3RlYWQgb2YgJnF1 b3Q7TG9jYXRpb246DQo8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5uZXQvd2ViZmluZ2VyPy4uIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUubmV0L3dlYmZpbmdlcj8uLjwvYT4uJnF1b3Q7 IGl0IG5lZWRzIHRvIGJlICZxdW90O0xvY2F0aW9uOg0KPGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxl Lm5ldC93ZWJmaW5nZXI/Li4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUubmV0L3dl YmZpbmdlcj8uLjwvYT4uJnF1b3Q7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZXJlIGFyZSBhIGZldyBvdGhlciBiaXRzIHNjYXR0 ZXJlZCBhcm91bmQuIE9uY2UgdGhlIGtpZHMgYXJlIGJhdGhlZCBhbmQgb2ZmIHRvIGJlZCBJJ2xs IHdyaXRlIHVwIGEgc3VtbWFyeS48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG9uZXN0bHksIG90aGVyIHRoYW4gdGhlIG5lZWQgdG8g Y29udHJvbCB0aGUgZmxvb2Qgb2YgZGlzY3Vzc2lvbnMgaGFwcGVuaW5nIG9uIHRoZSBtYWlsaW5n IGxpc3QsIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gdG8gcnVzaCB0aGlzIHRvIGNvbXBsZXRpb24u IExldCdzIGdldCBhIHJlbGF0aXZlbHkgc3RhYmxlIGRyYWZ0IG91dCB0aGVyZSBhbmQNCiBqdXN0 IGxldCBpdCBzaXQgZm9yIGEgd2hpbGUgc28gaW1wbGVtZW50b3JzIGNhbiBnZXQgbW9yZSBleHBl cmllbmNlIHdpdGggaXQuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPi0gSmFtZXM8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgMywgMjAxMiBhdCA2OjQ1IFBNLCBQYXVsIEUuIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5KYW1lcyw8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPldvdywgdGhh dOKAmXMgYSBsb3Qgb2YgY2hhbmdlcy4mbmJzcDsgSeKAmWQgcGVyc29uYWxseSBsaWtlIHRvIGtl ZXAgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gdGhlIHdheSBpdCBpcy4mbmJzcDsgVGhlIHdvcmQg 4oCcbGluayByZWxhdGlvbuKAnSBpcyBjb25mdXNpbmcgdG8gcGVvcGxlIHdobyBoYXZlDQogbm90 IGhlYXJkIGl0LCBhbmQgaGF2aW5nIHRoYXQgdmVyeSBicmllZiBzdGF0ZW1lbnQgaXMgdXNlZnVs LCBJIHRoaW5rLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+ PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+TWVyZ2luZyB0aGUg4oCcSW50cm9kdWN0aW9u4oCd IGFuZCDigJxPdmVydmlld+KAnSBzZWN0aW9ucyBtaWdodCBiZSBhIGdvb2QgaWRlYSwgYnV0IEkg cmVjYWxsIHNvbWUgdGltZSBhZ28gdGhlcmUgd2FzIG9uZSBzZWN0aW9uIGFuZCBpdCB3YXMgc3Vn Z2VzdGVkIHdlIHNwbGl0IGl0IGFwYXJ0LiZuYnNwOw0KIFdoYXQgd2Ugd291bGQgcHV0IGluIGVh Y2gsIEnigJltIG5vdCBzdXJlLiZuYnNwOyBJdOKAmXMgZGVmaW5pdGVseSBhIGJpdCBvdmVybGFw cGluZyBhdCB0aGUgbW9tZW50LiZuYnNwOyBJ4oCZbSBPSyB3aXRoIG1lcmdpbmcgdGhvc2Ugc2Vj dGlvbnMuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48 L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMWY0OTdkIj5JIHJlYWxseSwgcmVhbGx5IHByZWZlciB0byBrZWVwIHRo ZSBleGFtcGxlcyBpbiB0aGUgbWFpbiBib2R5LiAmbmJzcDtUaGV54oCZcmUgbWFya2VkIGFzIG5v bi1ub3JtYXRpdmUsIGJ1dCBiZWluZyBhYmxlIHRvIHJlYWQgdGhvc2UgYmVmb3JlIGdldHRpbmcg ZnVydGhlciBpbiB0aGUNCiBkb2N1bWVudCBpcyB2ZXJ5IGhlbHBmdWwgdG8gdGhlIHJlYWRlciB0 aGUgZmlyc3QgdGltZSB0aGV5IHJlYWQgdGhlIHRleHQuJm5ic3A7IEhlY2ssIGV2ZW4gaWYgdGhl eeKAmXZlIHJlYWQgaXQsIGl04oCZcyBuaWNlIHRvIHNlZSBleGFtcGxlcyByaWdodCB1cCBmcm9u dC4mbmJzcDsgT3RoZXJ3aXNlLCB0aGUgcmVhZGVy4oCZcyBoZWFkZWQgaXMgY2xvdWR5IGFsbCB0 aGUgd2F5IHRocm91Z2ggdGhlIHRleHQuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2Qi PiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5UaGUgaGVhZGVyIGZvciBT ZWN0aW9uIDIgKOKAnFRlcm1pbm9sb2d54oCdKSBhcHBlYXJzIHRvIGhhdmUgYmVlbiByZW1vdmVk IGFjY2lkZW50YWxseS48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9z cGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkluIHNlY3Rpb24gOCwgdGhlcmUgYXJlIGJ1 bGxldCBwb2ludHMgZm9yIHRoZSBJQU5BIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBtYXRlcmlhbC4m bmJzcDsgVGhvc2Ugc2hvdWxkIG5vdCBiZSB0aGVyZS48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkRvbuKAmXQg dXNlIOKAnFVSSeKAnSBiZWZvcmUgdGhlIGluc3RhbnQgbWVzc2FnaW5nIGFkZHJlc3MgaW4gdGhl IGNvbnRhY3QgYXJlYS4mbmJzcDsgRW1haWwgYWRkcmVzc2VzIGFyZSBhbHNvIFVSSXMgOi0pJm5i c3A7IEkgd2FudGVkIElNIHRoZXJlLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4m bmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+QmV5b25kIHRoYXQsIHRoZSBj aGFuZ2VzIGFyZSBzbyBzdWJzdGFudGlhbCB0aGF0IEnigJlsbCBuZWVkIHRpbWUgdG8gc2VlIGV4 YWN0bHkgd2hhdCB0aGV5IGFyZS4mbmJzcDsgSSB0cmllZCB0byBwcm9kdWNlIGEgbWVhbmluZ2Z1 bCBkaWZmLCBidXQgc2luY2UgdGhlIHdob2xlIGV4YW1wbGUNCiBzZWN0aW9uIHdhcyBtb3ZlZCwg ZGlmZiBwcm9ncmFtcyBnZXRzIHRvdGFsbHkgY29uZnVzZWQuPC9zcGFuPjx1PjwvdT48dT48L3U+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5QYXVs PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+ PC91PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbWVz IE0gU25lbGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5qYXNuZWxsQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBEZWNlbWJlciAwMywgMjAxMiA4OjM4IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJt YWlsdG86d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWJmaW5n ZXJAZ29vZ2xlZ3JvdXBzLmNvbTwvYT47IFBhdWwgSm9uZXM7IFRpbSBCcmF5PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFdlYkZpbmdlciA4IElucHV0Li4uPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkdpdmVuIHRoYXQgdGhlIHJlY2VudCBX ZWJGaW5nZXIgZGlzY3Vzc2lvbiBoYXMgYmVlbiBmbG9vZGluZyBhbmQgb3ZlcndoZWxtaW5nIHRo ZSBJRVRGIGFwcHNhd2cgbWFpbGluZyBsaXN0IEkgaGF2ZSBsZWZ0IHRoYXQgbWFpbGluZyBsaXN0 IG9mZiB0aGUgY2MgbGlzdCB1bnRpbCB0aGUgbmV3IFdGIHNwZWNpZmljIG1haWxpbmcgbGlzdCBo YXMNCiBiZWVuIHNldCB1cC4gV2hpbGUgcmVhZGluZyB0aHJvdWdoIHRoZSBsYXRlc3QgdmVyc2lv biBvZiB0aGUgc3BlYywgSSBzdGFydGVkIHRvIGNvbGxlY3QgYSBsaXN0IG9mIHNwZWNpZmljIGVk aXRzIHRoYXQgSSB0aG91Z2h0IG5lZWRlZCB0byBiZSBtYWRlLiBUaGUgbGlzdCBiZWNhbWUgcmF0 aGVyIGRldGFpbGVkIHNvIGl0IGVuZGVkIHVwIGp1c3QgYmVpbmcgZWFzaWVyIHRvIGRyYWZ0IHVw IGEgcHJvcG9zZWQgbmV3IHZlcnNpb24uPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGhhdmUgY2hlY2tlZCBpdCBpbiB0byBteSBwZXJzb25hbCBn aXRodWIgcmVwbyBoZXJlLi4uPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9nb28uZ2wv SWFRbm0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZ29vLmdsL0lhUW5tPC9hPjwvc3Bhbj48dT48 L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw Ozx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgcmF3 IHhtbCBpcyBoZXJlLi4uPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9nb28uZ2wvUWNO Q3IiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZ29vLmdsL1FjTkNyPC9hPjwvc3Bhbj48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1 PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyBhbHdheXMs IGZlZWRiYWNrIGlzIGRlZmluaXRlbHkgd2VsY29tZS48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBKYW1lczwvc3Bhbj48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnNwYW4uR3Jh bUUge21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0tPg0KPC9zdHlsZT4N Cjx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i d2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9udC1zaXplOjEycHg7 IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KPGRpdiBhbGln bj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxs YSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZp ZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJv cmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNh emlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBH cmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5v cm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBlLW1haWwgYW5kIGFu eSBhdHRhY2htZW50czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6DQogIDcuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVy ZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xhc3M9IkdyYW1FIj5p czwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOg0KICA3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVO LUdCIj5jb25maWRlbnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5 aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXINCiBieSByZXR1 cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+PGltZyBzcmM9ImNp ZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyIiBhbHQ9InJp c3BldHRhIGwnYW1iaWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+UmlzcGV0dGEgbCdhbWJp ZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bh bj48L2I+DQo8cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B3651EE16E344DFBB0D9864F7B62B1D8telecomitaliait_-- --_403647b9-28a8-4ad6-8e4a-8e6790e2ca52_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_403647b9-28a8-4ad6-8e4a-8e6790e2ca52_-- From evan@e14n.com Wed Dec 5 01:59:33 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BA821F8602 for ; Wed, 5 Dec 2012 01:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wemhcnqrH21 for ; Wed, 5 Dec 2012 01:59:29 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id C61BD21F85FC for ; Wed, 5 Dec 2012 01:59:28 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 9E4628D424B for ; Wed, 5 Dec 2012 10:11:48 +0000 (UTC) Message-ID: <50BF1AFB.5040809@e14n.com> Date: Wed, 05 Dec 2012 04:59:23 -0500 From: Evan Prodromou Organization: E14N User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070701060709010205060603" Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:59:33 -0000 This is a multi-part message in MIME format. --------------070701060709010205060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This puts a pretty big burden on the server. For many applications, there will be no "session" to get hijacked, and for others, the risk is tolerable. Can we add this to "Security Considerations" as a potential threat, and say that clients SHOULD consider session hijacking when using links returned via Webfinger? -Evan On 12-12-04 08:56 PM, James M Snell wrote: > To be clear, I am NOT saying that all links in the document would need > to use HTTPS. I'm saying that if requests to the Webfinger resource > are authenticated, links to resources in the same domain as the > WebFinger server need to use HTTPS or else we run the risk of a > session hijack. That's a very different statement than "TLS be used > for all link relations". > > In other words, if I send an authenticated request to > https://example.net/.well-known/webfinger?resource=foo, and the JRD > contains a link to an avatar image located on the same server, the > link should be like https://example.net/images/foo-avatar.png. > > - James > > > On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones > wrote: > > Tim, > > Perhaps we're discussing different issues. With respect to > whether TLS is used to query the "webfinger" resource or not, I > understand there are people arguing both sides. I'm personally > neutral on that. > > Where the discussion was going here was related to "where do link > relations in the webfinger response point?" There is an argument > that we must also require that TLS be used for all link relations. > I disagree with that as a requirement since we're now talking > about where a user stores his data (e.g., an avatar). If he > chooses to store that in Flickr or any $1/mo hosting provider > should not matter. Further, any client processing the WF response > could see that it is an "http:" URI and decide on a case-by-case > basis how to treat each link relation seen. > > Paul > > *From:*Tim Bray [mailto:twbray@google.com ] > *Sent:* Tuesday, December 04, 2012 2:27 AM > *To:* Paul E. Jones > *Cc:* James M Snell; webfinger@googlegroups.com > ; Mike Jones; Peter Saint-Andre > > > *Subject:* Re: WebFinger 8 Input... > > Paul, you can say this all you want, but there are coherent voices > on our mailing list saying that they really need something written > into the spec to give them assurance that they can use WF and > it'll either go through TLS or it won't happen. There are three > coherent come-backs to this: > > - Always HTTPS > > - Some sort of normative parameterized behavior > > - Those people shouldn't use WebFinger. > > At some point, someone's going to have to make a consensus call on > where the community stands. -T > > On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones > > wrote: > > James, > > Keep in mind that WF is to allow users to share all kinds of > information about themselves. Services that need to be secure will > use HTTPS. Those that do not, won't. > > If I tell my WF service that my avatar is located at some http:// > location, then that's the information the WF server should return > in responses. > > If information needs better security, then the URL would be > HTTPS. Any IdP would utilize an https:// address. > > In any case, the href value in WF can be any valid URI. Use or > non-use of TLS for these other resources to which WF refers is > really outside the scope of WF. > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Tuesday, December 04, 2012 12:44 AM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com > ; Tim Bray; Mike Jones; Peter > Saint-Andre > *Subject:* Re: WebFinger 8 Input... > > On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones > > wrote: > > James, > > What a WF resource points to should have nothing to do with > whether WF uses HTTPS or not. If I put my vcard out on the > Internet accessible only via http (which is presently the case), > then that's the way it's accessed. (Actually, the HTTPS version > works on my domain, but will redirect the client to the non-HTTPS > version.) > > Well... for a typical non-authenticated request to a WebFinger > resource, you're correct. There is an obvious risk, however, of > introducing a session hijacking vulnerability when using > authenticated WebFinger requests with an improperly secured server > if the JRD provides non-https links to the same domain. It would > be dangerous for us to assume that all relevant cookies provided > on a given domain have been secured properly. As a best practice, > links provided to resources located on the same domain should > simply be required to use https as a way of erring on the side of > caution. > > During a redirect, the redirection does not need to use the > same scheme if the group agrees to allowing HTTP. That said, > I fully agree the example in section 8 should show use of > HTTPS just as a means of encouragement. > > Issuing a https secured request to a WF endpoint that redirects to > an insecure third party location rather defeats the purpose of > requiring https for the first request, doesn't it? > > - James > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Monday, December 03, 2012 10:01 PM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com > ; Tim Bray; Mike Jones; > Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input... > > Yep, as expected really. Take the various edits for what they > are worth. It was either this or try to go through all the > multitude of threads and provide input on each individual > subject... this was by far the more efficient option for me. > I'll come up with a summary of the changes a bit later on this > evening. Most are purely editorial in nature, but there are a > few important technical items... > > For instance, when serving up a JRD over an HTTPS connection, > and that JRD contains link relations to resources hosted at > the same domain as the WebFinger service, there is a risk of a > TLS-downgrade attack if those link relations are not https > urls... e.g. in the examples we see things like "href": > "http://example.com/foo" ... when it really ought to be > "href": "https://example.com/foo" ... > > Similarly, if we are going to allow the use of 3xx redirects, > then the WebFinger server needs to make sure that the new > target URL is using the https scheme; i.e. instead of > "Location: http://example.net/webfinger?..." it needs to be > "Location: https://example.net/webfinger?..." > > There are a few other bits scattered around. Once the kids are > bathed and off to bed I'll write up a summary. > > Honestly, other than the need to control the flood of > discussions happening on the mailing list, I don't see any > reason to rush this to completion. Let's get a relatively > stable draft out there and just let it sit for a while so > implementors can get more experience with it. > > - James > > On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones > > wrote: > > James, > > Wow, that's a lot of changes. I'd personally like to keep the > terminology section the way it is. The word "link relation" is > confusing to people who have not heard it, and having that > very brief statement is useful, I think. > > Merging the "Introduction" and "Overview" sections might be a > good idea, but I recall some time ago there was one section > and it was suggested we split it apart. What we would put in > each, I'm not sure. It's definitely a bit overlapping at the > moment. I'm OK with merging those sections. > > I really, really prefer to keep the examples in the main body. > They're marked as non-normative, but being able to read those > before getting further in the document is very helpful to the > reader the first time they read the text. Heck, even if > they've read it, it's nice to see examples right up front. > Otherwise, the reader's headed is cloudy all the way through > the text. > > The header for Section 2 ("Terminology") appears to have been > removed accidentally. > > In section 8, there are bullet points for the IANA > registration template material. Those should not be there. > > Don't use "URI" before the instant messaging address in the > contact area. Email addresses are also URIs :-) I wanted IM there. > > Beyond that, the changes are so substantial that I'll need > time to see exactly what they are. I tried to produce a > meaningful diff, but since the whole example section was > moved, diff programs gets totally confused. > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Monday, December 03, 2012 8:38 PM > *To:* webfinger@googlegroups.com > ; Paul Jones; Tim Bray > *Subject:* WebFinger 8 Input... > > Given that the recent WebFinger discussion has been flooding > and overwhelming the IETF appsawg mailing list I have left > that mailing list off the cc list until the new WF specific > mailing list has been set up. While reading through the latest > version of the spec, I started to collect a list of specific > edits that I thought needed to be made. The list became rather > detailed so it ended up just being easier to draft up a > proposed new version. > > I have checked it in to my personal github repo here... > > http://goo.gl/IaQnm > > The raw xml is here... > > http://goo.gl/QcNCr > > As always, feedback is definitely welcome. > > - James > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------070701060709010205060603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This puts a pretty big burden on the server. For many applications, there will be no "session" to get hijacked, and for others, the risk is tolerable.

Can we add this to "Security Considerations" as a potential threat, and say that clients SHOULD consider session hijacking when using links returned via Webfinger?

-Evan

On 12-12-04 08:56 PM, James M Snell wrote:
To be clear, I am NOT saying that all links in the document would need to use HTTPS. I'm saying that if requests to the Webfinger resource are authenticated, links to resources in the same domain as the WebFinger server need to use HTTPS or else we run the risk of a session hijack. That's a very different statement than "TLS be used for all link relations". 

In other words, if I send an authenticated request to https://example.net/.well-known/webfinger?resource=foo, and the JRD contains a link to an avatar image located on the same server, the link should be like https://example.net/images/foo-avatar.png.

- James


On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

 

Perhaps we’re discussing different issues.  With respect to whether TLS is used to query the “webfinger” resource or not, I understand there are people arguing both sides.  I’m personally neutral on that.

 

Where the discussion was going here was related to “where do link relations in the webfinger response point?”  There is an argument that we must also require that TLS be used for all link relations.  I disagree with that as a requirement since we’re now talking about where a user stores his data (e.g., an avatar).  If he chooses to store that in Flickr or any $1/mo hosting provider should not matter.  Further, any client processing the WF response could see that it is an “http:” URI and decide on a case-by-case basis how to treat each link relation seen.

 

Paul

 

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-Andre


Subject: Re: WebFinger 8 Input...

 

Paul, you can say this all you want, but there are coherent voices on our mailing list saying that they really need something written into the spec to give them assurance that they can use WF and it’ll either go through TLS or it won’t happen.  There are three coherent come-backs to this:

 

- Always HTTPS

- Some sort of normative parameterized behavior

- Those people shouldn’t use WebFinger.

 

At some point, someone’s going to have to make a consensus call on where the community stands. -T

 

On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

 

Keep in mind that WF is to allow users to share all kinds of information about themselves.  Services that need to be secure will use HTTPS.  Those that do not, won’t.

 

If I tell my WF service that my avatar is located at some http:// location, then that’s the information the WF server should return in responses.

 

If information needs better security, then the URL would be HTTPS.  Any IdP would utilize an https:// address.

 

In any case, the href value in WF can be any valid URI.  Use or non-use of TLS for these other resources to which WF refers is really outside the scope of WF.

 

Paul

 

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

 

 

On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

 

What a WF resource points to should have nothing to do with whether WF uses HTTPS or not.  If I put my vcard out on the Internet accessible only via http (which is presently the case), then that’s the way it’s accessed.  (Actually, the HTTPS version works on my domain, but will redirect the client to the non-HTTPS version.)

 

Well... for a typical non-authenticated request to a WebFinger resource, you're correct. There is an obvious risk, however, of introducing a session hijacking vulnerability when using authenticated WebFinger requests with an improperly secured server if the JRD provides non-https links to the same domain. It would be dangerous for us to assume that all relevant cookies provided on a given domain have been secured properly. As a best practice, links provided to resources located on the same domain should simply be required to use https as a way of erring on the side of caution. 

 

 

During a redirect, the redirection does not need to use the same scheme if the group agrees to allowing HTTP.  That said, I fully agree the example in section 8 should show use of HTTPS just as a means of encouragement.

 

 

Issuing a https secured request to a WF endpoint that redirects to an insecure third party location rather defeats the purpose of requiring https for the first request, doesn't it?

 

- James

 

 

Paul

 

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...

 

Yep, as expected really. Take the various edits for what they are worth. It was either this or try to go through all the multitude of threads and provide input on each individual subject... this was by far the more efficient option for me. I'll come up with a summary of the changes a bit later on this evening. Most are purely editorial in nature, but there are a few important technical items... 

 

For instance, when serving up a JRD over an HTTPS connection, and that JRD contains link relations to resources hosted at the same domain as the WebFinger service, there is a risk of a TLS-downgrade attack if those link relations are not https urls... e.g. in the examples we see things like "href": "http://example.com/foo" ... when it really ought to be "href": "https://example.com/foo" ...

 

Similarly, if we are going to allow the use of 3xx redirects, then the WebFinger server needs to make sure that the new target URL is using the https scheme; i.e. instead of "Location: http://example.net/webfinger?..." it needs to be "Location: https://example.net/webfinger?..."

 

There are a few other bits scattered around. Once the kids are bathed and off to bed I'll write up a summary.

 

Honestly, other than the need to control the flood of discussions happening on the mailing list, I don't see any reason to rush this to completion. Let's get a relatively stable draft out there and just let it sit for a while so implementors can get more experience with it.

 

- James

 

On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

 

Wow, that’s a lot of changes.  I’d personally like to keep the terminology section the way it is.  The word “link relation” is confusing to people who have not heard it, and having that very brief statement is useful, I think.

 

Merging the “Introduction” and “Overview” sections might be a good idea, but I recall some time ago there was one section and it was suggested we split it apart.  What we would put in each, I’m not sure.  It’s definitely a bit overlapping at the moment.  I’m OK with merging those sections.

 

I really, really prefer to keep the examples in the main body.  They’re marked as non-normative, but being able to read those before getting further in the document is very helpful to the reader the first time they read the text.  Heck, even if they’ve read it, it’s nice to see examples right up front.  Otherwise, the reader’s headed is cloudy all the way through the text.

 

The header for Section 2 (“Terminology”) appears to have been removed accidentally.

 

In section 8, there are bullet points for the IANA registration template material.  Those should not be there.

 

Don’t use “URI” before the instant messaging address in the contact area.  Email addresses are also URIs :-)  I wanted IM there.

 

Beyond that, the changes are so substantial that I’ll need time to see exactly what they are.  I tried to produce a meaningful diff, but since the whole example section was moved, diff programs gets totally confused.

 

Paul

 

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.com; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...

 

Given that the recent WebFinger discussion has been flooding and overwhelming the IETF appsawg mailing list I have left that mailing list off the cc list until the new WF specific mailing list has been set up. While reading through the latest version of the spec, I started to collect a list of specific edits that I thought needed to be made. The list became rather detailed so it ended up just being easier to draft up a proposed new version.

 

I have checked it in to my personal github repo here...

 

 

The raw xml is here...

 

 

As always, feedback is definitely welcome.

 

- James

 

 

 




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------070701060709010205060603-- From laurentwalter.goix@telecomitalia.it Wed Dec 5 02:01:57 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251C621F87DA for ; Wed, 5 Dec 2012 02:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1y39ePl26OJ for ; Wed, 5 Dec 2012 02:01:54 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5B24821F870A for ; Wed, 5 Dec 2012 02:01:53 -0800 (PST) Content-Type: multipart/mixed; boundary="_0fc04f5d-24cc-4fe9-8974-bd70706b66da_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 5 Dec 2012 11:01:48 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 5 Dec 2012 11:01:46 +0100 From: Goix Laurent Walter To: "webfinger@ietf.org" , "webfinger@googlegroups.com" Date: Wed, 5 Dec 2012 11:01:42 +0100 Thread-Topic: About "resource", host-wide info and jrd Thread-Index: Ac3Sz4bPcbYorzfzR4+43xCr5DslYQ== Message-ID: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [webfinger] About "resource", host-wide info and jrd X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:01:57 -0000 --_0fc04f5d-24cc-4fe9-8974-bd70706b66da_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A224A0GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A224A0GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to bring here the discussion on the mandatory usage of the "resour= ce" parameter and the access to host-wide information. I understand that webfinger now moved away from rfc6415, and the webfinger = endpoint could be seen as a "lrdd" endpoint using "application/json" type. However currently if a client would like to retrieve host-wide information = there is no other option than using host-meta and/or host-meta.json. This may be fine as long as webfinger and host-meta.json use the exact same= data format (jrd) but anyway still require 2 endpoints being used with no = clear meaning of whether to follow lrdd or go to the wf endpoint in case bo= th are different. Hence webfinger may need to support host-wide info on its own as well, for = example by omitting the "resource" parameter. One could probably use the ht= tp root url of the domain itself as a valid resource parameter but http://e= xample.com/.well-known/webfinger?resource=3Dhttp://example.com seems quite = a trick. The omission of the "resource" parameter would also be useful in mobile net= works where the app does not know the actual identity of the user (and may = not be entitled to) but only the server does. In this case the server could= answer anyway with some user-specific information and could include an acr= : URI as an opaque identifier in the "subject" not to reveal the actual use= r identity. I recognize that "resource" params MUST be supported by servers but usage i= n requests from client should remain unspecified so that they can decide wh= ether to use it or not. In addition I would suggest that if a resource para= meter is not provided, the server should answer with hostwide information u= nless it can retrieve the own user identity through other means, and in thi= s case consider the request as resource-specific of the requesting user. Otherwise what is the rationale for mandating the resource parameter in all= queries? walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A224A0GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’d like to bring here th= e discussion on the mandatory usage of the “resource” parameter= and the access to host-wide information.

 

I understand that webfinger now= moved away from rfc6415, and the webfinger endpoint could be seen as a = 220;lrdd” endpoint using “application/json” type.

However currently if a client w= ould like to retrieve host-wide information there is no other option than u= sing host-meta and/or host-meta.json.

 

This may be fine as long as web= finger and host-meta.json use the exact same data format (jrd) but anyway s= till require 2 endpoints being used with no clear meaning of whether to fol= low lrdd or go to the wf endpoint in case both are different.

Hence webfinger may need to sup= port host-wide info on its own as well, for example by omitting the “= resource” parameter. One could probably use the http root url of the = domain itself as a valid resource parameter but http://example.com/.well-known/webfinger?resource=3Dhttp://example.= com seems quite a trick.

 

The omission of the “reso= urce” parameter would also be useful in mobile networks where the app= does not know the actual identity of the user (and may not be entitled to)= but only the server does. In this case the server could answer anyway with some user-specific information and could include = an acr: URI as an opaque identifier in the “subject” not to rev= eal the actual user identity.

 

I recognize that “resourc= e” params MUST be supported by servers but usage in requests from cli= ent should remain unspecified so that they can decide whether to use it or = not. In addition I would suggest that if a resource parameter is not provided, the server should answer with hostwide informat= ion unless it can retrieve the own user identity through other means, and i= n this case consider the request as resource-specific of the requesting use= r.

 

Otherwise what is the rationale= for mandating the resource parameter in all queries?

walter

 =

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A5A224A0GRFMBX704BA02_-- --_0fc04f5d-24cc-4fe9-8974-bd70706b66da_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_0fc04f5d-24cc-4fe9-8974-bd70706b66da_-- From bradfitz@google.com Tue Dec 4 20:05:51 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794FE21F8C0D for ; Tue, 4 Dec 2012 20:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTRsJvcZBJmH for ; Tue, 4 Dec 2012 20:05:49 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7F321F8BFC for ; Tue, 4 Dec 2012 20:05:49 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1264897wib.13 for ; Tue, 04 Dec 2012 20:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JkN27zOzMUNem2o+eNYExn1OxQ96tGHbWK5wJ3R2cvs=; b=WJCqP1LEnThOTUcerwEVnyJYpnBZvDPHVR1cbBnYUuTrwkfP3W53a1uiUN04rfnplI YvGgJiBKf03nmoHzcQ1TOi6ULA6vxFHVDjo/mb80Mbh9ZpZKedNJnZaK7YFpIAbtrsgi 5lxoR5J06tuVZvbcMwet/uZM1O0mQo0lbGQgc18vsocOt26Cpfy0Hcv/WB6uMhoY6gTa wCc2adq23mUFTGA+1Aety+IvXlGYIHt+S2cu3Wt8MprKgJH5G2GyBW+KF9TZxxRPwZ11 fcL8v1X7/L5ihHNmiQ3KWM5UyDQtf4aBOkRbw4mHK/W/x5tDhrE6E/ImBYzIcBQ2MfTI 70XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=JkN27zOzMUNem2o+eNYExn1OxQ96tGHbWK5wJ3R2cvs=; b=kpD8uUx6wq+SP/9+s2JKV8+2ZikGw84vB1RWY5+FH5EbrSDU/+KRQtNEklf8ew5tdO XZA9/DzH0YX/pY4y1QaMTAbHYdwANG7WK+T9tzIjStvLm5JbDnISX0NsMwc7eQl3Iv1A bljMSraW8Zcx0xAr1qh6VzJ2F8OVh7SeZNr+TsHBHB89jIYqjY0fi9SVTNQDTCFW3Rte 0ORNZNk2O5ilWR8QW9s954RJfNDEBO2/Cug27uIdFc46bjbY5+EvhsVwIe4TQcoPEl+d qDpXW6n+mvnF/6DGA64JgTxDBGePizLyL4F/EWqJp/kreGQI2XIJeAOHKs0QM2O5z0bY j2Zw== MIME-Version: 1.0 Received: by 10.180.74.108 with SMTP id s12mr844692wiv.12.1354680348225; Tue, 04 Dec 2012 20:05:48 -0800 (PST) Received: by 10.194.166.100 with HTTP; Tue, 4 Dec 2012 20:05:48 -0800 (PST) In-Reply-To: <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> Date: Tue, 4 Dec 2012 20:05:48 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d043c81e6f0afd304d0131883 X-Gm-Message-State: ALoCoQkuZ3fxw8BMQJ5UKB6QgquTdyNbmTa1emXF5Pes3C1MXP7Chi5M8eE7Q1N7a4JJc0PeMwP3y9XbNkgqhlFszuPq4oYoPMRKsw57XUzKb+RX3V8YPv58FhoOTKxtvojTrPVNnNaBvJG6KD/kC0rttmt82pxfm3+0vHsUuOha/1lPknJ027cWqiXvUSw9sgXBwAgrKe36 X-Mailman-Approved-At: Wed, 05 Dec 2012 05:21:04 -0800 Cc: webfinger@ietf.org, Tim Bray , James M Snell , Mike Jones , Peter Saint-Andre Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:05:51 -0000 --f46d043c81e6f0afd304d0131883 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that the webfinger response's links should be allowed to be any protocol, be it https://, http://, or gopher://. On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones wrote= : > Tim,**** > > ** ** > > Perhaps we=E2=80=99re discussing different issues. With respect to wheth= er TLS is > used to query the =E2=80=9Cwebfinger=E2=80=9D resource or not, I understa= nd there are > people arguing both sides. I=E2=80=99m personally neutral on that.**** > > ** ** > > Where the discussion was going here was related to =E2=80=9Cwhere do link > relations in the webfinger response point?=E2=80=9D There is an argument= that we > must also require that TLS be used for all link relations. I disagree wi= th > that as a requirement since we=E2=80=99re now talking about where a user = stores his > data (e.g., an avatar). If he chooses to store that in Flickr or any $1/= mo > hosting provider should not matter. Further, any client processing the W= F > response could see that it is an =E2=80=9Chttp:=E2=80=9D URI and decide o= n a case-by-case > basis how to treat each link relation seen.**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:twbray@google.com] > *Sent:* Tuesday, December 04, 2012 2:27 AM > *To:* Paul E. Jones > *Cc:* James M Snell; webfinger@googlegroups.com; Mike Jones; Peter > Saint-Andre > > *Subject:* Re: WebFinger 8 Input...**** > > ** ** > > Paul, you can say this all you want, but there are coherent voices on our > mailing list saying that they really need something written into the spec > to give them assurance that they can use WF and it=E2=80=99ll either go t= hrough TLS > or it won=E2=80=99t happen. There are three coherent come-backs to this:= **** > > ** ** > > - Always HTTPS**** > > - Some sort of normative parameterized behavior**** > > - Those people shouldn=E2=80=99t use WebFinger.**** > > ** ** > > At some point, someone=E2=80=99s going to have to make a consensus call o= n where > the community stands. -T**** > > ** ** > > On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > Keep in mind that WF is to allow users to share all kinds of information > about themselves. Services that need to be secure will use HTTPS. Those > that do not, won=E2=80=99t.**** > > **** > > If I tell my WF service that my avatar is located at some http://location= , then that=E2=80=99s the information the WF server should return in > responses.**** > > **** > > If information needs better security, then the URL would be HTTPS. Any > IdP would utilize an https:// address.**** > > **** > > In any case, the href value in WF can be any valid URI. Use or non-use o= f > TLS for these other resources to which WF refers is really outside the > scope of WF.**** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Tuesday, December 04, 2012 12:44 AM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input...**** > > **** > > **** > > On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > What a WF resource points to should have nothing to do with whether WF > uses HTTPS or not. If I put my vcard out on the Internet accessible only > via http (which is presently the case), then that=E2=80=99s the way it=E2= =80=99s accessed. > (Actually, the HTTPS version works on my domain, but will redirect the > client to the non-HTTPS version.)**** > > **** > > Well... for a typical non-authenticated request to a WebFinger resource, > you're correct. There is an obvious risk, however, of introducing a sessi= on > hijacking vulnerability when using authenticated WebFinger requests with = an > improperly secured server if the JRD provides non-https links to the same > domain. It would be dangerous for us to assume that all relevant cookies > provided on a given domain have been secured properly. As a best practice= , > links provided to resources located on the same domain should simply be > required to use https as a way of erring on the side of caution. **** > > **** > > **** > > During a redirect, the redirection does not need to use the same scheme i= f > the group agrees to allowing HTTP. That said, I fully agree the example = in > section 8 should show use of HTTPS just as a means of encouragement.**** > > **** > > **** > > Issuing a https secured request to a WF endpoint that redirects to an > insecure third party location rather defeats the purpose of requiring htt= ps > for the first request, doesn't it?**** > > **** > > - James**** > > **** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, December 03, 2012 10:01 PM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input...**** > > **** > > Yep, as expected really. Take the various edits for what they are worth. > It was either this or try to go through all the multitude of threads and > provide input on each individual subject... this was by far the more > efficient option for me. I'll come up with a summary of the changes a bit > later on this evening. Most are purely editorial in nature, but there are= a > few important technical items... **** > > **** > > For instance, when serving up a JRD over an HTTPS connection, and that JR= D > contains link relations to resources hosted at the same domain as the > WebFinger service, there is a risk of a TLS-downgrade attack if those lin= k > relations are not https urls... e.g. in the examples we see things like > "href": "http://example.com/foo" ... when it really ought to be "href": " > https://example.com/foo" ...**** > > **** > > Similarly, if we are going to allow the use of 3xx redirects, then the > WebFinger server needs to make sure that the new target URL is using the > https scheme; i.e. instead of "Location: http://example.net/webfinger?...= " > it needs to be "Location: https://example.net/webfinger?..."**** > > **** > > There are a few other bits scattered around. Once the kids are bathed and > off to bed I'll write up a summary.**** > > **** > > Honestly, other than the need to control the flood of discussions > happening on the mailing list, I don't see any reason to rush this to > completion. Let's get a relatively stable draft out there and just let it > sit for a while so implementors can get more experience with it.**** > > **** > > - James**** > > **** > > On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones > wrote:**** > > James,**** > > **** > > Wow, that=E2=80=99s a lot of changes. I=E2=80=99d personally like to kee= p the terminology > section the way it is. The word =E2=80=9Clink relation=E2=80=9D is confu= sing to people who > have not heard it, and having that very brief statement is useful, I thin= k. > **** > > **** > > Merging the =E2=80=9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D= sections might be a good idea, > but I recall some time ago there was one section and it was suggested we > split it apart. What we would put in each, I=E2=80=99m not sure. It=E2= =80=99s definitely > a bit overlapping at the moment. I=E2=80=99m OK with merging those secti= ons.**** > > **** > > I really, really prefer to keep the examples in the main body. They=E2= =80=99re > marked as non-normative, but being able to read those before getting > further in the document is very helpful to the reader the first time they > read the text. Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice = to see examples > right up front. Otherwise, the reader=E2=80=99s headed is cloudy all the= way > through the text.**** > > **** > > The header for Section 2 (=E2=80=9CTerminology=E2=80=9D) appears to have = been removed > accidentally.**** > > **** > > In section 8, there are bullet points for the IANA registration template > material. Those should not be there.**** > > **** > > Don=E2=80=99t use =E2=80=9CURI=E2=80=9D before the instant messaging addr= ess in the contact area. > Email addresses are also URIs :-) I wanted IM there.**** > > **** > > Beyond that, the changes are so substantial that I=E2=80=99ll need time t= o see > exactly what they are. I tried to produce a meaningful diff, but since t= he > whole example section was moved, diff programs gets totally confused.**** > > **** > > Paul**** > > **** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Monday, December 03, 2012 8:38 PM > *To:* webfinger@googlegroups.com; Paul Jones; Tim Bray > *Subject:* WebFinger 8 Input...**** > > **** > > Given that the recent WebFinger discussion has been flooding and > overwhelming the IETF appsawg mailing list I have left that mailing list > off the cc list until the new WF specific mailing list has been set up. > While reading through the latest version of the spec, I started to collec= t > a list of specific edits that I thought needed to be made. The list becam= e > rather detailed so it ended up just being easier to draft up a proposed n= ew > version.**** > > **** > > I have checked it in to my personal github repo here...**** > > **** > > http://goo.gl/IaQnm**** > > **** > > The raw xml is here...**** > > **** > > http://goo.gl/QcNCr**** > > **** > > As always, feedback is definitely welcome.**** > > **** > > - James**** > > **** > > **** > > ** ** > --f46d043c81e6f0afd304d0131883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= agree that the webfinger response's links should be allowed to be any = protocol, be it https://, http://, or gopher://.

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

=C2=A0

Perhaps we=E2=80=99re discussing different= issues.=C2=A0 With respect to whether TLS is used to query the =E2=80=9Cwe= bfinger=E2=80=9D resource or not, I understand there are people arguing bot= h sides.=C2=A0 I=E2=80=99m personally neutral on that.=

=C2=A0

Where the discussio= n was going here was related to =E2=80=9Cwhere do link relations in the web= finger response point?=E2=80=9D=C2=A0 There is an argument that we must als= o require that TLS be used for all link relations.=C2=A0 I disagree with th= at as a requirement since we=E2=80=99re now talking about where a user stor= es his data (e.g., an avatar).=C2=A0 If he chooses to store that in Flickr = or any $1/mo hosting provider should not matter.=C2=A0 Further, any client = processing the WF response could see that it is an =E2=80=9Chttp:=E2=80=9D = URI and decide on a case-by-case basis how to treat each link relation seen= .

=C2=A0

Paul<= /span>

=C2=A0

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones=
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-= Andre


Subject: Re: WebFinger 8 Input...

=C2=A0

Paul, you can say this all you want, b= ut there are coherent voices on our mailing list saying that they really ne= ed something written into the spec to give them assurance that they can use= WF and it=E2=80=99ll either go through TLS or it won=E2=80=99t happen. =C2= =A0There are three coherent come-backs to this:

=C2=A0

- Always HTTPS=

- Some sort of normative param= eterized behavior

- Those people shouldn=E2=80=99t use WebFinger.

=C2=A0

At some point, someone=E2=80= =99s going to have to make a consensus call on where the community stands. = -T

=C2=A0=

On Mon, Dec 3, 201= 2 at 9:58 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

Keep in mind that WF is t= o allow users to share all kinds of information about themselves.=C2=A0 Ser= vices that need to be secure will use HTTPS.=C2=A0 Those that do not, won= =E2=80=99t.

=C2=A0

If I tell my WF ser= vice that my avatar is located at some http:// location, then that=E2=80=99= s the information the WF server should return in responses.

=C2=A0

If information need= s better security, then the URL would be HTTPS.=C2=A0 Any IdP would utilize= an https:// address.

=C2=A0

In any case, the hr= ef value in WF can be any valid URI. =C2=A0Use or non-use of TLS for these = other resources to which WF refers is really outside the scope of WF.

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jone= s
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e
Subject: Re: WebFinger 8 Input...

=C2=A0

=C2=A0

On Mon, Dec 3, 2012 a= t 7:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

What a WF resource points= to should have nothing to do with whether WF uses HTTPS or not.=C2=A0 If I= put my vcard out on the Internet accessible only via http (which is presen= tly the case), then that=E2=80=99s the way it=E2=80=99s accessed.=C2=A0 (Ac= tually, the HTTPS version works on my domain, but will redirect the client = to the non-HTTPS version.)

=C2=A0

=

Well... for a typical non-authenticated request to a= WebFinger resource, you're correct. There is an obvious risk, however,= of introducing a session hijacking vulnerability when using authenticated = WebFinger requests with an improperly secured server if the JRD provides no= n-https links to the same domain. It would be dangerous for us to assume th= at all relevant cookies provided on a given domain have been secured proper= ly. As a best practice, links provided to resources located on the same dom= ain should simply be required to use https as a way of erring on the side o= f caution.=C2=A0

=C2=A0

=C2=A0=

During a redir= ect, the redirection does not need to use the same scheme if the group agre= es to allowing HTTP.=C2=A0 That said, I fully agree the example in section = 8 should show use of HTTPS just as a means of encouragement.<= u>

=C2=A0

=C2=A0=

Issuing a https secured request to a WF endpoin= t that redirects to an insecure third party location rather defeats the pur= pose of requiring https for the first request, doesn't it?

=C2=A0

- James

=C2=A0

=C2=A0=

Paul<= /u>

=C2=A0

From:= James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones=
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre=
Subject: Re: WebFinger 8 Input...

=C2=A0

Yep, as expected= really. Take the various edits for what they are worth. It was either this= or try to go through all the multitude of threads and provide input on eac= h individual subject... this was by far the more efficient option for me. I= 'll come up with a summary of the changes a bit later on this evening. = Most are purely editorial in nature, but there are a few important technica= l items...=C2=A0

=C2=A0

For instance= , when serving up a JRD over an HTTPS connection, and that JRD contains lin= k relations to resources hosted at the same domain as the WebFinger service= , there is a risk of a TLS-downgrade attack if those link relations are not= https urls... e.g. in the examples we see things like "href": &q= uot;http://example.com= /foo" ... when it really ought to be "href": "https://example.com/foo" ...

=C2=A0

=C2=A0

There = are a few other bits scattered around. Once the kids are bathed and off to = bed I'll write up a summary.

=C2=A0

Honest= ly, other than the need to control the flood of discussions happening on th= e mailing list, I don't see any reason to rush this to completion. Let&= #39;s get a relatively stable draft out there and just let it sit for a whi= le so implementors can get more experience with it.

=C2=A0

- Jame= s

=C2=A0

On Mon, Dec 3, 2012 at = 6:45 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=C2=A0

Wow, that=E2=80=99s a lot= of changes.=C2=A0 I=E2=80=99d personally like to keep the terminology sect= ion the way it is.=C2=A0 The word =E2=80=9Clink relation=E2=80=9D is confus= ing to people who have not heard it, and having that very brief statement i= s useful, I think.

=C2=A0

Merging the =E2=80= =9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D sections might be a= good idea, but I recall some time ago there was one section and it was sug= gested we split it apart.=C2=A0 What we would put in each, I=E2=80=99m not = sure.=C2=A0 It=E2=80=99s definitely a bit overlapping at the moment.=C2=A0 = I=E2=80=99m OK with merging those sections.

=C2=A0

I really, really pr= efer to keep the examples in the main body. =C2=A0They=E2=80=99re marked as= non-normative, but being able to read those before getting further in the = document is very helpful to the reader the first time they read the text.= =C2=A0 Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice to see exam= ples right up front.=C2=A0 Otherwise, the reader=E2=80=99s headed is cloudy= all the way through the text.

=C2=A0

The header for Sect= ion 2 (=E2=80=9CTerminology=E2=80=9D) appears to have been removed accident= ally.

=C2=A0

In section 8, there= are bullet points for the IANA registration template material.=C2=A0 Those= should not be there.

=C2=A0

Don=E2=80=99t use = =E2=80=9CURI=E2=80=9D before the instant messaging address in the contact a= rea.=C2=A0 Email addresses are also URIs :-)=C2=A0 I wanted IM there.

=C2=A0

Beyond that, the ch= anges are so substantial that I=E2=80=99ll need time to see exactly what th= ey are.=C2=A0 I tried to produce a meaningful diff, but since the whole exa= mple section was moved, diff programs gets totally confused.<= u>

=C2=A0

Paul<= u>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.co= m; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...<= u>

=C2=A0

Given = that the recent WebFinger discussion has been flooding and overwhelming the= IETF appsawg mailing list I have left that mailing list off the cc list un= til the new WF specific mailing list has been set up. While reading through= the latest version of the spec, I started to collect a list of specific ed= its that I thought needed to be made. The list became rather detailed so it= ended up just being easier to draft up a proposed new version.

=C2=A0

I have check= ed it in to my personal github repo here...

<= div>

=C2=A0

=C2=A0=C2=A0http://goo.gl/IaQnm

=C2=A0

The raw xml is here...<= /u>

=C2=A0

=C2=A0=C2=A0http://goo.gl/QcNCr

=C2=A0

As always, feedback is = definitely welcome.

=C2=A0

- James

=C2=A0<= /u>

=C2=A0

=C2=A0


--f46d043c81e6f0afd304d0131883-- From jpanzer@google.com Tue Dec 4 20:25:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6CF21F8C0A for ; Tue, 4 Dec 2012 20:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiDed9Lz7eGn for ; Tue, 4 Dec 2012 20:25:35 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D170B21F8C08 for ; Tue, 4 Dec 2012 20:25:34 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3981442lah.31 for ; Tue, 04 Dec 2012 20:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AqOZzUWY/oB0nJKcaRN/AfMXLzKtjkTCS7Y8nFc9XeI=; b=Eg+Xw8taoQfPXo5aQ6ezUD/VulFf484cOa6hVuox2rCn21ZE5pNLHVpxpfSJgZED5H DNT1KERUzxr/VSjDaMEUfVYclXi9YCCcgB2Dagx+HW3QCmdVQgVFaeyzexg7789YPRRr inpwKQ3BU6pQMMa7dI94T/sxSbG4R5Ew7cAoSM/v9GGkdzm1x2dL6AlzXm2LuWNkS8x2 +5P98v8GZfc2MlE/xi31E7Z3L8PPaDaqXJsLiwpmJMHm6plf2wwlD013U5M4yT7Ocflb u2D/LWYlQyjmfnjwWCosd4BLgy8LPt9ONEHkSi44EDZ0We4NTwhypNiqSOAauWKTN2Lb mobA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AqOZzUWY/oB0nJKcaRN/AfMXLzKtjkTCS7Y8nFc9XeI=; b=B3jjWkqmhZkIEQNmZO9rFy28sGmNS/hbyPv36gP9c6BvHJ7nG2DhXxcqTsTX8eSy/v q1dmbuGWvs2lAqDkpHjoQ9QbzYtHuy9goXTA+ajdkl/mtbuPvs9A8S80Llb33a4yDyOO 0L9nhcjMpniOEO3Gys9z2v5YUpl5737PMQorU7cF0J799VmK5hq9CYvprp1SRBcHPoDO ML0jlkDQ8Vzc1lD0DbqrwU2cbr+XdmVYOVOBXRrfAuwciHwwUvYrr4uX/oKnrocGhkog xaVvCtKuhSozmAq00rj0tlY9BKzKATbHBqSBbEe+1Sq1oN+C8KhoheZVN+sjgXg/Cr59 lWOg== MIME-Version: 1.0 Received: by 10.112.9.74 with SMTP id x10mr6722330lba.59.1354681533536; Tue, 04 Dec 2012 20:25:33 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 20:25:33 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 20:25:33 -0800 (PST) In-Reply-To: References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> Date: Tue, 4 Dec 2012 20:25:33 -0800 Message-ID: From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e0cb4efe307a9719f804d0135f91 X-Gm-Message-State: ALoCoQn84fBeKMlLsQgoW9jLu2KoqueH7i1/sWmPHO1bF+0BAKdJAbndO1uS00c8wgiyL5GMxM4wdUB+kKkGJU4j7QFNe7/m9/e5Zgs9rjp6mwarttlGh2e4SAr3eHpFy+U6+w/pc+T0fndH6yIZ24YYbtSSOle8GI2G4KyaV6d1jekpWu3mpwvGRtGp3cmc1wUtgWyFSdcw X-Mailman-Approved-At: Wed, 05 Dec 2012 05:21:04 -0800 Cc: webfinger@ietf.org, Mike Jones , James M Snell , Tim Bray , Peter Saint-Andre Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:25:37 -0000 --e0cb4efe307a9719f804d0135f91 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1. Well, gopher is beyond the pale of course. data: would be particularly useful. On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" wrote: > I agree that the webfinger response's links should be allowed to be any > protocol, be it https://, http://, or gopher://. > > On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones wrot= e: > >> Tim,**** >> >> ** ** >> >> Perhaps we=92re discussing different issues. With respect to whether TL= S >> is used to query the =93webfinger=94 resource or not, I understand there= are >> people arguing both sides. I=92m personally neutral on that.**** >> >> ** ** >> >> Where the discussion was going here was related to =93where do link >> relations in the webfinger response point?=94 There is an argument that= we >> must also require that TLS be used for all link relations. I disagree w= ith >> that as a requirement since we=92re now talking about where a user store= s his >> data (e.g., an avatar). If he chooses to store that in Flickr or any $1= /mo >> hosting provider should not matter. Further, any client processing the = WF >> response could see that it is an =93http:=94 URI and decide on a case-by= -case >> basis how to treat each link relation seen.**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> *From:* Tim Bray [mailto:twbray@google.com] >> *Sent:* Tuesday, December 04, 2012 2:27 AM >> *To:* Paul E. Jones >> *Cc:* James M Snell; webfinger@googlegroups.com; Mike Jones; Peter >> Saint-Andre >> >> *Subject:* Re: WebFinger 8 Input...**** >> >> ** ** >> >> Paul, you can say this all you want, but there are coherent voices on ou= r >> mailing list saying that they really need something written into the spe= c >> to give them assurance that they can use WF and it=92ll either go throug= h TLS >> or it won=92t happen. There are three coherent come-backs to this:**** >> >> ** ** >> >> - Always HTTPS**** >> >> - Some sort of normative parameterized behavior**** >> >> - Those people shouldn=92t use WebFinger.**** >> >> ** ** >> >> At some point, someone=92s going to have to make a consensus call on whe= re >> the community stands. -T**** >> >> ** ** >> >> On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones >> wrote:**** >> >> James,**** >> >> **** >> >> Keep in mind that WF is to allow users to share all kinds of information >> about themselves. Services that need to be secure will use HTTPS. Thos= e >> that do not, won=92t.**** >> >> **** >> >> If I tell my WF service that my avatar is located at some http://locatio= n, then that=92s the information the WF server should return in >> responses.**** >> >> **** >> >> If information needs better security, then the URL would be HTTPS. Any >> IdP would utilize an https:// address.**** >> >> **** >> >> In any case, the href value in WF can be any valid URI. Use or non-use >> of TLS for these other resources to which WF refers is really outside th= e >> scope of WF.**** >> >> **** >> >> Paul**** >> >> **** >> >> *From:* James M Snell [mailto:jasnell@gmail.com] >> *Sent:* Tuesday, December 04, 2012 12:44 AM >> *To:* Paul E. Jones >> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e >> *Subject:* Re: WebFinger 8 Input...**** >> >> **** >> >> **** >> >> On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones >> wrote:**** >> >> James,**** >> >> **** >> >> What a WF resource points to should have nothing to do with whether WF >> uses HTTPS or not. If I put my vcard out on the Internet accessible onl= y >> via http (which is presently the case), then that=92s the way it=92s acc= essed. >> (Actually, the HTTPS version works on my domain, but will redirect the >> client to the non-HTTPS version.)**** >> >> **** >> >> Well... for a typical non-authenticated request to a WebFinger resource, >> you're correct. There is an obvious risk, however, of introducing a sess= ion >> hijacking vulnerability when using authenticated WebFinger requests with= an >> improperly secured server if the JRD provides non-https links to the sam= e >> domain. It would be dangerous for us to assume that all relevant cookies >> provided on a given domain have been secured properly. As a best practic= e, >> links provided to resources located on the same domain should simply be >> required to use https as a way of erring on the side of caution. **** >> >> **** >> >> **** >> >> During a redirect, the redirection does not need to use the same scheme >> if the group agrees to allowing HTTP. That said, I fully agree the exam= ple >> in section 8 should show use of HTTPS just as a means of encouragement.*= * >> ** >> >> **** >> >> **** >> >> Issuing a https secured request to a WF endpoint that redirects to an >> insecure third party location rather defeats the purpose of requiring ht= tps >> for the first request, doesn't it?**** >> >> **** >> >> - James**** >> >> **** >> >> **** >> >> Paul**** >> >> **** >> >> *From:* James M Snell [mailto:jasnell@gmail.com] >> *Sent:* Monday, December 03, 2012 10:01 PM >> *To:* Paul E. Jones >> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e >> *Subject:* Re: WebFinger 8 Input...**** >> >> **** >> >> Yep, as expected really. Take the various edits for what they are worth. >> It was either this or try to go through all the multitude of threads and >> provide input on each individual subject... this was by far the more >> efficient option for me. I'll come up with a summary of the changes a bi= t >> later on this evening. Most are purely editorial in nature, but there ar= e a >> few important technical items... **** >> >> **** >> >> For instance, when serving up a JRD over an HTTPS connection, and that >> JRD contains link relations to resources hosted at the same domain as th= e >> WebFinger service, there is a risk of a TLS-downgrade attack if those li= nk >> relations are not https urls... e.g. in the examples we see things like >> "href": "http://example.com/foo" ... when it really ought to be "href": = " >> https://example.com/foo" ...**** >> >> **** >> >> Similarly, if we are going to allow the use of 3xx redirects, then the >> WebFinger server needs to make sure that the new target URL is using the >> https scheme; i.e. instead of "Location: http://example.net/webfinger?..= ." >> it needs to be "Location: https://example.net/webfinger?..."**** >> >> **** >> >> There are a few other bits scattered around. Once the kids are bathed an= d >> off to bed I'll write up a summary.**** >> >> **** >> >> Honestly, other than the need to control the flood of discussions >> happening on the mailing list, I don't see any reason to rush this to >> completion. Let's get a relatively stable draft out there and just let i= t >> sit for a while so implementors can get more experience with it.**** >> >> **** >> >> - James**** >> >> **** >> >> On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones >> wrote:**** >> >> James,**** >> >> **** >> >> Wow, that=92s a lot of changes. I=92d personally like to keep the >> terminology section the way it is. The word =93link relation=94 is conf= using >> to people who have not heard it, and having that very brief statement is >> useful, I think.**** >> >> **** >> >> Merging the =93Introduction=94 and =93Overview=94 sections might be a go= od idea, >> but I recall some time ago there was one section and it was suggested we >> split it apart. What we would put in each, I=92m not sure. It=92s defi= nitely >> a bit overlapping at the moment. I=92m OK with merging those sections.*= *** >> >> **** >> >> I really, really prefer to keep the examples in the main body. They=92r= e >> marked as non-normative, but being able to read those before getting >> further in the document is very helpful to the reader the first time the= y >> read the text. Heck, even if they=92ve read it, it=92s nice to see exam= ples >> right up front. Otherwise, the reader=92s headed is cloudy all the way >> through the text.**** >> >> **** >> >> The header for Section 2 (=93Terminology=94) appears to have been remove= d >> accidentally.**** >> >> **** >> >> In section 8, there are bullet points for the IANA registration template >> material. Those should not be there.**** >> >> **** >> >> Don=92t use =93URI=94 before the instant messaging address in the contac= t >> area. Email addresses are also URIs :-) I wanted IM there.**** >> >> **** >> >> Beyond that, the changes are so substantial that I=92ll need time to see >> exactly what they are. I tried to produce a meaningful diff, but since = the >> whole example section was moved, diff programs gets totally confused.***= * >> >> **** >> >> Paul**** >> >> **** >> >> *From:* James M Snell [mailto:jasnell@gmail.com] >> *Sent:* Monday, December 03, 2012 8:38 PM >> *To:* webfinger@googlegroups.com; Paul Jones; Tim Bray >> *Subject:* WebFinger 8 Input...**** >> >> **** >> >> Given that the recent WebFinger discussion has been flooding and >> overwhelming the IETF appsawg mailing list I have left that mailing list >> off the cc list until the new WF specific mailing list has been set up. >> While reading through the latest version of the spec, I started to colle= ct >> a list of specific edits that I thought needed to be made. The list beca= me >> rather detailed so it ended up just being easier to draft up a proposed = new >> version.**** >> >> **** >> >> I have checked it in to my personal github repo here...**** >> >> **** >> >> http://goo.gl/IaQnm**** >> >> **** >> >> The raw xml is here...**** >> >> **** >> >> http://goo.gl/QcNCr**** >> >> **** >> >> As always, feedback is definitely welcome.**** >> >> **** >> >> - James**** >> >> **** >> >> **** >> >> ** ** >> > > --e0cb4efe307a9719f804d0135f91 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

+1.=A0 Well, gopher is beyond the pale of course.

data: would be particularly useful.

On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick&q= uot; <bradfitz@google.com>= wrote:
I agre= e that the webfinger response's links should be allowed to be any proto= col, be it https://, http://, or gopher://.

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0

Perhaps we=92re discussing different issues.= =A0 With respect to whether TLS is used to query the =93webfinger=94 resour= ce or not, I understand there are people arguing both sides.=A0 I=92m perso= nally neutral on that.

=A0<= /p>

Where the discussion w= as going here was related to =93where do link relations in the webfinger re= sponse point?=94=A0 There is an argument that we must also require that TLS= be used for all link relations.=A0 I disagree with that as a requirement s= ince we=92re now talking about where a user stores his data (e.g., an avata= r).=A0 If he chooses to store that in Flickr or any $1/mo hosting provider = should not matter.=A0 Further, any client processing the WF response could = see that it is an =93http:=94 URI and decide on a case-by-case basis how to= treat each link relation seen.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones=
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-= Andre


Subject: Re: WebFinger 8 Input...

=A0

Paul, you can say this all you want, but there are coh= erent voices on our mailing list saying that they really need something wri= tten into the spec to give them assurance that they can use WF and it=92ll = either go through TLS or it won=92t happen. =A0There are three coherent com= e-backs to this:

=A0

- Always HTTPS

- Some sort of normative param= eterized behavior

- Those people shouldn=92t use WebFinger.

=A0

At some point, someone=92s going= to have to make a consensus call on where the community stands. -T<= u>

=A0

On Mon, Dec 3, 2012 at 9:58 PM, Pa= ul E. Jones <= paulej@packetizer.com> wrote:

James,

=A0

Keep in mind that WF is t= o allow users to share all kinds of information about themselves.=A0 Servic= es that need to be secure will use HTTPS.=A0 Those that do not, won=92t.

=A0<= /p>

If I tell my WF servic= e that my avatar is located at some http:// location, then that=92s the inf= ormation the WF server should return in responses.

=A0<= /p>

If information needs b= etter security, then the URL would be HTTPS.=A0 Any IdP would utilize an ht= tps:// address.

=A0<= /p>

In any case, the href = value in WF can be any valid URI. =A0Use or non-use of TLS for these other = resources to which WF refers is really outside the scope of WF.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jone= s
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e
Subject: Re: WebFinger 8 Input...

=A0

= =A0

On Mon, Dec 3, 2012 at 7:2= 8 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=A0

What a WF resource points= to should have nothing to do with whether WF uses HTTPS or not.=A0 If I pu= t my vcard out on the Internet accessible only via http (which is presently= the case), then that=92s the way it=92s accessed.=A0 (Actually, the HTTPS = version works on my domain, but will redirect the client to the non-HTTPS v= ersion.)

=A0

Well... for a typical non-authenticated request to a We= bFinger resource, you're correct. There is an obvious risk, however, of= introducing a session hijacking vulnerability when using authenticated Web= Finger requests with an improperly secured server if the JRD provides non-h= ttps links to the same domain. It would be dangerous for us to assume that = all relevant cookies provided on a given domain have been secured properly.= As a best practice, links provided to resources located on the same domain= should simply be required to use https as a way of erring on the side of c= aution.=A0

=A0

=

=A0=

During a redirect= , the redirection does not need to use the same scheme if the group agrees = to allowing HTTP.=A0 That said, I fully agree the example in section 8 shou= ld show use of HTTPS just as a means of encouragement.=

=A0<= /p>

=A0

Issuing a https secured request to a WF endpoin= t that redirects to an insecure third party location rather defeats the pur= pose of requiring https for the first request, doesn't it?

=A0

- James

= =A0

=A0

Paul<= /u>

=A0<= u>

From:= James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones=
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre=
Subject: Re: WebFinger 8 Input...

=A0

Yep, as expected re= ally. Take the various edits for what they are worth. It was either this or= try to go through all the multitude of threads and provide input on each i= ndividual subject... this was by far the more efficient option for me. I= 9;ll come up with a summary of the changes a bit later on this evening. Mos= t are purely editorial in nature, but there are a few important technical i= tems...=A0

=A0

For instance, w= hen serving up a JRD over an HTTPS connection, and that JRD contains link r= elations to resources hosted at the same domain as the WebFinger service, t= here is a risk of a TLS-downgrade attack if those link relations are not ht= tps urls... e.g. in the examples we see things like "href": "= ;http://example.com/fo= o" ... when it really ought to be "href": "https://example.com/foo&= quot; ...

=A0

Similarly, if w= e are going to allow the use of 3xx redirects, then the WebFinger server ne= eds to make sure that the new target URL is using the https scheme; i.e. in= stead of "Location: http://example.net/webfinger?..." it needs to be "= ;Location: h= ttps://example.net/webfinger?..."

=A0

There ar= e a few other bits scattered around. Once the kids are bathed and off to be= d I'll write up a summary.

=A0

Honestly= , other than the need to control the flood of discussions happening on the = mailing list, I don't see any reason to rush this to completion. Let= 9;s get a relatively stable draft out there and just let it sit for a while= so implementors can get more experience with it.

=A0

- James<= /span>

=A0

On Mon, Dec 3, 2012 at 6:4= 5 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=A0

Wow, that=92s a lot of ch= anges.=A0 I=92d personally like to keep the terminology section the way it = is.=A0 The word =93link relation=94 is confusing to people who have not hea= rd it, and having that very brief statement is useful, I think.

=A0<= /p>

Merging the =93Introdu= ction=94 and =93Overview=94 sections might be a good idea, but I recall som= e time ago there was one section and it was suggested we split it apart.=A0= What we would put in each, I=92m not sure.=A0 It=92s definitely a bit over= lapping at the moment.=A0 I=92m OK with merging those sections.

=A0<= /p>

I really, really prefe= r to keep the examples in the main body. =A0They=92re marked as non-normati= ve, but being able to read those before getting further in the document is = very helpful to the reader the first time they read the text.=A0 Heck, even= if they=92ve read it, it=92s nice to see examples right up front.=A0 Other= wise, the reader=92s headed is cloudy all the way through the text.<= u>

=A0<= /p>

The header for Section= 2 (=93Terminology=94) appears to have been removed accidentally.=

=A0<= /p>

In section 8, there ar= e bullet points for the IANA registration template material.=A0 Those shoul= d not be there.

=A0<= /p>

Don=92t use =93URI=94 = before the instant messaging address in the contact area.=A0 Email addresse= s are also URIs :-)=A0 I wanted IM there.

=A0<= /p>

Beyond that, the chang= es are so substantial that I=92ll need time to see exactly what they are.= =A0 I tried to produce a meaningful diff, but since the whole example secti= on was moved, diff programs gets totally confused.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.co= m; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...<= u>

=A0

Given th= at the recent WebFinger discussion has been flooding and overwhelming the I= ETF appsawg mailing list I have left that mailing list off the cc list unti= l the new WF specific mailing list has been set up. While reading through t= he latest version of the spec, I started to collect a list of specific edit= s that I thought needed to be made. The list became rather detailed so it e= nded up just being easier to draft up a proposed new version.=

=A0

I have checked = it in to my personal github repo here...

=A0

=A0

The raw xml is here...=

=A0

=A0

As always, feedback is = definitely welcome.

=A0

- James

=A0=

=A0

=A0

<= /div>

--e0cb4efe307a9719f804d0135f91-- From jpanzer@google.com Tue Dec 4 20:33:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8040B21F8C0C for ; Tue, 4 Dec 2012 20:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtiBBWzEaZsF for ; Tue, 4 Dec 2012 20:33:44 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18BA621F8BE2 for ; Tue, 4 Dec 2012 20:33:43 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4113907lbk.31 for ; Tue, 04 Dec 2012 20:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eJJkKAe3FneHJbv7Xmg5k2IFvDptY7b06UIpa0+Zm2U=; b=Sqfm6bIfU9txcB8AmCGxWmcBsQwVkfhAoYxJmTjNjl3jQ4TvkbOD3ELPeLdLes3Vlr 8XE0zAeUao/9/AUmoFag+EoX7e/1THhzEE8erAkQbTXywPVMV4ql/S7s4h3rTsHUYhuR LHglBiZXsGnY5s2dXoN93gq0NFHXi70wmL0LaK/b6pYKJIMaPuitKRUNlAUYzSobcWhZ 5EYhHVOJuNdrQg/7240IIwVx1bkwNrAohEdKepQi12tdw5RixOL5a6hypD8/Gvc8AKiX RKJynh0gCivClG49Ekk37yJK1M2p64s/oe9NDKRZwn6ic/vTc20kL02f8H+m8tBk+AGm tDBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eJJkKAe3FneHJbv7Xmg5k2IFvDptY7b06UIpa0+Zm2U=; b=mwDV8VuvqRVoEZksm/WzFNoj7LoBzMBe/goy/eG0ih7KEMCYVo/CBpVXMD6oplDxzW nC7UXeLw15QAeCpj4K3mXy1yeZ6s+aivfhr+ZHPEDO2yNXx0VwL3zd+mii5rlBNUIHU1 S3gpB+IxA/J4t9Xqo23/LD31YWUFmUN8zkmOGfebYmqEFOwbEDvOgCLVt/z4QcnrnpOQ 69mL9IlGD3NHWXObVQ5fYFV8uAwAB7tbcN/QM+79QU/Qdpt9dkra8wFoyELjV5pvF3oq AaiQiPkgWuSb8QU0QMmlZscRVAguFoiUWSXtrn/Uq0DXrGeexzLrF/gLbxH8GYpCkCpe WTpA== MIME-Version: 1.0 Received: by 10.152.111.131 with SMTP id ii3mr14994538lab.37.1354682022777; Tue, 04 Dec 2012 20:33:42 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 20:33:42 -0800 (PST) Received: by 10.114.4.197 with HTTP; Tue, 4 Dec 2012 20:33:42 -0800 (PST) In-Reply-To: References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> Date: Tue, 4 Dec 2012 20:33:42 -0800 Message-ID: From: John Panzer To: James M Snell Content-Type: multipart/alternative; boundary=f46d040839f1c0534504d0137c9f X-Gm-Message-State: ALoCoQnLiJQkPhwlBqKVTyf1H0X9U4eeEfsCsNZ/BLqqIWOUpa0U43OYH4AzsWOtXyJ+mFvCumui+xgp7/6plFkzDnKVFKzPs3qvAPr6iFORPwp3kxxnAMo8KI3rMExGkh4JEUhp4ZS20sYRrvq/VJvzb0PfnXzgnB4/zjcu8aAFb5EYsjiiU0UjyWHBJ1AEd1gkTN2g3kvO X-Mailman-Approved-At: Wed, 05 Dec 2012 05:21:04 -0800 Cc: webfinger@ietf.org, Mike Jones , Tim Bray , Peter Saint-Andre , webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:33:46 -0000 --f46d040839f1c0534504d0137c9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not orthogonal, as data: uris can't introduce a hijacking vulnerability and they are useful for that reason (plus latency). So web finger would be over restrictive if it were to specify https only for example. On Dec 4, 2012 8:28 PM, "James M Snell" wrote: > All good but entirely orthogonal to the issue I raised. This has nothing > to do with what schemes are allowed in general and everything to do with = a > possible session hijack vulnerability. > On Dec 4, 2012 8:25 PM, "John Panzer" wrote: > >> +1. Well, gopher is beyond the pale of course. >> >> data: would be particularly useful. >> On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" wrote: >> >>> I agree that the webfinger response's links should be allowed to be any >>> protocol, be it https://, http://, or gopher://. >>> >>> On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones wr= ote: >>> >>>> Tim,**** >>>> >>>> ** ** >>>> >>>> Perhaps we=92re discussing different issues. With respect to whether = TLS >>>> is used to query the =93webfinger=94 resource or not, I understand the= re are >>>> people arguing both sides. I=92m personally neutral on that.**** >>>> >>>> ** ** >>>> >>>> Where the discussion was going here was related to =93where do link >>>> relations in the webfinger response point?=94 There is an argument th= at we >>>> must also require that TLS be used for all link relations. I disagree= with >>>> that as a requirement since we=92re now talking about where a user sto= res his >>>> data (e.g., an avatar). If he chooses to store that in Flickr or any = $1/mo >>>> hosting provider should not matter. Further, any client processing th= e WF >>>> response could see that it is an =93http:=94 URI and decide on a case-= by-case >>>> basis how to treat each link relation seen.**** >>>> >>>> ** ** >>>> >>>> Paul**** >>>> >>>> ** ** >>>> >>>> *From:* Tim Bray [mailto:twbray@google.com] >>>> *Sent:* Tuesday, December 04, 2012 2:27 AM >>>> *To:* Paul E. Jones >>>> *Cc:* James M Snell; webfinger@googlegroups.com; Mike Jones; Peter >>>> Saint-Andre >>>> >>>> *Subject:* Re: WebFinger 8 Input...**** >>>> >>>> ** ** >>>> >>>> Paul, you can say this all you want, but there are coherent voices on >>>> our mailing list saying that they really need something written into t= he >>>> spec to give them assurance that they can use WF and it=92ll either go >>>> through TLS or it won=92t happen. There are three coherent come-backs= to >>>> this:**** >>>> >>>> ** ** >>>> >>>> - Always HTTPS**** >>>> >>>> - Some sort of normative parameterized behavior**** >>>> >>>> - Those people shouldn=92t use WebFinger.**** >>>> >>>> ** ** >>>> >>>> At some point, someone=92s going to have to make a consensus call on >>>> where the community stands. -T**** >>>> >>>> ** ** >>>> >>>> On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones >>>> wrote:**** >>>> >>>> James,**** >>>> >>>> **** >>>> >>>> Keep in mind that WF is to allow users to share all kinds of >>>> information about themselves. Services that need to be secure will us= e >>>> HTTPS. Those that do not, won=92t.**** >>>> >>>> **** >>>> >>>> If I tell my WF service that my avatar is located at some http://locat= ion, then that=92s the information the WF server should return in >>>> responses.**** >>>> >>>> **** >>>> >>>> If information needs better security, then the URL would be HTTPS. An= y >>>> IdP would utilize an https:// address.**** >>>> >>>> **** >>>> >>>> In any case, the href value in WF can be any valid URI. Use or non-us= e >>>> of TLS for these other resources to which WF refers is really outside = the >>>> scope of WF.**** >>>> >>>> **** >>>> >>>> Paul**** >>>> >>>> **** >>>> >>>> *From:* James M Snell [mailto:jasnell@gmail.com] >>>> *Sent:* Tuesday, December 04, 2012 12:44 AM >>>> *To:* Paul E. Jones >>>> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter >>>> Saint-Andre >>>> *Subject:* Re: WebFinger 8 Input...**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones >>>> wrote:**** >>>> >>>> James,**** >>>> >>>> **** >>>> >>>> What a WF resource points to should have nothing to do with whether WF >>>> uses HTTPS or not. If I put my vcard out on the Internet accessible o= nly >>>> via http (which is presently the case), then that=92s the way it=92s a= ccessed. >>>> (Actually, the HTTPS version works on my domain, but will redirect the >>>> client to the non-HTTPS version.)**** >>>> >>>> **** >>>> >>>> Well... for a typical non-authenticated request to a WebFinger >>>> resource, you're correct. There is an obvious risk, however, of introd= ucing >>>> a session hijacking vulnerability when using authenticated WebFinger >>>> requests with an improperly secured server if the JRD provides non-htt= ps >>>> links to the same domain. It would be dangerous for us to assume that = all >>>> relevant cookies provided on a given domain have been secured properly= . As >>>> a best practice, links provided to resources located on the same domai= n >>>> should simply be required to use https as a way of erring on the side = of >>>> caution. **** >>>> >>>> **** >>>> >>>> **** >>>> >>>> During a redirect, the redirection does not need to use the same schem= e >>>> if the group agrees to allowing HTTP. That said, I fully agree the ex= ample >>>> in section 8 should show use of HTTPS just as a means of encouragement= . >>>> **** >>>> >>>> **** >>>> >>>> **** >>>> >>>> Issuing a https secured request to a WF endpoint that redirects to an >>>> insecure third party location rather defeats the purpose of requiring = https >>>> for the first request, doesn't it?**** >>>> >>>> **** >>>> >>>> - James**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> Paul**** >>>> >>>> **** >>>> >>>> *From:* James M Snell [mailto:jasnell@gmail.com] >>>> *Sent:* Monday, December 03, 2012 10:01 PM >>>> *To:* Paul E. Jones >>>> *Cc:* webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter >>>> Saint-Andre >>>> *Subject:* Re: WebFinger 8 Input...**** >>>> >>>> **** >>>> >>>> Yep, as expected really. Take the various edits for what they are >>>> worth. It was either this or try to go through all the multitude of th= reads >>>> and provide input on each individual subject... this was by far the mo= re >>>> efficient option for me. I'll come up with a summary of the changes a = bit >>>> later on this evening. Most are purely editorial in nature, but there = are a >>>> few important technical items... **** >>>> >>>> **** >>>> >>>> For instance, when serving up a JRD over an HTTPS connection, and that >>>> JRD contains link relations to resources hosted at the same domain as = the >>>> WebFinger service, there is a risk of a TLS-downgrade attack if those = link >>>> relations are not https urls... e.g. in the examples we see things lik= e >>>> "href": "http://example.com/foo" ... when it really ought to be >>>> "href": "https://example.com/foo" ...**** >>>> >>>> **** >>>> >>>> Similarly, if we are going to allow the use of 3xx redirects, then the >>>> WebFinger server needs to make sure that the new target URL is using t= he >>>> https scheme; i.e. instead of "Location: >>>> http://example.net/webfinger?..." it needs to be "Location: >>>> https://example.net/webfinger?..."**** >>>> >>>> **** >>>> >>>> There are a few other bits scattered around. Once the kids are bathed >>>> and off to bed I'll write up a summary.**** >>>> >>>> **** >>>> >>>> Honestly, other than the need to control the flood of discussions >>>> happening on the mailing list, I don't see any reason to rush this to >>>> completion. Let's get a relatively stable draft out there and just let= it >>>> sit for a while so implementors can get more experience with it.**** >>>> >>>> **** >>>> >>>> - James**** >>>> >>>> **** >>>> >>>> On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones >>>> wrote:**** >>>> >>>> James,**** >>>> >>>> **** >>>> >>>> Wow, that=92s a lot of changes. I=92d personally like to keep the >>>> terminology section the way it is. The word =93link relation=94 is co= nfusing >>>> to people who have not heard it, and having that very brief statement = is >>>> useful, I think.**** >>>> >>>> **** >>>> >>>> Merging the =93Introduction=94 and =93Overview=94 sections might be a = good >>>> idea, but I recall some time ago there was one section and it was sugg= ested >>>> we split it apart. What we would put in each, I=92m not sure. It=92s >>>> definitely a bit overlapping at the moment. I=92m OK with merging tho= se >>>> sections.**** >>>> >>>> **** >>>> >>>> I really, really prefer to keep the examples in the main body. They= =92re >>>> marked as non-normative, but being able to read those before getting >>>> further in the document is very helpful to the reader the first time t= hey >>>> read the text. Heck, even if they=92ve read it, it=92s nice to see ex= amples >>>> right up front. Otherwise, the reader=92s headed is cloudy all the wa= y >>>> through the text.**** >>>> >>>> **** >>>> >>>> The header for Section 2 (=93Terminology=94) appears to have been remo= ved >>>> accidentally.**** >>>> >>>> **** >>>> >>>> In section 8, there are bullet points for the IANA registration >>>> template material. Those should not be there.**** >>>> >>>> **** >>>> >>>> Don=92t use =93URI=94 before the instant messaging address in the cont= act >>>> area. Email addresses are also URIs :-) I wanted IM there.**** >>>> >>>> **** >>>> >>>> Beyond that, the changes are so substantial that I=92ll need time to s= ee >>>> exactly what they are. I tried to produce a meaningful diff, but sinc= e the >>>> whole example section was moved, diff programs gets totally confused.*= * >>>> ** >>>> >>>> **** >>>> >>>> Paul**** >>>> >>>> **** >>>> >>>> *From:* James M Snell [mailto:jasnell@gmail.com] >>>> *Sent:* Monday, December 03, 2012 8:38 PM >>>> *To:* webfinger@googlegroups.com; Paul Jones; Tim Bray >>>> *Subject:* WebFinger 8 Input...**** >>>> >>>> **** >>>> >>>> Given that the recent WebFinger discussion has been flooding and >>>> overwhelming the IETF appsawg mailing list I have left that mailing li= st >>>> off the cc list until the new WF specific mailing list has been set up= . >>>> While reading through the latest version of the spec, I started to col= lect >>>> a list of specific edits that I thought needed to be made. The list be= came >>>> rather detailed so it ended up just being easier to draft up a propose= d new >>>> version.**** >>>> >>>> **** >>>> >>>> I have checked it in to my personal github repo here...**** >>>> >>>> **** >>>> >>>> http://goo.gl/IaQnm**** >>>> >>>> **** >>>> >>>> The raw xml is here...**** >>>> >>>> **** >>>> >>>> http://goo.gl/QcNCr**** >>>> >>>> **** >>>> >>>> As always, feedback is definitely welcome.**** >>>> >>>> **** >>>> >>>> - James**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> ** ** >>>> >>> >>> --f46d040839f1c0534504d0137c9f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Not orthogonal, as data: uris can't introduce a hijackin= g vulnerability and they are useful for that reason (plus latency).=A0 So w= eb finger would be over restrictive if it were to specify https only for ex= ample.

On Dec 4, 2012 8:28 PM, "James M Snell"= ; <jasnell@gmail.com> wrote:=

All good but entirely orthogonal to the issue I raised. This= has nothing to do with what schemes are allowed in general and everything = to do with a possible session hijack vulnerability.

On Dec 4, 2012 8:25 PM, "John Panzer" = <jpanzer@google.= com> wrote:

+1.=A0 Well, gopher is beyond the pale of course.

data: would be particularly useful.

On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick&q= uot; <bradfitz@= google.com> wrote:
I agre= e that the webfinger response's links should be allowed to be any proto= col, be it https://, http://, or gopher://.

On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Tim,

=A0

Perhaps we=92re discussing different issues.= =A0 With respect to whether TLS is used to query the =93webfinger=94 resour= ce or not, I understand there are people arguing both sides.=A0 I=92m perso= nally neutral on that.

=A0<= /p>

Where the discussion w= as going here was related to =93where do link relations in the webfinger re= sponse point?=94=A0 There is an argument that we must also require that TLS= be used for all link relations.=A0 I disagree with that as a requirement s= ince we=92re now talking about where a user stores his data (e.g., an avata= r).=A0 If he chooses to store that in Flickr or any $1/mo hosting provider = should not matter.=A0 Further, any client processing the WF response could = see that it is an =93http:=94 URI and decide on a case-by-case basis how to= treat each link relation seen.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:twbray@google.com]
Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones=
Cc: James M Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-= Andre


Subject: Re: WebFinger 8 Input...

=A0

Paul, you can say this all you want, but there are coh= erent voices on our mailing list saying that they really need something wri= tten into the spec to give them assurance that they can use WF and it=92ll = either go through TLS or it won=92t happen. =A0There are three coherent com= e-backs to this:

=A0

- Always HTTPS

- Some sort of normative param= eterized behavior

- Those people shouldn=92t use WebFinger.

=A0

At some point, someone=92s going= to have to make a consensus call on where the community stands. -T<= u>

=A0

On Mon, Dec 3, 2012 at 9:58 PM, Pa= ul E. Jones <= paulej@packetizer.com> wrote:

James,

=A0

Keep in mind that WF is t= o allow users to share all kinds of information about themselves.=A0 Servic= es that need to be secure will use HTTPS.=A0 Those that do not, won=92t.

=A0<= /p>

If I tell my WF servic= e that my avatar is located at some http:// location, then that=92s the inf= ormation the WF server should return in responses.

=A0<= /p>

If information needs b= etter security, then the URL would be HTTPS.=A0 Any IdP would utilize an ht= tps:// address.

=A0<= /p>

In any case, the href = value in WF can be any valid URI. =A0Use or non-use of TLS for these other = resources to which WF refers is really outside the scope of WF.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM
To: Paul E. Jone= s
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andr= e
Subject: Re: WebFinger 8 Input...

=A0

= =A0

On Mon, Dec 3, 2012 at 7:2= 8 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=A0

What a WF resource points= to should have nothing to do with whether WF uses HTTPS or not.=A0 If I pu= t my vcard out on the Internet accessible only via http (which is presently= the case), then that=92s the way it=92s accessed.=A0 (Actually, the HTTPS = version works on my domain, but will redirect the client to the non-HTTPS v= ersion.)

=A0

Well... for a typical non-authenticated request to a We= bFinger resource, you're correct. There is an obvious risk, however, of= introducing a session hijacking vulnerability when using authenticated Web= Finger requests with an improperly secured server if the JRD provides non-h= ttps links to the same domain. It would be dangerous for us to assume that = all relevant cookies provided on a given domain have been secured properly.= As a best practice, links provided to resources located on the same domain= should simply be required to use https as a way of erring on the side of c= aution.=A0

=A0

=

=A0=

During a redirect= , the redirection does not need to use the same scheme if the group agrees = to allowing HTTP.=A0 That said, I fully agree the example in section 8 shou= ld show use of HTTPS just as a means of encouragement.=

=A0<= /p>

=A0

Issuing a https secured request to a WF endpoin= t that redirects to an insecure third party location rather defeats the pur= pose of requiring https for the first request, doesn't it?

=A0

- James

= =A0

=A0

Paul<= /u>

=A0<= u>

From:= James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 10:01 PM
To: Paul E. Jones=
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre=
Subject: Re: WebFinger 8 Input...

=A0

Yep, as expected re= ally. Take the various edits for what they are worth. It was either this or= try to go through all the multitude of threads and provide input on each i= ndividual subject... this was by far the more efficient option for me. I= 9;ll come up with a summary of the changes a bit later on this evening. Mos= t are purely editorial in nature, but there are a few important technical i= tems...=A0

=A0

For instance, w= hen serving up a JRD over an HTTPS connection, and that JRD contains link r= elations to resources hosted at the same domain as the WebFinger service, t= here is a risk of a TLS-downgrade attack if those link relations are not ht= tps urls... e.g. in the examples we see things like "href": "= ;http://example.com/fo= o" ... when it really ought to be "href": "https://example.com/foo&= quot; ...

=A0

Similarly, if w= e are going to allow the use of 3xx redirects, then the WebFinger server ne= eds to make sure that the new target URL is using the https scheme; i.e. in= stead of "Location: http://example.net/webfinger?..." it needs to be "= ;Location: h= ttps://example.net/webfinger?..."

=A0

There ar= e a few other bits scattered around. Once the kids are bathed and off to be= d I'll write up a summary.

=A0

Honestly= , other than the need to control the flood of discussions happening on the = mailing list, I don't see any reason to rush this to completion. Let= 9;s get a relatively stable draft out there and just let it sit for a while= so implementors can get more experience with it.

=A0

- James<= /span>

=A0

On Mon, Dec 3, 2012 at 6:4= 5 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

=A0

Wow, that=92s a lot of ch= anges.=A0 I=92d personally like to keep the terminology section the way it = is.=A0 The word =93link relation=94 is confusing to people who have not hea= rd it, and having that very brief statement is useful, I think.

=A0<= /p>

Merging the =93Introdu= ction=94 and =93Overview=94 sections might be a good idea, but I recall som= e time ago there was one section and it was suggested we split it apart.=A0= What we would put in each, I=92m not sure.=A0 It=92s definitely a bit over= lapping at the moment.=A0 I=92m OK with merging those sections.

=A0<= /p>

I really, really prefe= r to keep the examples in the main body. =A0They=92re marked as non-normati= ve, but being able to read those before getting further in the document is = very helpful to the reader the first time they read the text.=A0 Heck, even= if they=92ve read it, it=92s nice to see examples right up front.=A0 Other= wise, the reader=92s headed is cloudy all the way through the text.<= u>

=A0<= /p>

The header for Section= 2 (=93Terminology=94) appears to have been removed accidentally.=

=A0<= /p>

In section 8, there ar= e bullet points for the IANA registration template material.=A0 Those shoul= d not be there.

=A0<= /p>

Don=92t use =93URI=94 = before the instant messaging address in the contact area.=A0 Email addresse= s are also URIs :-)=A0 I wanted IM there.

=A0<= /p>

Beyond that, the chang= es are so substantial that I=92ll need time to see exactly what they are.= =A0 I tried to produce a meaningful diff, but since the whole example secti= on was moved, diff programs gets totally confused.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Monday, December 03, 2012 8:38 PM
To: webfinger@googlegroups.co= m; Paul Jones; Tim Bray
Subject: WebFinger 8 Input...<= u>

=A0

Given th= at the recent WebFinger discussion has been flooding and overwhelming the I= ETF appsawg mailing list I have left that mailing list off the cc list unti= l the new WF specific mailing list has been set up. While reading through t= he latest version of the spec, I started to collect a list of specific edit= s that I thought needed to be made. The list became rather detailed so it e= nded up just being easier to draft up a proposed new version.=

=A0

I have checked = it in to my personal github repo here...

=A0

=A0

The raw xml is here...=

=A0

=A0

As always, feedback is = definitely welcome.

=A0

- James

=A0=

=A0

=A0

<= /div>

--f46d040839f1c0534504d0137c9f-- From evan@status.net Wed Dec 5 01:59:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46521F85FC for ; Wed, 5 Dec 2012 01:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx+v4GKqFDwJ for ; Wed, 5 Dec 2012 01:58:57 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id BE05021F85F5 for ; Wed, 5 Dec 2012 01:58:56 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 5E18D8D424B for ; Wed, 5 Dec 2012 10:11:15 +0000 (UTC) Message-ID: <50BF1ADA.8050307@status.net> Date: Wed, 05 Dec 2012 04:58:50 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070001070007010209000400" X-Mailman-Approved-At: Wed, 05 Dec 2012 05:21:04 -0800 Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:59:01 -0000 This is a cryptographically signed message in MIME format. --------------ms070001070007010209000400 Content-Type: multipart/alternative; boundary="------------090409020308080803070100" This is a multi-part message in MIME format. --------------090409020308080803070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable This puts a pretty big burden on the server. For many applications,=20 there will be no "session" to get hijacked, and for others, the risk is=20 tolerable. Can we add this to "Security Considerations" as a potential threat, and=20 say that clients SHOULD consider session hijacking when using links=20 returned via Webfinger? -Evan On 12-12-04 08:56 PM, James M Snell wrote: > To be clear, I am NOT saying that all links in the document would need = > to use HTTPS. I'm saying that if requests to the Webfinger resource=20 > are authenticated, links to resources in the same domain as the=20 > WebFinger server need to use HTTPS or else we run the risk of a=20 > session hijack. That's a very different statement than "TLS be used=20 > for all link relations". > > In other words, if I send an authenticated request to=20 > https://example.net/.well-known/webfinger?resource=3Dfoo, and the JRD=20 > contains a link to an avatar image located on the same server, the=20 > link should be like https://example.net/images/foo-avatar.png. > > - James > > > On Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones > wrote: > > Tim, > > Perhaps we're discussing different issues. With respect to > whether TLS is used to query the "webfinger" resource or not, I > understand there are people arguing both sides. I'm personally > neutral on that. > > Where the discussion was going here was related to "where do link > relations in the webfinger response point?" There is an argument > that we must also require that TLS be used for all link relations. > I disagree with that as a requirement since we're now talking > about where a user stores his data (e.g., an avatar). If he > chooses to store that in Flickr or any $1/mo hosting provider > should not matter. Further, any client processing the WF response > could see that it is an "http:" URI and decide on a case-by-case > basis how to treat each link relation seen. > > Paul > > *From:*Tim Bray [mailto:twbray@google.com ] > *Sent:* Tuesday, December 04, 2012 2:27 AM > *To:* Paul E. Jones > *Cc:* James M Snell; webfinger@googlegroups.com > ; Mike Jones; Peter Saint-Andre > > > *Subject:* Re: WebFinger 8 Input... > > Paul, you can say this all you want, but there are coherent voices > on our mailing list saying that they really need something written > into the spec to give them assurance that they can use WF and > it'll either go through TLS or it won't happen. There are three > coherent come-backs to this: > > - Always HTTPS > > - Some sort of normative parameterized behavior > > - Those people shouldn't use WebFinger. > > At some point, someone's going to have to make a consensus call on > where the community stands. -T > > On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones > > wrote: > > James, > > Keep in mind that WF is to allow users to share all kinds of > information about themselves. Services that need to be secure will > use HTTPS. Those that do not, won't. > > If I tell my WF service that my avatar is located at some http:// > location, then that's the information the WF server should return > in responses. > > If information needs better security, then the URL would be > HTTPS. Any IdP would utilize an https:// address. > > In any case, the href value in WF can be any valid URI. Use or > non-use of TLS for these other resources to which WF refers is > really outside the scope of WF. > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Tuesday, December 04, 2012 12:44 AM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com > ; Tim Bray; Mike Jones; Peter > Saint-Andre > *Subject:* Re: WebFinger 8 Input... > > On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones > > wrote: > > James, > > What a WF resource points to should have nothing to do with > whether WF uses HTTPS or not. If I put my vcard out on the > Internet accessible only via http (which is presently the case), > then that's the way it's accessed. (Actually, the HTTPS version > works on my domain, but will redirect the client to the non-HTTPS > version.) > > Well... for a typical non-authenticated request to a WebFinger > resource, you're correct. There is an obvious risk, however, of > introducing a session hijacking vulnerability when using > authenticated WebFinger requests with an improperly secured server > if the JRD provides non-https links to the same domain. It would > be dangerous for us to assume that all relevant cookies provided > on a given domain have been secured properly. As a best practice, > links provided to resources located on the same domain should > simply be required to use https as a way of erring on the side of > caution. > > During a redirect, the redirection does not need to use the > same scheme if the group agrees to allowing HTTP. That said, > I fully agree the example in section 8 should show use of > HTTPS just as a means of encouragement. > > Issuing a https secured request to a WF endpoint that redirects to > an insecure third party location rather defeats the purpose of > requiring https for the first request, doesn't it? > > - James > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Monday, December 03, 2012 10:01 PM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com > ; Tim Bray; Mike Jones; > Peter Saint-Andre > *Subject:* Re: WebFinger 8 Input... > > Yep, as expected really. Take the various edits for what they > are worth. It was either this or try to go through all the > multitude of threads and provide input on each individual > subject... this was by far the more efficient option for me. > I'll come up with a summary of the changes a bit later on this > evening. Most are purely editorial in nature, but there are a > few important technical items... > > For instance, when serving up a JRD over an HTTPS connection, > and that JRD contains link relations to resources hosted at > the same domain as the WebFinger service, there is a risk of a > TLS-downgrade attack if those link relations are not https > urls... e.g. in the examples we see things like "href": > "http://example.com/foo" ... when it really ought to be > "href": "https://example.com/foo" ... > > Similarly, if we are going to allow the use of 3xx redirects, > then the WebFinger server needs to make sure that the new > target URL is using the https scheme; i.e. instead of > "Location: http://example.net/webfinger?..." it needs to be > "Location: https://example.net/webfinger?..." > > There are a few other bits scattered around. Once the kids are > bathed and off to bed I'll write up a summary. > > Honestly, other than the need to control the flood of > discussions happening on the mailing list, I don't see any > reason to rush this to completion. Let's get a relatively > stable draft out there and just let it sit for a while so > implementors can get more experience with it. > > - James > > On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones > > wrote: > > James, > > Wow, that's a lot of changes. I'd personally like to keep the > terminology section the way it is. The word "link relation" is > confusing to people who have not heard it, and having that > very brief statement is useful, I think. > > Merging the "Introduction" and "Overview" sections might be a > good idea, but I recall some time ago there was one section > and it was suggested we split it apart. What we would put in > each, I'm not sure. It's definitely a bit overlapping at the > moment. I'm OK with merging those sections. > > I really, really prefer to keep the examples in the main body. > They're marked as non-normative, but being able to read those > before getting further in the document is very helpful to the > reader the first time they read the text. Heck, even if > they've read it, it's nice to see examples right up front. > Otherwise, the reader's headed is cloudy all the way through > the text. > > The header for Section 2 ("Terminology") appears to have been > removed accidentally. > > In section 8, there are bullet points for the IANA > registration template material. Those should not be there. > > Don't use "URI" before the instant messaging address in the > contact area. Email addresses are also URIs :-) I wanted IM the= re. > > Beyond that, the changes are so substantial that I'll need > time to see exactly what they are. I tried to produce a > meaningful diff, but since the whole example section was > moved, diff programs gets totally confused. > > Paul > > *From:*James M Snell [mailto:jasnell@gmail.com > ] > *Sent:* Monday, December 03, 2012 8:38 PM > *To:* webfinger@googlegroups.com > ; Paul Jones; Tim Bray > *Subject:* WebFinger 8 Input... > > Given that the recent WebFinger discussion has been flooding > and overwhelming the IETF appsawg mailing list I have left > that mailing list off the cc list until the new WF specific > mailing list has been set up. While reading through the latest > version of the spec, I started to collect a list of specific > edits that I thought needed to be made. The list became rather > detailed so it ended up just being easier to draft up a > proposed new version. > > I have checked it in to my personal github repo here... > > http://goo.gl/IaQnm > > The raw xml is here... > > http://goo.gl/QcNCr > > As always, feedback is definitely welcome. > > - James > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------090409020308080803070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This puts a pretty big burden on the server. For many applications, there will be no "session" to get hijacked, and for others, the risk is tolerable.

Can we add this to "Security Considerations" as a potential threat, and say that clients SHOULD consider session hijacking when using links returned via Webfinger?

-Evan

On 12-12-04 08:56 PM, James M Snell wrote:
To be clear, I a= m NOT saying that all links in the document would need to use HTTPS. I'm saying that if requests to the Webfinger resource are authenticated, links to resources in the same domain as the WebFinger server need to use HTTPS or else we run the risk of a session hijack. That's a very different statement than "TLS be used for all link relations". 

In other words, if I send= an authenticated request to https://example.net/.well-known/webfinger?resource=3Dfoo, and the JRD contains a link to an avatar image located on the same server, the link should be like https://ex= ample.net/images/foo-avatar.png.

- James


On Tue, Dec 4, 2012 at 5:51 PM, Paul= E. Jones <p= aulej@packetizer.com> wrote:

Tim,

 

Perhaps we’re discussing different issues.  With= respect to whether TLS is used to query the “webfinge= r” resource or not, I understand there are people arguing both sides.  I’m personally neut= ral on that.

 

Where the discussion was going here was related to “where do link relations in the webfinger res= ponse point?”  There is an argument that we mu= st also require that TLS be used for all link relations.&nb= sp; I disagree with that as a requirement since we̵= 7;re now talking about where a user stores his data (e.g., an avatar).  If he chooses to store tha= t in Flickr or any $1/mo hosting provider should not matter.  Further, any client processing the WF= response could see that it is an “http:” URI and decide on a case-by-case basis how to treat each link relation seen.

 

Paul

 

From: Tim Bray [mailto:twbray@google.com] Sent: Tuesday, December 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M Snell; webfinger@googlegroups.co= m; Mike Jones; Peter Saint-Andre


Subject: Re: WebFinger 8 Input...

 

Paul, you can say this all you want, but there are coherent voices on our mailing list saying that they really need something written into the spec to give them assurance that they can use WF and it’= ;ll either go through TLS or it won’t hap= pen.  There are three coherent come-backs t= o this:

 

- Always HTTPS

- Some sort of normative parameterized behavior

- Those people shouldn’t use WebFinge= r.

 

At some point, someone’s going to have= to make a consensus call on where the community stands. -T

 

On Mon, Dec 3, 2012 at 9:58 PM, Paul E. Jones <paulej@packetizer= =2Ecom> wrote:

James,

 

Keep in mind that WF is to allow users to share all kinds of information about themselves.&nbs= p; Services that need to be secure will use HTTPS.  Those that = do not, won’t.

 

If I tell my WF service that my avatar is located at some http:// location, then that’s the information the WF server should return in responses.

 

If information needs better security, then the URL would be HTTPS.  Any IdP would utiliz= e an https:// address.

 

In any case, the href value in WF can be any valid URI.  Use o= r non-use of TLS for these other resources to which WF refers is really outside the scope of WF.

 

Paul

 

From: James M Snell [mailto:jasnell= @gmail.com]
Sent: Tuesday, December 04, 2012 12:44 AM<= br> To: Paul E. Jones Cc: webfing= er@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre
Subject: Re: WebFinger 8 Input...=

 

 

=

On Mon, Dec 3, 2012 at 7:28 PM, Paul E. Jones <paulej@pa= cketizer.com> wrote:

James,

 

What a WF resource points to should have nothing to do with whether WF uses HTTPS or not. = ; If I put my vcard out on the Internet accessible only via http (which is presently the case), then that’s the w= ay it’s accessed.&nb= sp; (Actually, the HTTPS version works on my domain, but will redirect the client to the non-HTTPS version.)

 =

Well..= =2E for a typical non-authenticated request to a WebFinger resource, you're correct. There is an obvious risk, however, of introducing a session hijacking vulnerability when using authenticated WebFinger requests with an improperly secured server if the JRD provides non-https links to the same domain. It would be dangerous for us to assume that all relevant cookies provided on a given domain have been secured properly. As a best practice, links provided to resources located on the same domain should simply be required to use https as a way of erring on the side of caution.&nbs= p;

 =

 

During a redirect, the redirection does not need to use the same scheme if the group agrees to allowing HTTP.  That said= , I fully agree the example in section 8 should show use of HTTPS just as a means of encouragement.=

 

 =

Issuin= g a https secured request to a WF endpoint that redirects to an insecure third party location rather defeats the purpose of requiring https for the first request, doesn't it?<= /p>

 =

- Jame= s

 =

 =

Paul

 

From: James M Snell [mailto:jasnell@gmail.com= ]
Sent: Monday, December 03, 2012 10:01 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre
= Subject:= Re: WebFinger 8 Input...

 

Yep,= as expected really. Take the various edits for what they are worth. It was either this or try to go through all the multitude of threads and provide input on each individual subject... this was by far the more efficient option for me. I'll come up with a summary of the changes a bit later on this evening. Most are purely editorial in nature, but there are a few important technical items... <= /span>

 

For instance, when serving up a JRD over an HTTPS connection, and that JRD contains link relations to resources hosted at the same domain as the WebFinger service, there is a risk of a TLS-downgrade attack if those link relations are not https urls... e.g. in the examples we see things like "href": "<= a moz-do-not-send=3D"true" href=3D"http://example.com/foo" target=3D"_blank= ">http://example.com/foo" ... when it really ought to be "href": "https://example.com/fo= o" ...

 

Simi= larly, if we are going to allow the use of 3xx redirects, then the WebFinger server needs to make sure that the new target URL is using the https scheme; i.e. instead of "Location: http://example= =2Enet/webfinger?..." it needs to be "Location: https://example.net/webfinger?..."

 

Ther= e are a few other bits scattered around. Once the kids are bathed and off to bed I'll write up a summary.=

 

Hone= stly, other than the need to control the flood of discussions happening on the mailing list, I don't see any reason to rush this to completion. Let's get a relatively stable draft out there and just let it sit for a while so implementors can get more experience with it.=

 

- James

 

On Mon, Dec 3, 2012 at 6:45 PM, Paul E. Jones <paulej@packetizer= =2Ecom> wrote:

James,

 

Wow, that’s a = lot of changes.&nbs= p; I’d perso= nally like to keep the terminology section the way it is. = ; The word “= ;link relation”= is confusing to people who have not heard it, and having that very brief statement is useful, I think.

 

Merging the “Introduc= tion” and “Over= view” sections might be a good idea, but I recall some time ago there was one section and it was suggested we split it apart.  Wh= at we would put in each, I̵= 7;m not sure. = It’s definitely a bit overlapping at the moment.&nbs= p; I’m OK wi= th merging those sections.

 

I really, really prefer to keep the examples in the main body.  The= y’re marked as non-normative, but being able to read those before getting further in the document is very helpful to the reader the first time they read the text.  Hec= k, even if they’ve r= ead it, it’s = nice to see examples right up front. = Otherwise, the reader’s headed is cloudy all the way through the text.

 

The header for Section 2 (“Termino= logy”) appears to have been removed accidentally.

 

In section 8, there are bullet points for the IANA registration template material. = Those should not be there.

 

Don’t use “URI&= #8221; before the instant messaging address in the contact area.&n= bsp; Email addresses are also URIs :-)&n= bsp; I wanted IM there.

 

Beyond that, the changes are so substantial that I’ll= need time to see exactly what they are. = I tried to produce a meaningful diff, but since the whole example section was moved, diff programs gets totally confused.

 

Paul

 

=

From: James M Snell [mailto:jasnell@gmail.com= ]
Sent: Monday, December 03, 2012 8:38 PM To: webfinger@googlegroups.com; Paul Jones; Tim Bray
Subject:= WebFinger 8 Input...=

 

Give= n that the recent WebFinger discussion has been flooding and overwhelming the IETF appsawg mailing list I have left that mailing list off the cc list until the new WF specific mailing list has been set up. While reading through the latest version of the spec, I started to collect a list of specific edits that I thought needed to be made. The list became rather detailed so it ended up just being easier to draft up a proposed new version.=

 

I have checked it in to my personal github repo here...<= /p>

 

 

The raw xml is here...<= /p>

 

 

As always, feedback is definitely welcome.=

 

- James

 

 

=

 




_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------090409020308080803070100-- --------------ms070001070007010209000400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMDUw OTU4NTBaMCMGCSqGSIb3DQEJBDEWBBQxPOfvHzfYGKtwBl23OiEuYg2qLTBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAHUo fcNtSlkG3jS537V0P8Nc9G2MvEoI8lNp5DBIoq43LrTtnxwHe3awvpPgS6EhuFsxBI7unAZG D2CFRIg0te9/ZJh4giz0G8YSezzXcQqXcRrY50IKwfVzPcZ9eJgZWmhQvhAtfBASnR9UVBZ+ MaX0idy+QSRwfkgpo42KdFl+VBkyRe5Ku+M3jbP9HTtKbd5yy0TRNWmxRnlAK7FvibymAets gS8FEGQh4lhpFD1lbB5KlCrVoyd7vgdv35QBoFgIrA8EmZkuvrDfwntStDTFEpqH46VXswTi DWpTbm1NI3zdQVjMexSwxvdxax3af5Nda+4m/kXw04XxbywP0QYAAAAAAAA= --------------ms070001070007010209000400-- From salvatore.loreto@ericsson.com Wed Dec 5 06:01:24 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FCB21F855B for ; Wed, 5 Dec 2012 06:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPI6w0ntSZSl for ; Wed, 5 Dec 2012 06:01:23 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CA88621F854B for ; Wed, 5 Dec 2012 06:01:20 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-51-50bf53afa8dd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 44.5F.06323.FA35FB05; Wed, 5 Dec 2012 15:01:19 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Dec 2012 15:01:19 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 646702B1A; Wed, 5 Dec 2012 16:01:19 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3F36453D7D; Wed, 5 Dec 2012 16:01:18 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F191B539DD; Wed, 5 Dec 2012 16:01:17 +0200 (EET) Message-ID: <50BF53AE.6050504@ericsson.com> Date: Wed, 5 Dec 2012 16:01:18 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje764P0BBp/3GlpM/N7AZrHoxnRG ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj6unTzAUTOSomzehmaWDcwtbFyMkhIWAi MWP3DhYIW0ziwr31QHEuDiGBk4wSF+8+ZoFw1jNKzDp6nB2kSkhgF6PEzMfSEIm1jBLrbmxn h3CWMkpM+n+fGaSKV0BbYt/T70A2BweLgIrE8vflIGE2ATOJ5w+3gJWICsRKbL10mQ2iXFDi 5MwnYGeIAJ2x/ugDsDizgL5Ew5o5rCC2sICkxPI5nYwQcVuJC3Ous0DY8hLb385hhnhBTeLq uU3MEIdqSfSe7WSawCg8C8mKWUjaZyFpX8DIvIqRPTcxMye93HwTIzCMD275bbCDcdN9sUOM 0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw7l3JmZq4iZd55gVxU++o5VXi PWedZk9VZi0Q6fmlPiulcJpQ0FumHDbJt/v2uq6fn/b1eDK/l/8pO+fn/01ap57mcPjOlryT pTz/wcWjXWfCKrQX9CcorXO3/J76t3CWkN3xyVMOflE/2N0vXO1Yc2iKWbND9bUJz2Z9iU49 pPhSnOXY9LAvSizFGYmGWsxFxYkAWd1SDTECAAA= Cc: "Murray S. Kucherawy" Subject: [webfinger] hello Webfingers X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:01:24 -0000 Hi there, welcome everybody to the webfinger mailing list. We have decided to create the *webfinger* mailing list to offload the traffic in the apps-discuss one that is meant to be a general venue where to discuss about all the Apps issues. Now that we have the ad-hoc mailing list as APPSAwg co-chair, and the one responsible for the webfinger draft, I think it is the time, for the sake to make progress and finalize the work, to send out a couple of call for consensus to see if we can reach a consensus (and eventually evaluate what kind/level of consensus we have) on questions that have become to be repetitive and somehow circular. I will send out the call for consensus in series so that I can focus and concentrate the attention on that specific issue. Of course meanwhile you are free, and actually I encourage you, to continue to discuss in parallel all the other webfinger issues and/or details in this mailing list. best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com From salvatore.loreto@ericsson.com Wed Dec 5 06:58:57 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1200B21F8CCC for ; Wed, 5 Dec 2012 06:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.129 X-Spam-Level: X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8At9AoWmnu4 for ; Wed, 5 Dec 2012 06:58:56 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E832F21F8C13 for ; Wed, 5 Dec 2012 06:58:55 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-10-50bf612e3ee4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 62.E7.06323.E216FB05; Wed, 5 Dec 2012 15:58:54 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Dec 2012 15:58:54 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3DDB42B1A; Wed, 5 Dec 2012 16:58:54 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 13D9153D2A; Wed, 5 Dec 2012 16:58:53 +0200 (EET) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BFCFA538CF; Wed, 5 Dec 2012 16:58:52 +0200 (EET) Message-ID: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 16:58:53 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvja5e4v4Ag+Wf9Swmfm9gs1h0Yzqj A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxbss79oL57BWnd/UyNTBeYu1i5OSQEDCR eNJ7kRHCFpO4cG89WxcjF4eQwElGif+vZjBDOOsZJW4vOAWV2cUoceBxL1RmLaPE+rcNjBDO UkaJx5cnsYMM4xXQltg3+z8ziM0ioCLx/NRRsIVsAmYSzx9uAYuLCsRKbL10mQ2iXlDi5Mwn LCC2CNAh648+AIszC+hLNKyZA9YrLGAqsX7le2aIuK3EhTnXWSBseYntb+cwQzyhJnH13CYw W0hAS6L3bCfTBEbhWUhWzELSPgtJ+wJG5lWM7LmJmTnp5eabGIGhfHDLb4MdjJvuix1ilOZg URLn1VPd7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcY6o8sFca5sICUN7X+ENKWd5RTec WN1qYzh17awDrVu+5785K+N5SP7wizqhiOr6g1tfcrWpncm/d1qFR/jkemeHaKaYjDZmzmMM T/1X1LLlXvN9Pc1TI2uGoYLBZN/3D/ezp+aaW5mduJnVqrn5zj3mgPT35cmFuy7U1PPuqltz MSz3uw+vEktxRqKhFnNRcSIAL90cxzMCAAA= Cc: "Murray S. Kucherawy" Subject: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:58:57 -0000 During the last couple of weeks there has been a lot of mail discussing whether WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger fallback from HTTPS to HTTP. There are people with a clear preference (sometime strong) one way or the other, but also people that are more flexible and also having a preference could live with the other. However the discussion so far has not produced any clear consensus the editor can include in the next version of the wg draft. So as chairs I want explicitly to check where the wg consensus is 1) HTTPS only versus 2) HTTPS + HTTP but only as fallback So please provide your preference and if you want also the reason why you think WebFinger should adopt that particular solution. This consensus call will run until December Thursday 13th, 2012 best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com From jasnell@gmail.com Wed Dec 5 09:04:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D32921F8CA4 for ; Wed, 5 Dec 2012 09:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PXDFfxKcPt7 for ; Wed, 5 Dec 2012 09:04:43 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE8021F8CA0 for ; Wed, 5 Dec 2012 09:04:42 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9200840ieb.31 for ; Wed, 05 Dec 2012 09:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z/pZk4GlOcW+GNtsPDKcff9Pw8Mf8kNmxjnsckIAG5E=; b=ff28HeP5SjRoPmoFRgrJSxJfGGJMQCutG8cTij79cW1XF8REreh6PE5gMtecemv3H9 q2t4TBG6z8U7g4kq3kI81+CKfp8IffA2X41rS7I7N6N4kr9gkj34yeIM45SWdEBngDw0 t/zXtWucSfoAPhx+W//msKQ7uSxFpfeUFyDUefBRdQy9BuOnFfiYrQS+xA402Li0UkcR FQkvEGJ/2OCkMU3mMeEsBk2imMLRD+Q0xzf9YDK3rLJ+GwnSO39InfnV1chuOfVkxOIW ehLWPzVSXjTiMk/3rFxain50EnLBMqUuftLqvv/djHFmjNCalLE1nkPMG80kqNG6v9bG UtEg== Received: by 10.50.184.229 with SMTP id ex5mr2777290igc.72.1354727082579; Wed, 05 Dec 2012 09:04:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 5 Dec 2012 09:04:22 -0800 (PST) In-Reply-To: <50BF612D.3070001@ericsson.com> References: <50BF612D.3070001@ericsson.com> From: James M Snell Date: Wed, 5 Dec 2012 09:04:22 -0800 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=14dae9340ddf86556104d01dfa61 Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:04:47 -0000 --14dae9340ddf86556104d01dfa61 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > During the last couple of weeks there has been a lot of mail discussing > whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or the > other, > but also people that are more flexible and also having a preference could > live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why you > think WebFinger should > adopt that particular solution. > > I'm +0 on both of these. There is a third option that I prefer.. 3) HTTPS or HTTP... leave the decision up to the server and client depending on their own specific needs. Servers can enforce the use of https if that server deems it necessary. Likewise, clients can choose to use https or http if it deems it necessary. - James > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > > -- > Salvatore Loreto, PhD > www.sloreto.com > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --14dae9340ddf86556104d01dfa61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 5, 20= 12 at 6:58 AM, Salvatore Loreto <salvatore.loreto@ericsson.com= > wrote:

During the last couple of weeks there has been a lot of mail discussing whe= ther
WebFinger MUST support HTTPS only or instead it should be allowed for WebFi= nger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the o= ther,
but also people that are more flexible and also having a preference could l= ive with the other.

However the discussion so far has not produced any clear consensus the edit= or can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you t= hink WebFinger should
adopt that particular solution.


I'm +0 on both of these. There is = a third option that I prefer..

3) HTTPS or HTTP...= leave the decision up to the server and client depending on their own spec= ific needs. Servers can enforce the use of https if that server deems it ne= cessary. Likewise, clients can choose to use https or http if it deems it n= ecessary.
=C2=A0
- James


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--14dae9340ddf86556104d01dfa61-- From tbray@textuality.com Wed Dec 5 09:07:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15F21F8629 for ; Wed, 5 Dec 2012 09:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JcyKWLqyBNq for ; Wed, 5 Dec 2012 09:07:18 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFED321F87FF for ; Wed, 5 Dec 2012 09:07:17 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5914579oag.31 for ; Wed, 05 Dec 2012 09:07:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NfyQEp4mo9mccRUn61D81dZjhWb/MnLSC6eUxjd0fgc=; b=kAiFUbk8zAnpmh04qJSICPkYPHJyrEZr3694KFFyVTe0uX7yQ03yXVg0h48Z2Q1AeE 1KsQEOwh3PA2X6AureQAUDjpyBa9BOv5GdrkTHZrswVHvuitKFU7aVyYOgQ3nbDwl4aK +/Vxwm5vcQSvpRSx2Q7fOLf39qqq8yPWn5fSWQ84dIbYqyXpD4AIz9MoKoeY8Qirq0to xRXGFKdYWqcK+tdtC1HZV5QliojzxZ1afydY6tt/D7RDCGeFt5uG5RGKgYH55p2E0wk9 uUUQ+KiJTyH+zAC5ie+xBkEzAtFZFl9K1R+Mun4dtEKQgz2oRTPQoLiNvM83FJbnUfxO 3Nrg== MIME-Version: 1.0 Received: by 10.60.1.164 with SMTP id 4mr14276381oen.47.1354727237528; Wed, 05 Dec 2012 09:07:17 -0800 (PST) Received: by 10.76.12.134 with HTTP; Wed, 5 Dec 2012 09:07:17 -0800 (PST) X-Originating-IP: [2620:0:1000:147d:598c:8737:c00d:cc43] In-Reply-To: <50BF612D.3070001@ericsson.com> References: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 09:07:17 -0800 Message-ID: From: Tim Bray To: Salvatore Loreto Content-Type: multipart/alternative; boundary=e89a8fb1ffe2c2ae4a04d01e03c0 X-Gm-Message-State: ALoCoQnyJLL53FgodJ5IKzmf7U5+zJnB5UrWuiKgCpgb3tVN70+L1UfsUYfckT1hxFc8hNK0Ml0E Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:07:22 -0000 --e89a8fb1ffe2c2ae4a04d01e03c0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 on #1 -1 on #2, I=92d be OK with fallback if it were a way to have it explicitly allowed/disallowed by the caller. -T On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > During the last couple of weeks there has been a lot of mail discussing > whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or the > other, > but also people that are more flexible and also having a preference could > live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why you > think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > > -- > Salvatore Loreto, PhD > www.sloreto.com > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --e89a8fb1ffe2c2ae4a04d01e03c0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 on #1

-1 on #2, I=92d be OK with fallback if it were a way to hav= e it explicitly allowed/disallowed by the caller.

=A0-T

On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

During the last couple of weeks there has been a lot of mail discussing whe= ther
WebFinger MUST support HTTPS only or instead it should be allowed for WebFi= nger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the o= ther,
but also people that are more flexible and also having a preference could l= ive with the other.

However the discussion so far has not produced any clear consensus the edit= or can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you t= hink WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--e89a8fb1ffe2c2ae4a04d01e03c0-- From mmn@hethane.se Wed Dec 5 09:39:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4C21F8C3F for ; Wed, 5 Dec 2012 09:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfq1R85pJH6Q for ; Wed, 5 Dec 2012 09:39:02 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 747F521F897C for ; Wed, 5 Dec 2012 09:39:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Dec 2012 18:38:58 +0100 From: Mikael Nordfeldth To: Message-ID: <6f9d4091bb8a32db5a9234a63bc9d851@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:39:03 -0000 Pardon if I lose thread metadata in this message. Salvatore asked about the consensus for HTTPS only vs priority HTTPS followed by secondary HTTP. TL;DR: I support suggested priority for HTTPS followed by an optional HTTP fallback. (not necessarily a MUST on https for first connection, maybe my client service entirely relies upon end-user verification anyway - see my example of pretending to be Barack Obama further down) HTTPS only would be a MUCH bigger threat to widespread WF adoption than, say XRD support. For the small startup services that just want to put out or aggregate data, properly configured HTTPS servers are hard and expensive - without a proper configuration there is no practical difference from HTTP. In many languages the HTTPS toolkits are bad at verifying CA signatures. Adding to that, CA trust is NOT globally equal. Considering that most HTTPS connections are verified blindly through system-default CA bundles, most real-world Webfinger HTTPS request will be _equal_ to HTTP in trust. (How many of your systems trust Verisign but not CAcert.org?) Clients that authenticate against webfinger servers will likely be trustworthier (make actual use of HTTPS) as they should know the remote server beforehand, CA chain and all. Other reasons for my reasoning: * Webfinger servers generally will serve public data. It is meant to support building better user experience by giving trivial metadata about various kinds of internet identities. ANY data published without authentication should be regarded as PUBLIC and NON-VERIFIED. Remember that I could have my mmn@hethane.se webfinger put out a rel-me with mailto:obama@whitehouse.gov - not a single connection encryption/signing protocol in the world can stop that type of incorrect source data. Most WF data will probably be in one way or another verified by end-users sooner or later. * Responsibility for sensitive data retrieval is mostly put on the client. Clients that authenticate or fetch data that would be abused are well aware of risks when fetching data over non-verified connections. * Servers that don't support HTTPS reasonably don't have sensitive data in the first place (for interception or manipulation). All-in-all my point is that HTTPS is ONLY benficial when connecting to a previously known. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From ve7jtb@ve7jtb.com Wed Dec 5 09:46:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4C21F86AA for ; Wed, 5 Dec 2012 09:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIdmxZXkJcWb for ; Wed, 5 Dec 2012 09:46:26 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 689DB21F8554 for ; Wed, 5 Dec 2012 09:46:25 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5790305obc.31 for ; Wed, 05 Dec 2012 09:46:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=17jSsPT0xYY5k+YZcCLgXd+Yz5UC+n0b2+aD13SM09A=; b=HAp+Coxz2S29Z3CXhAbtv1jLYPrmvO7k8lvzlyk6X99ugUOu11hMea7p+WaLTFmQGs DeEao07D/GHjL7CFaTXdTieVqWZrFtzYWtQNNCZHep5W5eUlAKzbWXByilE9Z69fUnqL uYHoTZHcHHfzuPPr/DmjpxyHbGemh0qI6ipHCegrn9oCRRnBhudjwAkhMLIPSYc3Ij8d FhiufmjFdDxpgzckVjsupBVMKNQuPf1eaXPujEzeS6pWaPkw5+pbeleHVx0sa9NI/ed7 erAm87tDs+CMQl7E00m7AK1/7x6zjZOHGN4n5pXhu6VjcmW2Wm039MkrbidtVIQ2wzux 8upg== Received: by 10.182.64.14 with SMTP id k14mr11088641obs.72.1354729570457; Wed, 05 Dec 2012 09:46:10 -0800 (PST) Received: from [192.168.1.211] (190-20-39-166.baf.movistar.cl. [190.20.39.166]) by mx.google.com with ESMTPS id ht7sm2777918obc.15.2012.12.05.09.46.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 09:46:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F79FC6E0-398C-4A4F-9BAE-3379E9C1797B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Wed, 5 Dec 2012 14:45:53 -0300 Message-Id: References: <50BF612D.3070001@ericsson.com> To: James M Snell X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmoKpXg1NqcNEUVu3jC1Tp+ssQPO+lyOXXy3oeHTZTaC9i/K3M7V68NIm3jqlH7teYpHrDJ Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:46:27 -0000 --Apple-Mail=_F79FC6E0-398C-4A4F-9BAE-3379E9C1797B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for 1 Http fallback increases client complexity. It also makes it hard for = upper level applications to know what is going on in the underlying WF = library. On 2012-12-05, at 2:04 PM, James M Snell wrote: >=20 > On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto = wrote: >=20 > During the last couple of weeks there has been a lot of mail = discussing whether > WebFinger MUST support HTTPS only or instead it should be allowed for = WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or = the other, > but also people that are more flexible and also having a preference = could live with the other. >=20 > However the discussion so far has not produced any clear consensus the = editor can include in the > next version of the wg draft. >=20 > So as chairs I want explicitly to check where the wg consensus is >=20 > 1) HTTPS only >=20 > versus >=20 > 2) HTTPS + HTTP but only as fallback >=20 > So please provide your preference and if you want also the reason why = you think WebFinger should > adopt that particular solution. >=20 >=20 > I'm +0 on both of these. There is a third option that I prefer.. >=20 > 3) HTTPS or HTTP... leave the decision up to the server and client = depending on their own specific needs. Servers can enforce the use of = https if that server deems it necessary. Likewise, clients can choose to = use https or http if it deems it necessary. > =20 > - James >=20 >=20 > This consensus call will run until December Thursday 13th, 2012 >=20 > best regards > Salvatore >=20 > --=20 > Salvatore Loreto, PhD > www.sloreto.com >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_F79FC6E0-398C-4A4F-9BAE-3379E9C1797B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1 for 1

Http fallback increases client complexity.    It also makes it hard for upper level applications to know what is going on in the underlying WF library.

On 2012-12-05, at 2:04 PM, James M Snell <jasnell@gmail.com> wrote:


On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

During the last couple of weeks there has been a lot of mail discussing whether
WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the other,
but also people that are more flexible and also having a preference could live with the other.

However the discussion so far has not produced any clear consensus the editor can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you think WebFinger should
adopt that particular solution.


I'm +0 on both of these. There is a third option that I prefer..

3) HTTPS or HTTP... leave the decision up to the server and client depending on their own specific needs. Servers can enforce the use of https if that server deems it necessary. Likewise, clients can choose to use https or http if it deems it necessary.
 
- James


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--Apple-Mail=_F79FC6E0-398C-4A4F-9BAE-3379E9C1797B-- From Michael.Jones@microsoft.com Wed Dec 5 10:05:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A421F8CDA for ; Wed, 5 Dec 2012 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.821 X-Spam-Level: X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJeAtUYfdvPQ for ; Wed, 5 Dec 2012 10:05:39 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FB21F8B9A for ; Wed, 5 Dec 2012 10:05:38 -0800 (PST) Received: from mail19-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 18:05:33 +0000 Received: from mail19-va3 (localhost [127.0.0.1]) by mail19-va3-R.bigfish.com (Postfix) with ESMTP id E8B4A1202D6; Wed, 5 Dec 2012 18:05:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371I542Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dh18602ehz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail19-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail19-va3 (localhost.localdomain [127.0.0.1]) by mail19-va3 (MessageSwitch) id 135473073212161_18457; Wed, 5 Dec 2012 18:05:32 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.248]) by mail19-va3.bigfish.com (Postfix) with ESMTP id F33204E0060; Wed, 5 Dec 2012 18:05:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 18:05:31 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 5 Dec 2012 18:05:30 +0000 From: Mike Jones To: Salvatore Loreto , "webfinger@ietf.org" Thread-Topic: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP Thread-Index: AQHN0vkXK5b60rwnHkGd4L6Y43lAepgKgCSA Date: Wed, 5 Dec 2012 18:05:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436691A405@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <50BF612D.3070001@ericsson.com> In-Reply-To: <50BF612D.3070001@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:05:40 -0000 1) HTTPS only It prevents the downgrade attacks that would otherwise certainly happen. -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Salvatore Loreto Sent: Wednesday, December 05, 2012 6:59 AM To: webfinger@ietf.org Cc: Murray S. Kucherawy Subject: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP During the last couple of weeks there has been a lot of mail discussing whe= ther WebFinger MUST support HTTPS only or instead it should be allowed for = WebFinger fallback from HTTPS to HTTP. There are people with a clear preference (sometime strong) one way or the o= ther, but also people that are more flexible and also having a preference c= ould live with the other. However the discussion so far has not produced any clear consensus the edit= or can include in the next version of the wg draft. So as chairs I want explicitly to check where the wg consensus is 1) HTTPS only versus 2) HTTPS + HTTP but only as fallback So please provide your preference and if you want also the reason why you t= hink WebFinger should adopt that particular solution. This consensus call will run until December Thursday 13th, 2012 best regards Salvatore --=20 Salvatore Loreto, PhD www.sloreto.com _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From barryleiba.mailing.lists@gmail.com Wed Dec 5 10:18:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A1321F8CCE for ; Wed, 5 Dec 2012 10:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.102 X-Spam-Level: X-Spam-Status: No, score=-103.102 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbOTJrj5mkNn for ; Wed, 5 Dec 2012 10:18:15 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86821F8CBD for ; Wed, 5 Dec 2012 10:18:14 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4705501lah.31 for ; Wed, 05 Dec 2012 10:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eq74nJ8tH1j2i/4Jt1nT1rxKD+EzMH0GJLvvAp+fwMM=; b=uC4TDluQUtsZkJMsXbAAYLcAonhWQvj7JjJ/SgH1qj5bdFzNcv07GjbAauVRsWLB4F L5HwL+bQqv+taY8ijXjOwlqFdMmU/R0fBfavOcoXiKKNX34Ie5l3okmqGLG/VFsBuNFy jPaJXGllk0eg5jKRmS3aGHxpzoTQPD6hJyx9RYWc5swhB4MfJATsvkKkb8O9FLwbqrk5 TLuNIy9z7WUTmTtpcqJtkr6lqp6fz76YezDZdOrwOQ3Gwd3onFCz9KtgdgI/FbUn6QGR yRLdr5dWF4RQ5yaegqswImZhWgTL+Xo3ySoA9H9EXZB0XPVrgUMrhLdMzmGSGEuIgIeC 6CxA== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr17620933lab.38.1354731493987; Wed, 05 Dec 2012 10:18:13 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Wed, 5 Dec 2012 10:18:13 -0800 (PST) In-Reply-To: <8ADA643B-3CC7-43A8-9E51-A49BA30063F5@ve7jtb.com> References: <8ADA643B-3CC7-43A8-9E51-A49BA30063F5@ve7jtb.com> Date: Wed, 5 Dec 2012 13:18:13 -0500 X-Google-Sender-Auth: UfzBacFIv-BHicUco5d2XEzYu-I Message-ID: From: Barry Leiba To: John Bradley , Brad Fitzpatrick Content-Type: text/plain; charset=ISO-8859-1 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] Draft -07 mod proposal: HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:18:16 -0000 Please remember to replace apps-discuss@ietf.org with webfinger@ietf.org if you continue this or other webfinger-related threads. Barry, App AD On Tue, Dec 4, 2012 at 2:43 PM, John Bradley wrote: > HSTS doesn't protect against a DNS attack before the client makes first > contact. It is intended to prevent leaking https: bound cookies after the > first contact. > I don't think it helps us in any way. An attacker would redirect the client > to the fake site without HSTS before it makes the WF request. > > The certificate verification re RFC6125 per OAuth and other specs still > needs to be added, rather than just implied. > > John B. > > On 2012-12-04, at 4:03 PM, Brad Fitzpatrick wrote: > > On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook wrote: >> >> and HTTPS-enabled servers SHOULD use HSTS to ensure that clients are not >> vulnerable to downgrade attacks. > > > HSTS is a huge hammer and very few sites are prepared to enable it. I don't > think it should be a SHOULD, especially because webfinger shares the same > domain as other things on that host, and WebFinger's use of HSTS would > influence other paths on that host. (yes, I already hear the arguments for > a webfinger subdomain coming back) > >> It's worth noting that DNS is still a huge security hole in all of this. I >> don't see Webfinger mandating the use of DNSSEC, nor the methods by which to >> verify certificates, so no-one should be under the illusion that mandating >> HTTPS is going to lead to "secure" implementations. > > > I believe verification of certs with root CAs was implicit. At least that's > what (almost?) all HTTP clients do by default anyway. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From evan@status.net Wed Dec 5 11:45:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8246D21F8CA1 for ; Wed, 5 Dec 2012 11:45:29 -0800 (PST) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JymbvGS77T8G for ; Wed, 5 Dec 2012 11:45:28 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id AF9C021F8C64 for ; Wed, 5 Dec 2012 11:45:28 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 8B2B08D4240 for ; Wed, 5 Dec 2012 19:57:49 +0000 (UTC) Message-ID: <50BFA457.1090101@status.net> Date: Wed, 05 Dec 2012 14:45:27 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <50BF612D.3070001@ericsson.com> In-Reply-To: <50BF612D.3070001@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:45:29 -0000 2) The attacks that have people concerned are only important for a certain class of applications, which can easily specify HTTPS-only separately. Explicitly supporting HTTP allows for experimentation and low-security applications. HTTPS can cause increased costs for small community and individual Web sites -- not only for the cert, but also for additional infrastructure. HTTPS is rarely supported for shared-hosting systems. As a Webfinger library developer for node.js, I appreciate the security concern and will be happy to include configuration flags to prevent fallback to HTTP if needed by the client. -Evan On 2012-12-05 09:58, Salvatore Loreto wrote: > > During the last couple of weeks there has been a lot of mail > discussing whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or > the other, > but also people that are more flexible and also having a preference > could live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why > you think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From evan@status.net Wed Dec 5 11:49:12 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5821F8C72 for ; Wed, 5 Dec 2012 11:49:12 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T2n4Abnv1cT for ; Wed, 5 Dec 2012 11:49:11 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32C21F8CBD for ; Wed, 5 Dec 2012 11:49:11 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 467498D4247 for ; Wed, 5 Dec 2012 20:01:32 +0000 (UTC) Message-ID: <50BFA536.5080507@status.net> Date: Wed, 05 Dec 2012 14:49:10 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> In-Reply-To: <50BFA457.1090101@status.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:49:13 -0000 I also think there's a logical inconsistency in the argument that a) nobody needs plain-old HTTP but b) if plain-old HTTP fallback is allowed, it will be so popular that high-security applications will have no choice but to use libraries that default to fallback. -Evan On 2012-12-05 14:45, Evan Prodromou wrote: > 2) > > The attacks that have people concerned are only important for a > certain class of applications, which can easily specify HTTPS-only > separately. > > Explicitly supporting HTTP allows for experimentation and low-security > applications. HTTPS can cause increased costs for small community and > individual Web sites -- not only for the cert, but also for additional > infrastructure. HTTPS is rarely supported for shared-hosting systems. > > As a Webfinger library developer for node.js, I appreciate the > security concern and will be happy to include configuration flags to > prevent fallback to HTTP if needed by the client. > > -Evan > > On 2012-12-05 09:58, Salvatore Loreto wrote: >> >> During the last couple of weeks there has been a lot of mail >> discussing whether >> WebFinger MUST support HTTPS only or instead it should be allowed for >> WebFinger >> fallback from HTTPS to HTTP. >> There are people with a clear preference (sometime strong) one way or >> the other, >> but also people that are more flexible and also having a preference >> could live with the other. >> >> However the discussion so far has not produced any clear consensus >> the editor can include in the >> next version of the wg draft. >> >> So as chairs I want explicitly to check where the wg consensus is >> >> 1) HTTPS only >> >> versus >> >> 2) HTTPS + HTTP but only as fallback >> >> So please provide your preference and if you want also the reason why >> you think WebFinger should >> adopt that particular solution. >> >> >> This consensus call will run until December Thursday 13th, 2012 >> >> best regards >> Salvatore >> > > -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From bradfitz@google.com Wed Dec 5 11:59:31 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52B621F8C7E for ; Wed, 5 Dec 2012 11:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfS133wsyYsI for ; Wed, 5 Dec 2012 11:59:31 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 056B721F8713 for ; Wed, 5 Dec 2012 11:59:17 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2486966wey.31 for ; Wed, 05 Dec 2012 11:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+hLRxufvBXDayrJeOGiKVPYmz9FScCMRsgqyPwYv0n4=; b=bzs2T1qcQ1c2/w/mnH1KPv2+GOu5W62Bs/dhlaIlyUg08xr4m9AR2Lf1bt3g2x96L4 R31HGlmXmtX4dbegKbnrC8mDGfMvJ0Y8/z90IkZn/lS+jUs/3uPqM47509X1fG4BjuEO ShDP8CHpv58DwFWWzz4lb61rc9uDlQNHtUCHjgD7mzpuboQ8QcOo4urDzEeNdzK90WO5 9pL9MQweScmmFNAjkssp3d30TJ6XNF6sEWfzz+MGWbpD37yONtIgaDpzrl+wHjO6Obl8 RmLXPFRdBmRUA573zZGzvAeuZluctiMK5U3C922h137iCMr7d7yvFC40X1eMzSiOmZVC yb5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+hLRxufvBXDayrJeOGiKVPYmz9FScCMRsgqyPwYv0n4=; b=krajdu7gvDpYGmRGPwZlhRTHEL68Vr31jHrD5gkTkIj9ZTXbOgKEZ/NSqpIbv1F2j4 LJO8ipz8yagw0TChFkrj7SEFZj5nn9csSwcoLVy9OqtdFUxyjTv5Jt8ruFRmFXm46clu LEErBCWPn0We3Zye5x7WmHONJrncVg/j9lTVAIslhyRGqnm6V2BP+aYmHpP5segmh3lU QU/l7t6hqJhc+A5CCErRZGIbJFs06yaweREHlEfWhMAGP9Ae6I4Ih7ZYRga5RjjHz/8b dCn17XzixS2gwMAQTIcec1IWJ91tjCUXP9d82KN2b4IkAC1C1pUvhtYdn6Yyu3aHY8U5 6DWw== MIME-Version: 1.0 Received: by 10.180.92.132 with SMTP id cm4mr5172152wib.12.1354737557106; Wed, 05 Dec 2012 11:59:17 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 11:59:16 -0800 (PST) In-Reply-To: <50BFA536.5080507@status.net> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> Date: Wed, 5 Dec 2012 11:59:16 -0800 Message-ID: From: Brad Fitzpatrick To: Evan Prodromou Content-Type: multipart/alternative; boundary=f46d043be1f4daf04404d0206a34 X-Gm-Message-State: ALoCoQlBMjRE+TekBFrvby6baGRAlt/QG16SAyjxqZzkGazhKKTL6OsoGYV/VfKJz91vgUl9oSVRcAKMZWhozto7YLNETa8CXYR9heCCqYn7LC15X3DwiOAX5RQCe+bRJtI2liZhrEcHWbdufth0iJhP07eClX/48QStDNKZEIwEh5eS/h5eWjm4om8iOfdf9p+3EMtHuyOl Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:59:32 -0000 --f46d043be1f4daf04404d0206a34 Content-Type: text/plain; charset=UTF-8 I don't believe that's the security argument. I understand it more as: If we mandate complexity (in the spec), we will get complexity (in clients, per the spec), and in complexity lies security problems (clients not having HTTPS-only modes). Whereas if we say "HTTPS-only" in the spec, it will lead to simpler clients lacking options which are then secure-by-default. On Wed, Dec 5, 2012 at 11:49 AM, Evan Prodromou wrote: > I also think there's a logical inconsistency in the argument that a) > nobody needs plain-old HTTP but b) if plain-old HTTP fallback is allowed, > it will be so popular that high-security applications will have no choice > but to use libraries that default to fallback. > > -Evan > > > On 2012-12-05 14:45, Evan Prodromou wrote: > >> 2) >> >> The attacks that have people concerned are only important for a certain >> class of applications, which can easily specify HTTPS-only separately. >> >> Explicitly supporting HTTP allows for experimentation and low-security >> applications. HTTPS can cause increased costs for small community and >> individual Web sites -- not only for the cert, but also for additional >> infrastructure. HTTPS is rarely supported for shared-hosting systems. >> >> As a Webfinger library developer for node.js, I appreciate the security >> concern and will be happy to include configuration flags to prevent >> fallback to HTTP if needed by the client. >> >> -Evan >> >> On 2012-12-05 09:58, Salvatore Loreto wrote: >> >>> >>> During the last couple of weeks there has been a lot of mail discussing >>> whether >>> WebFinger MUST support HTTPS only or instead it should be allowed for >>> WebFinger >>> fallback from HTTPS to HTTP. >>> There are people with a clear preference (sometime strong) one way or >>> the other, >>> but also people that are more flexible and also having a preference >>> could live with the other. >>> >>> However the discussion so far has not produced any clear consensus the >>> editor can include in the >>> next version of the wg draft. >>> >>> So as chairs I want explicitly to check where the wg consensus is >>> >>> 1) HTTPS only >>> >>> versus >>> >>> 2) HTTPS + HTTP but only as fallback >>> >>> So please provide your preference and if you want also the reason why >>> you think WebFinger should >>> adopt that particular solution. >>> >>> >>> This consensus call will run until December Thursday 13th, 2012 >>> >>> best regards >>> Salvatore >>> >>> >> >> > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --f46d043be1f4daf04404d0206a34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= don't believe that's the security argument.

I u= nderstand it more as: =C2=A0If we mandate complexity (in the spec), we will= get complexity (in clients, per the spec), and in complexity lies security= problems (clients not having HTTPS-only modes).

Whereas if we say "HTTPS-only" in the spec, i= t will lead to simpler clients lacking options which are then secure-by-def= ault.


On Wed, Dec 5= , 2012 at 11:49 AM, Evan Prodromou <evan@status.net> wrote:
I also think there's a logical inconsist= ency in the argument that a) nobody needs plain-old HTTP but b) if plain-ol= d HTTP fallback is allowed, it will be so popular that high-security applic= ations will have no choice but to use libraries that default to fallback.

-Evan


On 2012-12-05 14:45, Evan Prodromou wrote:
2)

The attacks that have people concerned are only important for a certain cla= ss of applications, which can easily specify HTTPS-only separately.

Explicitly supporting HTTP allows for experimentation and low-security appl= ications. HTTPS can cause increased costs for small community and individua= l Web sites -- not only for the cert, but also for additional infrastructur= e. HTTPS is rarely supported for shared-hosting systems.

As a Webfinger library developer for node.js, I appreciate the security con= cern and will be happy to include configuration flags to prevent fallback t= o HTTP if needed by the client.

-Evan

On 2012-12-05 09:58, Salvatore Loreto wrote:

During the last couple of weeks there has been a lot of mail discussing whe= ther
WebFinger MUST support HTTPS only or instead it should be allowed for WebFi= nger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the o= ther,
but also people that are more flexible and also having a preference could l= ive with the other.

However the discussion so far has not produced any clear consensus the edit= or can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you t= hink WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore





--
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net= P: +1-514-554-3826

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--f46d043be1f4daf04404d0206a34-- From jpanzer@google.com Wed Dec 5 13:30:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4774621F8C5C for ; Wed, 5 Dec 2012 13:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.785 X-Spam-Level: X-Spam-Status: No, score=-101.785 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8+Y2p2M-5mW for ; Wed, 5 Dec 2012 13:30:01 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2B0921F8B9E for ; Wed, 5 Dec 2012 13:30:00 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4998469lbk.31 for ; Wed, 05 Dec 2012 13:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eo7PYLtY/QXpUBDllevWwMvcJeRpFeyvVc/5v5un1rQ=; b=J2wUeSf9mShS1rEsIu6hCBPq6rV/oMNfRxLZLKxG+CTF+7fufJ4KbpB26dY8yzABXH pZH5aEITQK6vX4rd6wPOrXaJhmh06ZhUnJioi9AUtU6XfSpkShc6hcG0kiGTfPJx9rL0 hQwiNpszqAjo0OK1pA+mAVFTXPKVYe7D6s1kjshi7EGNZoVpQSZ+h/84jABRhr04LVLU v0EJUsqWgonOBX8DF3cxhHSPsett255CQ6DaljjZksu0jzAATMxImL7mjz/lszJnkgsR Rv4Ew7FD/vkJ42/sfnO7eXxKNytbaMSyjC20/rQ2y7MbWyrEvhkfxY7fl6PkTrUetDPC grXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=eo7PYLtY/QXpUBDllevWwMvcJeRpFeyvVc/5v5un1rQ=; b=LPgsoVKeuKIwy9u6+RFgiZspHNAWY0317W1e8u4HzOzA2kdBz5Gvaal4gTE3jplgOm EG1UnCWjlZiK/c/s3rhR3LT48ZptGi+ncMAH++JYln+Qq3tUCKnzfh9RLQbWChzxQCnE ny8OuucePDFX0Vj7lDZsAyLogZfcRW9Q3GvR0ahwvOICoTtEfbttbynx+D5/1OBPquq/ YlLRKms5rS8U9wJxiBIP7GUgOmqcHAa7KhcozhijhKk2ZYiUNvkbcUYTzah69Ri1+p0N 0w64m8MBg6Zu70b/F0fpW7B3zFUAeu2Kgf/kRfAWpvzXApO//x6/WHMJgiZA1whzYr1M 8ahQ== Received: by 10.112.45.232 with SMTP id q8mr3224908lbm.23.1354742999639; Wed, 05 Dec 2012 13:29:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.29.161 with HTTP; Wed, 5 Dec 2012 13:29:39 -0800 (PST) In-Reply-To: <50BF612D.3070001@ericsson.com> References: <50BF612D.3070001@ericsson.com> From: John Panzer Date: Wed, 5 Dec 2012 13:29:39 -0800 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=bcaec554dd9c4166df04d021af96 X-Gm-Message-State: ALoCoQkvnydjrxJCnOkZ5uKZBlxtssWh4ACa50mEZkw5W53TrTyVpGFTw1nFkVPRuSEOy+gttKlv0Sncy8b6FwJjMIt0mrK0alrOoGVNnvqNFEC8Fwf9MMW6Kcs1sSeiBMM6xTEvA8Bz46lX/F0NkrB+Hcbmewnlw4FNjFuYFTYOHaejUpyxtWafG2yLko9VPd2byQxJcmdT Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:30:05 -0000 --bcaec554dd9c4166df04d021af96 Content-Type: text/plain; charset=ISO-8859-1 +1 on #1 -1 on #2 On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > During the last couple of weeks there has been a lot of mail discussing > whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or the > other, > but also people that are more flexible and also having a preference could > live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why you > think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > > -- > Salvatore Loreto, PhD > www.sloreto.com > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --bcaec554dd9c4166df04d021af96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 on = #1

-1 on #2

On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto = <salv= atore.loreto@ericsson.com> wrote:

During the last couple of weeks there has been a lot of mail discussing whe= ther
WebFinger MUST support HTTPS only or instead it should be allowed for WebFi= nger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the o= ther,
but also people that are more flexible and also having a preference could l= ive with the other.

However the discussion so far has not produced any clear consensus the edit= or can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you t= hink WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--bcaec554dd9c4166df04d021af96-- From mmn@hethane.se Wed Dec 5 15:02:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205B521F8CA4 for ; Wed, 5 Dec 2012 15:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp1Oy0Ot4svG for ; Wed, 5 Dec 2012 15:02:58 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6F21F8C11 for ; Wed, 5 Dec 2012 15:02:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2012 00:02:53 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> Message-ID: <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:02:59 -0000 05.12.2012 20:59 skrev Brad Fitzpatrick: > Whereas if we say "HTTPS-only" in the spec, it will lead to simpler > clients > lacking options which are then secure-by-default. Except that the clients are _not_ secure just because they use HTTPS. Especially if they're of the "simpler" kind. Anyone supporting the HTTPS-only alternative because it's "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user would be able to serve any data at all to the majority of WF clients "secure-by-default", if they do not have the CAcert root certificate installed. Are the posters here supporting https-only of the opinion that any non-verifiable HTTPS connection should ABORT and return an error?! Then what should my clients do, that don't have have any Verisign, GoDaddy or Comodo certificates to validate against? The "complexity" problem that some say arises is easily solved in libraries by serving metadata in returned objects with some kind of "verified"/"secure" flag that is either true or false. Something which should be part of best practice response handling anyway (certificate/validity assertion). So if we were to suddenly ignore unverifiable certificate signatures, there's no reason to use HTTPS at all. It's better to let the server decide whether to allow non-HTTPS connections for its specific data - and have the client _prefer_ HTTPS and allow use of HTTP for non-sensitive data. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From bradfitz@google.com Wed Dec 5 15:12:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4B621F8B2A for ; Wed, 5 Dec 2012 15:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItrileADOeZW for ; Wed, 5 Dec 2012 15:12:16 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id ED2E921F8AD9 for ; Wed, 5 Dec 2012 15:12:15 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2480537wgb.13 for ; Wed, 05 Dec 2012 15:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MlimRYCeyijq4mYwWIH+l8Mb/HLuR6QeE7t0kllGVyE=; b=VH2XjFDPDG/rto4nt2mQc5fie1SburliskuHjC1Qf6Xxjwp808cY+th+ETSzUMl8ET wMlXy9GCoZPOhozGg/X+NieufCVFGgGfNH28V7qXp0Zw9x74UZQG1qy5zjE9GBZY4QNa VFZpuec3KAUcBr2YOTozvsFVJFqf3at5gSnfe6ELTCAHPgtWgOrsF3cSlhHZzzhRdQOm SaBmXq5yFQx0Wu697W3uPsUq3SY09FHTrLjk2Y1FIefwWYHGM+ZAUP9HxsPk4BIwiAce +Yt96FirPtwn3rh64TtaP+Mkn3czO2JTHsNVNa1nVBO3Pkrk7T+y4/MEmJ9s5mi9EOzF lSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MlimRYCeyijq4mYwWIH+l8Mb/HLuR6QeE7t0kllGVyE=; b=OYvvajfjUjdQLSCH6e6cNu/qHNbokzZUemTKKQ8j7vWO9vPFgi5tqsjcjcBhlf2+bp mBmbJrftQCBAHBlSbFc+CKEj0CP0xjmV4+DBhjEmnwy2qXtcaZUXNDRw2rA23Jy2ZWkz Sy+eNTfFxnu0FAGeB+MYCaxAsPFgN7Q9tKJWwylc1QuNL2VwUQiwpwCXdPUVkodsA/4F jxc4uIRL16olH4uQ/YzO3hvGRhjWmJe+ykxa+mJU8bv9MoDV5dvNJUfDL9hjOwIoH7fg gNiar21mHxY0LtXg+I8rQT5M4pz1ieaqLFs1eCizGAZhy57WuTcY0aNlZI1YharbH0cD RENg== MIME-Version: 1.0 Received: by 10.216.150.209 with SMTP id z59mr6778294wej.106.1354749134768; Wed, 05 Dec 2012 15:12:14 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 15:12:14 -0800 (PST) In-Reply-To: <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Date: Wed, 5 Dec 2012 15:12:14 -0800 Message-ID: From: Brad Fitzpatrick To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=0016e6d7e95ef009f104d0231cc7 X-Gm-Message-State: ALoCoQmq0NM4GjjTAVFEABmq/XJphmyrJjvn7gqriH7AZCmYpdCLS51Z/tJyoIjmjA2d68E14QFCyKY+j7Qhd5rKzGnlsX90xJMZ2aedMpVy4MaguJBhTxgjueGI+uFMHFtRXV03geX/fR0NcQhqQ7uLI7ejaXHRPpo1farfoFwO1XF5dNjA9UCR01Wc9HxozgkgiXmmQigg Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:12:17 -0000 --0016e6d7e95ef009f104d0231cc7 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 3:02 PM, Mikael Nordfeldth wrote: > 05.12.2012 20:59 skrev Brad Fitzpatrick: > > Whereas if we say "HTTPS-only" in the spec, it will lead to simpler >> clients >> lacking options which are then secure-by-default. >> > > Except that the clients are _not_ secure just because they use HTTPS. > Especially if they're of the "simpler" kind. > > Anyone supporting the HTTPS-only alternative because it's > "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user > would be able to serve any data at all to the majority of WF clients > "secure-by-default", if they do not have the CAcert root certificate > installed. > They wouldn't. Your clients would need to trust CAcert.org. It's obvious that you don't like the Root CAs, and you're not alone. Nobody loves the current situation, but they're basically all we've got right now, considering the continuing sorry state of DNS. > Are the posters here supporting https-only of the opinion that any > non-verifiable HTTPS connection should ABORT and return an error?! Yes. > Then what should my clients do, that don't have have any Verisign, GoDaddy > or Comodo certificates to validate against? > What do your HTTPS clients currently do? --0016e6d7e95ef009f104d0231cc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 5, 2012 at 3:02 PM, Mikael Nordfeldth <mmn@hethane.se> wrote:
05.12.2012 20:59 = skrev Brad Fitzpatrick:

Whereas if we say "HTTPS-only" in the spec, it will lead to simpl= er clients
lacking options which are then secure-by-default.

Except that the clients are _not_ secure just because they use HTTPS. Espec= ially if they're of the "simpler" kind.

Anyone supporting the HTTPS-only alternative because it's "secure-= by-default" or similar, PLEASE explain how I as a CAcert.org user woul= d be able to serve any data at all to the majority of WF clients "secu= re-by-default", if they do not have the CAcert root certificate instal= led.

They wouldn't. Your clients would need= to trust CAcert.org.

It's obvious that you do= n't like the Root CAs, and you're not alone. Nobody loves the curre= nt situation, but they're basically all we've got right now, consid= ering the continuing sorry state of DNS.
=C2=A0
Are the posters here suppor= ting https-only of the opinion that any non-verifiable HTTPS connection sho= uld ABORT and return an error?!

Yes.
=C2=A0
Then what should my clients do, that don't have have any Verisign, G= oDaddy or Comodo certificates to validate against?

What do your HTTPS clients currently do?

--0016e6d7e95ef009f104d0231cc7-- From mmn@hethane.se Wed Dec 5 15:48:08 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4721F8C57 for ; Wed, 5 Dec 2012 15:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZNhcM6cWkkx for ; Wed, 5 Dec 2012 15:48:07 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9C521F8C51 for ; Wed, 5 Dec 2012 15:48:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2012 00:48:04 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Message-ID: X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:48:08 -0000 06.12.2012 00:12 skrev Brad Fitzpatrick: >> Anyone supporting the HTTPS-only alternative because it's >> "secure-by-default" or similar, PLEASE explain how I as a CAcert.org >> user >> would be able to serve any data at all to the majority of WF clients >> "secure-by-default", if they do not have the CAcert root certificate >> installed. >> > > They wouldn't. Your clients would need to trust CAcert.org. So it can also be referred to as the alternative effectively cutting off the majority of the internet from using Webfinger properly? How's that for hindering adoption. We might as well get XRD back in the game or require that only mobile devices produced by fruit-named IT companies may use the Webfinger protocol according the specification. > It's obvious that you don't like the Root CAs, and you're not alone. > Nobody > loves the current situation, but they're basically all we've got > right now, > considering the continuing sorry state of DNS. So why would we go further down the rabbit hole? HTTP Webfinger requests may be fully verifiable via simple methods like GPG signatures or any other arbitrary out-of-band communication that users can apply if they can't rely on HTTPS automation. Avoiding the issue of HTTPS/CA design vulnerabilities and restricting alternative uses only worsens the situation and does not provide any additional security. >> Then what should my clients do, that don't have have any Verisign, >> GoDaddy >> or Comodo certificates to validate against? >> > > What do your HTTPS clients currently do? They're StatusNet RFC 6415 clients/servers that work more along the lines of a TOFU/POP style of verification ("Trust On First Use/Persistence of Pseudonym"). And a somewhat basic user interaction to verify the data on first retrieval (accepting subscription). -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From bradfitz@google.com Wed Dec 5 16:04:50 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9421F8CA4 for ; Wed, 5 Dec 2012 16:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRwBDl63JLt4 for ; Wed, 5 Dec 2012 16:04:49 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id C136921F8CA0 for ; Wed, 5 Dec 2012 16:04:48 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2496245wgb.13 for ; Wed, 05 Dec 2012 16:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hIeDibvL9rwGrwGZPh72vBgNttX1YHh2yoIlJ/k9tgQ=; b=px4IiA6m+n/ItEOOH8AQ3SoUMFMo+qg7VKKq9Kh0eJIu8erFc6hQFg69HCtUbvK4W3 KfcZLCUm7IhwNl8kIvmhdjVDcOQwvn7ahDCr+mdFaTDjuSaWKQF+yaps02tvlFNQJDZs S+blKyftDO7jn6WvT111f3oF0F5q4Iufao0l0QtpljOpsXXODCYr23pJTxzOewNOgA5c 25ESXyWUmJlfYFVewDXu8salL7Mupm3M9fSgS0S4S3FBaKhHZC9Ec3xbtsPNhftlp0/z dbpfgeqUmp+XylCV2Bq762MZQjsJxnQf2Xb/9zXQfyM77HUGyitbH1DV+/PFsa2v1ShX uywQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hIeDibvL9rwGrwGZPh72vBgNttX1YHh2yoIlJ/k9tgQ=; b=NjkPbtPc4iBiJh1ZR3lqRst+G63+kRBfIF/DDxdsKF8kQc460mtKxwwHR1gDYD5zrs qxoY7XEkAB728WBjeuUDnPafbZcBwY8HNxZmVyQPkBauvKj/g+aF0jr63n6uep2BchHX D4Arvb1qlDkvdApaUDuTZF9nZ8gLCCrAgLxvzzjxsEsG42a7/hflcQWGdg5WdhmoOgTD AEpWibrWM6U3ZugTkdzDw9roDU8GIBK1hgomRhDpnyAhwlMZ7znDSnUnSJKLjvzVewNG 8sfWtHM14k0+16EtlMPTTtLmCjCj1dJ9+oAChD1jMi2igTW3acYIIgMbew45bIomaZSa EptQ== MIME-Version: 1.0 Received: by 10.180.85.194 with SMTP id j2mr6042558wiz.12.1354752287852; Wed, 05 Dec 2012 16:04:47 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 16:04:47 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Date: Wed, 5 Dec 2012 16:04:47 -0800 Message-ID: From: Brad Fitzpatrick To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=f46d0444ef31e0471904d023d8bd X-Gm-Message-State: ALoCoQkw5iNLaxEzdlOQCMrBnlm2WNC658xU0ar17ApgrLacya/JsyuivbHipGV1rTYEDmDil3WVOAzzB9Tq6bm86M1jKR5JSpP1azmdly26hSdEKVRmBl900JZb0lLkSWV0br1SSHYXe4/8qZgzx/bw5N/BpbCS5tH4dnf/DFOQW4WvWkx9+Sj/3OUpqAf3XvotGYhC41yz Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:04:50 -0000 --f46d0444ef31e0471904d023d8bd Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 3:48 PM, Mikael Nordfeldth wrote: > 06.12.2012 00:12 skrev Brad Fitzpatrick: > > Anyone supporting the HTTPS-only alternative because it's >>> "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user >>> would be able to serve any data at all to the majority of WF clients >>> "secure-by-default", if they do not have the CAcert root certificate >>> installed. >>> >>> >> They wouldn't. Your clients would need to trust CAcert.org. >> > > So it can also be referred to as the alternative effectively cutting off > the majority of the internet from using Webfinger properly? How's that for > hindering adoption. We might as well get XRD back in the game or require > that only mobile devices produced by fruit-named IT companies may use the > Webfinger protocol according the specification. > > > It's obvious that you don't like the Root CAs, and you're not alone. >> Nobody >> loves the current situation, but they're basically all we've got right >> now, >> considering the continuing sorry state of DNS. >> > > So why would we go further down the rabbit hole? HTTP Webfinger requests > may be fully verifiable via simple methods like GPG signatures or any other > arbitrary out-of-band communication that users can apply if they can't rely > on HTTPS automation. > > Avoiding the issue of HTTPS/CA design vulnerabilities and restricting > alternative uses only worsens the situation and does not provide any > additional security. > > > Then what should my clients do, that don't have have any Verisign, GoDaddy >>> or Comodo certificates to validate against? >>> >>> >> What do your HTTPS clients currently do? >> > > They're StatusNet RFC 6415 clients/servers that work more along the lines > of a TOFU/POP style of verification ("Trust On First Use/Persistence of > Pseudonym"). And a somewhat basic user interaction to verify the data on > first retrieval (accepting subscription). Well, actually, the latest draft didn't specify which Root CAs were consulted. It just says to verify the certs. Perhaps an HTTPS-only+TOFU WebFinger client is a conforming client. I agree that many things are still possible to do securely over HTTP if you have signing or content-addressability + security elsewhere. The concern is that those are all very dorky, theoretical, and seldom-used, and mandating them would be complicate the spec. Not specifying HTTPS-only leaves a lot of people uncomfortable about not knowing how clients (clients not under their control) will be implemented. Nothing's perfect... it's always about making trade-offs. I'm thinking HTTPS-only is a trade-off, but the one that best maximizes applicability, simplicity and security, while not grossly harming any of those three. At the end of the day I've voting +1 for HTTPS-only out of simplicity: one request for clients. I don't personally own stock in any Root CA company, and I'm not a fan of the cert system, but it's better than HTTP to on top of. --f46d0444ef31e0471904d023d8bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Wed, Dec 5, 2012 at 3:48 PM, Mikael No= rdfeldth <mmn@hethane.se> wrote:
06.12.2012 00:12 skrev Brad Fitzpatrick:
Anyone supporting the HTTPS-only alternative because it's
"secure-by-default" or similar, PLEASE explain how I as a CAcert.= org user
would be able to serve any data at all to the majority of WF clients
"secure-by-default", if they do not have the CAcert root certific= ate
installed.


They wouldn't. Your clients would need to trust CAcert.org.

So it can also be referred to as the alternative effectively cutting off th= e majority of the internet from using Webfinger properly? How's that fo= r hindering adoption. We might as well get XRD back in the game or require = that only mobile devices produced by fruit-named IT companies may use the W= ebfinger protocol according the specification.


It's obvious that you don't like the Root CAs, and you're not a= lone. Nobody
loves the current situation, but they're basically all we've got ri= ght now,
considering the continuing sorry state of DNS.

So why would we go further down the rabbit hole? HTTP Webfinger requests ma= y be fully verifiable via simple methods like GPG signatures or any other a= rbitrary out-of-band communication that users can apply if they can't r= ely on HTTPS automation.

Avoiding the issue of HTTPS/CA design vulnerabilities and restricting alter= native uses only worsens the situation and does not provide any additional = security.


Then what should my clients do, that don't have have any Verisign, GoDa= ddy
or Comodo certificates to validate against?


What do your HTTPS clients currently do?

They're StatusNet RFC 6415 clients/servers that work more along the lin= es of a TOFU/POP style of verification ("Trust On First Use/Persistenc= e of Pseudonym"). And a somewhat basic user interaction to verify the = data on first retrieval (accepting subscription).

Well, actually, the latest draft didn't specify whi= ch Root CAs were consulted. It just says to verify the certs. Perhaps an HT= TPS-only+TOFU WebFinger client is a conforming client.

I agree that many things are still possible to do securely over HTTP i= f you have signing or content-addressability + security elsewhere. =C2=A0Th= e concern is that those are all very dorky, theoretical, and seldom-used, a= nd mandating them would be complicate the spec. =C2=A0Not specifying HTTPS-= only leaves a lot of people uncomfortable about not knowing how clients (cl= ients not under their control) will be implemented.

Nothing's perfect... it's always about making t= rade-offs. =C2=A0I'm thinking HTTPS-only is a trade-off, but the one th= at best maximizes applicability, simplicity and security, while not grossly= harming any of those three.

At the end of the day I've voting +1 for HTTPS-only= out of simplicity: one request for clients. =C2=A0I don't personally o= wn stock in any Root CA company, and I'm not a fan of the cert system, = but it's better than HTTP to on top of.
--f46d0444ef31e0471904d023d8bd-- From ve7jtb@ve7jtb.com Wed Dec 5 16:05:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6326621F8CA4 for ; Wed, 5 Dec 2012 16:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuzOOMOWG9v4 for ; Wed, 5 Dec 2012 16:05:44 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9287621F87FF for ; Wed, 5 Dec 2012 16:05:44 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so6207518obc.31 for ; Wed, 05 Dec 2012 16:05:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=o/eyQr3YBtWqaq8Z9pGPcjc3FEKiI19q16DknjLG+6o=; b=ozRgLzqTeuk8wlJ8BZKIwfHv62NkvSZ74hzLms7pxoI3+OAr/BGoP2/rkZdC+h6LhZ gU110Rbehi8ylxxWZ9MXCdux5CVzT3cMmWplbxEPPtjMoDQ/zSsqcPSczbLkZ/GLqp6b fG8Q4kvsIFYDaNayYuoEcLb8JocUPmm3Htk8Z7RLRHuHiEZzHS49Sxj3AnYx9etm1paT bwDy0SFQ04L+OlJYF0N7kI3iCgBQTrNBCV3VN+FZLt6lnWZnYzebPjjotzursAD/wVsp ovf8EUC0iBCTZ6VUg59A2N/7WuS/e0hUKqnEE0joWX3nIxNugXh7S6p6nykuqYePvWHA 5M7Q== Received: by 10.60.4.165 with SMTP id l5mr9588787oel.84.1354752343886; Wed, 05 Dec 2012 16:05:43 -0800 (PST) Received: from [192.168.1.211] (190-20-17-163.baf.movistar.cl. [190.20.17.163]) by mx.google.com with ESMTPS id d17sm3273715obu.0.2012.12.05.16.05.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 16:05:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Date: Wed, 5 Dec 2012 21:05:24 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3EB55C23-1C36-4462-8EF0-AD61FA05B6F3@ve7jtb.com> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> To: Mikael Nordfeldth X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlZ/5ikWHANasjBxnokPM/iEfo7qNRRVGS4k/5JCDpdXL9oz99IgMIutXDg2OxfoQ0619nW Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:05:45 -0000 Yes that is exactly what we are proposing. A client that cannot verify = the cert from the WF server should abort. The use of TLS is mostly to prevent DNS attacks where a client would be = tricked into accessing a fake WF server controlled by an attacker, the = transport integrity/encryption is a secondary benefit. A self signed cert provides no protection for DNS, so is not = appropriate, unless the client has the vert configured through some out = of band method. I understand this is not the answer you and others want. My concern about fallback is that it will be inconsistently interpreted = by libraries so common shared libraries are going to be more of a = challenge, especially if the spec is precluded from talking about = anything other than the wire format. John B. On 2012-12-05, at 8:02 PM, Mikael Nordfeldth wrote: > 05.12.2012 20:59 skrev Brad Fitzpatrick: >> Whereas if we say "HTTPS-only" in the spec, it will lead to simpler = clients >> lacking options which are then secure-by-default. >=20 > Except that the clients are _not_ secure just because they use HTTPS. = Especially if they're of the "simpler" kind. >=20 > Anyone supporting the HTTPS-only alternative because it's = "secure-by-default" or similar, PLEASE explain how I as a CAcert.org = user would be able to serve any data at all to the majority of WF = clients "secure-by-default", if they do not have the CAcert root = certificate installed. >=20 > Are the posters here supporting https-only of the opinion that any = non-verifiable HTTPS connection should ABORT and return an error?! Then = what should my clients do, that don't have have any Verisign, GoDaddy or = Comodo certificates to validate against? >=20 >=20 > The "complexity" problem that some say arises is easily solved in = libraries by serving metadata in returned objects with some kind of = "verified"/"secure" flag that is either true or false. Something which = should be part of best practice response handling anyway = (certificate/validity assertion). >=20 >=20 > So if we were to suddenly ignore unverifiable certificate signatures, = there's no reason to use HTTPS at all. It's better to let the server = decide whether to allow non-HTTPS connections for its specific data - = and have the client _prefer_ HTTPS and allow use of HTTP for = non-sensitive data. >=20 > --=20 > Mikael Nordfeldth > http://blog.mmn-o.se/ > mmn@hethane.se > +46705657637 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From bradfitz@google.com Wed Dec 5 16:07:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E97C21F8CDE for ; Wed, 5 Dec 2012 16:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BizjHdsU57AW for ; Wed, 5 Dec 2012 16:07:39 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D65E121F8CDF for ; Wed, 5 Dec 2012 16:07:38 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2577556wey.31 for ; Wed, 05 Dec 2012 16:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/A/j6RW6l1shlaRBcZcH+ZZaapuFiM218RNKER11Hy8=; b=fqKKBVPgAyoSUDm6gH1z8EUEMeEU3zvjlWm8MMDTknJiQJpnN8Lnr4BofIQarqe9sA j8pJSqjpMYLu4lAX5T7svBqGNY/PC2qXlq79zmDKJvrxlmQgd17hJm6wJgYFtx0MfmEH x24kgxDvC3kUraWrTo181e16jtuawJdyTn60bTwG9HbmJYgwmwJC2VaD0n5WrM6lFTJm QeooR+ZeL5IaYa284+uI/yCiri9yN/az5zX6ed/rN6W3rKcOgPgqUFttoKADes889ibl QVPuTM8S420KHNqz7PDSNoxpGlshj6XXgnKLPK8gbqYwK8saW5NzykrzgHjgKTAbaWFl vZIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/A/j6RW6l1shlaRBcZcH+ZZaapuFiM218RNKER11Hy8=; b=MLCxtcoubl6FVWRzNFgKLCyJpoVfLPPicQbkh0IlRRZWxPXSbnfy3PEL4yo9qHEDCX FVaAcblY1e4vN4zS/ApJppSC/V68d8UgU3jFF7AhW75l2hekrjfV30aHfgtXMEEVn3N+ 3hFrB66gxWhnHOgeyfEDyH9ac3ru1Ng2ZyvntkD+wRjThNG0FgMm9RRdGp08CnsUNaa/ ICAXPVjv8QxgbFVncuBV7iL58PADjd0m5crfidFTHkjyQB30bGea6mbNVLl/m4AdUj4C qDGfyH3vYeJ+dfXUlFFiRIhPApai12Yerrsoq70iTw8NobOlHbPuiuOzS3SDKdt/Y2XE PhlA== MIME-Version: 1.0 Received: by 10.180.87.39 with SMTP id u7mr6058612wiz.6.1354752457985; Wed, 05 Dec 2012 16:07:37 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 16:07:37 -0800 (PST) In-Reply-To: <50BF612D.3070001@ericsson.com> References: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 16:07:37 -0800 Message-ID: From: Brad Fitzpatrick To: Salvatore Loreto Content-Type: multipart/alternative; boundary=f46d044280f8044cfd04d023e36c X-Gm-Message-State: ALoCoQlDhERBUENLpsRFr6n+kZm9K2IqXM5KkLxvSRQ0+ZWBqkKfYqKMf1Z6T7vTFOmy3+XCs2AIJVS4g+bgMK/diyj6UFxumIUjDN2ljFJfPgWVuYZI+5n8yzX61YWnYWggxeLaifGcUgUjEBvEErnqXWhHKXmAAuZPUTE/yuR77ix2NCGfS+OJ4U7DBARbh3oHNQ3xVJvW Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:07:40 -0000 --f46d044280f8044cfd04d023e36c Content-Type: text/plain; charset=UTF-8 +1 to #1 (HTTPS-only) It keeps clients simpler (just one HTTP request), and provides better security than none (even if it's not ideal). On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > During the last couple of weeks there has been a lot of mail discussing > whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or the > other, > but also people that are more flexible and also having a preference could > live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why you > think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > > -- > Salvatore Loreto, PhD > www.sloreto.com > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --f46d044280f8044cfd04d023e36c Content-Type: text/html; charset=UTF-8
+1 to #1 (HTTPS-only)

It keeps clients simpler (just one HTTP request), and provides better security than none (even if it's not ideal).


On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

During the last couple of weeks there has been a lot of mail discussing whether
WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the other,
but also people that are more flexible and also having a preference could live with the other.

However the discussion so far has not produced any clear consensus the editor can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you think WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--f46d044280f8044cfd04d023e36c-- From jpanzer@google.com Wed Dec 5 16:08:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC74221F8CDD for ; Wed, 5 Dec 2012 16:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.476 X-Spam-Level: X-Spam-Status: No, score=-101.476 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoZeBOsK6fLI for ; Wed, 5 Dec 2012 16:08:40 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8120521F8CA4 for ; Wed, 5 Dec 2012 16:08:39 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4953206lah.31 for ; Wed, 05 Dec 2012 16:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c/6gTgVoNf/GRr5QlOkDCDay7V5/SBKwDNNenF+5yl8=; b=LEnez+LgO67nFR90QCFEVr8As04Cg/hL7vgVDdB8MUg4rRe5hHe9fDdIGTvIEnx4Z1 Ful1o/lp+VhnO2uXkiL7uxr+44QN6xU9BtsuZl/Ny1u53KCayfDO5a742H/rcKi8YErk ZpK8wlgl00irM//qZ/1v4NBIZP2R0HwkduMehV4KElTRtBM2DqTXYElHv1ZTdbLB95wl cdTbxw4STm1xBoxovltGdHJPlNKkAiwNWtLy8IWgHIKScySD6iLNTi0P6/lh1ykCTY8d 5lkDnIv7Da6Ky4bd4G/0Xwao7tHYMaUDprfvEmg4XayHawPKuHilwUirJi5Qyx08WsYK YG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=c/6gTgVoNf/GRr5QlOkDCDay7V5/SBKwDNNenF+5yl8=; b=H38ogxIDStbQU0JrVPNWQDBinjAacy7JsBXvGfU3+1u6daZDuQv8R71iRQmhE9Ed45 qT0ABpogc4IUIc6iVO4VY5aD8ARofF3lKFlDeUs/ScoVhU2zbwKv9jgco2RECWp7B5Ce ul9F7AG0fybcVuElaf6b/YCTYHZgWPuWitxX8Y5BgSUWVeNb1PklI/Hxtafs0/+jxz1d pEAp/u5GldlZ0/eNWhw+S2IIgoH7//ow21yFyIM+P9msejIHt5LjKioCcO2T+vL6EPPN FeuKZtGpQY1c3a9LrcxpOuYNRA31kzkxQC/hRThTfq0S2xrTGpw2sLOHxt9OdwMOckDx nfQQ== MIME-Version: 1.0 Received: by 10.112.39.73 with SMTP id n9mr91529lbk.114.1354752518061; Wed, 05 Dec 2012 16:08:38 -0800 (PST) Received: by 10.114.29.161 with HTTP; Wed, 5 Dec 2012 16:08:37 -0800 (PST) Received: by 10.114.29.161 with HTTP; Wed, 5 Dec 2012 16:08:37 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Date: Wed, 5 Dec 2012 16:08:37 -0800 Message-ID: From: John Panzer To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=e0cb4efe2f4e98fe8004d023e68b X-Gm-Message-State: ALoCoQlnT9MO8Ai4UfEtEvW7igJRREUl/rLUkZfHtM2Pa87AxkpuKXQgiXwWLIA9TItHnxsdaFokcAo/Xukgea+xjaA1MVLRznjywstgG7BSYJxO+Iu6u1KZS2GyLOdWzt9Hau0+aeW/JvsL4AeybNtcbnDd1GTX+9dSXSqIgmhPXRY76DazUFQ1DXd9X+Sicyj2XQj0ZHLT Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:08:40 -0000 --e0cb4efe2f4e98fe8004d023e68b Content-Type: text/plain; charset=ISO-8859-1 This is outside the scope of Webfinger, but: Add /.well-known/host_public_key to your servers,read it at first retrieval for that host and add to trust chain for that host before your first Web finger call, and then use https-only web finger. Its a tiny bit more work and not the most secure thing in the world but it separates the PKI from the protocol... On Dec 5, 2012 3:48 PM, "Mikael Nordfeldth" wrote: > 06.12.2012 00:12 skrev Brad Fitzpatrick: > >> Anyone supporting the HTTPS-only alternative because it's >>> "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user >>> would be able to serve any data at all to the majority of WF clients >>> "secure-by-default", if they do not have the CAcert root certificate >>> installed. >>> >>> >> They wouldn't. Your clients would need to trust CAcert.org. >> > > So it can also be referred to as the alternative effectively cutting off > the majority of the internet from using Webfinger properly? How's that for > hindering adoption. We might as well get XRD back in the game or require > that only mobile devices produced by fruit-named IT companies may use the > Webfinger protocol according the specification. > > It's obvious that you don't like the Root CAs, and you're not alone. >> Nobody >> loves the current situation, but they're basically all we've got right >> now, >> considering the continuing sorry state of DNS. >> > > So why would we go further down the rabbit hole? HTTP Webfinger requests > may be fully verifiable via simple methods like GPG signatures or any other > arbitrary out-of-band communication that users can apply if they can't rely > on HTTPS automation. > > Avoiding the issue of HTTPS/CA design vulnerabilities and restricting > alternative uses only worsens the situation and does not provide any > additional security. > > Then what should my clients do, that don't have have any Verisign, GoDaddy >>> or Comodo certificates to validate against? >>> >>> >> What do your HTTPS clients currently do? >> > > They're StatusNet RFC 6415 clients/servers that work more along the lines > of a TOFU/POP style of verification ("Trust On First Use/Persistence of > Pseudonym"). And a somewhat basic user interaction to verify the data on > first retrieval (accepting subscription). > > -- > Mikael Nordfeldth > http://blog.mmn-o.se/ > mmn@hethane.se > +46705657637 > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --e0cb4efe2f4e98fe8004d023e68b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This is outside the scope of Webfinger, but:=A0 Add /.well-k= nown/host_public_key to your servers,read it at first retrieval for that ho= st and add to trust chain for that host before your first Web finger call, = and then use https-only web finger.=A0 Its a tiny bit more work and not the= most secure thing in the world but it separates the PKI from the protocol.= ..

On Dec 5, 2012 3:48 PM, "Mikael Nordfeldth&= quot; <mmn@hethane.se> wrote:
06.12.2012 00:12 skrev Brad Fitzpatrick:
Anyone supporting the HTTPS-only alternative because it's
"secure-by-default" or similar, PLEASE explain how I as a CAcert.= org user
would be able to serve any data at all to the majority of WF clients
"secure-by-default", if they do not have the CAcert root certific= ate
installed.


They wouldn't. Your clients would need to trust CAcert.org.

So it can also be referred to as the alternative effectively cutting off th= e majority of the internet from using Webfinger properly? How's that fo= r hindering adoption. We might as well get XRD back in the game or require = that only mobile devices produced by fruit-named IT companies may use the W= ebfinger protocol according the specification.

It's obvious that you don't like the Root CAs, and you're not a= lone. Nobody
loves the current situation, but they're basically all we've got ri= ght now,
considering the continuing sorry state of DNS.

So why would we go further down the rabbit hole? HTTP Webfinger requests ma= y be fully verifiable via simple methods like GPG signatures or any other a= rbitrary out-of-band communication that users can apply if they can't r= ely on HTTPS automation.

Avoiding the issue of HTTPS/CA design vulnerabilities and restricting alter= native uses only worsens the situation and does not provide any additional = security.

Then what should my clients do, that don't have have any Verisign, GoDa= ddy
or Comodo certificates to validate against?


What do your HTTPS clients currently do?

They're StatusNet RFC 6415 clients/servers that work more along the lin= es of a TOFU/POP style of verification ("Trust On First Use/Persistenc= e of Pseudonym"). And a somewhat basic user interaction to verify the = data on first retrieval (accepting subscription).

--
Mikael Nordfeldth
http://blog.mmn-o.se/
mmn@hethane.se
+46= 705657637
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger
--e0cb4efe2f4e98fe8004d023e68b-- From mmn@hethane.se Wed Dec 5 16:17:51 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2E21F8765 for ; Wed, 5 Dec 2012 16:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRARaiXqlufz for ; Wed, 5 Dec 2012 16:17:50 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0161021F874D for ; Wed, 5 Dec 2012 16:17:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2012 01:17:46 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> Message-ID: <3468a2e2b3a8000725e84a2f15b76829@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:17:51 -0000 06.12.2012 01:04 skrev Brad Fitzpatrick: > Well, actually, the latest draft didn't specify which Root CAs were > consulted. It just says to verify the certs. Perhaps an > HTTPS-only+TOFU > WebFinger client is a conforming client. Yes, but my server would be out of reach for anyone else. > I agree that many things are still possible to do securely over HTTP > if you > have signing or content-addressability + security elsewhere. The > concern > is that those are all very dorky, theoretical, and seldom-used, and > mandating them would be complicate the spec. I understand what you're getting at, but as I wrote in a previous message on this thread, I think it should be stressed that Webfinger generally carries public, user-defined data that may be incorrect at the source. So the data _itself_ is not necessarily trustworthy. http://www.ietf.org/mail-archive/web/webfinger/current/msg00017.html The (cut-up) quote: "* Webfinger servers generally will serve public data. It is meant to support building better user experience by giving trivial metadata about various kinds of internet identities. [...] Most WF data will probably be in one way or another verified by end-users sooner or later." Any non-public data transfers will of course implement every single bit of verifiable security feasible. Thus I think my stance is pretty clear on the post linked above (msg00017.html), so I probably won't be discussing this specific issue anymore. I simply believe the downsides regarding adoptability outweigh the trivial issues with voluntary data integrity. From what I can see, most people +1 the https-only and I suppose it's my democratic duty to sit back and accept that I'm a minority after having said my part. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From nick@silverbucket.net Wed Dec 5 16:25:56 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A921F8BE6 for ; Wed, 5 Dec 2012 16:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPgYyQtoTowk for ; Wed, 5 Dec 2012 16:25:56 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E664C21F8BE2 for ; Wed, 5 Dec 2012 16:25:55 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5101416lbk.31 for ; Wed, 05 Dec 2012 16:25:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9BRALT5egseuXU2B1MjI9lTfrRCHYCdCHu+EOfOTXjc=; b=nQAxUqNAKFSCaM2zGD9YPB2GGdy3XeTlfTdAqFxthXNm2BAfMXvV3p7S/MnF6gsl7q lmocXqbOG3CSYXyQ8X1nChxgjLyTh5vGAXEaMpRfS/igQLXYxkzYxkDUm7ivvQ4vNvww knl/wjBRx7YeIRZ9p4HpymVcjqvxh47NjGsAoCXVO5TdU33JVwh/c8tywZxaQBanic0d S0DmXScenzYCmLBlrXlgLPmL+9BsxxMJ73kvcnVBr62lvfs5k9Meeiim+d3ZV9CC4rvJ V8kQnpGefD7NIhJ1vONhqbHbM1DClZXXBt4A5M0526bgCozRyWJtReGVm63S0AJi6rPf i0Cg== Received: by 10.112.83.100 with SMTP id p4mr110819lby.96.1354753554442; Wed, 05 Dec 2012 16:25:54 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id gr12sm2725949lab.3.2012.12.05.16.25.53 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 16:25:53 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4962147lah.31 for ; Wed, 05 Dec 2012 16:25:53 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr128952lbd.54.1354753553061; Wed, 05 Dec 2012 16:25:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 5 Dec 2012 16:25:22 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> From: Nick Jennings Date: Thu, 6 Dec 2012 01:25:22 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnhMdE/iUwSEuUmlk7odZ1YxE1rk5B9baD56hDMPsw8zVb6GUsLEcjLNtSAt/Qk/3mWVYUI Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:25:57 -0000 No one is taking CPU cycles, network latency, and plain old "get me an avatar as fast as possible" libraries into account here and it's a little worrying that we only have 2 options, both of which require at least a first attempt at HTTPS. I gave a few good reasons why a developer may want to just use HTTP, and I don't think it's necessary to mandate that a client needs to first make an HTTPS call in order to be compliant. If you want to make some mandate on client behavior, make it that they have to provide configuration options to allow for HTTP, HTTPS and both (with HTTPS first, then fallback to HTTP). You can make HTTPS -> HTTP the default even. But I think developers should be able to use HTTP only if they want to, and I think there's good reason for them to want to in many cases. On Thu, Dec 6, 2012 at 1:07 AM, Brad Fitzpatrick wrote: > +1 to #1 (HTTPS-only) > > It keeps clients simpler (just one HTTP request), and provides better > security than none (even if it's not ideal). > > > On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto > wrote: >> >> >> During the last couple of weeks there has been a lot of mail discussing >> whether >> WebFinger MUST support HTTPS only or instead it should be allowed for >> WebFinger >> fallback from HTTPS to HTTP. >> There are people with a clear preference (sometime strong) one way or the >> other, >> but also people that are more flexible and also having a preference could >> live with the other. >> >> However the discussion so far has not produced any clear consensus the >> editor can include in the >> next version of the wg draft. >> >> So as chairs I want explicitly to check where the wg consensus is >> >> 1) HTTPS only >> >> versus >> >> 2) HTTPS + HTTP but only as fallback >> >> So please provide your preference and if you want also the reason why you >> think WebFinger should >> adopt that particular solution. >> >> >> This consensus call will run until December Thursday 13th, 2012 >> >> best regards >> >> Salvatore >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From bradfitz@google.com Wed Dec 5 16:29:33 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5C921F8C17 for ; Wed, 5 Dec 2012 16:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC6d9L9V4Ee3 for ; Wed, 5 Dec 2012 16:29:30 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id BE71C21F8BEC for ; Wed, 5 Dec 2012 16:29:29 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so65240wib.13 for ; Wed, 05 Dec 2012 16:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oCMEdY7TeIV7x8yA9Kk631Fgg1iU6dD9ivN4n3ZnUdM=; b=PH2VyAqiL6Grh/vIF0qIlbE0A4NK19CDo2OQIt97FB2rZOCfoW1qzhCbt/jmTCSG/G 97+0N4BIfEbFgv4PemjW36y6UHIosj2Vev+v2ZW7JjGzCuxX0wkpYZv9XYLQsALSpwJy pKenmlSRjJYMu1KZERWbtEVUhx7XuRov/oZAiW3XUDRsYb5ioFrYzE7Dy89JPIBR/T47 3l7fYenEPNxULdj3qLUnh+SGfFxM3KiTT3PE5DyuCaIE+eAHvhgg6XCxA8xHB8Y+kMY3 lCmcWtLJ5gBMgWQ67FXWLzUJyk3gpWBLIitzl2IWYZK1qNrA9T6B6CLNEy1/YrIUTKUf nImA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oCMEdY7TeIV7x8yA9Kk631Fgg1iU6dD9ivN4n3ZnUdM=; b=Aq0QipwixqAploz2SGSdgh4m676lgeYYnwvIqZhmS+ttP6HVdGDjQBRUOlReL/Zzon WVvBqlpGTBmNu4/8X1BzIoiCFyQii958kgQ3Tq7Ih901XsITSHLV6eWFu2oguQsRe3Up ABL7Zh2MQi+YAaRRfj749CWz6yQIfAQFqAxWK5+z9PT9VCmigvh0ndIMb3/hPTPhmi4L cYTdZERapl2PECu99fk79pa2qRezHLtv1iXWiS2ZV54Imq8oYngj9vKuxgQoQMHQ2pMn xHQP65fM45BNw+0pRBSnPE+YypNTN/VCDu0IrNx/LigBsPHXBnkY2gUZC+aSKdDmtJEU K9VQ== MIME-Version: 1.0 Received: by 10.180.103.41 with SMTP id ft9mr6126508wib.6.1354753768869; Wed, 05 Dec 2012 16:29:28 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 16:29:28 -0800 (PST) In-Reply-To: <3468a2e2b3a8000725e84a2f15b76829@hethane.se> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> Date: Wed, 5 Dec 2012 16:29:28 -0800 Message-ID: From: Brad Fitzpatrick To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=20cf3068459126ce0f04d0243136 X-Gm-Message-State: ALoCoQk/rXkzswmNyvOkTJtiLicrnY0QcglP6hR1flxoiV9fB49vatCWp6DcSgJAcJVQFvCpPpANUjrxejjudahtcUUjr+PH+pNL4Xuzp+Gv0zdGwC787cOVRvUX6fU/GMzCaf+X2nTiPV/uEKE4Th2GGmmlEP262SZPOtfDYVgTTxTq6AhrFHrIy5eZSz4qF59h8hJskjYg Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:29:33 -0000 --20cf3068459126ce0f04d0243136 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 4:17 PM, Mikael Nordfeldth wrote: > 06.12.2012 01:04 skrev Brad Fitzpatrick: > > Well, actually, the latest draft didn't specify which Root CAs were >> consulted. It just says to verify the certs. Perhaps an HTTPS-only+TOFU >> WebFinger client is a conforming client. >> > > Yes, but my server would be out of reach for anyone else. > > > I agree that many things are still possible to do securely over HTTP if >> you >> have signing or content-addressability + security elsewhere. The concern >> is that those are all very dorky, theoretical, and seldom-used, and >> mandating them would be complicate the spec. >> > > I understand what you're getting at, but as I wrote in a previous message > on this thread, I think it should be stressed that Webfinger generally > carries public, user-defined data that may be incorrect at the source. So > the data _itself_ is not necessarily trustworthy. > http://www.ietf.org/mail-**archive/web/webfinger/current/**msg00017.html > > The (cut-up) quote: "* Webfinger servers generally will serve public data. > It is meant to support building better user experience by giving trivial > metadata about various kinds of internet identities. [...] Most WF data > will probably be in one way or another verified by end-users sooner or > later." > That's one use case. But here's another: what if the server wants to advertise the user's OpenID end-point? The existence of WebFinger clients in the world that may be trying HTTP after HTTPS' failure means that the server (say, doing both WebFinger and OpenID on HTTPS-only) has little confidence that its users aren't getting impersonated around the web by unknown third-parties on unknown third-party websites (using said HTTP-permitting WebFinger client), and getting MITMed by somebody breaking port 443, forcing a downgrade to HTTP, confusing the third-party site, and then pointing at their rogue OpenID server instead asserting whatever they want. Meanwhile the good HTTPS-only host never saw a single packet. That's why people want HTTPS-only end-to-end, despite the additional annoyance it'll cause to some servers for some use cases. --20cf3068459126ce0f04d0243136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 5, 2012 at 4:17 PM, Mikael Nordfeldth <mmn@hethane.se> wrote:
06.12.2012 01:04 = skrev Brad Fitzpatrick:

Well, actually, the latest draft didn't specify which Root CAs were
consulted. It just says to verify the certs. Perhaps an HTTPS-only+TOFU
WebFinger client is a conforming client.

Yes, but my server would be out of reach for anyone else.
=

I agree that many things are still possible to do securely over HTTP if you=
have signing or content-addressability + security elsewhere. =C2=A0The conc= ern
is that those are all very dorky, theoretical, and seldom-used, and
mandating them would be complicate the spec.

I understand what you're getting at, but as I wrote in a previous messa= ge on this thread, I think it should be stressed that Webfinger generally c= arries public, user-defined data that may be incorrect at the source. So th= e data _itself_ is not necessarily trustworthy. htt= p://www.ietf.org/mail-archive/web/webfinger/current/msg00017.= html

The (cut-up) quote: "* Webfinger servers generally will serve public d= ata. It is meant to support building better user experience by giving trivi= al metadata about various kinds of internet identities. [...] Most WF data = will probably be in one way or another verified by end-users sooner or late= r."

That's one use case. =C2=A0But here= 9;s another: =C2=A0what if the server wants to advertise the user's Ope= nID end-point? =C2=A0The existence of WebFinger clients in the world that m= ay be trying HTTP after HTTPS' failure means that the server (say, doin= g both WebFinger and OpenID on HTTPS-only) has little confidence that its u= sers aren't getting impersonated around the web by unknown third-partie= s on unknown third-party websites (using said HTTP-permitting WebFinger cli= ent), and getting MITMed by somebody breaking port 443, forcing a downgrade= to HTTP, confusing the third-party site, and then pointing at their rogue = OpenID server instead asserting whatever they want. =C2=A0Meanwhile the goo= d HTTPS-only host never saw a single packet.

That's why people want HTTPS-only end-to-end, despi= te the additional annoyance it'll cause to some servers for some use ca= ses.
--20cf3068459126ce0f04d0243136-- From bradfitz@google.com Wed Dec 5 16:32:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD44421F8CA0 for ; Wed, 5 Dec 2012 16:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgJBn47s6Dzn for ; Wed, 5 Dec 2012 16:32:46 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDA21F8C33 for ; Wed, 5 Dec 2012 16:32:45 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so55856wib.13 for ; Wed, 05 Dec 2012 16:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4SegWvo57kcPa2LVG9gUEYhISIdAXEMs+Y3gl1lcfq8=; b=mPbGMTvbsByjAHNCAowIlXULhjs7wB4L9Ri1KqoCO4dX91KpArTRoO0f3johWJUB+z rHv+nk40Z1yFyddSSQM8bHeUiY2sADbo6yw6In1czO93XPZe+UQI9ySkynHtAhy0iyv2 CC43e2Ag02STAa4ZZahdBrK+b9DPkyAeJNrOlCCbG1zgtmFjH9OcsIuFrtvMxJAtjQr6 UbAgrpwr5rJNf6oLCTYQu5FV51F1GV3lfx+64sWnfWcez1WpZrmvBUF+1ypFYzVgvHbL oGziqRcer95HENrsnqwCiQt0on8AP0fjxL4Ie0Rv1atV/yJV9wenQKX/uGPG9R2ZQT1z vxdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4SegWvo57kcPa2LVG9gUEYhISIdAXEMs+Y3gl1lcfq8=; b=UwUPTcYQxJvlWjV4CAQB0NHj2VDNgKihHzueiVRw5XijWvE1kIX3kiNgMfv84hhuO+ rkXx1qQB4dj1k+dZaq0fEZU+Wce4LbjWbCkIfPwKfAssCsuzJhqbchVhT3TaMfoxVSPz CtZ90bkR8FdZnBu5+eTNPiE4RjquU14JYfI4bnhceVqjWix+RXWVsdxg4l996HBbOHix J8VXjmmEbampiokumeFpzYCzAkVxPreWosNwoAt99HleIAUxx4Au/lOOhbgQZ0zAX+mM oEno/MAgUxxfeqT8O23juqgSIeN/gCtFFi3hdoKppqsYGSGfnOlQMxsR4OGD4yJUtYCQ +10w== MIME-Version: 1.0 Received: by 10.216.140.19 with SMTP id d19mr7661028wej.34.1354753965073; Wed, 05 Dec 2012 16:32:45 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 16:32:45 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 16:32:45 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=0016e6dee6e8d8a60004d0243cd9 X-Gm-Message-State: ALoCoQliuQqsXmTPNqg3rQJLlK1cdqtEf4rImR2brxo9ee20arkgPaa6oBeqJIbltXAuV2LimXTnlk/fGSEadmwoDiNr3X+DexokNEzuP+eU7eP752Mi/LmdCsfNkXNa81ujjaPsyipZ9//ZPPPt9RfUCvFH2UGrX5jEs5fFcxY8rppamaVufOZybyKf3IAPNvcqVa36iV9I Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:32:46 -0000 --0016e6dee6e8d8a60004d0243cd9 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings wrote: > No one is taking CPU cycles, network latency, and plain old "get me an > avatar as fast as possible" libraries into account here and it's a > little worrying that we only have 2 options, both of which require at > least a first attempt at HTTPS. FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips than when these WebFinger conversations started in ~2006. The "HTTPS is slow" argument is a little dated. --0016e6dee6e8d8a60004d0243cd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --0016e6dee6e8d8a60004d0243cd9-- From nick@silverbucket.net Wed Dec 5 16:43:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEC721F8C23 for ; Wed, 5 Dec 2012 16:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dreuhdTbNEP for ; Wed, 5 Dec 2012 16:43:29 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB39B21F8CA0 for ; Wed, 5 Dec 2012 16:43:28 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4969393lah.31 for ; Wed, 05 Dec 2012 16:43:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ckGM0cu+xrpjOx4xsGt+Hz1hWD+r230Io+ftwC4eAhw=; b=OLhPj9w/UpXsbB4Erq/2T0NiZEUAbH6ZC88fm6eJMoQgEp9gvgGk0xnwaJ6sipQtE+ O8fV67ydnjZUqZyzu2rzA97okIqMeBQ8Ww/13IhKNjRjq6EEaLLfK7oJQr/IEFBwXBj4 fKnVtFdX+nbEhSCZvHSCIUeY7JAq8povaRBXY+BA2jxAEktcu+gAJdJ0GgIopXsWySB/ NUoTkU4IZdgjWOkUMJ4E3nnoe0koxLOH0yAYt3k4EHJwN0PR7jMqlu+QWZQ81tzTY0Yd KKt8GgBbt6lb8L9usLGhY6xLxvhdneVF80weYUqpnrNDwJlYij8GsOGukrY1Ywl7vUAo E9pQ== Received: by 10.112.29.102 with SMTP id j6mr149184lbh.21.1354754607611; Wed, 05 Dec 2012 16:43:27 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id u9sm2810413lbf.5.2012.12.05.16.43.26 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 16:43:26 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5109815lbk.31 for ; Wed, 05 Dec 2012 16:43:26 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr143323lbd.54.1354754606424; Wed, 05 Dec 2012 16:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 5 Dec 2012 16:42:55 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> From: Nick Jennings Date: Thu, 6 Dec 2012 01:42:55 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnIRCcjYMws0RzMjqfM+Wmd6MLhH138xlDA7XNeJ/W5bDK3LgB6NIZpxUYUk6/9rrSEfKDo Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:43:29 -0000 On Thu, Dec 6, 2012 at 1:32 AM, Brad Fitzpatrick wrote: > On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings wrote: >> >> No one is taking CPU cycles, network latency, and plain old "get me an >> avatar as fast as possible" libraries into account here and it's a >> little worrying that we only have 2 options, both of which require at >> least a first attempt at HTTPS. > > > FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips than > when these WebFinger conversations started in ~2006. > > The "HTTPS is slow" argument is a little dated. I wasn't actually making the "HTTPS is slow" argument. If you read my posts you'd see I was actually talking about CPU cycles more in relation to battery drainage on mobile devices, as well as network latency in non-metro areas (I have trouble with HTTPS on my android phone here in Prague, which has decent service overall, it can simply not work in other parts of the country). I was also talking about page with hundreds or thousands of posts - using HTTPS could make a difference. Why not give the option for client sites to decide how they want to load their data? If I'm a developer and I want to load a bunch of avatars, and that's it, I'd much rather do an HTTP -> HTTPS fallback rather than the other way around. So not only are we saying "everyone needs to buy SSL certs" we're saying "everyone needs to be in first world countries", "that's too bad about your battery-life drainage", and the one I really don't understand: "we're worried you (the potential future developer) are going to make a crappy WF client that we'll somehow be forced to use" From mmn@hethane.se Wed Dec 5 16:49:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7BB21F8BBC for ; Wed, 5 Dec 2012 16:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HbRSkV7xCeE for ; Wed, 5 Dec 2012 16:49:13 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 560C721F8484 for ; Wed, 5 Dec 2012 16:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2012 01:49:11 +0100 From: Mikael Nordfeldth To: Brad Fitzpatrick In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> Message-ID: X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:49:14 -0000 06.12.2012 01:29 skrev Brad Fitzpatrick: > That's one use case. But here's another: what if the server wants > to > advertise the user's OpenID end-point? > > [description of how https server may never be queried and clients get > tricked] > > That's why people want HTTPS-only end-to-end, despite the additional > annoyance it'll cause to some servers for some use cases. The said client is obviously a badly programmed client. My recommendation to anyone in this situation is to stop using services that trust non-verified data for user identification. There will be TONS of badly programmed webfinger clients anyway that simply don't verify the connection. Not verifying HTTPS connections is the default behaviour in many url/http[s] libraries. I don't see how some words in a specification would make these insecurely developed applications disappear. I believe the recommended behaviour in a situation like the one above is quite strongly defined with the wording in section 9 of draft 07: While Section 5.1 allows for clients that fail to establish an HTTPS connection to attempt a query using HTTP, a client and any underlying client libraries are not required to re-issue queries using HTTP and SHOULD NOT when security for a given application that uses WebFinger is paramount. Maybe it can be refined to say something about not ever doing anything that will be used as anything security or privacy related. But honestly I think it would not have an effect on the ones who end up doing these bad security designs at all. The only way to stop them is to stop using their services. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From jpanzer@google.com Wed Dec 5 16:53:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B321F874D for ; Wed, 5 Dec 2012 16:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PH26RyYMnDo for ; Wed, 5 Dec 2012 16:53:45 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E843521F8765 for ; Wed, 5 Dec 2012 16:53:44 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4973736lah.31 for ; Wed, 05 Dec 2012 16:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n2p11wcThLeZlbTTYj8VwH9HP4D1G7xGxubb4FNCw5I=; b=HmwAdUPh+dae0PTwKVtd5AEZYOAebCHJDcAj3CThv/Z9PfofpxxdrQWTYV7qMe/+3U RkUoBS/EbHkqCfmSiPP4LvutZILeAQxtvnHWSD+Ry2rz0kQcCPOp4Jg2VeCs6D7KGmDF RmXgRlnKQuc+4C2usRI3+YntvMhHMXbn+qmBQTPxUPVfUgtY3qiUrRRFNMpqDm8Civ+C tupZ9S2695gPZgm5D76lmNpGyvUU4Owe/S8lRLNFo5ewVYye7GNN59x9X59nUdpnnD5D mSNlj7HQv/tJQTdFdd31vWVqWr4xcr/E7cS+eLgxZ1CtqX7zU7lBXNk4pFCXo73rZx7b YtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=n2p11wcThLeZlbTTYj8VwH9HP4D1G7xGxubb4FNCw5I=; b=QP0C+H+28uXjHgrrGbj/l6/6F4tScTchSPoTUqsPBA1r4GEru2lKTwAPHeQbvKXXMh NBGefU7NUTQ4uub04YgJ++P0YHi1ACOdbfFchSTrjyvyiqPSS9XC5cVlUqV52REvhgif xoJhPxNz2yZHwRWMsuHB8pbg6hbtvutT43fFNc9E+6oBVPE2QoaoMp7hw3xMaUgYM31N 7O5LSlqL48ZSTCT/hYtnpxtDbLPtGFOCHvJcSH1bNg1HN8LCZfT1f7Dn/GNh3ZP75bsK 2a182OQTldavUsPCbJX9kHKf44tg+mx11XoKuXehLUd4VJgCPUSM5fQVxSA3X9NF4yFd jsAw== Received: by 10.112.88.7 with SMTP id bc7mr131167lbb.108.1354755223617; Wed, 05 Dec 2012 16:53:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.29.161 with HTTP; Wed, 5 Dec 2012 16:53:23 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> From: John Panzer Date: Wed, 5 Dec 2012 16:53:23 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=f46d0401697bdc80ce04d02487af X-Gm-Message-State: ALoCoQmqRsAhv0Ig/3W0vxqWGplMGC9IhuyvrBp0b/1e5mwsfl1hVuyRDrDAWplcFMFcHv+VqSOZID4qQ/DWDUIXmhzVOMScQHD05CBtdZxXX47a0OaY7XEIQ7isXToLjm+lLemfcFvcLLXY/uS79wHp3IzulFvdIbVAcPqfcU8NkPV4pWWhZXxCg3sL2l2M82loJO5IRllm Cc: Salvatore Loreto , webfinger@ietf.org, Nick Jennings , "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:53:46 -0000 --f46d0401697bdc80ce04d02487af Content-Type: text/plain; charset=ISO-8859-1 Apropos: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html On Wed, Dec 5, 2012 at 4:32 PM, Brad Fitzpatrick wrote: > On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings wrote: > >> No one is taking CPU cycles, network latency, and plain old "get me an >> avatar as fast as possible" libraries into account here and it's a >> little worrying that we only have 2 options, both of which require at >> least a first attempt at HTTPS. > > > FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips than > when these WebFinger conversations started in ~2006. > > The "HTTPS is slow" argument is a little dated. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --f46d0401697bdc80ce04d02487af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apropo= s:=A0http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
On Wed, Dec 5, 2012 at 4:32 PM, Brad Fitzpat= rick <bradfitz@google.com> wrote:
On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings <nick@silver= bucket.net> wrote:
No one is taking CPU cycles, network latency, and plain old "ge= t me an
avatar as fast as possible" libraries into account here and it's a=
little worrying that we only have 2 options, both of which require at
least a first attempt at HTTPS.

FWIW,= CPUs are remarkably faster and HTTPS involves fewer round-trips than when = these WebFinger conversations started in ~2006.

The "HTTPS is slow" argument is a little dated.


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--f46d0401697bdc80ce04d02487af-- From mmn@hethane.se Wed Dec 5 16:58:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901DB21F8C07 for ; Wed, 5 Dec 2012 16:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0BASphxWxtq for ; Wed, 5 Dec 2012 16:58:45 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id D90BC21F8BCB for ; Wed, 5 Dec 2012 16:58:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2012 01:58:41 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <50BF612D.3070001@ericsson.com> Message-ID: X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:58:45 -0000 06.12.2012 01:25 skrev Nick Jennings: > No one is taking CPU cycles, network latency, and plain old "get me > an > avatar as fast as possible" libraries into account here and it's a > little worrying that we only have 2 options, both of which require at > least a first attempt at HTTPS. I for one "support suggested priority for HTTPS followed by an optional HTTP fallback. (not necessarily a MUST on https for first connection, maybe my client service entirely relies upon end-user verification anyway)" as posted in http://www.ietf.org/mail-archive/web/webfinger/current/msg00017.html Just wanted to let you know you're not alone in trusting the clients to do the right thing - and simply stop using clients (as an end-user) that don't respect your privacy in cases of sensitive data transfers. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From duerst@it.aoyama.ac.jp Wed Dec 5 17:02:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9D21F8731 for ; Wed, 5 Dec 2012 17:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.244 X-Spam-Level: X-Spam-Status: No, score=-100.244 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kQRedRY4L+l for ; Wed, 5 Dec 2012 17:02:09 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 010D521F8C11 for ; Wed, 5 Dec 2012 17:02:08 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qB6122Cs026353 for ; Thu, 6 Dec 2012 10:02:02 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7320_6305_8b8ad880_3f40_11e2_84e3_001d096c5782; Thu, 06 Dec 2012 10:02:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51317) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 6 Dec 2012 10:02:04 +0900 Message-ID: <50BFEE85.3040801@it.aoyama.ac.jp> Date: Thu, 06 Dec 2012 10:01:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Evan Prodromou References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> In-Reply-To: <50BFA457.1090101@status.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:02:10 -0000 I strongly prefer 2), for very similar reasons as those outlined below. Regards, Martin. On 2012/12/06 4:45, Evan Prodromou wrote: > 2) > > The attacks that have people concerned are only important for a certain > class of applications, which can easily specify HTTPS-only separately. > > Explicitly supporting HTTP allows for experimentation and low-security > applications. HTTPS can cause increased costs for small community and > individual Web sites -- not only for the cert, but also for additional > infrastructure. HTTPS is rarely supported for shared-hosting systems. > > As a Webfinger library developer for node.js, I appreciate the security > concern and will be happy to include configuration flags to prevent > fallback to HTTP if needed by the client. > > -Evan > > On 2012-12-05 09:58, Salvatore Loreto wrote: >> >> During the last couple of weeks there has been a lot of mail >> discussing whether >> WebFinger MUST support HTTPS only or instead it should be allowed for >> WebFinger >> fallback from HTTPS to HTTP. >> There are people with a clear preference (sometime strong) one way or >> the other, >> but also people that are more flexible and also having a preference >> could live with the other. >> >> However the discussion so far has not produced any clear consensus the >> editor can include in the >> next version of the wg draft. >> >> So as chairs I want explicitly to check where the wg consensus is >> >> 1) HTTPS only >> >> versus >> >> 2) HTTPS + HTTP but only as fallback >> >> So please provide your preference and if you want also the reason why >> you think WebFinger should >> adopt that particular solution. >> >> >> This consensus call will run until December Thursday 13th, 2012 >> >> best regards >> Salvatore >> > > From bradfitz@google.com Wed Dec 5 17:05:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BAE21F8CE7 for ; Wed, 5 Dec 2012 17:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCPgjmI6HcgG for ; Wed, 5 Dec 2012 17:05:53 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id BBDFA21F8CE3 for ; Wed, 5 Dec 2012 17:05:51 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2511999wgb.13 for ; Wed, 05 Dec 2012 17:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gkz65FfPb+suNt0RmlWx34gDcXFuvm82nV0ps/vzafs=; b=VQn44zd9pGUvmjVEuZ7SbD7ebaGuczDtRH4oS0sOSGJbpcTrJFnrsWv+yiqcN2+/gL ixr4MNiHl7KiNXhSLtNpYlj6ktbaR8j07Svbw/lBI6u6CfZ2DzeWKUBLou4JsTWrRKbk Mcu8FdxdQANAnKT8UVfAWxTSfUaRi+tcqgG+6jfmCHxbq8uYw3Ufz4ZKeGKOw+JarXjX qX7zoUg/YDAwdPtv0mP1Y7VejoQXpyi/BZXmOJfa2Tv6hwPP/zxuNLYQHuLt5zA7f4H3 tyQp1k4oEPkW9WyhxrT30HdDkg5wk13S0P8LuZdjWXHOW73NGlj4k/gTzmyUko+vYVUf awMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Gkz65FfPb+suNt0RmlWx34gDcXFuvm82nV0ps/vzafs=; b=MDWcl3wk48WJN7NBlht3/rBA96wLMO5QunlqXp9i2qmd0PoFA2lN910ZFAVi2XIZzO JGBe4ssqX9OzGL6KR6WMgNAmysH3NuUIYA3q78B4VgqIEdgJHc4+7wsnLvxxhkhTfiCN aeKfc1UjnuSpr0+Bsk+piKiULNciipf4D8gTbkW4z8t7q+6bnOQpbIalXA38VpH5lmWg u3B224EaujCdhqRndEWdYg6Bixhg5HU8leA/Yt+8Qccw/cOQYMtgJmIQRaTD/FBuJ34g CxTG5G3f6l4RcMS4ddKRPq3XfKkDE7mTIrmmsGa8zb5ULJrDVZr9K1DZ0kC4AVNTzvMe HASw== MIME-Version: 1.0 Received: by 10.216.220.35 with SMTP id n35mr5982812wep.128.1354755950490; Wed, 05 Dec 2012 17:05:50 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 17:05:50 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> Date: Wed, 5 Dec 2012 17:05:50 -0800 Message-ID: From: Brad Fitzpatrick To: Mikael Nordfeldth Content-Type: multipart/alternative; boundary=0016e6dd8a1e2fb42904d024b381 X-Gm-Message-State: ALoCoQlTHiGfKZmttjxmAZcIBcTL49Sq71ulNnTOu8hvhqKqC5ojstr/F/umQgZfcUrnkBx5qeRtT2+YbQRBhhBzeKZGHUcBUXI/ArPZrh0JH+VOqJPdGiTmcQXZKFYgZXpyp4oM5dlNP4INs6uYhxd+32Aj+VN31hNs88FE1j6JyWnrbkU/QAaaAn10AB7pTT7tV+abIUNV Cc: webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:05:54 -0000 --0016e6dd8a1e2fb42904d024b381 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth wrote: > 06.12.2012 01:29 skrev Brad Fitzpatrick: > >> That's one use case. But here's another: what if the server wants to >> advertise the user's OpenID end-point? >> >> [description of how https server may never be queried and clients get >> tricked] >> >> >> That's why people want HTTPS-only end-to-end, despite the additional >> annoyance it'll cause to some servers for some use cases. >> > > The said client is obviously a badly programmed client. My recommendation > to anyone in this situation is to stop using services that trust > non-verified data for user identification. > > There will be TONS of badly programmed webfinger clients anyway that > simply don't verify the connection. Not verifying HTTPS connections is the > default behaviour in many url/http[s] libraries. I don't see how some words > in a specification would make these insecurely developed applications > disappear. > > > I believe the recommended behaviour in a situation like the one above is > quite strongly defined with the wording in section 9 of draft 07: > > While Section 5.1 allows for clients that fail to establish an HTTPS > connection to attempt a query using HTTP, a client and any underlying > client libraries are not required to re-issue queries using HTTP and > SHOULD NOT when security for a given application that uses WebFinger > is paramount. > > Maybe it can be refined to say something about not ever doing anything > that will be used as anything security or privacy related. But honestly I > think it would not have an effect on the ones who end up doing these bad > security designs at all. The only way to stop them is to stop using their > services. Agreed. But sometimes it's hard to know who sucks until it's too late. (e.g. all these leaked password databases in plain text or with unsalted hashes....) Ignoring security, though, the thing I like most about HTTPS-only is that it's one request instead of two. --0016e6dd8a1e2fb42904d024b381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth <mmn@hethane.se> wrote:
06.12.2012 01:29 = skrev Brad Fitzpatrick:
That's one use case. =C2=A0But here's another: =C2=A0what if the se= rver wants to
advertise the user's OpenID end-point?

[description of how https server may never be queried and clients get trick= ed]


That's why people want HTTPS-only end-to-end, despite the additional annoyance it'll cause to some servers for some use cases.

The said client is obviously a badly programmed client. My recommendation t= o anyone in this situation is to stop using services that trust non-verifie= d data for user identification.

There will be TONS of badly programmed webfinger clients anyway that simply= don't verify the connection. Not verifying HTTPS connections is the de= fault behaviour in many url/http[s] libraries. I don't see how some wor= ds in a specification would make these insecurely developed applications di= sappear.


I believe the recommended behaviour in a situation like the one above is qu= ite strongly defined with the wording in section 9 of draft 07:

=C2=A0 =C2=A0While Section 5.1 allows for clients that fail to establish an= HTTPS
=C2=A0 =C2=A0connection to attempt a query using HTTP, a client and any und= erlying
=C2=A0 =C2=A0client libraries are not required to re-issue queries using HT= TP and
=C2=A0 =C2=A0SHOULD NOT when security for a given application that uses Web= Finger
=C2=A0 =C2=A0is paramount.

Maybe it can be refined to say something about not ever doing anything that= will be used as anything security or privacy related. But honestly I think= it would not have an effect on the ones who end up doing these bad securit= y designs at all. The only way to stop them is to stop using their services= .

Agreed. =C2=A0But sometimes it's hard to know who s= ucks until it's too late. (e.g. all these leaked password databases in = plain text or with unsalted hashes....)

Ignoring s= ecurity, though, the thing I like most about HTTPS-only is that it's on= e request instead of two.
--0016e6dd8a1e2fb42904d024b381-- From evan@status.net Wed Dec 5 17:07:58 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64AC21F8CF8 for ; Wed, 5 Dec 2012 17:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsih5UAmz572 for ; Wed, 5 Dec 2012 17:07:58 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E221F8CFB for ; Wed, 5 Dec 2012 17:07:57 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id EE1548D448E for ; Thu, 6 Dec 2012 01:20:18 +0000 (UTC) Message-ID: <50BFEFE7.3010704@status.net> Date: Wed, 05 Dec 2012 20:07:51 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050209020802020100030806" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:07:59 -0000 This is a cryptographically signed message in MIME format. --------------ms050209020802020100030806 Content-Type: multipart/alternative; boundary="------------050409000304010306010802" This is a multi-part message in MIME format. --------------050409000304010306010802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If it's as easy to implement HTTPS as everyone seems to think, then even = with fallback it will always be just one request. -Evan On 12-12-05 08:05 PM, Brad Fitzpatrick wrote: > On Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth > wrote: > > 06.12.2012 01:29 skrev Brad Fitzpatrick: > > That's one use case. But here's another: what if the server > wants to > advertise the user's OpenID end-point? > > [description of how https server may never be queried and > clients get tricked] > > > That's why people want HTTPS-only end-to-end, despite the > additional > annoyance it'll cause to some servers for some use cases. > > > The said client is obviously a badly programmed client. My > recommendation to anyone in this situation is to stop using > services that trust non-verified data for user identification. > > There will be TONS of badly programmed webfinger clients anyway > that simply don't verify the connection. Not verifying HTTPS > connections is the default behaviour in many url/http[s] > libraries. I don't see how some words in a specification would > make these insecurely developed applications disappear. > > > I believe the recommended behaviour in a situation like the one > above is quite strongly defined with the wording in section 9 of > draft 07: > > While Section 5.1 allows for clients that fail to establish an > HTTPS > connection to attempt a query using HTTP, a client and any > underlying > client libraries are not required to re-issue queries using > HTTP and > SHOULD NOT when security for a given application that uses > WebFinger > is paramount. > > Maybe it can be refined to say something about not ever doing > anything that will be used as anything security or privacy > related. But honestly I think it would not have an effect on the > ones who end up doing these bad security designs at all. The only > way to stop them is to stop using their services. > > > Agreed. But sometimes it's hard to know who sucks until it's too=20 > late. (e.g. all these leaked password databases in plain text or with=20 > unsalted hashes....) > > Ignoring security, though, the thing I like most about HTTPS-only is=20 > that it's one request instead of two. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------050409000304010306010802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If it's as easy to implement HTTPS as everyone seems to think, then even with fallback it will always be just one request.

-Evan

On 12-12-05 08:05 PM, Brad Fitzpatrick wrote:
On Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth <mmn@hethane.= se> wrote:
06.12.2012 01:29 skrev Brad Fitzpatrick:
That's one use case.  But here's another:  what= if the server wants to
advertise the user's OpenID end-point?

[description of how https server may never be queried and clients get tricked]


That's why people want HTTPS-only end-to-end, despite the additional
annoyance it'll cause to some servers for some use cases.

The said client is obviously a badly programmed client. My recommendation to anyone in this situation is to stop using services that trust non-verified data for user identification.

There will be TONS of badly programmed webfinger clients anyway that simply don't verify the connection. Not verifying HTTPS connections is the default behaviour in many url/http[s] libraries. I don't see how some words in a specification would make these insecurely developed applications disappear.


I believe the recommended behaviour in a situation like the one above is quite strongly defined with the wording in section 9 of draft 07:

   While Section 5.1 allows for clients that fail t= o establish an HTTPS
   connection to attempt a query using HTTP, a clie= nt and any underlying
   client libraries are not required to re-issue qu= eries using HTTP and
   SHOULD NOT when security for a given application= that uses WebFinger
   is paramount.

Maybe it can be refined to say something about not ever doing anything that will be used as anything security or privacy related. But honestly I think it would not have an effect on the ones who end up doing these bad security designs at all. The only way to stop them is to stop using their services.

Agreed.  But sometimes it's hard to know who sucks un= til it's too late. (e.g. all these leaked password databases in plain text or with unsalted hashes....)

Ignoring security, though, the thing I like most about HTTPS-only is that it's one request instead of two.


_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------050409000304010306010802-- --------------ms050209020802020100030806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMDYw MTA3NTFaMCMGCSqGSIb3DQEJBDEWBBRA7pDxlaRdljhOQa1qCOkZaEstYTBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAIEZ FHzWVVCv0zOHHG9HUgRB7tbd71KpAMJXSOL7vKUYlwvRIEGGgzi3cU9hiGd5A/s4k2eG81H0 txVsVNBz3e+31SV1RUUXRGltyuhn2Z3pLWrJrlxH8mUJ5EOJF+8WACbdZdsewtL51QrLnHPQ 286nvA6m8MzmLEBjNUjxHT6V17Nom0Zjy8TMi3TEy5qgLPWE+saLohDHXT7oSPSCC1J9gaZh CbHKu7oZgeaDlQcT583c6F6+NuJJ6YDVUzx2wZdW6IkirHAcS5qkSrPKVGGc5tVfek5aCzw4 2OycCWDtFY8PPGZavz3IWsxUloFMJ/utS6r4z+KfT1iilcp1Vs4AAAAAAAA= --------------ms050209020802020100030806-- From bradfitz@google.com Wed Dec 5 17:16:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41C21F85E8 for ; Wed, 5 Dec 2012 17:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kd4BhRNzwXn for ; Wed, 5 Dec 2012 17:16:35 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85821F85CB for ; Wed, 5 Dec 2012 17:16:35 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2514722wgb.13 for ; Wed, 05 Dec 2012 17:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jmax1IQv2JFZOXqOtjBkszxL2Bcxi3gd+Rzb6AkJbAI=; b=RXPD7eFfbohDTaSB0WG2W9ryZl2lGTnHzRVyJk6WAjJiWvm2735POMvW7Af6UsjiYy 1LjIKpsq8ItG5AUhxIUWZuVGA5/lCz9ojj+aFHcDLvMrN5uvKtRcArb8jCGdvfR+i+93 LGQ4BO15Hh+jI5GH/voGq51ZEGfP8XmCnye/BuM6reI8MeJFYwHsfu+mkHM09opGlslu szUlLNUfS4wzL1K6sWLJzXvdvSCIazEwnEBtheWR6PGo/3iyj02WY/ijCky1bXXSAROd eBvj4Xjv1AKeiN41UzXSadRpnaPIiscLQwzMBdn+ZrMaUbySh+Dn2GmPPxCSaJXXr3By E3Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Jmax1IQv2JFZOXqOtjBkszxL2Bcxi3gd+Rzb6AkJbAI=; b=SbZpXjUJvcRma5w82NYfVHou3pSa9/U8+PgI+x7bSjLtLlC6jfeIBl7V/AzJsyINxn tZFVXeeXq2eXw1ATVoqyJYY9x80kslxfO1r4qc6NgAKgl526IAbkNuUCj0+RIivfIjJ2 /2QdzExj3gwfAULy0EzFAMASXuRoA0o3rgaxrqPOUL9NyBypN3b/aEDQ/4hvCWTYJVjl mMFPZ+QTsBDzKvmVgt3ASf0PKBPTJ2PnAo9JHKEV0o8N6PXBGaiB2MHPWcCxaAGZ81Oh M+wZSxh1PIOZBD8Tv0CAKuL8971qBJojuVwL2sfHGIALxU7AHT5imWGwG4KL6eM58nwS 5IKw== MIME-Version: 1.0 Received: by 10.180.103.41 with SMTP id ft9mr6273716wib.6.1354756594552; Wed, 05 Dec 2012 17:16:34 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 5 Dec 2012 17:16:34 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 17:16:34 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=20cf30684591934d6b04d024d9d3 X-Gm-Message-State: ALoCoQnj0md2ekXRuBTCXo5t2WJqwa0ldgPfUvsiQUV/6Qm7Q0nzu1r98Z/DqlLLlHRQTPFl1c6G2Ra21nb5j+hybthvKnz693Vud98SfShEsfPC4xl7L9jYHXaz9wcpBzBCm0QMD8162Y3GFXRaCWLDJHe3B56EukQK9JE9ktaUxHYfz50noeT/IN9ik5qAjo004Y8H8Aid Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:16:36 -0000 --20cf30684591934d6b04d024d9d3 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 4:42 PM, Nick Jennings wrote: > On Thu, Dec 6, 2012 at 1:32 AM, Brad Fitzpatrick > wrote: > > On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings > wrote: > >> > >> No one is taking CPU cycles, network latency, and plain old "get me an > >> avatar as fast as possible" libraries into account here and it's a > >> little worrying that we only have 2 options, both of which require at > >> least a first attempt at HTTPS. > > > > > > FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips > than > > when these WebFinger conversations started in ~2006. > > > > The "HTTPS is slow" argument is a little dated. > > I wasn't actually making the "HTTPS is slow" argument. If you read my > posts you'd see I was actually talking about CPU cycles more in > relation to battery drainage on mobile devices, as well as network > latency in non-metro areas (I have trouble with HTTPS on my android > phone here in Prague, which has decent service overall, it can simply > not work in other parts of the country). > Is your provider blocking HTTPS? > I was also talking about page with hundreds or thousands of posts - > using HTTPS could make a difference. > Presumably many of requests will re-use cached connections. > Why not give the option for client sites to decide how they want to > load their data? If I'm a developer and I want to load a bunch of > avatars, and that's it, I'd much rather do an HTTP -> HTTPS fallback > rather than the other way around. I'd prefer no fallback in either direction. > So not only are we saying "everyone needs to buy SSL certs" I've never bought one... the free StartCom ones have always worked for me. > we're > saying "everyone needs to be in first world countries", That's a stretch. How? > "that's too > bad about your battery-life drainage", The screen and the radio staying in one of the lower-power RRC states tends to be way more important than CPU on mobile devices. Doing any sort of fallback in either direction means keeping the radio on for longer. > and the one I really don't > understand: "we're worried you (the potential future developer) are > going to make a crappy WF client that we'll somehow be forced to use" > Discussed in the other threads about people not wanting to be build secure protocols atop insecure ones. --20cf30684591934d6b04d024d9d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 5, 2012 at 4:42 PM, Nick Jennings <nick@silverbucket.net> wrote:
On Thu, Dec 6, 2012 at 1:32 AM, Brad Fitzpatrick <= ;bradfitz@google.com> wrote:<= br> > On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings <nick@silverbucket.net> wrote:
>>
>> No one is taking CPU cycles, network latency, and plain old "= get me an
>> avatar as fast as possible" libraries into account here and i= t's a
>> little worrying that we only have 2 options, both of which require= at
>> least a first attempt at HTTPS.
>
>
> FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips = than
> when these WebFinger conversations started in ~2006.
>
> The "HTTPS is slow" argument is a little dated.

I wasn't actually making the "HTTPS is slow" argu= ment. If you read my
posts you'd see I was actually talking about CPU cycles more in
relation to battery drainage on mobile devices, as well as network
latency in non-metro areas (I have trouble with HTTPS on my android
phone here in Prague, which has decent service overall, it can simply
not work in other parts of the country).

Is your provider blocking HTTPS?
=C2=A0
I was also talking about page with hundreds or thousands of posts -
using HTTPS could make a difference.

Pr= esumably many of requests will re-use cached connections.
=C2=A0<= /div>
Why not give the option for client sites to decide how they want to
load their data? If I'm a developer and I want to load a bunch of
avatars, and that's it, I'd much rather do an HTTP -> HTTPS fall= back
rather than the other way around.

I'd p= refer no fallback in either direction.
=C2=A0
So not only are we saying "everyone needs to buy SSL certs"

I've never bought one... the free StartCom o= nes have always worked for me.
=C2=A0
we're
saying "everyone needs to be in first world countries",

That's a stretch. =C2=A0How?
=C2=A0
"that's too
bad about your battery-life drainage",

The screen and the radio staying in one of the lower-power RRC states tend= s to be way more important than CPU on mobile devices. =C2=A0Doing any sort= of fallback in either direction means keeping the radio on for longer.
=C2=A0
and the one I really don&#= 39;t
understand: "we're worried you (the potential future developer) ar= e
going to make a crappy WF client that we'll somehow be forced to use&qu= ot;

Discussed in the other threads abou= t people not wanting to be build secure protocols atop insecure ones.

--20cf30684591934d6b04d024d9d3-- From nick@silverbucket.net Wed Dec 5 17:49:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2466821F89FE for ; Wed, 5 Dec 2012 17:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8NkWQPZiPPn for ; Wed, 5 Dec 2012 17:49:03 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA22021F894B for ; Wed, 5 Dec 2012 17:49:02 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4999547lah.31 for ; Wed, 05 Dec 2012 17:48:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=l5EDFIZMZ2oFyMJpMeuxn4TKJEB5IXN0K8tXYjEJJ1E=; b=d8g18QaNdYpmnUFwGbMIqsqp9qk8OX+mgqAOOQViPXpV5B1K9KxqVqySSCxuYwtAoz UhEW8Sfbi70pjP1SzetXRvkL+wybNGLbVyLzMY0ajlNKY4jzIl9A/U9zwm4VxioPps9J 3m3FLyBq32Dv2xOtn8smNp0vqk1OD+UNKXzzR0s3hdPuMQpIJZ7zXh2qbxkYYwUtsbcj HGa1c0drA9NGL6svvmpKvKDHKw7sKX6aekIQx8QyZW/6rm1AwVegWhyjGVFTdYW51iew eTd2O8pWOrATZiXexLWXfy+VnSX9H4e4fBJd5NI5p7pvuqg2QAjV1OuI+BaLN6A9ta3I Fplg== Received: by 10.152.104.115 with SMTP id gd19mr18817762lab.13.1354758539609; Wed, 05 Dec 2012 17:48:59 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id so7sm2773143lab.0.2012.12.05.17.48.58 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 17:48:58 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5140979lbk.31 for ; Wed, 05 Dec 2012 17:48:58 -0800 (PST) Received: by 10.152.162.1 with SMTP id xw1mr18808384lab.3.1354758538460; Wed, 05 Dec 2012 17:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 5 Dec 2012 17:48:28 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> From: Nick Jennings Date: Thu, 6 Dec 2012 02:48:28 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmlX4b7HPPPqP05LRn/+H5VEe08C+mssLPrFlPWK1ReCCmHNdYqFDVa5v6K4RIfkkOOtjMT Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:49:04 -0000 On Thu, Dec 6, 2012 at 2:16 AM, Brad Fitzpatrick wrote: > On Wed, Dec 5, 2012 at 4:42 PM, Nick Jennings wrote: >> >> On Thu, Dec 6, 2012 at 1:32 AM, Brad Fitzpatrick >> wrote: >> > On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings >> > wrote: >> >> >> >> No one is taking CPU cycles, network latency, and plain old "get me an >> >> avatar as fast as possible" libraries into account here and it's a >> >> little worrying that we only have 2 options, both of which require at >> >> least a first attempt at HTTPS. >> > >> > >> > FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips >> > than >> > when these WebFinger conversations started in ~2006. >> > >> > The "HTTPS is slow" argument is a little dated. >> >> I wasn't actually making the "HTTPS is slow" argument. If you read my >> posts you'd see I was actually talking about CPU cycles more in >> relation to battery drainage on mobile devices, as well as network >> latency in non-metro areas (I have trouble with HTTPS on my android >> phone here in Prague, which has decent service overall, it can simply >> not work in other parts of the country). > > Is your provider blocking HTTPS? No, I think it's a latency issue. >> I was also talking about page with hundreds or thousands of posts - >> using HTTPS could make a difference. > > Presumably many of requests will re-use cached connections. OK, fair enough - though I think the idea of why you may want to just use HTTP when you can still stands. >> >> Why not give the option for client sites to decide how they want to >> load their data? If I'm a developer and I want to load a bunch of >> avatars, and that's it, I'd much rather do an HTTP -> HTTPS fallback >> rather than the other way around. > > I'd prefer no fallback in either direction. I totally agree with you here, except that I think it would be easier for the developer of the client library to go ahead and implement the fallback (optional) rather than having developers who use the library have to implement their own fallback for the cases where they need to do so. Unless we require HTTPS only, it's a fact that some providers will only offer one or the other for various reasons. That said, should we really get into whether or not a client library should implement fallback? You say you'd prefer not, so you'd probably use a client library that allows you to turn it off. I could see a reason to make it HTTPS with no fallback by default. With the option to enable HTTP fallback, or HTTP only, depending on your use-case. I would imagine most of the time people would configure their client library to be HTTPS with HTTP fallback, to try to ensure they'll get a successful callback with some data they can use. >> >> So not only are we saying "everyone needs to buy SSL certs" > > I've never bought one... the free StartCom ones have always worked for me. Thanks for that link (last week?), I got one and set it up on my server after you mentioned it. This is great, as far as I know it's the only one out there providing free certs. Still, I think most people will feel they have to buy a cert and so not bother to implement WF because SSL is required and they don't want to drop $60+/year just to be able to participate. >> >> we're >> saying "everyone needs to be in first world countries", > > That's a stretch. How? I meant in reference to poor network coverage on mobile networks, or rural areas, underdeveloped countries. But yeah, you're right, it is a stretch. >> >> "that's too >> bad about your battery-life drainage", > > The screen and the radio staying in one of the lower-power RRC states tends > to be way more important than CPU on mobile devices. Doing any sort of > fallback in either direction means keeping the radio on for longer. Good point. Unless the client is using WF for some security related process, auth or whatever, then it would make sense for them to only use HTTP. >> >> and the one I really don't >> understand: "we're worried you (the potential future developer) are >> going to make a crappy WF client that we'll somehow be forced to use" > > > Discussed in the other threads about people not wanting to be build secure > protocols atop insecure ones. > Yeah, I think I'm missing the point here. I don't know why there seems to be a concern about people writing poor clients that they are somehow forced to use (or don't know better). If you're writing an authentication library you better know what you're doing, and if you make use of someone else's WF library, you better know what it's doing. From randall.leeds@gmail.com Wed Dec 5 20:00:28 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8121F8A9C for ; Wed, 5 Dec 2012 20:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS6EY8WSo6Bp for ; Wed, 5 Dec 2012 20:00:27 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65521F8983 for ; Wed, 5 Dec 2012 20:00:27 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so6347368obc.31 for ; Wed, 05 Dec 2012 20:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tMeROp1G8Zy7WAkq3m95L+hM4V5jkpsqntjO3V6f5pw=; b=E86dXD8wbUgsvCe9P6XbcOH9gpQntzn9nBHviQLDeDbrsmaQ5Qqen0Q+Ee77/1wr4y YDqA28CzH/FWI/TW8QBEd/en/ZcgzPcj1xlzSEIjIn6a//Rvl2JOdWoD1axBYOYeAq+X fGdYAd2U0uNQPKfPV+iFKue44tyfsrDs480Eq2h5WA8miYpQnBUhjT319XUiqHylbbWf rzQztYVQS2aB6hNXR8VW4hlp6Uu5xa+AUHom8uDR+dyjL9W0GyXJgh0JW8XqW9TL4yVz ApOoGBIuDaBMgYc09EK7eHfs32+xB61YHVbO60wtd8I1XckgKtlsT9h/iRzNMWYAfCXh TEog== MIME-Version: 1.0 Received: by 10.60.21.167 with SMTP id w7mr115971oee.18.1354766426798; Wed, 05 Dec 2012 20:00:26 -0800 (PST) Received: by 10.76.21.6 with HTTP; Wed, 5 Dec 2012 20:00:26 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> Date: Wed, 5 Dec 2012 20:00:26 -0800 Message-ID: From: Randall Leeds To: James M Snell Content-Type: multipart/alternative; boundary=e89a8f83ae279f7a8d04d02723d9 Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 04:00:28 -0000 --e89a8f83ae279f7a8d04d02723d9 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 9:04 AM, James M Snell wrote: > > On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto < > salvatore.loreto@ericsson.com> wrote: > >> >> During the last couple of weeks there has been a lot of mail discussing >> whether >> WebFinger MUST support HTTPS only or instead it should be allowed for >> WebFinger >> fallback from HTTPS to HTTP. >> There are people with a clear preference (sometime strong) one way or the >> other, >> but also people that are more flexible and also having a preference could >> live with the other. >> >> However the discussion so far has not produced any clear consensus the >> editor can include in the >> next version of the wg draft. >> >> So as chairs I want explicitly to check where the wg consensus is >> >> 1) HTTPS only > > >> versus >> >> 2) HTTPS + HTTP but only as fallback >> > >> So please provide your preference and if you want also the reason why you >> think WebFinger should >> adopt that particular solution. >> > > 3) HTTPS or HTTP... leave the decision up to the server and client > depending on their own specific needs. Servers can enforce the use of https > if that server deems it necessary. Likewise, clients can choose to use > https or http if it deems it necessary. > I'll +1 this third option. It seems abundantly clear that some strongly want HTTP to be supported while some strongly want to ensure that their use will never use HTTP (as a fallback, or at all), but I just don't see the value in specifying that behavior. Implementors and users of WF will sort it all out. Public, "trivial" metadata server? Accept HTTP requests. Writing an authentication flow into your application? Use HTTPS when connecting. If I were to design a library tomorrow, I would probably require the user to specify which should be used. If I were feeling strongly that things should be as simple as possible to play with, I might make it optional and default to HTTP (no hassle, no certs, and one can play with client libraries and IdP code locally, etc). I probably wouldn't implement any fallback at all! The application can simple call my library again and change the parameter. The point is that the least surprising thing to me would be to pick one, but give the user an option. That's what any caring library author should do, IMO. Automatic fallback is useless magic. I suspect many authors trying to craft a general-use WF library would come to a similar conclusion. In the end we will have libraries that are as flexible or strict as their users need them to be, but the spec doesn't need to go there. --e89a8f83ae279f7a8d04d02723d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 5, 2012 a= t 9:04 AM, James M Snell <jasnell@gmail.com> wrote:

On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <salvatore.l= oreto@ericsson.com> wrote:

During the last couple of weeks there has been a lot of mail discussing whe= ther
WebFinger MUST support HTTPS only or instead it should be allowed for WebFi= nger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the o= ther,
but also people that are more flexible and also having a preference could l= ive with the other.

However the discussion so far has not produced any clear consensus the edit= or can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only=C2=A0

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you t= hink WebFinger should
adopt that particular solution.

3) HTTPS or HTTP... leave th= e decision up to the server and client depending on their own specific need= s. Servers can enforce the use of https if that server deems it necessary. = Likewise, clients can choose to use https or http if it deems it necessary.=

I'll +1 this third option.

It = seems abundantly clear that some strongly want HTTP to be supported while s= ome strongly want to ensure that their use will never use HTTP (as a fallba= ck, or at all), but I just don't see the value in specifying that behav= ior. Implementors and users of WF will sort it all out.

Public, "trivial" metadata server? Accept HTTP requests.
<= br>Writing an authentication flow into your application? Use HTTPS when con= necting.

If I were to design a library tomorrow, I would probably re= quire the user to specify which should be used. If I were feeling strongly = that things should be as simple as possible to play with, I might make it o= ptional and default to HTTP (no hassle, no certs, and one can play with cli= ent libraries and IdP code locally, etc). I probably wouldn't implement= any fallback at all! The application can simple call my library again and = change the parameter.

The point is that the least surprising thing to me would be to pick one= , but give the user an option. That's what any caring library author sh= ould do, IMO. Automatic fallback is useless magic. I suspect many authors t= rying to craft a general-use WF library would come to a similar conclusion.=

In the end we will have libraries that are as flexible or strict as the= ir users need them to be, but the spec doesn't need to go there.
--e89a8f83ae279f7a8d04d02723d9-- From duerst@it.aoyama.ac.jp Wed Dec 5 21:12:49 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0F321F8D12 for ; Wed, 5 Dec 2012 21:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGh4bsrg-uFy for ; Wed, 5 Dec 2012 21:12:49 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C621F8BED for ; Wed, 5 Dec 2012 21:12:48 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id qB65Cfss026618 for ; Thu, 6 Dec 2012 14:12:41 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7323_c113_8f74552a_3f63_11e2_8547_001d096c5782; Thu, 06 Dec 2012 14:12:41 +0900 Received: from [IPv6:::1] ([133.2.210.1]:43325) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 6 Dec 2012 14:12:43 +0900 Message-ID: <50C02943.9090301@it.aoyama.ac.jp> Date: Thu, 06 Dec 2012 14:12:35 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Randall Leeds References: <50BF612D.3070001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Salvatore Loreto , webfinger@ietf.org, James M Snell , "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 05:12:49 -0000 On 2012/12/06 13:00, Randall Leeds wrote: > On Wed, Dec 5, 2012 at 9:04 AM, James M Snell wrote: >> On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto< >> salvatore.loreto@ericsson.com> wrote: >>> So as chairs I want explicitly to check where the wg consensus is >>> >>> 1) HTTPS only >> >> >>> versus >>> >>> 2) HTTPS + HTTP but only as fallback >>> >> >>> So please provide your preference and if you want also the reason why you >>> think WebFinger should >>> adopt that particular solution. >>> >> >> 3) HTTPS or HTTP... leave the decision up to the server and client >> depending on their own specific needs. Servers can enforce the use of https >> if that server deems it necessary. Likewise, clients can choose to use >> https or http if it deems it necessary. >> > > I'll +1 this third option. That option would be fine with me, too. Regards, Martin. > It seems abundantly clear that some strongly want HTTP to be supported > while some strongly want to ensure that their use will never use HTTP (as a > fallback, or at all), but I just don't see the value in specifying that > behavior. Implementors and users of WF will sort it all out. > > Public, "trivial" metadata server? Accept HTTP requests. > > Writing an authentication flow into your application? Use HTTPS when > connecting. > > If I were to design a library tomorrow, I would probably require the user > to specify which should be used. If I were feeling strongly that things > should be as simple as possible to play with, I might make it optional and > default to HTTP (no hassle, no certs, and one can play with client > libraries and IdP code locally, etc). I probably wouldn't implement any > fallback at all! The application can simple call my library again and > change the parameter. > > The point is that the least surprising thing to me would be to pick one, > but give the user an option. That's what any caring library author should > do, IMO. Automatic fallback is useless magic. I suspect many authors trying > to craft a general-use WF library would come to a similar conclusion. > > In the end we will have libraries that are as flexible or strict as their > users need them to be, but the spec doesn't need to go there. > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From william_john_mills@yahoo.com Wed Dec 5 21:40:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE221F8D15 for ; Wed, 5 Dec 2012 21:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IefcqCsWgJz2 for ; Wed, 5 Dec 2012 21:40:12 -0800 (PST) Received: from nm34-vm7.bullet.mail.ne1.yahoo.com (nm34-vm7.bullet.mail.ne1.yahoo.com [98.138.229.87]) by ietfa.amsl.com (Postfix) with ESMTP id F36BA21F8D0F for ; Wed, 5 Dec 2012 21:40:11 -0800 (PST) Received: from [98.138.90.49] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 06 Dec 2012 05:40:06 -0000 Received: from [98.138.226.165] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 06 Dec 2012 05:40:06 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 06 Dec 2012 05:40:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 421129.45091.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 56380 invoked by uid 60001); 6 Dec 2012 05:40:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354772405; bh=rP04eovVdo9Wwn6omIJShkIBOHhNzaJfbFvS43rHBM8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OASjsYGCGzXYUjB06waLDDbvgRtcknAG/r1wag5r1uO3ZR45egcylIfNPO5f2AY5G08y2ol7enzC8AGQfCf4yDci84waMR1WptMnkYayebNDaEV83ctLtDYWwrJsjxoNiSJbdSP/rHuQijN2gOCbkDGjpXWSbm9LSQ34iUg0a7o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qTZAXIlDgxIgsfLqHN/dHtI8osuPwN3HbXfET9g+AWopHCjlM5gFvPPZPs33kmLqOKCOyhtOGDUqZ7v72L206uUuzNZgt4euReRMvtAsN0is8CIlkzNp1FwTHQJdqwyROUjpkgcsmCxceuJdyyl5rinMEyvw+QVEZtwdR9R6zlo=; X-YMail-OSG: 5yK5Hw4VM1kESG1EabcINXcoCHLm5qA_ojm_EOwSVOCHNGI A99FA5E7YFicPaxCJGQ3OjmoyzTB29J8zDqr2.H6fRKAug2C0ZGmjY.ve1f_ 5wKQIZqJiXS4ogMe4G8SRmC3oJgV40OWHEcsfUANKOixPcS8APGnRQEvbhNe Dgtp40c6.EtdS9E2zMVBq1wPuCuQ5yc71w_A4JkpfuuUO_kkQRWb_IcQCNAu h.MbRvnsZRzpRCqglWD4tVhTS_XDm0aHG3lkmOdq4zN_n44uO9fINpSr224U IoPK2ezVz7DTF158EkgXTvTU4SXG9zlunVz8SwVigAifG_uNdMDbMgG0iDev ol_yV0gb0L9yLE_rU6J.mxyBAIBe9hdGU..4YXYLtIzHQsvPpl7GW7se6MnO PYpoEhOO5JTf5lyNKC89B5vk5JNHMMasikd0hlLXNPggcXUQHVPGzNRmOpVK JvEmqfQQzmWAw1CKVUyR0xPmb4KYtLPJAw3HG8THaX_6OZlCU6zCHC_FzNGR 63dJt0PL7rZ4F4MWwyPov8I8MzAJlzI9kAdcaG9bqaCzQKTeeGoaWCRD4Jws STbvB0tCwRDghKRZO9FqIDS6MgoZyN9p2RJoJhG7Yzp8wTjub0fNKajPeM1g JpbVRHf6hH1G6kBzwy6Tgy0JRMUHmXnHj9r67E0P6VQVvA_JsBCbMCyny Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Wed, 05 Dec 2012 21:40:05 PST X-Rocket-MIMEInfo: 001.001, KzEKCgoKCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IEpvaG4gUGFuemVyIDxqcGFuemVyQGdvb2dsZS5jb20.Cj5Ubzogd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb20gCj5DYzogd2ViZmluZ2VyQGlldGYub3JnOyBNaWtlIEpvbmVzIDxtaWNoYWVsLmpvbmVzQG1pY3Jvc29mdC5jb20.OyBKYW1lcyBNIFNuZWxsIDxqYXNuZWxsQGdtYWlsLmNvbT47IFRpbSBCcmF5IDx0d2JyYXlAZ29vZ2xlLmNvbT47IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0.IAo.U2UBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.128.478 References: <0ceb01cdd1c9$67a15370$36e3fa50$@packetizer.com> <0d3401cdd1cf$6da29760$48e7c620$@packetizer.com> <0d7e01cdd1e4$6e3a36f0$4aaea4d0$@packetizer.com> <0ec601cdd28b$11b45350$351cf9f0$@packetizer.com> Message-ID: <1354772405.49786.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 5 Dec 2012 21:40:05 -0800 (PST) From: William Mills To: John Panzer , "webfinger@googlegroups.com" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1061947870-1354772405=:49786" Cc: "webfinger@ietf.org" , Mike Jones , James M Snell , Tim Bray , Peter Saint-Andre Subject: Re: [webfinger] WebFinger 8 Input... X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 05:40:14 -0000 --258328648-1061947870-1354772405=:49786 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1=0A=0A=0A=0A=0A>________________________________=0A> From: John Panzer =0A>To: webfinger@googlegroups.com =0A>Cc: webfinger@ietf= .org; Mike Jones ; James M Snell ; Tim Bray ; Peter Saint-Andre =0A>Sent: Tuesday, December 4, 2012 8:25 PM=0A>Subject: Re: [webfinger] W= ebFinger 8 Input...=0A> =0A>=0A>+1.=C2=A0 Well, gopher is beyond the pale o= f course.=0A>data: would be particularly useful.=0A>On Dec 4, 2012 8:05 PM,= "Brad Fitzpatrick" wrote:=0A>=0A>I agree that the we= bfinger response's links should be allowed to be any protocol, be it https:= //, http://, or gopher://.=0A>>=0A>>=0A>>On Tue, Dec 4, 2012 at 5:51 PM, Pa= ul E. Jones wrote:=0A>>=0A>>Tim,=0A>>>=C2=A0=0A>>>P= erhaps we=E2=80=99re discussing different issues.=C2=A0 With respect to whe= ther TLS is used to query the =E2=80=9Cwebfinger=E2=80=9D resource or not, = I understand there are people arguing both sides.=C2=A0 I=E2=80=99m persona= lly neutral on that.=0A>>>=C2=A0=0A>>>Where the discussion was going here w= as related to =E2=80=9Cwhere do link relations in the webfinger response po= int?=E2=80=9D=C2=A0 There is an argument that we must also require that TLS= be used for all link relations.=C2=A0 I disagree with that as a requiremen= t since we=E2=80=99re now talking about where a user stores his data (e.g.,= an avatar).=C2=A0 If he chooses to store that in Flickr or any $1/mo hosti= ng provider should not matter.=C2=A0 Further, any client processing the WF = response could see that it is an =E2=80=9Chttp:=E2=80=9D URI and decide on = a case-by-case basis how to treat each link relation seen.=0A>>>=C2=A0=0A>>= >Paul=0A>>>=C2=A0=0A>>>From:Tim Bray [mailto:twbray@google.com] =0A>>>Sent:= Tuesday, December 04, 2012 2:27 AM=0A>>>To: Paul E. Jones=0A>>>Cc: James M= Snell; webfinger@googlegroups.com; Mike Jones; Peter Saint-Andre=0A>>>=0A>= >>Subject: Re: WebFinger 8 Input...=0A>>>=C2=A0=0A>>>Paul, you can say this= all you want, but there are coherent voices on our mailing list saying tha= t they really need something written into the spec to give them assurance t= hat they can use WF and it=E2=80=99ll either go through TLS or it won=E2=80= =99t happen. =C2=A0There are three coherent come-backs to this:=0A>>>=C2=A0= =0A>>>- Always HTTPS=0A>>>- Some sort of normative parameterized behavior= =0A>>>- Those people shouldn=E2=80=99t use WebFinger.=0A>>>=C2=A0=0A>>>At s= ome point, someone=E2=80=99s going to have to make a consensus call on wher= e the community stands. -T=0A>>>=C2=A0=0A>>>On Mon, Dec 3, 2012 at 9:58 PM,= Paul E. Jones wrote:=0A>>>James,=0A>>>=C2=A0=0A>>>= Keep in mind that WF is to allow users to share all kinds of information ab= out themselves.=C2=A0 Services that need to be secure will use HTTPS.=C2=A0= Those that do not, won=E2=80=99t.=0A>>>=C2=A0=0A>>>If I tell my WF service= that my avatar is located at some http:// location, then that=E2=80=99s th= e information the WF server should return in responses.=0A>>>=C2=A0=0A>>>If= information needs better security, then the URL would be HTTPS.=C2=A0 Any = IdP would utilize an https:// address.=0A>>>=C2=A0=0A>>>In any case, the hr= ef value in WF can be any valid URI. =C2=A0Use or non-use of TLS for these = other resources to which WF refers is really outside the scope of WF.=0A>>>= =C2=A0=0A>>>Paul=0A>>>=C2=A0=0A>>>From:James M Snell [mailto:jasnell@gmail.= com] =0A>>>Sent: Tuesday, December 04, 2012 12:44 AM=0A>>>To: Paul E. Jones= =0A>>>Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-And= re=0A>>>Subject: Re: WebFinger 8 Input...=0A>>>=C2=A0=0A>>>=C2=A0=0A>>>On M= on, Dec 3, 2012 at 7:28 PM, Paul E. Jones wrote:=0A= >>>James,=0A>>>=C2=A0=0A>>>What a WF resource points to should have nothing= to do with whether WF uses HTTPS or not.=C2=A0 If I put my vcard out on th= e Internet accessible only via http (which is presently the case), then tha= t=E2=80=99s the way it=E2=80=99s accessed.=C2=A0 (Actually, the HTTPS versi= on works on my domain, but will redirect the client to the non-HTTPS versio= n.)=0A>>>=C2=A0=0A>>>Well... for a typical non-authenticated request to a W= ebFinger resource, you're correct. There is an obvious risk, however, of in= troducing a session hijacking vulnerability when using authenticated WebFin= ger requests with an improperly secured server if the JRD provides non-http= s links to the same domain. It would be dangerous for us to assume that all= relevant cookies provided on a given domain have been secured properly. As= a best practice, links provided to resources located on the same domain sh= ould simply be required to use https as a way of erring on the side of caut= ion.=C2=A0=0A>>>=C2=A0=0A>>>=C2=A0=0A>>>>During a redirect, the redirection= does not need to use the same scheme if the group agrees to allowing HTTP.= =C2=A0 That said, I fully agree the example in section 8 should show use of= HTTPS just as a means of encouragement.=0A>>>>=C2=A0=0A>>>=C2=A0=0A>>>Issu= ing a https secured request to a WF endpoint that redirects to an insecure = third party location rather defeats the purpose of requiring https for the = first request, doesn't it?=0A>>>=C2=A0=0A>>>- James=0A>>>=C2=A0=0A>>>=C2=A0= =0A>>>Paul=0A>>>>=C2=A0=0A>>>>From:James M Snell [mailto:jasnell@gmail.com]= =0A>>>>Sent: Monday, December 03, 2012 10:01 PM=0A>>>>To: Paul E. Jones=0A= >>>>Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint-Andre= =0A>>>>Subject: Re: WebFinger 8 Input...=0A>>>>=C2=A0=0A>>>>Yep, as expecte= d really. Take the various edits for what they are worth. It was either thi= s or try to go through all the multitude of threads and provide input on ea= ch individual subject... this was by far the more efficient option for me. = I'll come up with a summary of the changes a bit later on this evening. Mos= t are purely editorial in nature, but there are a few important technical i= tems...=C2=A0=0A>>>>=C2=A0=0A>>>>For instance, when serving up a JRD over a= n HTTPS connection, and that JRD contains link relations to resources hoste= d at the same domain as the WebFinger service, there is a risk of a TLS-dow= ngrade attack if those link relations are not https urls... e.g. in the exa= mples we see things like "href": "http://example.com/foo" ... when it reall= y ought to be "href": "https://example.com/foo" ...=0A>>>>=C2=A0=0A>>>>Simi= larly, if we are going to allow the use of 3xx redirects, then the WebFinge= r server needs to make sure that the new target URL is using the https sche= me; i.e. instead of "Location: http://example.net/webfinger?..." it needs t= o be "Location: https://example.net/webfinger?..."=0A>>>>=C2=A0=0A>>>>There= are a few other bits scattered around. Once the kids are bathed and off to= bed I'll write up a summary.=0A>>>>=C2=A0=0A>>>>Honestly, other than the n= eed to control the flood of discussions happening on the mailing list, I do= n't see any reason to rush this to completion. Let's get a relatively stabl= e draft out there and just let it sit for a while so implementors can get m= ore experience with it.=0A>>>>=C2=A0=0A>>>>- James=0A>>>>=C2=A0=0A>>>>On Mo= n, Dec 3, 2012 at 6:45 PM, Paul E. Jones wrote:=0A>= >>>James,=0A>>>>=C2=A0=0A>>>>Wow, that=E2=80=99s a lot of changes.=C2=A0 I= =E2=80=99d personally like to keep the terminology section the way it is.= =C2=A0 The word =E2=80=9Clink relation=E2=80=9D is confusing to people who = have not heard it, and having that very brief statement is useful, I think.= =0A>>>>=C2=A0=0A>>>>Merging the =E2=80=9CIntroduction=E2=80=9D and =E2=80= =9COverview=E2=80=9D sections might be a good idea, but I recall some time = ago there was one section and it was suggested we split it apart.=C2=A0 Wha= t we would put in each, I=E2=80=99m not sure.=C2=A0 It=E2=80=99s definitely= a bit overlapping at the moment.=C2=A0 I=E2=80=99m OK with merging those s= ections.=0A>>>>=C2=A0=0A>>>>I really, really prefer to keep the examples in= the main body. =C2=A0They=E2=80=99re marked as non-normative, but being ab= le to read those before getting further in the document is very helpful to = the reader the first time they read the text.=C2=A0 Heck, even if they=E2= =80=99ve read it, it=E2=80=99s nice to see examples right up front.=C2=A0 O= therwise, the reader=E2=80=99s headed is cloudy all the way through the tex= t.=0A>>>>=C2=A0=0A>>>>The header for Section 2 (=E2=80=9CTerminology=E2=80= =9D) appears to have been removed accidentally.=0A>>>>=C2=A0=0A>>>>In secti= on 8, there are bullet points for the IANA registration template material.= =C2=A0 Those should not be there.=0A>>>>=C2=A0=0A>>>>Don=E2=80=99t use =E2= =80=9CURI=E2=80=9D before the instant messaging address in the contact area= .=C2=A0 Email addresses are also URIs :-)=C2=A0 I wanted IM there.=0A>>>>= =C2=A0=0A>>>>Beyond that, the changes are so substantial that I=E2=80=99ll = need time to see exactly what they are.=C2=A0 I tried to produce a meaningf= ul diff, but since the whole example section was moved, diff programs gets = totally confused.=0A>>>>=C2=A0=0A>>>>Paul=0A>>>>=C2=A0=0A>>>>From:James M S= nell [mailto:jasnell@gmail.com] =0A>>>>Sent: Monday, December 03, 2012 8:38= PM=0A>>>>To: webfinger@googlegroups.com; Paul Jones; Tim Bray=0A>>>>Subjec= t: WebFinger 8 Input...=0A>>>>=C2=A0=0A>>>>Given that the recent WebFinger = discussion has been flooding and overwhelming the IETF appsawg mailing list= I have left that mailing list off the cc list until the new WF specific ma= iling list has been set up. While reading through the latest version of the= spec, I started to collect a list of specific edits that I thought needed = to be made. The list became rather detailed so it ended up just being easie= r to draft up a proposed new version.=0A>>>>=C2=A0=0A>>>>I have checked it = in to my personal github repo here...=0A>>>>=C2=A0=0A>>>>=C2=A0=C2=A0http:/= /goo.gl/IaQnm=0A>>>>=C2=A0=0A>>>>The raw xml is here...=0A>>>>=C2=A0=0A>>>>= =C2=A0=C2=A0http://goo.gl/QcNCr=0A>>>>=C2=A0=0A>>>>As always, feedback is d= efinitely welcome.=0A>>>>=C2=A0=0A>>>>- James=0A>>>>=C2=A0=0A>>>=C2=A0=0A>>= >=C2=A0=0A>>=0A>_______________________________________________=0A>webfinge= r mailing list=0A>webfinger@ietf.org=0A>https://www.ietf.org/mailman/listin= fo/webfinger=0A>=0A>=0A> --258328648-1061947870-1354772405=:49786 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

From:<= /b> John Panzer <jpanzer@google.com>
To: webfinger@googlegroups.com
Cc: webfinger@ietf.org; Mike Jones <michae= l.jones@microsoft.com>; James M Snell <jasnell@gmail.com>; Tim Bra= y <twbray@google.com>; Peter Saint-Andre <stpeter@stpeter.im> <= br> Sent: Tuesday, December 4, 2012 8:= 25 PM
Subject: Re: [we= bfinger] WebFinger 8 Input...

+1.  Well, gopher is beyond the pale of course.=0A
data: would be particularly useful.
=0A
On Dec 4, 2012 8:05 PM, "Brad Fitzpatrick" &= lt;bradfitz@google.com> wrote:=
=0A
I agree that the webfinger = response's links should be allowed to be any protocol, be it https://, http= ://, or gopher://.

=0A= =0AOn Tue, Dec 4, 2012 at 5:51 PM, Paul E. Jones <paulej@packetizer.com> = wrote:
=0A=0A
Tim,
=0A=0A&= nbsp;
Perhaps we=E2=80=99re discussing diffe= rent issues.  With respect to whether TLS is used to query the =E2=80= =9Cwebfinger=E2=80=9D resource or not, I understand there are people arguin= g both sides.  I=E2=80=99m personally neutral on that.
=0A=0A
 
Where= the discussion was going here was related to =E2=80=9Cwhere do link relati= ons in the webfinger response point?=E2=80=9D  There is an argument th= at we must also require that TLS be used for all link relations.  I di= sagree with that as a requirement since we=E2=80=99re now talking about whe= re a user stores his data (e.g., an avatar).  If he chooses to store t= hat in Flickr or any $1/mo hosting provider should not matter.  Furthe= r, any client processing the WF response could see that it is an =E2=80=9Ch= ttp:=E2=80=9D URI and decide on a case-by-case basis how to treat each link= relation seen.
=0A=0A
 <= /u>
Paul
=0A=0A
=  
=0A=0A
From: Tim Bray [mailto:twbray@google.com]
=0A=0ASent: Tuesday, Decembe= r 04, 2012 2:27 AM
To: Paul E. Jones
Cc: James M Snell;= webfinger@googlegrou= ps.com; Mike Jones; Peter Saint-Andre
=0A=0A

Sub= ject: Re: WebFinger 8 Input...
 
Paul, you can say th= is all you want, but there are coherent voices on our mailing list saying t= hat they really need something written into the spec to give them assurance= that they can use WF and it=E2=80=99ll either go through TLS or it won=E2= =80=99t happen.  There are three coherent come-backs to this:
=0A=0A
 
- Always H= TTPS
=0A=0A
- Some sort of normative parame= terized behavior
=0A- Those people shouldn= =E2=80=99t use WebFinger.
=0A
 =
At some point, someone=E2=80=99s going to have t= o make a consensus call on where the community stands. -T
=0A=0A
 
On Mon, Dec 3,= 2012 at 9:58 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=0A=0A
James,
 
=0A=0A
Keep in mind that WF is to allow users to= share all kinds of information about themselves.  Services that need = to be secure will use HTTPS.  Those that do not, won=E2=80=99t.=
=0A=0A
 
If I tell my WF service that my avatar is located at some http:// loca= tion, then that=E2=80=99s the information the WF server should return in re= sponses.
=0A=0A
 <= /u>
If information needs better security, then the URL would= be HTTPS.  Any IdP would utilize an https:// address.
=0A=0A
 
In an= y case, the href value in WF can be any valid URI.  Use or non-use of = TLS for these other resources to which WF refers is really outside the scop= e of WF.
=0A=0A
 <= /u>
Paul
=0A=0A
 
=0A=0A
From: James M Snell [mailto:jasnell@gmail.com]
=0A=0ASent: Tuesday, December 04= , 2012 12:44 AM
To: Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray= ; Mike Jones; Peter Saint-Andre
=0A=0ASubject: Re: WebFinger 8 In= put...
 
=  
On Mon,= Dec 3, 2012 at 7:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:
=0A=0A
James,
 
=0A=0A
What a WF resource points to should have = nothing to do with whether WF uses HTTPS or not.  If I put my vcard ou= t on the Internet accessible only via http (which is presently the case), t= hen that=E2=80=99s the way it=E2=80=99s accessed.  (Actually, the HTTP= S version works on my domain, but will redirect the client to the non-HTTPS= version.)
=0A=0A
 
Well... for a typical non-authenticated request to a W= ebFinger resource, you're correct. There is an obvious risk, however, of in= troducing a session hijacking vulnerability when using authenticated WebFin= ger requests with an improperly secured server if the JRD provides non-http= s links to the same domain. It would be dangerous for us to assume that all= relevant cookies provided on a given domain have been secured properly. As= a best practice, links provided to resources located on the same domain sh= ould simply be required to use https as a way of erring on the side of caut= ion. 
=0A=0A
 
=0A=0A
 
During a redirect, the re= direction does not need to use the same scheme if the group agrees to allow= ing HTTP.  That said, I fully agree the example in section 8 should sh= ow use of HTTPS just as a means of encouragement.=0A=0A
 
=
 
= =0A=0A
Issuing a https secured req= uest to a WF endpoint that redirects to an insecure third party location ra= ther defeats the purpose of requiring https for the first request, doesn't = it?
=0A=0A
 
- James
 
=  
=0A=0A
= Paul
 
= =0A=0A
From: James M Snell [mailto:jasnell@gmail.c= om]
=0A=0ASent: Monday, December 03, 2012 10:01 PM
To:= Paul E. Jones
Cc: webfinger@googlegroups.com; Tim Bray; Mike Jones; Peter Saint= -Andre
=0A=0ASubject: Re: WebFinger 8 Input...
 
Yep= , as expected really. Take the various edits for what they are worth. It wa= s either this or try to go through all the multitude of threads and provide= input on each individual subject... this was by far the more efficient opt= ion for me. I'll come up with a summary of the changes a bit later on this = evening. Most are purely editorial in nature, but there are a few important= technical items... 
=0A=0A
 
For instance, when serving up a= JRD over an HTTPS connection, and that JRD contains link relations to reso= urces hosted at the same domain as the WebFinger service, there is a risk o= f a TLS-downgrade attack if those link relations are not https urls... e.g.= in the examples we see things like "href": "http://example.com/foo" ... whe= n it really ought to be "href": "https://example.com/foo" ...=
=0A=0A
 <= u>
Similarly, if we are going to allow the use of 3xx redirects, then the We= bFinger server needs to make sure that the new target URL is using the http= s scheme; i.e. instead of "Location: http://example.net/webfinger?..." it needs to be "Location: https://example.net/webfinger?..."
=0A=0A
 
There are a few other bits scattered around. Once the k= ids are bathed and off to bed I'll write up a summary.=
=0A=0A
 
Honestly, other than the need to control the flood of discussions happenin= g on the mailing list, I don't see any reason to rush this to completion. L= et's get a relatively stable draft out there and just let it sit for a whil= e so implementors can get more experience with it.=0A=0A
 
- J= ames
=0A=0A 
On Mon, Dec 3, 2012 at 6:45 PM= , Paul E. Jones <paulej@packet= izer.com> wrote:
=0A=0AJames,=
 
=0A= =0A
Wow, that=E2=80=99s a lot of changes.  I=E2=80=99d person= ally like to keep the terminology section the way it is.  The word =E2= =80=9Clink relation=E2=80=9D is confusing to people who have not heard it, = and having that very brief statement is useful, I think.
=0A=0A
 
Merging = the =E2=80=9CIntroduction=E2=80=9D and =E2=80=9COverview=E2=80=9D sections = might be a good idea, but I recall some time ago there was one section and = it was suggested we split it apart.  What we would put in each, I=E2= =80=99m not sure.  It=E2=80=99s definitely a bit overlapping at the mo= ment.  I=E2=80=99m OK with merging those sections.
=0A=0A
 
I really,= really prefer to keep the examples in the main body.  They=E2=80=99re= marked as non-normative, but being able to read those before getting furth= er in the document is very helpful to the reader the first time they read t= he text.  Heck, even if they=E2=80=99ve read it, it=E2=80=99s nice to = see examples right up front.  Otherwise, the reader=E2=80=99s headed i= s cloudy all the way through the text.
=0A=0A 
The header for Section 2 (= =E2=80=9CTerminology=E2=80=9D) appears to have been removed accidentally.
=0A=0A
 
<= div class=3D"yiv365522807MsoNormal">In section 8, there are bullet points for the IANA registration te= mplate material.  Those should not be there.=0A=0A
 
Don=E2=80=99t u= se =E2=80=9CURI=E2=80=9D before the instant messaging address in the contac= t area.  Email addresses are also URIs :-)  I wanted IM there.
=0A=0A
 
Beyond that, the changes are so substantial that I=E2=80=99ll need = time to see exactly what they are.  I tried to produce a meaningful di= ff, but since the whole example section was moved, diff programs gets total= ly confused.
=0A=0A
 =
Paul
=0A=0A
 = ;
=0A=0A
From: James M Snell [mailto:jasnell@gmail.com]
=0A=0ASent: Monday, December= 03, 2012 8:38 PM
To: webfinger@googlegroups.com; Paul Jones; Tim Bray
Subject= : WebFinger 8 Input...
=0A=0A
 
Given that the recent WebFi= nger discussion has been flooding and overwhelming the IETF appsawg mailing= list I have left that mailing list off the cc list until the new WF specif= ic mailing list has been set up. While reading through the latest version o= f the spec, I started to collect a list of specific edits that I thought ne= eded to be made. The list became rather detailed so it ended up just being = easier to draft up a proposed new version.
=0A=0A=
 
<= div>
I have checked it= in to my personal github repo here...
=0A=0A 
=0A=0A 
The raw xml is here...
 
 
=0A=0AAs always, feedback is = definitely welcome.
 
- James
=0A=0A=
 
 <= /u>
=0A=0A
 =
=0A=0A=0A
_________________= ______________________________
webfinger mailing list
webfinger@ietf= .org
https://www.ietf.org/mailman/listinfo/webfinger

<= br> --258328648-1061947870-1354772405=:49786-- From william_john_mills@yahoo.com Wed Dec 5 21:51:58 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE121F8BAE for ; Wed, 5 Dec 2012 21:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.448 X-Spam-Level: X-Spam-Status: No, score=-17.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahvw59ibmGkQ for ; Wed, 5 Dec 2012 21:51:57 -0800 (PST) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0421F89FE for ; Wed, 5 Dec 2012 21:51:56 -0800 (PST) Received: from [98.139.212.145] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 06 Dec 2012 05:51:54 -0000 Received: from [98.139.212.250] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 06 Dec 2012 05:51:54 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 06 Dec 2012 05:51:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 277122.45315.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 44909 invoked by uid 60001); 6 Dec 2012 05:51:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354773113; bh=HeZounnbTiMTrAITgAw4zrAnvss5WqF1IUWeB2iB4iw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=t5d5fRSjCr9LvcDrsRD1/ykXJ3wYIDZVCEL0iB7vpKIeyUNgLecdhYzYmnZg6q2uoddR1ssnwNmnIozyYll0he/Fhjj5ECKpatb67JneCQsyeWXvXPq9Qm+fTKcklQa0V5mXpn2HcAsmjr/aZsAawOmIk6sW9k7Fj04jp6pihqI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Bdacp5OnVOsXtO5eTDeVG7xYBFKuHqgQj36j3H7YfW2aeGFC/gY7Mndtdii/mFihqEEyNpNxKybjeqyeMyM8nK8vAL4XNWK6s9kTWcAvgReZnGFFDXuJMr3D/oqT2HQJ2VXbZ1QgDz91nB9zszX5pAG2ySrXki4ds2B8pntjAw8=; X-YMail-OSG: 8epVeXAVM1lmnyk9UmFnqk4wOeP6BfLeiOM5uCM2qwveQJK aWzOPCvcrAPSgcLvorKW_A0LBSoFvWq8LNkP0PEs7yzR1IKPOyDpOTG72TSp b_bn6fgbwUqdnEllWbGnrNd2A5nQjjtmudAlRojq1.GbF.Q1A5_Yy3DF.Q8n Fye63X3GL7osX2yoDOt.qQyTpt6TZPCKCE.IDKpN6o.FgMm_Jm5Jf95XbpXZ qbC4ZSvCiYElJJdG9RB0HcVAZ3aKXtEt94OjHK4TrTiwqrSKTzag4JTUX5Fz pmHWz5k01FzmD0fFkbeoLbXhaPiDJdwIQWKtiEv5HEAihB4gb_y_o7hHLeWO 70F27_kusuAYdVIBR6j9.LBkaQnwDGgJl6wVCCc6g1fC6Si5ZRGt4F0rnz32 DS.r4F2XXhtaUSHrQgzWegkKtnz11NwWMrRa_umJvWJ1w7.lgJtafq1mc6P6 Gb.d1Az3d5.skgMaJ8QwyFBdb5ekvsKs- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Wed, 05 Dec 2012 21:51:53 PST X-Rocket-MIMEInfo: 001.001, SSdtIGluIHRoZcKgICMxIG9yICMzIGJ1dCBub3QgIzIgY2FtcC4KCgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiAiIk1hcnRpbiBKLiBEw7xyc3QiIiA8ZHVlcnN0QGl0LmFveWFtYS5hYy5qcD4KPlRvOiBSYW5kYWxsIExlZWRzIDxyYW5kYWxsLmxlZWRzQGdtYWlsLmNvbT4gCj5DYzogU2FsdmF0b3JlIExvcmV0byA8c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20.OyB3ZWJmaW5nZXJAaWV0Zi5vcmc7IEphbWVzIE0gU25lbGwgPGphc25lbGxAZ21haWwuY29tPjsgTXUBMAEBAQE- X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.128.478 References: <50BF612D.3070001@ericsson.com> <50C02943.9090301@it.aoyama.ac.jp> Message-ID: <1354773113.42778.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 5 Dec 2012 21:51:53 -0800 (PST) From: William Mills To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Randall Leeds In-Reply-To: <50C02943.9090301@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1755160348-1354773113=:42778" Cc: Salvatore Loreto , "webfinger@ietf.org" , James M Snell , "Murray S. Kucherawy" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 05:51:58 -0000 --835683298-1755160348-1354773113=:42778 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm in the=A0 #1 or #3 but not #2 camp.=0A=0A=0A=0A=0A=0A>_________________= _______________=0A> From: ""Martin J. D=FCrst"" =0A= >To: Randall Leeds =0A>Cc: Salvatore Loreto ; webfinger@ietf.org; James M Snell ; Murray S. Kucherawy =0A>Sent: Wednesday, Dece= mber 5, 2012 9:12 PM=0A>Subject: Re: [webfinger] Consensus call: HTTPS only= vs HTTPS-and-HTTP=0A> =0A>On 2012/12/06 13:00, Randall Leeds wrote:=0A>> O= n Wed, Dec 5, 2012 at 9:04 AM, James M Snell=A0 wrote:= =0A>=0A>>> On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto<=0A>>> salvator= e.loreto@ericsson.com>=A0 wrote:=0A>=0A>>>> So as chairs I want explicitly = to check where the wg consensus is=0A>>>>=0A>>>> 1) HTTPS only=0A>>>=0A>>>= =0A>>>> versus=0A>>>>=0A>>>> 2) HTTPS + HTTP but only as fallback=0A>>>>=0A= >>>=0A>>>> So please provide your preference and if you want also the reaso= n why you=0A>>>> think WebFinger should=0A>>>> adopt that particular soluti= on.=0A>>>>=0A>>>=0A>>> 3) HTTPS or HTTP... leave the decision up to the ser= ver and client=0A>>> depending on their own specific needs. Servers can enf= orce the use of https=0A>>> if that server deems it necessary. Likewise, cl= ients can choose to use=0A>>> https or http if it deems it necessary.=0A>>>= =0A>>=0A>> I'll +1 this third option.=0A>=0A>That option would be fine with= me, too.=0A>=0A>Regards,=A0 Martin.=0A>=0A>> It seems abundantly clear th= at some strongly want HTTP to be supported=0A>> while some strongly want to= ensure that their use will never use HTTP (as a=0A>> fallback, or at all),= but I just don't see the value in specifying that=0A>> behavior. Implement= ors and users of WF will sort it all out.=0A>>=0A>> Public, "trivial" metad= ata server? Accept HTTP requests.=0A>>=0A>> Writing an authentication flow = into your application? Use HTTPS when=0A>> connecting.=0A>>=0A>> If I were = to design a library tomorrow, I would probably require the user=0A>> to spe= cify which should be used. If I were feeling strongly that things=0A>> shou= ld be as simple as possible to play with, I might make it optional and=0A>>= default to HTTP (no hassle, no certs, and one can play with client=0A>> li= braries and IdP code locally, etc). I probably wouldn't implement any=0A>> = fallback at all! The application can simple call my library again and=0A>> = change the parameter.=0A>>=0A>> The point is that the least surprising thin= g to me would be to pick one,=0A>> but give the user an option. That's what= any caring library author should=0A>> do, IMO. Automatic fallback is usele= ss magic. I suspect many authors trying=0A>> to craft a general-use WF libr= ary would come to a similar conclusion.=0A>>=0A>> In the end we will have l= ibraries that are as flexible or strict as their=0A>> users need them to be= , but the spec doesn't need to go there.=0A>>=0A>>=0A>>=0A>>=0A>> _________= ______________________________________=0A>> webfinger mailing list=0A>> web= finger@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/webfinger=0A>___= ____________________________________________=0A>webfinger mailing list=0A>w= ebfinger@ietf.org=0A>https://www.ietf.org/mailman/listinfo/webfinger=0A>=0A= >=0A> --835683298-1755160348-1354773113=:42778 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm in th= e  #1 or #3 but not #2 camp.


<= blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5= px; margin-top: 5px; padding-left: 5px;">
= From: ""Martin J. D=FCrst"" &l= t;duerst@it.aoyama.ac.jp>
To:<= /span> Randall Leeds <randall.leeds@gmail.com>
Cc: Salvatore Loreto <salvatore.loret= o@ericsson.com>; webfinger@ietf.org; James M Snell <jasnell@gmail.com= >; Murray S. Kucherawy <superuser@gmail.com>
Sent: Wednesday, December 5, 2012 9:12 PM
Subject: Re: [webfinger] Consensus ca= ll: HTTPS only vs HTTPS-and-HTTP

On 2012/12/06 13:00= , Randall Leeds wrote:
> On Wed, Dec 5, 2012 at 9:04 AM, James M Snel= l<jasnell@gmail.com>  wrote:

>> On Wed, Dec 5, 2= 012 at 6:58 AM, Salvatore Loreto<
>> sal= vatore.loreto@ericsson.com>  wrote:

>>> So as c= hairs I want explicitly to check where the wg consensus is
>>><= br>>>> 1) HTTPS only
>>
>>
>>> versu= s
>>>
>>> 2) HTTPS + HTTP but only as fallback
>>>
>>
>>> So please provide you= r preference and if you want also the reason why you
>>> think = WebFinger should
>>> adopt that particular solution.
>>= ;>
>>
>> 3) HTTPS or HTTP... leave the decision up to = the server and client
>> depending on their own specific needs. Se= rvers can enforce the use of https
>> if that server deems it nece= ssary. Likewise, clients can choose to use
>> https or http if it = deems it necessary.
>>
>
> I'll +1 this third option.<= br>
That option would be fine with me, too.

Regards,  Marti= n.

> It seems abundantly clear that some strongly want HTTP to be= supported
> while some strongly want to ensure that their use will n= ever use HTTP (as a
> fallback, or at all), but I just don't see the = value in specifying that
> behavior. Implementors and users of WF will sort it all out.
>
> Public, "trivial" metadata server= ? Accept HTTP requests.
>
> Writing an authentication flow into= your application? Use HTTPS when
> connecting.
>
> If I = were to design a library tomorrow, I would probably require the user
>= ; to specify which should be used. If I were feeling strongly that things> should be as simple as possible to play with, I might make it option= al and
> default to HTTP (no hassle, no certs, and one can play with = client
> libraries and IdP code locally, etc). I probably wouldn't im= plement any
> fallback at all! The application can simple call my lib= rary again and
> change the parameter.
>
> The point is t= hat the least surprising thing to me would be to pick one,
> but give= the user an option. That's what any caring library author should
> d= o, IMO. Automatic fallback is useless magic. I suspect many authors trying
> to craft a general-use WF library would come to a similar c= onclusion.
>
> In the end we will have libraries that are as fl= exible or strict as their
> users need them to be, but the spec doesn= 't need to go there.
>
>
>
>
> ______________= _________________________________
> webfinger mailing list
> w= ebfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webf= inger
_______________________________________________
webfinger m= ailing list
webfinger@ietf.org
https://www.ietf.org/mailman/l= istinfo/webfinger


=20
--835683298-1755160348-1354773113=:42778-- From mmn@hethane.se Thu Dec 6 01:21:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366DA21F854E for ; Thu, 6 Dec 2012 01:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpL34e8VxwNe for ; Thu, 6 Dec 2012 01:21:38 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 913FE21F853F for ; Thu, 6 Dec 2012 01:21:38 -0800 (PST) From: Mikael Nordfeldth To: "Martin J." =?ISO-8859-1?Q?D=FCrs?= , Randall Leeds X-Mailer: Modest 3.90.7 References: <50BF612D.3070001@ericsson.com> <50C02943.9090301@it.aoyama.ac.jp> In-Reply-To: <50C02943.9090301@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-ID: <1354786272.9346.1.camel@Nokia-N900> Date: Thu, 06 Dec 2012 10:31:14 +0100 Message-Id: <1354786274.9346.2.camel@Nokia-N900> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mikael Nordfeldth List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:21:39 -0000 On tor  6 dec 2012 06:12:35, "Martin J. Dürst" wrote: > On 2012/12/06 13:00, Randall Leeds wrote: > > On Wed, Dec 5, 2012 at 9:04 AM, James M Snell > > wrote: > > > > > > > 3) HTTPS or HTTP... leave the decision up to the server and client > > > depending on their own specific needs. Servers can enforce the use > > > of https if that server deems it necessary. Likewise, clients can > > > choose to use https or http if it deems it necessary. > > > > > > > I'll +1 this third option. > > That option would be fine with me, too. Yes. The third option is my favorite. It does not assume developers can be fixed by just giving them a more restrictive toolkit. From perpetual-tripper@wwelves.org Thu Dec 6 01:38:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7921F8629 for ; Thu, 6 Dec 2012 01:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.761 X-Spam-Level: X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwbD3fh-Av66 for ; Thu, 6 Dec 2012 01:38:25 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9080421F8624 for ; Thu, 6 Dec 2012 01:38:25 -0800 (PST) X-Originating-IP: 217.70.178.129 Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 2FC00172090 for ; Thu, 6 Dec 2012 10:38:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 9Ew-fqhdYybp for ; Thu, 6 Dec 2012 10:38:12 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D96EF1720BC for ; Thu, 6 Dec 2012 10:38:12 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: webfinger In-reply-to: <3468a2e2b3a8000725e84a2f15b76829@hethane.se> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> Date: Thu, 06 Dec 2012 09:38:11 +0000 Message-Id: <1354786441-sup-4934@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:38:26 -0000 Excerpts from Mikael Nordfeldth's message of 2012-12-06 00:17:46 +0000: > 06.12.2012 01:04 skrev Brad Fitzpatrick: > > Well, actually, the latest draft didn't specify which Root CAs were > > consulted. It just says to verify the certs. Perhaps an=20 > > HTTPS-only+TOFU > > WebFinger client is a conforming client. >=20 > Yes, but my server would be out of reach for anyone else. how about keeping it HTTPS only just to cut off very basic threats and at= the same time make a informative reference to work done on supporting CA= cert and other autonomous CAs? i would expect that for now people would u= se *mainstream* CAs and just get certs from StartSSL which don't require = payment with money, but in a long run we can start facing this issue in a= systematic way. one day we need to fix this CA problem anyhow :) From perpetual-tripper@wwelves.org Thu Dec 6 01:38:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DCE21F8629 for ; Thu, 6 Dec 2012 01:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWCg4TanPtoY for ; Thu, 6 Dec 2012 01:38:59 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1406621F8624 for ; Thu, 6 Dec 2012 01:38:59 -0800 (PST) X-Originating-IP: 217.70.178.139 Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 67F8417207E for ; Thu, 6 Dec 2012 10:38:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IoWnn1N7C0tR for ; Thu, 6 Dec 2012 10:38:47 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 054F417208F for ; Thu, 6 Dec 2012 10:38:47 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: webfinger In-reply-to: <50BF612D.3070001@ericsson.com> References: <50BF612D.3070001@ericsson.com> Date: Thu, 06 Dec 2012 09:38:46 +0000 Message-Id: <1354786700-sup-968@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:38:59 -0000 +1 HTTPS only From nick@silverbucket.net Thu Dec 6 02:37:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4569821F85C6 for ; Thu, 6 Dec 2012 02:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJmtOUkqIkUe for ; Thu, 6 Dec 2012 02:37:47 -0800 (PST) Received: from mail-lb0-f194.google.com (mail-lb0-f194.google.com [209.85.217.194]) by ietfa.amsl.com (Postfix) with ESMTP id E79A121F8514 for ; Thu, 6 Dec 2012 02:37:38 -0800 (PST) Received: by mail-lb0-f194.google.com with SMTP id gf7so731034lbb.1 for ; Thu, 06 Dec 2012 02:37:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=W8L0vyEDSQD6vW147ZykveLlw8Je3hibQ575JvfsvyA=; b=fvEWksLHiYVZvzlacsOaZbGqWp79P9giD1Eh2zSraer98VLHNYuW77/rdEQ3HF5fsU VeRiwnd8/7AUuljth2dDNiwx8O7+vBPWcGx5or60OrPAseRgbVfHxJQdTwBMDpxVg6Nv Oj8tTka9Uwe1owcndxtqiTjwgof1jNhBgMg9QhwXXaGmh2Y+7CjS2jIAq+rgW3ywJcU1 4RJC2Gj6oXhEtAAkvKnQNbgz7gmM8n99usd/QSH+8zF25pQhwf73MmDTfc0xiaouyPfz ja142ZLmS+ZSPhu9W6IsNTi5C7oy/m/t3mJQ2kYPr4gHaM950eXbFz94+XDEbK6A65sf GSzQ== Received: by 10.152.124.111 with SMTP id mh15mr1126790lab.20.1354790257717; Thu, 06 Dec 2012 02:37:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id pg5sm1764014lab.6.2012.12.06.02.37.36 (version=SSLv3 cipher=OTHER); Thu, 06 Dec 2012 02:37:37 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so5301635lah.31 for ; Thu, 06 Dec 2012 02:37:36 -0800 (PST) Received: by 10.152.105.173 with SMTP id gn13mr1101412lab.41.1354790256486; Thu, 06 Dec 2012 02:37:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 6 Dec 2012 02:37:04 -0800 (PST) In-Reply-To: <3FC2D4E4-44A5-4318-B330-E99A77F185A2@josephholsten.com> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <3FC2D4E4-44A5-4318-B330-E99A77F185A2@josephholsten.com> From: Nick Jennings Date: Thu, 6 Dec 2012 11:37:04 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkDQx1tI5bamFYH6di1fu7NYrAie7uzcV2V7Yd4V4xI4mERcWxk2Vvc8ZNu7e2DIZejDkp6 Cc: "webfinger@ietf.org" , Evan Prodromou Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 10:37:48 -0000 On Thu, Dec 6, 2012 at 7:56 AM, Joseph Holsten w= rote: > On Dec 5, 2012, at 13:26, Nick Jennings wrote: > >> On Wed, Dec 5, 2012 at 8:59 PM, Brad Fitzpatrick w= rote: >>> I don't believe that's the security argument. >>> >>> I understand it more as: If we mandate complexity (in the spec), we wi= ll >>> get complexity (in clients, per the spec), and in complexity lies secur= ity >>> problems (clients not having HTTPS-only modes). >>> >>> Whereas if we say "HTTPS-only" in the spec, it will lead to simpler cli= ents >>> lacking options which are then secure-by-default. >> >> >> Although I like the idea of keeping it simple and secure by default, >> I'm starting to lean on the side of *both* being optional. The more I >> think about it, the more it really should be the decision of the >> client library, not the server, as to what type of query they are >> going to make. The server can, of course, restrict HTTP requests if >> it's serving sensitive data. > > As an implementor, you've gone from two test cases (success via https in = secure mode, failure to discover) and added three more (success via https i= n insecure mode, sucess via http fallback in insecure mide, and failure via= http fallback in https only mode) that I have to test. > Are you talking about the library itself or the user of the library? In the case of the library, you don't really have to 'test' for whether the success was via https or http as long as we are not supporting downgrading (which I don't think we should). >From the perspective of the user of the library, you'd specify your requirements when initializing the library. > That's not counting the myriad redirects, timeouts, retries and caching = that a mature client requires. Retries and timeouts would definitely suck when having to consider a 'fallback' option in the library. Though you don't have to implement a fallback. In which case, the client implementation would be no different if we go with option #3 >> By forcing HTTPS, or even requiring it as the initial query, we're not >> allowing the client library to be optimized for it's task. There are >> performance hits, and if you multiply that for situations where the >> client app may need to make hundreds or thousands of requests, that beco= mes a valid consideration. > > If you're talking about thousands of requests in any small amount if time= , and you're afraid of the processing and latency https adds, you basically= aren't mature enough to be calling any external SaaS. Much less calling tw= itter, facebook, google plus, or any other social network for their data. I was actually talking about browser-side requests (since we specify the need for CORS headers), not server-side. So it has nothing to do with my "maturity" ... though now that you mention it, I guess I should get a job. :) > I work at a social media analytics company. We pull large quantities ad t= his kind of data all day long. And we've had to build frustratingly complex= exception handling, retrying, timeouts and scheduling into our data collec= tors to get deal with these APIs that are officially blessed by the social = networks in question. Do you think the same SLAs will apply to an insecure,= public data only, weird discovery protocol that isn't core to their busine= ss? > > And you think a shop should be afraid of https? Afraid? Absolutely not. I was just bringing up the point that some situations (ie. web apps) may want to optimize as best they can. If the data is trivial, why not use HTTP. > And another thing. Latency? You're making an https request first, waitin= g for connect() to time out, then making an http request, right? Or are you= calling http directly, then getting redirected to https on sites that requ= ire it? Which particular latency should my client library be trying to avoi= d? I meant the additional latency of the HTTPS protocol itself (more noticeable on high latency mobile networks). I wasn't referring to fallback. > Also, please stop thinking of this as just a spec. This isn't us agreeing= to a spec. This is agreeing to how we want our implementations to work tog= ether, and writing it down. If you weren't interested in actually creating = working code, why would anyone be interested in achieving rough consensus w= ith you? What ever gave you the impression that I'm not interested in creating working code? In fact that's exactly why I became involved in WebFinger, it's a key part of the current projects I work on in the open-source world, and could potentially be adopted, in some form, at the companies where I manage development and technology decisions. I see WebFinger as a crucial piece of most of my development moving forward. That said, I was merely bringing up holes I saw in the HTTPS-only boat, which I've also been in this past week. I'm not so sure anymore, option #3 sounds good for adoption and allowing for more use-cases, but I would go with #1 if that was the consensus. I definitely don't like #2. -Nick From paulej@packetizer.com Thu Dec 6 11:50:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69E21F8941 for ; Thu, 6 Dec 2012 11:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-1.582, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAqUbl5H72Bl for ; Thu, 6 Dec 2012 11:50:00 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3E21F8937 for ; Thu, 6 Dec 2012 11:50:00 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qB6Jnwkb029270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Dec 2012 14:49:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354823399; bh=9ZJ0hwRczv02P/E1s0PWtxNCCZQF2Hu0TiHUwJM0fQI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=fCuTFFCkoah5QTiTGqf7uikwjiisDxTZKxrV3QLQRFmr5scx99NHOK8OE7s+TG9Z1 5sl3xEeqaYENdDqPJyt5Sl/QyOaggmZWeyTPAZuney5Ndmm0l3BXgdFL3kIHOC6X3Z sLXIXUbDzJZjo+DQSCTWFk4b6RmimEB/y67UJSwo= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , , References: In-Reply-To: Date: Thu, 6 Dec 2012 14:50:04 -0500 Message-ID: <00b301cdd3ea$e38f26b0$aaad7410$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00B4_01CDD3C0.FABA3020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJxbLV+5TPolvlk9MFIbS96PGZHHZbE6jzQ Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] About "resource", host-wide info and jrd X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:50:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B4_01CDD3C0.FABA3020 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B5_01CDD3C0.FABA3020" ------=_NextPart_001_00B5_01CDD3C0.FABA3020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Walter, =20 I=92ve not seen any comments on this, so let me ask question and make comments. =20 What would be the expected response if the =93resource=94 parameter was = not present? You said: =20 The omission of the =93resource=94 parameter would also be useful in = mobile networks where the app does not know the actual identity of the user = (and may not be entitled to) but only the server does. In this case the = server could answer anyway with some user specific information and could include an acr: URI as an opaque = identifier in the =93subject=94 not to reveal the actual user identity. =20 How would it help to return a document that is not user-specific? If = the server provides replies for 1,000,000 users, what user-specific = information would it return without an identifier? =20 We could certainly allow the server to return a default JRD of some sort = if no user-specific information is supplied, but it just takes in the = direction of RFC 6415. So, if that=92s the kind of solution you want, then I=92d = suggest you do that. Both RFC 6415 and WebFinger are related in that one was derived from the other (albeit, significantly modified and simplified). However, it seems reasonable to me that both can go forward. And, it is made simpler if both support a common format like JRD. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Goix Laurent Walter Sent: Wednesday, December 05, 2012 5:02 AM To: webfinger@ietf.org; webfinger@googlegroups.com Subject: [webfinger] About "resource", host-wide info and jrd =20 Hi all, =20 I=92d like to bring here the discussion on the mandatory usage of the =93resource=94 parameter and the access to host-wide information. =20 I understand that webfinger now moved away from rfc6415, and the = webfinger endpoint could be seen as a =93lrdd=94 endpoint using = =93application/json=94 type.=20 However currently if a client would like to retrieve host-wide = information there is no other option than using host-meta and/or host-meta.json. =20 This may be fine as long as webfinger and host-meta.json use the exact = same data format (jrd) but anyway still require 2 endpoints being used with = no clear meaning of whether to follow lrdd or go to the wf endpoint in case both are different.=20 Hence webfinger may need to support host-wide info on its own as well, = for example by omitting the =93resource=94 parameter. One could probably use = the http root url of the domain itself as a valid resource parameter but http://example.com/.well-known/webfinger?resource=3Dhttp://example.com = seems quite a trick. =20 The omission of the =93resource=94 parameter would also be useful in = mobile networks where the app does not know the actual identity of the user = (and may not be entitled to) but only the server does. In this case the = server could answer anyway with some user-specific information and could = include an acr: URI as an opaque identifier in the =93subject=94 not to reveal the = actual user identity. =20 I recognize that =93resource=94 params MUST be supported by servers but = usage in requests from client should remain unspecified so that they can decide whether to use it or not. In addition I would suggest that if a resource parameter is not provided, the server should answer with hostwide information unless it can retrieve the own user identity through other means, and in this case consider the request as resource-specific of the requesting user. =20 Otherwise what is the rationale for mandating the resource parameter in = all queries? walter =20 =20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. = Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =E8 necessario.=20 =20 ------=_NextPart_001_00B5_01CDD3C0.FABA3020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Walter,

 

I’ve not seen any = comments on this, so let me ask question and make = comments.

 

What would be the = expected response if the “resource” parameter was not = present?=A0 You said:

 

The omission of the “resource” = parameter would also be useful in mobile networks where the app does not = know the actual identity of the user (and may not be entitled to) but = only the server does. In this case the server could answer anyway with = some user

specific information and could include an acr: = URI as an opaque identifier in the “subject” not to reveal = the actual user identity.

 

How would it help to = return a document that is not user-specific?=A0 If the server provides = replies for 1,000,000 users, =A0what user-specific information would it = return without an identifier?

 

We could certainly allow = the server to return a default JRD of some sort if no user-specific = information is supplied, but it just takes in the direction of RFC = 6415.=A0=A0 So, if that’s the kind of solution you want, then = I’d suggest you do that.=A0 Both RFC 6415 and WebFinger are = related in that one was derived from the other (albeit, significantly = modified and simplified).=A0 However, it seems reasonable to me that = both can go forward.=A0 And, it is made simpler if both support a common = format like JRD.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Goix Laurent Walter
Sent: Wednesday, December = 05, 2012 5:02 AM
To: webfinger@ietf.org; = webfinger@googlegroups.com
Subject: [webfinger] About = "resource", host-wide info and = jrd

 

Hi = all,

 

I’d like to bring here the discussion on the = mandatory usage of the “resource” parameter and the access = to host-wide information.

 

I understand = that webfinger now moved away from rfc6415, and the webfinger endpoint = could be seen as a “lrdd” endpoint using = “application/json” type.

However currently if a client would like to retrieve = host-wide information there is no other option than using host-meta = and/or host-meta.json.

 

This may be = fine as long as webfinger and host-meta.json use the exact same data = format (jrd) but anyway still require 2 endpoints being used with no = clear meaning of whether to follow lrdd or go to the wf endpoint in case = both are different.

Hence webfinger = may need to support host-wide info on its own as well, for example by = omitting the “resource” parameter. One could probably use = the http root url of the domain itself as a valid resource parameter but = http://example.com/.well-known/webfinger?resource=3Dhttp://example= .com seems quite a trick.

 

The omission = of the “resource” parameter would also be useful in mobile = networks where the app does not know the actual identity of the user = (and may not be entitled to) but only the server does. In this case the = server could answer anyway with some user-specific information and could = include an acr: URI as an opaque identifier in the “subject” = not to reveal the actual user identity.

 

I recognize = that “resource” params MUST be supported by servers but = usage in requests from client should remain unspecified so that they can = decide whether to use it or not. In addition I would suggest that if a = resource parameter is not provided, the server should answer with = hostwide information unless it can retrieve the own user identity = through other means, and in this case consider the request as = resource-specific of the requesting user.

 

Otherwise = what is the rationale for mandating the resource parameter in all = queries?

walter

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. =

= This e-mail and any attachments=  is = confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, Thanks.= =

= 3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 = necessario.=

 

------=_NextPart_001_00B5_01CDD3C0.FABA3020-- ------=_NextPart_000_00B4_01CDD3C0.FABA3020 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------=_NextPart_000_00B4_01CDD3C0.FABA3020-- From laurentwalter.goix@telecomitalia.it Thu Dec 6 16:36:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345D521F86B7 for ; Thu, 6 Dec 2012 16:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RGCMcfllbSA for ; Thu, 6 Dec 2012 16:36:17 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2021F86B3 for ; Thu, 6 Dec 2012 16:36:16 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 7 Dec 2012 01:36:08 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 7 Dec 2012 01:36:07 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Fri, 7 Dec 2012 01:35:59 +0100 Thread-Topic: [webfinger] About "resource", host-wide info and jrd Thread-Index: Ac3UEtlC3DBhXMtmS2WgX4rzZGBmLw== Message-ID: <25D64365-EF15-4EE5-ABA8-D9FDE37DA29C@telecomitalia.it> References: <00b301cdd3ea$e38f26b0$aaad7410$@packetizer.com> In-Reply-To: <00b301cdd3ea$e38f26b0$aaad7410$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_25D64365EF154EE5ABA8D9FDE37DA29Ctelecomitaliait_" MIME-Version: 1.0 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] About "resource", host-wide info and jrd X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 00:36:18 -0000 --_000_25D64365EF154EE5ABA8D9FDE37DA29Ctelecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gcGF1bCwNCg0KVGhhbmtzIGZvciB0aGlzLiBNeSBhbnN3ZXJzIGlubGluZS4NCg0KTGUg NiBkw6ljLiAyMDEyIMOgIDIwOjUwLCAiUGF1bCBFLiBKb25lcyIgPHBhdWxlakBwYWNrZXRpemVy LmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tPj4gYSDDqWNyaXQgOg0KDQpXYWx0ZXIs DQoNCknigJl2ZSBub3Qgc2VlbiBhbnkgY29tbWVudHMgb24gdGhpcywgc28gbGV0IG1lIGFzayBx dWVzdGlvbiBhbmQgbWFrZSBjb21tZW50cy4NCg0KV2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQg cmVzcG9uc2UgaWYgdGhlIOKAnHJlc291cmNl4oCdIHBhcmFtZXRlciB3YXMgbm90IHByZXNlbnQ/ ICBZb3Ugc2FpZDoNCg0KVGhlIG9taXNzaW9uIG9mIHRoZSDigJxyZXNvdXJjZeKAnSBwYXJhbWV0 ZXIgd291bGQgYWxzbyBiZSB1c2VmdWwgaW4gbW9iaWxlIG5ldHdvcmtzIHdoZXJlIHRoZSBhcHAg ZG9lcyBub3Qga25vdyB0aGUgYWN0dWFsIGlkZW50aXR5IG9mIHRoZSB1c2VyIChhbmQgbWF5IG5v dCBiZSBlbnRpdGxlZCB0bykgYnV0IG9ubHkgdGhlIHNlcnZlciBkb2VzLiBJbiB0aGlzIGNhc2Ug dGhlIHNlcnZlciBjb3VsZCBhbnN3ZXIgYW55d2F5IHdpdGggc29tZSB1c2VyDQpzcGVjaWZpYyBp bmZvcm1hdGlvbiBhbmQgY291bGQgaW5jbHVkZSBhbiBhY3I6IFVSSSBhcyBhbiBvcGFxdWUgaWRl bnRpZmllciBpbiB0aGUg4oCcc3ViamVjdOKAnSBub3QgdG8gcmV2ZWFsIHRoZSBhY3R1YWwgdXNl ciBpZGVudGl0eS4NCg0KDQpIb3cgd291bGQgaXQgaGVscCB0byByZXR1cm4gYSBkb2N1bWVudCB0 aGF0IGlzIG5vdCB1c2VyLXNwZWNpZmljPw0KSXQgd291bGQgZ3JlYXRseSBzaW1wbGlmeSB0aGUg d29yayBvZiBpbXBsZW1lbnRpbmcrZXhwb3NpbmcgYm90aCByZmM2NDE1IGFuZCB3ZWJmaW5nZXIg aWYgd2ViZmluZ2VyIGNvdWxkIGFsc28gcHJvdmlkZSBob3N0IHdpZGUgaW5mbyAod2hpY2ggaXMg cG90ZW50aWFsbHkgdmVyeSBlYXN5IHRvIGRvIGlmIHRoZSByZXNvdXJjZSBwYXJhbSBiZWNvbWVz IG9wdGlvbmFsKS4gSSBhbSBpbnNpc3Rpbmcgb24gdGhpcyBiZWNhdXNlIGFzIGl0IHdhcyByZW1h cmtlZCBzb21lIG1vbnRoIGFnbyBpZiB3ZWJmaW5nZXIgZ29lcyBhIGRpZmZlcmVudCBkaXJlY3Rp b24gZnJvbSByZmM2NDE1IGFuZCB5b3UgbmVlZCB0byBjb252aW5jZSB0aGUgY3VycmVudCAob3Bl biBzb3VyY2UpIGNvbW11bml0eSBvZiBhZG9wdGluZyB3ZWJmaW5nZXIsIGl0IGhhcyB0byBkbyBh dCBsZWFzdCB0aGUgc2FtZSB0aGFuIHdoYXQgNjQxNSBpcyBjdXJyZW50bHkgZG9pbmcsIG90aGVy d2lzZSB0aGVyZSBhcmUgbGl0dGxlIGNoYW5jZXMgZm9yIGJlaW5nIGFkb3B0ZWQgc29vbmVyLg0K dXNlZnVsIEhvc3Qtd2lkZSBpbmZvIGNhbiBiZSBmb3IgZXhhbXBsZSB0aGUgb2F1dGgyIGVuZHBv aW50cyBvciBhbnkgb3RoZXIgdGVsIHdoaWNoIFVSTCBtYXkgbm90IHZhcnkgb24gYSB1c2VyLXNw ZWNpZmljIGJhc2lzLg0KDQpJZiB0aGUgc2VydmVyIHByb3ZpZGVzIHJlcGxpZXMgZm9yIDEsMDAw LDAwMCB1c2VycywgIHdoYXQgdXNlci1zcGVjaWZpYyBpbmZvcm1hdGlvbiB3b3VsZCBpdCByZXR1 cm4gd2l0aG91dCBhbiBpZGVudGlmaWVyPw0KSW4gY2FzZSB0aGUgc2VydmVyIG1hbmFnZXMgdG8g aWRlbnRpZnkgdGhlIHRhcmdldCB1c2VyIGFueXdheSB0aHJvdWdoIG90aGVyIG1lYW5zIChlZyBi eSByZWNvZ25pemluZyB0aGUgcmVxdWVzdGluZyB1c2VyIGFuZCBpbXBsaWNpdGx5IGNvbnNpZGVy IGl0IHRoZSB0YXJnZXQgdXNlciBhcyB3ZWxsKSwgdGhlbiBpdCBjYW4gcmV0dXJuIHVzZXItc3Bl Y2lmaWMgaW5mby4gUHV0dGluZyBvciBub3QgdGhlIGFjdHVhbCBwbGFpbiBpZGVudGlmaWVyIGlu IHRoZSBzdWJqZWN0IG1heSBiZSBhbiBpbnRlcm5hbCBwb2xpY3ksIGFuZCB0aGUgdXNlIG9mIGFj cjogVXJpcyAoYW5vbnltb3VzIGN1c3RvbWVyIHJlZmVyZW5jZSkgdG8gcHJvdmlkZSBhIGhpZGRl biBpZGVudGl0eSBtYXkgYmUgY29uc2lkZXJlZCBJbiBvdGhlciBjYXNlcw0KDQoNCldlIGNvdWxk IGNlcnRhaW5seSBhbGxvdyB0aGUgc2VydmVyIHRvIHJldHVybiBhIGRlZmF1bHQgSlJEIG9mIHNv bWUgc29ydCBpZiBubyB1c2VyLXNwZWNpZmljIGluZm9ybWF0aW9uIGlzIHN1cHBsaWVkLCBidXQg aXQganVzdCB0YWtlcyBpbiB0aGUgZGlyZWN0aW9uIG9mIFJGQyA2NDE1LiAgIFNvLCBpZiB0aGF0 4oCZcyB0aGUga2luZCBvZiBzb2x1dGlvbiB5b3Ugd2FudCwgdGhlbiBJ4oCZZCBzdWdnZXN0IHlv dSBkbyB0aGF0LiAgQm90aCBSRkMgNjQxNSBhbmQgV2ViRmluZ2VyIGFyZSByZWxhdGVkIGluIHRo YXQgb25lIHdhcyBkZXJpdmVkIGZyb20gdGhlIG90aGVyIChhbGJlaXQsIHNpZ25pZmljYW50bHkg bW9kaWZpZWQgYW5kIHNpbXBsaWZpZWQpLiAgSG93ZXZlciwgaXQgc2VlbXMgcmVhc29uYWJsZSB0 byBtZSB0aGF0IGJvdGggY2FuIGdvIGZvcndhcmQuICBBbmQsIGl0IGlzIG1hZGUgc2ltcGxlciBp ZiBib3RoIHN1cHBvcnQgYSBjb21tb24gZm9ybWF0IGxpa2UgSlJELg0KVGhpbmdzIHdvdWxkIGdl dCBtdWNoIHdvcnNlIGlmIGJvdGggNjQxNSBhbmQgd2Ygd291bGQgbm90IHNoYXJlIHRoZSBzYW1l IGRhdGEgZm9ybWF0LCBlc3BlY2lhbGx5IGlmIHdmIHN0YXlzIHJlc291cmNlLXNwZWNpZmljIG9u bHkgYW5kIGRvZXMgbm90IGFjY29tbW9kYXRlIGhvc3Qgd2lkZSBpbmZvDQoNCldhbHRlcg0KDQpQ YXVsDQoNCkZyb206IHdlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp3ZWJmaW5nZXIt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzp3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEdvaXggTGF1cmVudCBXYWx0ZXINClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIg MDUsIDIwMTIgNTowMiBBTQ0KVG86IHdlYmZpbmdlckBpZXRmLm9yZzxtYWlsdG86d2ViZmluZ2Vy QGlldGYub3JnPjsgd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb208bWFpbHRvOndlYmZpbmdlckBn b29nbGVncm91cHMuY29tPg0KU3ViamVjdDogW3dlYmZpbmdlcl0gQWJvdXQgInJlc291cmNlIiwg aG9zdC13aWRlIGluZm8gYW5kIGpyZA0KDQpIaSBhbGwsDQoNCknigJlkIGxpa2UgdG8gYnJpbmcg aGVyZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFuZGF0b3J5IHVzYWdlIG9mIHRoZSDigJxyZXNv dXJjZeKAnSBwYXJhbWV0ZXIgYW5kIHRoZSBhY2Nlc3MgdG8gaG9zdC13aWRlIGluZm9ybWF0aW9u Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB3ZWJmaW5nZXIgbm93IG1vdmVkIGF3YXkgZnJvbSByZmM2 NDE1LCBhbmQgdGhlIHdlYmZpbmdlciBlbmRwb2ludCBjb3VsZCBiZSBzZWVuIGFzIGEg4oCcbHJk ZOKAnSBlbmRwb2ludCB1c2luZyDigJxhcHBsaWNhdGlvbi9qc29u4oCdIHR5cGUuDQpIb3dldmVy IGN1cnJlbnRseSBpZiBhIGNsaWVudCB3b3VsZCBsaWtlIHRvIHJldHJpZXZlIGhvc3Qtd2lkZSBp bmZvcm1hdGlvbiB0aGVyZSBpcyBubyBvdGhlciBvcHRpb24gdGhhbiB1c2luZyBob3N0LW1ldGEg YW5kL29yIGhvc3QtbWV0YS5qc29uLg0KDQpUaGlzIG1heSBiZSBmaW5lIGFzIGxvbmcgYXMgd2Vi ZmluZ2VyIGFuZCBob3N0LW1ldGEuanNvbiB1c2UgdGhlIGV4YWN0IHNhbWUgZGF0YSBmb3JtYXQg KGpyZCkgYnV0IGFueXdheSBzdGlsbCByZXF1aXJlIDIgZW5kcG9pbnRzIGJlaW5nIHVzZWQgd2l0 aCBubyBjbGVhciBtZWFuaW5nIG9mIHdoZXRoZXIgdG8gZm9sbG93IGxyZGQgb3IgZ28gdG8gdGhl IHdmIGVuZHBvaW50IGluIGNhc2UgYm90aCBhcmUgZGlmZmVyZW50Lg0KSGVuY2Ugd2ViZmluZ2Vy IG1heSBuZWVkIHRvIHN1cHBvcnQgaG9zdC13aWRlIGluZm8gb24gaXRzIG93biBhcyB3ZWxsLCBm b3IgZXhhbXBsZSBieSBvbWl0dGluZyB0aGUg4oCccmVzb3VyY2XigJ0gcGFyYW1ldGVyLiBPbmUg Y291bGQgcHJvYmFibHkgdXNlIHRoZSBodHRwIHJvb3QgdXJsIG9mIHRoZSBkb21haW4gaXRzZWxm IGFzIGEgdmFsaWQgcmVzb3VyY2UgcGFyYW1ldGVyIGJ1dCBodHRwOi8vZXhhbXBsZS5jb20vLndl bGwta25vd24vd2ViZmluZ2VyP3Jlc291cmNlPWh0dHA6Ly9leGFtcGxlLmNvbSBzZWVtcyBxdWl0 ZSBhIHRyaWNrLg0KDQpUaGUgb21pc3Npb24gb2YgdGhlIOKAnHJlc291cmNl4oCdIHBhcmFtZXRl ciB3b3VsZCBhbHNvIGJlIHVzZWZ1bCBpbiBtb2JpbGUgbmV0d29ya3Mgd2hlcmUgdGhlIGFwcCBk b2VzIG5vdCBrbm93IHRoZSBhY3R1YWwgaWRlbnRpdHkgb2YgdGhlIHVzZXIgKGFuZCBtYXkgbm90 IGJlIGVudGl0bGVkIHRvKSBidXQgb25seSB0aGUgc2VydmVyIGRvZXMuIEluIHRoaXMgY2FzZSB0 aGUgc2VydmVyIGNvdWxkIGFuc3dlciBhbnl3YXkgd2l0aCBzb21lIHVzZXItc3BlY2lmaWMgaW5m b3JtYXRpb24gYW5kIGNvdWxkIGluY2x1ZGUgYW4gYWNyOiBVUkkgYXMgYW4gb3BhcXVlIGlkZW50 aWZpZXIgaW4gdGhlIOKAnHN1YmplY3TigJ0gbm90IHRvIHJldmVhbCB0aGUgYWN0dWFsIHVzZXIg aWRlbnRpdHkuDQoNCkkgcmVjb2duaXplIHRoYXQg4oCccmVzb3VyY2XigJ0gcGFyYW1zIE1VU1Qg YmUgc3VwcG9ydGVkIGJ5IHNlcnZlcnMgYnV0IHVzYWdlIGluIHJlcXVlc3RzIGZyb20gY2xpZW50 IHNob3VsZCByZW1haW4gdW5zcGVjaWZpZWQgc28gdGhhdCB0aGV5IGNhbiBkZWNpZGUgd2hldGhl ciB0byB1c2UgaXQgb3Igbm90LiBJbiBhZGRpdGlvbiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBpZiBh IHJlc291cmNlIHBhcmFtZXRlciBpcyBub3QgcHJvdmlkZWQsIHRoZSBzZXJ2ZXIgc2hvdWxkIGFu c3dlciB3aXRoIGhvc3R3aWRlIGluZm9ybWF0aW9uIHVubGVzcyBpdCBjYW4gcmV0cmlldmUgdGhl IG93biB1c2VyIGlkZW50aXR5IHRocm91Z2ggb3RoZXIgbWVhbnMsIGFuZCBpbiB0aGlzIGNhc2Ug Y29uc2lkZXIgdGhlIHJlcXVlc3QgYXMgcmVzb3VyY2Utc3BlY2lmaWMgb2YgdGhlIHJlcXVlc3Rp bmcgdXNlci4NCg0KT3RoZXJ3aXNlIHdoYXQgaXMgdGhlIHJhdGlvbmFsZSBmb3IgbWFuZGF0aW5n IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4gYWxsIHF1ZXJpZXM/DQp3YWx0ZXINCg0KDQpRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZh bWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGlu Zm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJp Y2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCjxpbWFnZTAwMS5naWY+UmlzcGV0dGEgbCdh bWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0K DQoNCg== --_000_25D64365EF154EE5ABA8D9FDE37DA29Ctelecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SGVsbG8g cGF1bCw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBmb3IgdGhpcy4mbmJzcDtNeSBh bnN3ZXJzIGlubGluZS48L2Rpdj48ZGl2Pjxicj5MZSA2IGTDqWMuIDIwMTIgw6AgMjA6NTAsICJQ YXVsIEUuIEpvbmVzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbSI+ cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPjxicj48L2Rp dj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUyIj48bWV0YSBu YW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRp dW0pIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Cjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDU2 LjdwdCA1Ni43cHQgNTYuN3B0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldhbHRlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SeKAmXZlIG5vdCBzZWVuIGFueSBjb21tZW50cyBvbiB0aGlzLCBzbyBsZXQgbWUg YXNrIHF1ZXN0aW9uIGFuZCBtYWtlIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5XaGF0IHdvdWxkIGJlIHRoZSBleHBlY3RlZCByZXNwb25zZSBpZiB0aGUg4oCccmVz b3VyY2XigJ0gcGFyYW1ldGVyIHdhcyBub3QgcHJlc2VudD8mbmJzcDsgWW91IHNhaWQ6PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPSJNc29UYWJs ZUdyaWQiIGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVyOm5vbmUiPjx0 Ym9keT48dHI+PHRkIHdpZHRoPSI2MjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NDY2LjVw dDtib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMDA4RTQwIDMuMHB0O3BhZGRpbmc6MGlu IDUuNHB0IDBpbiA1LjRwdCI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoZSBvbWlzc2lvbiBvZiB0aGUg4oCccmVzb3VyY2XigJ0gcGFyYW1ldGVyIHdv dWxkIGFsc28gYmUgdXNlZnVsIGluIG1vYmlsZSBuZXR3b3JrcyB3aGVyZSB0aGUgYXBwIGRvZXMg bm90IGtub3cgdGhlIGFjdHVhbCBpZGVudGl0eSBvZiB0aGUgdXNlciAoYW5kIG1heSBub3QgYmUg ZW50aXRsZWQgdG8pIGJ1dCBvbmx5IHRoZSBzZXJ2ZXIgZG9lcy4gSW4gdGhpcyBjYXNlIHRoZSBz ZXJ2ZXIgY291bGQgYW5zd2VyIGFueXdheSB3aXRoIHNvbWUgdXNlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+c3Bl Y2lmaWMgaW5mb3JtYXRpb24gYW5kIGNvdWxkIGluY2x1ZGUgYW4gYWNyOiBVUkkgYXMgYW4gb3Bh cXVlIGlkZW50aWZpZXIgaW4gdGhlIOKAnHN1YmplY3TigJ0gbm90IHRvIHJldmVhbCB0aGUgYWN0 dWFsIHVzZXIgaWRlbnRpdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4RTQwIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhF NDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SG93IHdvdWxkIGl0IGhlbHAgdG8gcmV0dXJuIGEgZG9j dW1lbnQgdGhhdCBpcyBub3QgdXNlci1zcGVjaWZpYz8mbmJzcDsgPC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj5JdCB3b3VsZCBncmVhdGx5IHNpbXBsaWZ5IHRoZSB3b3Jr IG9mIGltcGxlbWVudGluZytleHBvc2luZyBib3RoIHJmYzY0MTUgYW5kIHdlYmZpbmdlciBpZiB3 ZWJmaW5nZXIgY291bGQgYWxzbyBwcm92aWRlIGhvc3Qgd2lkZSBpbmZvICh3aGljaCBpcyBwb3Rl bnRpYWxseSB2ZXJ5IGVhc3kgdG8gZG8gaWYgdGhlIHJlc291cmNlIHBhcmFtIGJlY29tZXMgb3B0 aW9uYWwpLiBJIGFtIGluc2lzdGluZyBvbiB0aGlzIGJlY2F1c2UgYXMgaXQgd2FzIHJlbWFya2Vk IHNvbWUgbW9udGggYWdvIGlmIHdlYmZpbmdlciBnb2VzIGEgZGlmZmVyZW50IGRpcmVjdGlvbiBm cm9tIHJmYzY0MTUgYW5kIHlvdSBuZWVkIHRvIGNvbnZpbmNlIHRoZSBjdXJyZW50IChvcGVuIHNv dXJjZSkgY29tbXVuaXR5IG9mIGFkb3B0aW5nIHdlYmZpbmdlciwgaXQgaGFzIHRvIGRvIGF0IGxl YXN0IHRoZSBzYW1lIHRoYW4gd2hhdCA2NDE1IGlzIGN1cnJlbnRseSBkb2luZywgb3RoZXJ3aXNl IHRoZXJlIGFyZSBsaXR0bGUgY2hhbmNlcyBmb3IgYmVpbmcgYWRvcHRlZCBzb29uZXIuPC9kaXY+ PGRpdj51c2VmdWwgSG9zdC13aWRlIGluZm8gY2FuIGJlIGZvciBleGFtcGxlIHRoZSBvYXV0aDIg ZW5kcG9pbnRzIG9yIGFueSBvdGhlciB0ZWwgd2hpY2ggVVJMIG1heSBub3QgdmFyeSBvbiBhIHVz ZXItc3BlY2lmaWMgYmFzaXMuPC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+ PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SWYgdGhlIHNlcnZlciBwcm92aWRlcyByZXBsaWVzIGZvciAxLDAw MCwwMDAgdXNlcnMsICZuYnNwO3doYXQgdXNlci1zcGVjaWZpYyBpbmZvcm1hdGlvbiB3b3VsZCBp dCByZXR1cm4gd2l0aG91dCBhbiBpZGVudGlmaWVyPzwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+SW4gY2FzZSB0aGUgc2VydmVyIG1hbmFnZXMgdG8gaWRlbnRpZnkgdGhl IHRhcmdldCB1c2VyIGFueXdheSB0aHJvdWdoIG90aGVyIG1lYW5zIChlZyBieSByZWNvZ25pemlu ZyB0aGUgcmVxdWVzdGluZyB1c2VyIGFuZCBpbXBsaWNpdGx5IGNvbnNpZGVyIGl0IHRoZSB0YXJn ZXQgdXNlciBhcyB3ZWxsKSwgdGhlbiBpdCBjYW4gcmV0dXJuIHVzZXItc3BlY2lmaWMgaW5mby4g UHV0dGluZyBvciBub3QgdGhlIGFjdHVhbCBwbGFpbiBpZGVudGlmaWVyIGluIHRoZSBzdWJqZWN0 IG1heSBiZSBhbiBpbnRlcm5hbCBwb2xpY3ksIGFuZCB0aGUgdXNlIG9mIGFjcjogVXJpcyAoYW5v bnltb3VzIGN1c3RvbWVyIHJlZmVyZW5jZSkgdG8gcHJvdmlkZSBhIGhpZGRlbiBpZGVudGl0eSBt YXkgYmUgY29uc2lkZXJlZCBJbiBvdGhlciBjYXNlczwvZGl2Pjxicj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48ZGl2PjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5XZSBjb3VsZCBjZXJ0YWlubHkgYWxsb3cgdGhlIHNlcnZlciB0byByZXR1cm4gYSBk ZWZhdWx0IEpSRCBvZiBzb21lIHNvcnQgaWYgbm8gdXNlci1zcGVjaWZpYyBpbmZvcm1hdGlvbiBp cyBzdXBwbGllZCwgYnV0IGl0IGp1c3QgdGFrZXMgaW4gdGhlIGRpcmVjdGlvbiBvZiBSRkMgNjQx NS4mbmJzcDsmbmJzcDsgU28sIGlmIHRoYXTigJlzIHRoZSBraW5kIG9mIHNvbHV0aW9uIHlvdSB3 YW50LCB0aGVuIEnigJlkIHN1Z2dlc3QgeW91IGRvIHRoYXQuJm5ic3A7IEJvdGggUkZDIDY0MTUg YW5kIFdlYkZpbmdlciBhcmUgcmVsYXRlZCBpbiB0aGF0IG9uZSB3YXMgZGVyaXZlZCBmcm9tIHRo ZSBvdGhlciAoYWxiZWl0LCBzaWduaWZpY2FudGx5IG1vZGlmaWVkIGFuZCBzaW1wbGlmaWVkKS4m bmJzcDsgSG93ZXZlciwgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSB0aGF0IGJvdGggY2FuIGdv IGZvcndhcmQuJm5ic3A7IEFuZCwgaXQgaXMgbWFkZSBzaW1wbGVyIGlmIGJvdGggc3VwcG9ydCBh IGNvbW1vbiBmb3JtYXQgbGlrZSBKUkQuPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj5UaGluZ3Mgd291bGQgZ2V0IG11Y2ggd29yc2UgaWYgYm90aCA2NDE1IGFuZCB3ZiB3 b3VsZCBub3Qgc2hhcmUgdGhlIHNhbWUgZGF0YSBmb3JtYXQsIGVzcGVjaWFsbHkgaWYgd2Ygc3Rh eXMgcmVzb3VyY2Utc3BlY2lmaWMgb25seSBhbmQgZG9lcyBub3QgYWNjb21tb2RhdGUgaG9zdCB3 aWRlIGluZm88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldhbHRlcjwvZGl2PjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA8YSBocmVmPSJtYWlsdG86d2Vi ZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmciPndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnPC9hPiBb PGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86d2ViZmlu Z2VyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkdvaXggTGF1cmVu dCBXYWx0ZXI8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMDUsIDIwMTIgNTow MiBBTTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXJAaWV0Zi5vcmciPndl YmZpbmdlckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXJAZ29vZ2xlZ3Jv dXBzLmNvbSI+d2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5jb208L2E+PGJyPjxiPlN1YmplY3Q6PC9i PiBbd2ViZmluZ2VyXSBBYm91dCAicmVzb3VyY2UiLCBob3N0LXdpZGUgaW5mbyBhbmQganJkPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj5J4oCZZCBsaWtlIHRvIGJyaW5nIGhlcmUgdGhlIGRpc2N1c3Npb24gb24gdGhlIG1h bmRhdG9yeSB1c2FnZSBvZiB0aGUg4oCccmVzb3VyY2XigJ0gcGFyYW1ldGVyIGFuZCB0aGUgYWNj ZXNzIHRvIGhvc3Qtd2lkZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVy c3RhbmQgdGhhdCB3ZWJmaW5nZXIgbm93IG1vdmVkIGF3YXkgZnJvbSByZmM2NDE1LCBhbmQgdGhl IHdlYmZpbmdlciBlbmRwb2ludCBjb3VsZCBiZSBzZWVuIGFzIGEg4oCcbHJkZOKAnSBlbmRwb2lu dCB1c2luZyDigJxhcHBsaWNhdGlvbi9qc29u4oCdIHR5cGUuIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIgY3VycmVudGx5IGlmIGEgY2xpZW50IHdvdWxkIGxpa2Ug dG8gcmV0cmlldmUgaG9zdC13aWRlIGluZm9ybWF0aW9uIHRoZXJlIGlzIG5vIG90aGVyIG9wdGlv biB0aGFuIHVzaW5nIGhvc3QtbWV0YSBhbmQvb3IgaG9zdC1tZXRhLmpzb24uPG86cD48L286cD48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBtYXkgYmUgZmluZSBhcyBsb25nIGFzIHdlYmZpbmdlciBhbmQgaG9zdC1t ZXRhLmpzb24gdXNlIHRoZSBleGFjdCBzYW1lIGRhdGEgZm9ybWF0IChqcmQpIGJ1dCBhbnl3YXkg c3RpbGwgcmVxdWlyZSAyIGVuZHBvaW50cyBiZWluZyB1c2VkIHdpdGggbm8gY2xlYXIgbWVhbmlu ZyBvZiB3aGV0aGVyIHRvIGZvbGxvdyBscmRkIG9yIGdvIHRvIHRoZSB3ZiBlbmRwb2ludCBpbiBj YXNlIGJvdGggYXJlIGRpZmZlcmVudC4gPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVuY2Ugd2ViZmluZ2VyIG1heSBuZWVkIHRvIHN1cHBvcnQgaG9zdC13aWRlIGluZm8gb24g aXRzIG93biBhcyB3ZWxsLCBmb3IgZXhhbXBsZSBieSBvbWl0dGluZyB0aGUg4oCccmVzb3VyY2Xi gJ0gcGFyYW1ldGVyLiBPbmUgY291bGQgcHJvYmFibHkgdXNlIHRoZSBodHRwIHJvb3QgdXJsIG9m IHRoZSBkb21haW4gaXRzZWxmIGFzIGEgdmFsaWQgcmVzb3VyY2UgcGFyYW1ldGVyIGJ1dCA8YSBo cmVmPSJodHRwOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24vd2ViZmluZ2VyP3Jlc291cmNlPWh0 dHA6Ly9leGFtcGxlLmNvbSI+aHR0cDovL2V4YW1wbGUuY29tLy53ZWxsLWtub3duL3dlYmZpbmdl cj9yZXNvdXJjZT1odHRwOi8vZXhhbXBsZS5jb208L2E+IHNlZW1zIHF1aXRlIGEgdHJpY2suPG86 cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9taXNzaW9uIG9mIHRoZSDigJxyZXNvdXJjZeKAnSBwYXJh bWV0ZXIgd291bGQgYWxzbyBiZSB1c2VmdWwgaW4gbW9iaWxlIG5ldHdvcmtzIHdoZXJlIHRoZSBh cHAgZG9lcyBub3Qga25vdyB0aGUgYWN0dWFsIGlkZW50aXR5IG9mIHRoZSB1c2VyIChhbmQgbWF5 IG5vdCBiZSBlbnRpdGxlZCB0bykgYnV0IG9ubHkgdGhlIHNlcnZlciBkb2VzLiBJbiB0aGlzIGNh c2UgdGhlIHNlcnZlciBjb3VsZCBhbnN3ZXIgYW55d2F5IHdpdGggc29tZSB1c2VyLXNwZWNpZmlj IGluZm9ybWF0aW9uIGFuZCBjb3VsZCBpbmNsdWRlIGFuIGFjcjogVVJJIGFzIGFuIG9wYXF1ZSBp ZGVudGlmaWVyIGluIHRoZSDigJxzdWJqZWN04oCdIG5vdCB0byByZXZlYWwgdGhlIGFjdHVhbCB1 c2VyIGlkZW50aXR5LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVjb2duaXplIHRoYXQg4oCccmVz b3VyY2XigJ0gcGFyYW1zIE1VU1QgYmUgc3VwcG9ydGVkIGJ5IHNlcnZlcnMgYnV0IHVzYWdlIGlu IHJlcXVlc3RzIGZyb20gY2xpZW50IHNob3VsZCByZW1haW4gdW5zcGVjaWZpZWQgc28gdGhhdCB0 aGV5IGNhbiBkZWNpZGUgd2hldGhlciB0byB1c2UgaXQgb3Igbm90LiBJbiBhZGRpdGlvbiBJIHdv dWxkIHN1Z2dlc3QgdGhhdCBpZiBhIHJlc291cmNlIHBhcmFtZXRlciBpcyBub3QgcHJvdmlkZWQs IHRoZSBzZXJ2ZXIgc2hvdWxkIGFuc3dlciB3aXRoIGhvc3R3aWRlIGluZm9ybWF0aW9uIHVubGVz cyBpdCBjYW4gcmV0cmlldmUgdGhlIG93biB1c2VyIGlkZW50aXR5IHRocm91Z2ggb3RoZXIgbWVh bnMsIGFuZCBpbiB0aGlzIGNhc2UgY29uc2lkZXIgdGhlIHJlcXVlc3QgYXMgcmVzb3VyY2Utc3Bl Y2lmaWMgb2YgdGhlIHJlcXVlc3RpbmcgdXNlci48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlcndp c2Ugd2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBtYW5kYXRpbmcgdGhlIHJlc291cmNlIHBhcmFt ZXRlciBpbiBhbGwgcXVlcmllcz88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj53 YWx0ZXI8c3BhbiBsYW5nPSJJVCIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjYwMCIgc3R5bGU9IndpZHRoOjYuMjVpbiI+PHRib2R5Pjx0cj48dGQgd2lkdGg9IjU4NSIg c3R5bGU9IndpZHRoOjQzOC43NXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4g Y2xhc3M9Im1zb25vcm1hbDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNj bHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVl c3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJp YXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVu dGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBl IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gPC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJt c29ub3JtYWwwIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjwvc3Bh bj48c3BhbiBjbGFzcz0ibXNvbm9ybWFsMCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtpcyZuYnNwOzwvc3Bhbj48L2k+PC9zcGFu PjxzcGFuIGNsYXNzPSJtc29ub3JtYWwwIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBE aXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlz IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRo ZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PC9zcGFuPjxzcGFu IGNsYXNzPSJtc29ub3JtYWwwIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiA8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZsdDtpbWFnZTAwMS5naWYmZ3Q7UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9u IHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_25D64365EF154EE5ABA8D9FDE37DA29Ctelecomitaliait_-- From nick@silverbucket.net Wed Dec 5 13:27:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA921F8A85 for ; Wed, 5 Dec 2012 13:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C7EMXmoHTJP for ; Wed, 5 Dec 2012 13:27:13 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F363821F89FF for ; Wed, 5 Dec 2012 13:27:12 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4860716lah.31 for ; Wed, 05 Dec 2012 13:27:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=aLt6opCsHXvw7+Z/lJ+O3EcdKUhixurEMI9eGfNNdh4=; b=KWgNH9396aZ5HewhVSM8luNO9KI4hERsYeRfWgQGcAYsgTC+VaQFjNbvyjJ/43ye0u nIE/hNw8Wq9YjVR6sTY1aZOKzuMX48xX3v2XlSCw64EbTb1e8yyu82+jCGIMmI512Hu9 XNiCptEjLUWTFYy4ZA0D/DMUpfU5D0W3uh4tWHWp6ZqnsBDeeWipNmclZ0B9Re9gzQu2 nhXZ6DwCyc2tFI16mYTdirNY3JGWBhhWyIjnqChJOOjIeBijCLQI8a8WsFAi/7Ug5FYZ qv3k6V51FTc5740OsjEtFt61p6N9BetIEeAr6C2Rv0TxpN2ad2qNJp694YA2Ju5Ag7Vw +y6g== Received: by 10.112.11.34 with SMTP id n2mr7935932lbb.100.1354742831783; Wed, 05 Dec 2012 13:27:11 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id oz12sm2606285lab.17.2012.12.05.13.27.10 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 13:27:10 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4996541lbk.31 for ; Wed, 05 Dec 2012 13:27:10 -0800 (PST) Received: by 10.152.108.48 with SMTP id hh16mr17902183lab.25.1354742830021; Wed, 05 Dec 2012 13:27:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 5 Dec 2012 13:26:39 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> From: Nick Jennings Date: Wed, 5 Dec 2012 22:26:39 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkHiftujyqIwijMMT9UK9QgCDgj4j8/ziesO/Hmq17BoRo2lP4Q5NmpF/3KnRfzh9fPS3Dz X-Mailman-Approved-At: Thu, 06 Dec 2012 23:11:12 -0800 Cc: webfinger@ietf.org, Evan Prodromou Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:27:14 -0000 On Wed, Dec 5, 2012 at 8:59 PM, Brad Fitzpatrick wrote: > I don't believe that's the security argument. > > I understand it more as: If we mandate complexity (in the spec), we will > get complexity (in clients, per the spec), and in complexity lies security > problems (clients not having HTTPS-only modes). > > Whereas if we say "HTTPS-only" in the spec, it will lead to simpler clients > lacking options which are then secure-by-default. > Although I like the idea of keeping it simple and secure by default, I'm starting to lean on the side of *both* being optional. The more I think about it, the more it really should be the decision of the client library, not the server, as to what type of query they are going to make. The server can, of course, restrict HTTP requests if it's serving sensitive data. If I'm an auth library of some sort, I'm going to use HTTPS only to make my queries. If the server does not support HTTPS, then the server obviously isn't prepared to handle auth-related topics. If I'm a library used for blog comment avatars/basic info, I'm going to use HTTP pretty much exclusively because I don't want the increased latency and processing power involved with establishing encrypted sessions for every single comment on the page. If I'm a mobile app and the data I need to query is not sensitive, again I'm going to prefer HTTP because of the latency and processing power (battery life and unreliable internet connectivity). By forcing HTTPS, or even requiring it as the initial query, we're not allowing the client library to be optimized for it's task. There are performance hits, and if you multiply that for situations where the client app may need to make hundreds or thousands of requests, that becomes a valid consideration. -Nick From joseph@josephholsten.com Wed Dec 5 22:56:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1F621F8D5B for ; Wed, 5 Dec 2012 22:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz7bo-Vfv-5o for ; Wed, 5 Dec 2012 22:56:08 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1424621F8D5A for ; Wed, 5 Dec 2012 22:56:05 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 746FD8266; Thu, 6 Dec 2012 01:56:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; s=sasl; bh=td2Hv+7DF1Pk49zM jgv7KdU2TRA=; b=QNVOnnd6fKyWOd2sdNSu2rCI45iR8Cu9B+K72z1HAEGj6Plw S21PCJEJTvjxGWnsxqWULT2FF3yWALvKXSu8Xh9P4rDuwODhxce4adDcUiJQjvEQ toXjCT3aZ+Ry0wmtI8tdOkRZljUXeSPmNcjmxFKPTnVf8rWbfJZBIQu2xdA= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 607568265; Thu, 6 Dec 2012 01:56:04 -0500 (EST) Received: from [10.0.1.3] (unknown [76.28.212.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 6E9F98264; Thu, 6 Dec 2012 01:56:03 -0500 (EST) References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3FC2D4E4-44A5-4318-B330-E99A77F185A2@josephholsten.com> X-Mailer: iPhone Mail (10A523) From: Joseph Holsten Date: Wed, 5 Dec 2012 22:56:25 -0800 To: "webfinger@googlegroups.com" X-Pobox-Relay-ID: 00131916-3F72-11E2-B209-995F2E706CDE-15777318!b-pb-sasl-quonix.pobox.com X-Mailman-Approved-At: Thu, 06 Dec 2012 23:11:12 -0800 Cc: "webfinger@ietf.org" , Evan Prodromou , "webfinger@googlegroups.com" Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 06:56:09 -0000 On Dec 5, 2012, at 13:26, Nick Jennings wrote: > On Wed, Dec 5, 2012 at 8:59 PM, Brad Fitzpatrick wro= te: >> I don't believe that's the security argument. >>=20 >> I understand it more as: If we mandate complexity (in the spec), we will= >> get complexity (in clients, per the spec), and in complexity lies securit= y >> problems (clients not having HTTPS-only modes). >>=20 >> Whereas if we say "HTTPS-only" in the spec, it will lead to simpler clien= ts >> lacking options which are then secure-by-default. >=20 >=20 > Although I like the idea of keeping it simple and secure by default, > I'm starting to lean on the side of *both* being optional. The more I > think about it, the more it really should be the decision of the > client library, not the server, as to what type of query they are > going to make. The server can, of course, restrict HTTP requests if > it's serving sensitive data. As an implementor, you've gone from two test cases (success via https in sec= ure mode, failure to discover) and added three more (success via https in in= secure mode, sucess via http fallback in insecure mide, and failure via http= fallback in https only mode) that I have to test. That's not counting the myriad redirects, timeouts, retries and caching tha= t a mature client requires. > By forcing HTTPS, or even requiring it as the initial query, we're not > allowing the client library to be optimized for it's task. There are > performance hits, and if you multiply that for situations where the > client app may need to make hundreds or thousands of requests, that become= s a valid consideration. If you're talking about thousands of requests in any small amount if time, a= nd you're afraid of the processing and latency https adds, you basically are= n't mature enough to be calling any external SaaS. Much less calling twitter= , facebook, google plus, or any other social network for their data. I work at a social media analytics company. We pull large quantities ad this= kind of data all day long. And we've had to build frustratingly complex exc= eption handling, retrying, timeouts and scheduling into our data collectors t= o get deal with these APIs that are officially blessed by the social network= s in question. Do you think the same SLAs will apply to an insecure, public d= ata only, weird discovery protocol that isn't core to their business?=20 And you think a shop should be afraid of https? And another thing. Latency? You're making an https request first, waiting f= or connect() to time out, then making an http request, right? Or are you cal= ling http directly, then getting redirected to https on sites that require i= t? Which particular latency should my client library be trying to avoid? Also, please stop thinking of this as just a spec. This isn't us agreeing to= a spec. This is agreeing to how we want our implementations to work togethe= r, and writing it down. If you weren't interested in actually creating worki= ng code, why would anyone be interested in achieving rough consensus with yo= u?= From perpetual-tripper@wwelves.org Tue Dec 11 12:40:33 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFAE11E809B for ; Tue, 11 Dec 2012 12:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUXYq5cqjd3C for ; Tue, 11 Dec 2012 12:40:32 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id BF7BF11E809C for ; Tue, 11 Dec 2012 12:40:32 -0800 (PST) X-Originating-IP: 217.70.178.135 Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 33D9AA8087; Tue, 11 Dec 2012 21:40:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fQoSjDXCK5ab; Tue, 11 Dec 2012 21:40:18 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BB769A8076; Tue, 11 Dec 2012 21:40:18 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Markus Lanthaler In-reply-to: <50b8b1ba.a74fec0a.307d.1b98SMTPIN_ADDED_BROKEN@gmr-mx.google.com> References: <014701cdce69$c51ef240$4f5cd6c0$@packetizer.com> <3C24A51B-2D83-4142-896F-8C587BC045D2@josephholsten.com> <7A879D5E-5012-4EB6-9017-BB13FAB65A0A@josephholsten.com> <00ac01cdceef$84a7fdc0$8df7f940$@lanthaler@gmx.net> <1354276043-sup-1914@heahdk.net> <50b8b1ba.a74fec0a.307d.1b98SMTPIN_ADDED_BROKEN@gmr-mx.google.com> Date: Tue, 11 Dec 2012 20:40:18 +0000 Message-Id: <1355258144-sup-4085@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: IETF Webfinger , webfinger Subject: Re: [webfinger] [apps-discuss] WebFinger payload as array or object X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 20:40:33 -0000 Excerpts from Markus Lanthaler's message of 2012-11-30 13:16:32 +0000: > On Friday, November 30, 2012 12:50 PM, =E2=98=AE elf Pavlik =E2=98=AE > > > > [just brainstorming] would you see sense in evaluating use of JSON-LD= ? > > :) >=20 > That depends on what you mean by evaluating use of JSON-LD!? >=20 > If you mean exposing "generic" JSON-LD, i.e., JSON-LD without any restr= ictions on the shape of the data (JSON-LD serializes graphs and most of t= he time there are multiple ways to transform a graph to a tree) I don't t= hink it would make much sense. >=20 > However, if you mean to ensure that a webfinger response can be transfo= mred to a JSON-LD document I think it would make a lot of sense. Especial= ly considering how trivial the "required" changes are. Actually those cha= nges are not required in the traditional sense but are required to extrac= t data that is easy to consume. The current structure would yield to data= whose structure is quite unusual and difficult to consume.=20 >=20 > After a quick glance it looks like that moving the rels out of the link= objects would be all that's required. If you want to push this a bit fur= ther you could rename href to subject as those objects than basically aga= in represent subjects. Perhaps you would even like to go as far as removi= ng the "properties" and "links" keys and put that data directly in the to= p-level object. After all, both are properties of the subject. thank you for clarifying! also just recalled JSON-LD Macros project which could maybe help with pro= viding common transformations for webfinger profiles to JSON-LD: https://= github.com/antoniogarrote/json-ld-macros From laurentwalter.goix@telecomitalia.it Wed Dec 12 01:58:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF4A21F8975 for ; Wed, 12 Dec 2012 01:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcPFsvmsrE7v for ; Wed, 12 Dec 2012 01:58:13 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 59FE821F87F2 for ; Wed, 12 Dec 2012 01:58:13 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 12 Dec 2012 10:58:08 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 12 Dec 2012 10:58:08 +0100 From: Goix Laurent Walter To: Mikael Nordfeldth , =?utf-8?B?TWFydGluIEouIETDvHJz?= , Randall Leeds Date: Wed, 12 Dec 2012 10:58:06 +0100 Thread-Topic: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP Thread-Index: Ac3Tkx+Q90o9043iQoGnavV1dLaQ7gEujsuA Message-ID: References: <50BF612D.3070001@ericsson.com> <50C02943.9090301@it.aoyama.ac.jp> <1354786274.9346.2.camel@Nokia-N900> In-Reply-To: <1354786274.9346.2.camel@Nokia-N900> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Salvatore Loreto , "webfinger@ietf.org" Subject: [webfinger] R: Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 09:58:14 -0000 SSB3b3VsZCBhbHNvICsxIGZvciBvcHRpb24gMy4NCg0KV2UndmUgc2VlbiBkdXJpbmcgdGhlIGxh c3QgeWVhciBub3cgbWFueSBkaXN0aW5jdCB1c2UgY2FzZXMgdGhhdCBmYXZvciBlaXRoZXIgaHR0 cHMgYW5kL29yIGh0dHAuIEFzIGEgZ2VuZXJpYyBpZXRmIGZyYW1ld29yayB3ZWJmaW5nZXIgc2hv dWxkIHNpbXBseSBjbGFyaWZ5IHRoZSByaXNrcyBpbXBsaWVkIGJ5IHVzaW5nIHBsYWluIGh0dHAg aW4gYSBzb3J0IG9mICJob3ctdG8iIGd1aWRlIGJhc2VkIG9uIHRoZSBtb3N0IHBvcHVsYXIgdXNh Z2VzIG9mIHdmLg0KVGhlIHNwZWMgbWF5IHNheSBhdCBtb3N0IHRoYXQgY2xpZW50cyBTSE9VTEQg YXR0ZW1wdCBIVFRQUyBmaXJzdCBidXQgaXQgbWF5IG5vdCBiZSBhbHdheXMgZmVhc2libGUgKHNl ZSB0aGUgbW9iaWxlIG5ldHdvcmsgdXNlIGNhc2UpLiBTZXJ2ZXJzIGFzIHdlbGwgU0hPVUxEIGV4 cG9zZSB3ZWJmaW5nZXIgb3ZlciBIVFRQUyBidXQgbWF5IGhhdmUgdmVyeSBnb29kIHJlYXNvbnMg bm90IHRvIGRvIHNvIChkdWUgdG8gY2VydGlmaWNhdGlvbiBjb21wbGV4aXR5IGZvciBzbWFsbCBz aXRlcyBhbmQvb3Igc2ltcGx5IGJlY2F1c2UgdGhlIHJlbGVhc2VkIGluZm9ybWF0aW9uIGlzIGlu dGVuZGVkIGZvciBwdWJsaWMgdXNlKQ0KDQpJdCBzaG91bGQgYmUgdXAgdG8gc3BlY2lmaWMgY29u dGV4dHMvc3BlY3MgdG8gInByb2ZpbGUiIHRoZSB3ZWJmaW5nZXIgc3BlYyBieSBwcm9tb3Rpbmcg YSBzcGVjaWZpYyBmbG93IChodHRwcy1vbmx5LCBmYWxsYmFjaywgZXRjKSBlZyBPTUEgU05FVywg T3BlbklEIENvbm5lY3Qgb3IgdGhlIHNpbmdsZSBTb2NpYWwgRW50cmVwcmlzZSBzb2Z0d2FyZSBp bXBsZW1lbnRhdGlvbnMuDQoNCndhbHRlcg0KDQo+IC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0t LS0tDQo+IERhOiB3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndlYmZpbmdlci1i b3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8NCj4gZGkgTWlrYWVsIE5vcmRmZWxkdGgNCj4gSW52 aWF0bzogZ2lvdmVkw6wgNiBkaWNlbWJyZSAyMDEyIDEwLjMxDQo+IEE6IE1hcnRpbiBKLiBEw7xy czsgUmFuZGFsbCBMZWVkcw0KPiBDYzogU2FsdmF0b3JlIExvcmV0bzsgd2ViZmluZ2VyQGlldGYu b3JnDQo+IE9nZ2V0dG86IFJlOiBbd2ViZmluZ2VyXSBDb25zZW5zdXMgY2FsbDogSFRUUFMgb25s eSB2cyBIVFRQUy1hbmQtSFRUUA0KPg0KPiBPbiB0b3IgICA2IGRlYyAyMDEyIDA2OjEyOjM1LCAi TWFydGluIEouIETDvHJzdCIgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+DQo+IHdyb3RlOg0KPg0K PiA+IE9uIDIwMTIvMTIvMDYgMTM6MDAsIFJhbmRhbGwgTGVlZHMgd3JvdGU6DQo+ID4gPiBPbiBX ZWQsIERlYyA1LCAyMDEyIGF0IDk6MDQgQU0sIEphbWVzIE0gU25lbGw8amFzbmVsbEBnbWFpbC5j b20+DQo+ID4gPiB3cm90ZToNCj4gPg0KPiA+ID4gPg0KPiA+ID4gPiAzKSBIVFRQUyBvciBIVFRQ Li4uIGxlYXZlIHRoZSBkZWNpc2lvbiB1cCB0byB0aGUgc2VydmVyIGFuZCBjbGllbnQNCj4gPiA+ ID4gZGVwZW5kaW5nIG9uIHRoZWlyIG93biBzcGVjaWZpYyBuZWVkcy4gU2VydmVycyBjYW4gZW5m b3JjZSB0aGUgdXNlDQo+ID4gPiA+IG9mIGh0dHBzIGlmIHRoYXQgc2VydmVyIGRlZW1zIGl0IG5l Y2Vzc2FyeS4gTGlrZXdpc2UsIGNsaWVudHMgY2FuDQo+ID4gPiA+IGNob29zZSB0byB1c2UgaHR0 cHMgb3IgaHR0cCBpZiBpdCBkZWVtcyBpdCBuZWNlc3NhcnkuDQo+ID4gPiA+DQo+ID4gPg0KPiA+ ID4gSSdsbCArMSB0aGlzIHRoaXJkIG9wdGlvbi4NCj4gPg0KPiA+IFRoYXQgb3B0aW9uIHdvdWxk IGJlIGZpbmUgd2l0aCBtZSwgdG9vLg0KPg0KPiBZZXMuIFRoZSB0aGlyZCBvcHRpb24gaXMgbXkg ZmF2b3JpdGUuDQo+IEl0IGRvZXMgbm90IGFzc3VtZSBkZXZlbG9wZXJzIGNhbiBiZSBmaXhlZCBi eSBqdXN0IGdpdmluZyB0aGVtIGEgbW9yZQ0KPiByZXN0cmljdGl2ZSB0b29sa2l0Lg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB3ZWJmaW5nZXIg bWFpbGluZyBsaXN0DQo+IHdlYmZpbmdlckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3dlYmZpbmdlcg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVy aXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVu dG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlz dHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJp bnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4NCg0K From mmn@hethane.se Wed Dec 12 02:26:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095F421F890D for ; Wed, 12 Dec 2012 02:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIQWMxI7BoNQ for ; Wed, 12 Dec 2012 02:26:42 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id F2D3921F8906 for ; Wed, 12 Dec 2012 02:26:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 12 Dec 2012 11:26:36 +0100 From: Mikael Nordfeldth To: In-Reply-To: <1354786441-sup-4934@heahdk.net> References: <50BF612D.3070001@ericsson.com> <50BFA457.1090101@status.net> <50BFA536.5080507@status.net> <4b2474cc542f82333d1d33ef828eb0cc@hethane.se> <3468a2e2b3a8000725e84a2f15b76829@hethane.se> <1354786441-sup-4934@heahdk.net> Message-ID: <560249757f4558b208801e10cabc510d@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:26:43 -0000 06.12.2012 10:38 skrev ☮ elf Pavlik ☮: > how about keeping it HTTPS only just to cut off very basic threats > and at the same time make a informative reference to work done on > supporting CAcert and other autonomous CAs? HTTPS won't make bad programmers less bad. Thus the basic threats will be just as real with or without it. Given that the suggested behaviour for HTTPS-only is to _ignore_ unverified certificates, I believe CAcert etc. will have a _harder_ time catching on than in an environment where HTTP/unverified HTTPS is flagged "not verified". Either way, there's also a huge risk of software being _less_ secure if it assumes HTTPS traffic is always Good(tm) just because the server signature is validated. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From salvatore.loreto@ericsson.com Wed Dec 12 07:48:28 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA421E8042 for ; Wed, 12 Dec 2012 07:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KesWChFgCt-x for ; Wed, 12 Dec 2012 07:48:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 46BE421F841B for ; Wed, 12 Dec 2012 07:48:24 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-63-50c8a747f91a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id ED.6D.10459.747A8C05; Wed, 12 Dec 2012 16:48:24 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 12 Dec 2012 16:48:23 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 975842B24 for ; Wed, 12 Dec 2012 17:48:23 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 44ED953D68 for ; Wed, 12 Dec 2012 17:48:22 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F296B53C90 for ; Wed, 12 Dec 2012 17:48:21 +0200 (EET) Message-ID: <50C8A746.3030209@ericsson.com> Date: Wed, 12 Dec 2012 17:48:22 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <50BF612D.3070001@ericsson.com> In-Reply-To: <50BF612D.3070001@ericsson.com> Content-Type: multipart/alternative; boundary="------------000008020901070400030700" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvja7H8hMBBq9aOSwW3ZjO6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMbXD9kKJtlWdDZ8Z21g/K/dxcjJISFgInFn5Sc2CFtM4sK9 9UA2F4eQwElGiecdf9khnA2MEjdv/YJyLjNKbH3ykwXCOcYoser9e2YI5zyjxIL+B8wgw3gF tCXmfTrCCmKzCKhKnN+7BizOJmAm8fzhFjBbVCBWYuuly2wQ9YISJ2c+YQGxRYAOWX/0AVhc WKCdUWLKHk0QWwho5u/e3WC9nAI6EreuvQOrZxYIk1i6dyEzxBNqElfPbWKGqNeS6D3byTSB UXgWkhWzkLRA2LYSF+Zch4rLS2x/Owcqritx4f8UFPEFjGyrGNlzEzNz0ssNNzECw//glt+6 OxhPnRM5xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Pf3dr8zLLeulPu H0q+XWx2uOFdeuEaf8dd1QfhG+fUvl+Zvns16+LnX9Us8p/z7XyiNlnwzrmr8d9ZrcMlZU45 TL/Sv/rZyYVRq3dNWnPo+f7OrEW/YsvDe9yvGjBJtHhbfKz5JXjt6/M1i9S9Pl2f8ybaRWXB gljZI+JrEneujCya9m5/Z6CFEktxRqKhFnNRcSIALHBqhk0CAAA= Subject: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:48:28 -0000 --------------000008020901070400030700 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Even if the consensus call will formally end tomorrow I have to say that so far I don't see any consensus, the wg participants are divided almost equally in two camps one that is for HTTPS only and the other one that want to have the possibility to use both HTTP and HTTPS. What I can see clearly is only that the wg does not like the proposal #2 "HTTPS + HTTP but only as fallback". So for the sake of making progress I want to propose a compromise solution that while it will allow to use both at same time will try to reduce at the minimum the security risks to have both; in particular it tries to reduce the risk that can come from an automatic fall back from HTTPS to HTTP. With this proposal of course you have to accept and live with the fact that the client will be "more complicated" as it has to support both. Here is the idea and the proposed text for it: Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS and the server has an invalid certificate, the client MUST accept that the WebFinger query has failed. WebFinger servers operating on HTTP MAY redirect a client using HTTP status codes 301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST follow the redirection, issuing a query to the URI in the Location header. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI and the client MUST follow the redirection. However, WebFinger servers operating on HTTPS MUST NOT redirect a client to an HTTP URI. so please provide your comments, feedback on this compromise solution and also state clearly if you support it or not best regards Salvatore On 12/5/12 4:58 PM, Salvatore Loreto wrote: > > During the last couple of weeks there has been a lot of mail > discussing whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or > the other, > but also people that are more flexible and also having a preference > could live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why > you think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > -- Salvatore Loreto, PhD www.sloreto.com --------------000008020901070400030700 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
<with the wg chair hat on>


Even if the consensus call will formally end tomorrow I have to say that so far I don't see any consensus,
the wg participants are divided almost equally in two camps one that is for HTTPS only
and the other one that want to have the possibility to use both HTTP and HTTPS.
What I can see clearly is only that the wg does not like the proposal #2 "HTTPS + HTTP but only as fallback".

So for the sake of making progress
I want to propose a compromise solution that while it will allow to use both at same time
will try to reduce at the minimum the security risks to have both;
in particular it tries to reduce the risk that can come from an automatic fall back from HTTPS to HTTP.
With this proposal of course you have to accept and live with the fact that the client will be "more complicated"
as it has to support both.
Here is the idea and the proposed text for it:


Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP,
but MUST NOT attempt to use both, either serially or in parallel. 
The choice of transport protocols depends on the client’s security requirements,
though use of HTTPS is RECOMMENDED in most situations. 

If a query is issued using HTTPS and the server has an invalid certificate,
the client MUST accept that the WebFinger query has failed.
 
WebFinger servers operating on HTTP MAY redirect a client using HTTP status codes
301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST follow the redirection,
issuing a query to the URI in the Location header. 
Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI
and the client MUST follow the redirection. However, WebFinger servers operating on HTTPS
MUST NOT redirect a client to an HTTP URI.

so please provide your comments, feedback on this compromise solution and also state clearly if you support it or not

best regards
Salvatore



On 12/5/12 4:58 PM, Salvatore Loreto wrote:

During the last couple of weeks there has been a lot of mail discussing whether
WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the other,
but also people that are more flexible and also having a preference could live with the other.

However the discussion so far has not produced any clear consensus the editor can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you think WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore 



-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------000008020901070400030700-- From jasnell@gmail.com Wed Dec 12 08:20:32 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE9921E80C1 for ; Wed, 12 Dec 2012 08:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QVhvnCfuTzk for ; Wed, 12 Dec 2012 08:20:29 -0800 (PST) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4549D21E804A for ; Wed, 12 Dec 2012 08:20:29 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id w21so1094711iac.18 for ; Wed, 12 Dec 2012 08:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lUy2LEQGCFE1AJP1CmBlQqSkZ7Heo22dSTRmF7sBS4E=; b=IGV7Ey4E1qgJQ7qK2ezQm/f5aOAQU2OA3IXCZ9Y4E5nwFIXk7AJOLfHMbHX46yWEo6 eOyhODH+eJX2AnnlOrvJLfsRrAlkon20GypYupQtrJc8ku4jzovZTblrPRBzbGP1X6/P a/q8u37x3mKAvArxI9robzawQPFRhPqyl3Tfq2+/1Ctv/PyV9lAZBvAHqth8jEdO17p9 J+DhPsG5kA/cYUTGtAJw+FfydKixDq0nfnzmgThP1Vb9tktJBiEMREzaT5i8DpbxXJPs cSO1XNWnvfxPCNSxPg9Xxr2rictxLrPsc7VetBMG/03hJZNPXYDucz2/Hrqom4ZUtC5W ys2A== Received: by 10.50.178.106 with SMTP id cx10mr14019318igc.24.1355329228813; Wed, 12 Dec 2012 08:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 12 Dec 2012 08:20:08 -0800 (PST) In-Reply-To: <50C8A746.3030209@ericsson.com> References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> From: James M Snell Date: Wed, 12 Dec 2012 08:20:08 -0800 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=e89a8f5036c83cb7b004d0aa2d2b Cc: webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:20:32 -0000 --e89a8f5036c83cb7b004d0aa2d2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... this is excellent. On Wed, Dec 12, 2012 at 7:48 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > > > Even if the consensus call will formally end tomorrow I have to say that > so far I don't see any consensus, > the wg participants are divided almost equally in two camps one that is > for HTTPS only > and the other one that want to have the possibility to use both HTTP and > HTTPS. > What I can see clearly is only that the wg does not like the proposal #2 > "HTTPS + HTTP but only as fallback". > > So for the sake of making progress > I want to propose a compromise solution that while it will allow to use > both at same time > will try to reduce at the minimum the security risks to have both; > in particular it tries to reduce the risk that can come from an automatic > fall back from HTTPS to HTTP. > With this proposal of course you have to accept and live with the fact > that the client will be "more complicated" > as it has to support both. > Here is the idea and the proposed text for it: > > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, > but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, > though use of HTTPS is RECOMMENDED in most situations. > > If a query is issued using HTTPS and the server has an invalid > certificate, > the client MUST accept that the WebFinger query has failed. > > WebFinger servers operating on HTTP MAY redirect a client using HTTP > status codes > 301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST > follow the redirection, > issuing a query to the URI in the Location header. > Likewise, WebFinger servers operating on HTTPS MAY redirect a client to > another HTTPS URI > and the client MUST follow the redirection. However, WebFinger servers > operating on HTTPS > MUST NOT redirect a client to an HTTP URI. > > > so please provide your comments, feedback on this compromise solution and > also state clearly if you support it or not > > best regards > Salvatore > > > > On 12/5/12 4:58 PM, Salvatore Loreto wrote: > > > During the last couple of weeks there has been a lot of mail discussing > whether > WebFinger MUST support HTTPS only or instead it should be allowed for > WebFinger > fallback from HTTPS to HTTP. > There are people with a clear preference (sometime strong) one way or the > other, > but also people that are more flexible and also having a preference could > live with the other. > > However the discussion so far has not produced any clear consensus the > editor can include in the > next version of the wg draft. > > So as chairs I want explicitly to check where the wg consensus is > > 1) HTTPS only > > versus > > 2) HTTPS + HTTP but only as fallback > > So please provide your preference and if you want also the reason why you > think WebFinger should > adopt that particular solution. > > > This consensus call will run until December Thursday 13th, 2012 > > best regards > Salvatore > > > > -- > Salvatore Loreto, PhDwww.sloreto.com > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8f5036c83cb7b004d0aa2d2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... this is excellent.


On Wed, Dec 12, 2012= at 7:48 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
=20 =20 =20
<with the wg chair hat on>


Even if the consensus call will formally end tomorrow I have to say that so far I don't see any consensus,
the wg participants are divided almost equally in two camps one that is for HTTPS only
and the other one that want to have the possibility to use both HTTP and HTTPS.
What I can see clearly is only that the wg does not like the proposal #2 "HTTPS + HTTP but only as fallback".

So for the sake of making progress
I want to propose a compromise solution that while it will allow to use both at same time
will try to reduce at the minimum the security risks to have both; in particular it tries to reduce the risk that can come from an automatic fall back from HTTPS to HTTP.
With this proposal of course you have to accept and live with the fact that the client will be "more complicated"
as it has to support both.
Here is the idea and the proposed text for it:


Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP,
but MUST NOT attempt to use both, either serially or in parallel.=C2=A0
The choice of transport protocols depends on the client=E2=80=99s security requirements,
though use of HTTPS is RECOMMENDED in most situations.=C2=A0

If a query is issued using HTTPS and the server has an invalid certificate,
the client MUST accept that the WebFinger query has failed.
=C2=A0
WebFinger servers operating on HTTP MAY redirect a client using HTTP status codes
301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST follow the redirection,
issuing a query to the URI in the Location header.=C2=A0
Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI
and the client MUST follow the redirection. However, WebFinger servers operating on HTTPS
MUST NOT redirect a client to an HTTP URI.

so please provide your comments, feedback on this compromise solution and also state clearly if you support it or not

best regards
Salvatore



On 12/5/12 4:58 PM, Salvatore Loreto wrote:

During the last couple of weeks there has been a lot of mail discussing whether
WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the other,
but also people that are more flexible and also having a preference could live with the other.

However the discussion so far has not produced any clear consensus the editor can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why you think WebFinger should
adopt that particular solution.


This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore 



--=20
Salvatore Loreto, PhD
www.sloreto.com

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8f5036c83cb7b004d0aa2d2b-- From cyrus@daboo.name Wed Dec 12 08:37:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0A521E80D3 for ; Wed, 12 Dec 2012 08:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RCgZKlsWdyB for ; Wed, 12 Dec 2012 08:37:11 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8162B21F88C4 for ; Wed, 12 Dec 2012 08:37:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 31FFF37CA2E4; Wed, 12 Dec 2012 11:37:08 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi8i-LlWvKh5; Wed, 12 Dec 2012 11:37:07 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 8C67F37CA2D7; Wed, 12 Dec 2012 11:37:06 -0500 (EST) Date: Wed, 12 Dec 2012 11:37:03 -0500 From: Cyrus Daboo To: Salvatore Loreto , webfinger@ietf.org Message-ID: In-Reply-To: <50C8A746.3030209@ericsson.com> References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2699 Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:37:15 -0000 Hi Salvatore, --On December 12, 2012 5:48:22 PM +0200 Salvatore Loreto=20 wrote: > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, > but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s = security > requirements, > though use of HTTPS is RECOMMENDED in most situations. OK. > If a query is issued using HTTPS and the server has an invalid > certificate, > the client MUST accept that the WebFinger query has failed. I don't see how you can enforce this. Often times certificate checking is=20 done at a layer below the application code - a user may have previously=20 "accepted" an invalid certificate for a particular domain and in that case=20 subsequent application layer HTTPS connections can succeed without any kind = of "invalid certificate" notification. A better statement is: If client security requirements require the use of HTTPS, then clients MUST use HTTPS and MUST NOT fall back to HTTP connections either as a result of internal failure handling or as a result of a server-redirect. I think my proposed text is something clients can reasonably and reliably=20 do. > WebFinger servers operating on HTTP MAY redirect a client using HTTP > status codes > 301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST Don't quote specific response codes - new redirect codes can be defined=20 (e.g. 308:=20 ) > follow the redirection, > issuing a query to the URI in the Location header. > Likewise, WebFinger servers operating on HTTPS MAY redirect a client to > another HTTPS URI > and the client MUST follow the redirection. I am not sure we should enforce "MUST follow the redirection". First off=20 redirect behavior is built into HTTP so there is no need to repeat any 2119 = language. Second, there may be additional client security requirements that = restrict what sources it is willing to trust and the client should be=20 allowed to reject a redirect to an untrusted source. > However, WebFinger servers operating on HTTPS > MUST NOT redirect a client to an HTTP URI. The last requirement "servers MUST NOT redirect HTTPS to HTTP" needs to be=20 backed up by a statement on the client side that "clients MUST NOT follow=20 HTTPS to HTTP redirects" (which is what I included in my proposal above). Also, this behavior seems like it might be applicable to more than just=20 webfinger apps. Apps with similar security/trust requirements probably=20 exist, so shouldn't this behavior perhaps be rolled into something the=20 Websec WG should work on? --=20 Cyrus Daboo From paulej@packetizer.com Wed Dec 12 09:03:02 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D350C21F881C for ; Wed, 12 Dec 2012 09:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6B4OMUGlfJR for ; Wed, 12 Dec 2012 09:03:01 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E06C921F87F2 for ; Wed, 12 Dec 2012 09:03:00 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBCH2oLw029435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 12:02:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355331770; bh=WzRj3aKXcm9o8gfw0IvW2kWaGbEJH47xCjMwWTdVLfM=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aiHuRlP8c3Yc6rAYQkvV8gX2b50lJBKFpq+LD8Jgsa5Kf0pKCUc66XXeEoV9HMdUn Xeb+Y0YXbBqebT6i509oOry4HpiveBclWKFS32Tz7NLuqhoPhMlrplG/I68dxTYj2U a5M3CnfTGDtWCcQ1HYD4k6GlJ088Q0+2AhrB3oC4= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'Salvatore Loreto'" , References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> In-Reply-To: Date: Wed, 12 Dec 2012 12:02:59 -0500 Message-ID: <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgs3uWOXh1f7Eiv72bV+v1Wv2RMQNXOuP9AsmTS+6XPqMfIA== Content-Language: en-us Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:03:02 -0000 Cyrus, > > Clients MAY issue a query to the WebFinger server using either HTTPS > > or HTTP, but MUST NOT attempt to use both, either serially or in > > parallel. > > The choice of transport protocols depends on the client=E2=80=99s = security > > requirements, though use of HTTPS is RECOMMENDED in most situations. >=20 > OK. >=20 > > If a query is issued using HTTPS and the server has an invalid > > certificate, the client MUST accept that the WebFinger query has > > failed. >=20 > I don't see how you can enforce this. Often times certificate checking > is done at a layer below the application code - a user may have > previously "accepted" an invalid certificate for a particular domain = and > in that case subsequent application layer HTTPS connections can = succeed > without any kind of "invalid certificate" notification. That might be true if the transport layer below the WF client has been = configured by the user to ignore certificate errors and the client code = is oblivious to this fact. We cannot fix that, but we can at least = provide guidance to those who do have some control over the transport or = when there is an error. =20 > A better statement is: >=20 > If client security requirements require the use of HTTPS, then > clients MUST use HTTPS and MUST NOT fall back to HTTP connections > either as a result of internal failure handling or as a result of = a > server-redirect. > > I think my proposed text is something clients can reasonably and > reliably do. This does not address your stated concern with certificates. This is = more-or-less a re-wording of the first paragraph in Sal's message. = Personally, I would prefer to not introduce the words "fall back", = because there is "fall back" concept in WebFinger. A client may use = HTTPS or HTTP. So, what's written now is: Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client=E2=80=99s security requirements, though use of HTTPS is = RECOMMENDED in most situations. =20 > > WebFinger servers operating on HTTP MAY redirect a client using = HTTP > > status codes 301, 302, or 307 to another HTTP or an HTTPS URI and = the > > client MUST >=20 > Don't quote specific response codes - new redirect codes can be = defined > (e.g. 308: > ) That's probably a good idea. Should we say "status codes 3xx"? How is = this usually phrases? =20 > > follow the redirection, > > issuing a query to the URI in the Location header. > > Likewise, WebFinger servers operating on HTTPS MAY redirect a client > > to another HTTPS URI and the client MUST follow the redirection. >=20 > I am not sure we should enforce "MUST follow the redirection". First = off > redirect behavior is built into HTTP so there is no need to repeat any > 2119 language. Second, there may be additional client security > requirements that restrict what sources it is willing to trust and the > client should be allowed to reject a redirect to an untrusted source. Redirection behavior is defined in 2119 and this does not re-define it. = It just says "do it". We can soften that word to "SHOULD". Does that = help? Clearly, barring any good reason to not redirect, a client SHOULD = adhere to a redirection request. =20 > > However, WebFinger servers operating on HTTPS MUST NOT redirect a > > client to an HTTP URI. >=20 > The last requirement "servers MUST NOT redirect HTTPS to HTTP" needs = to > be backed up by a statement on the client side that "clients MUST NOT > follow HTTPS to HTTP redirects" (which is what I included in my = proposal > above). How about this additional sentence? Further, a client that issues a request using HTTPS MUST NOT follow a redirection to an HTTP URI. Note, though, that a client in a web browser it totally powerless to = prevent that from happening. =20 > Also, this behavior seems like it might be applicable to more than = just > webfinger apps. Apps with similar security/trust requirements probably > exist, so shouldn't this behavior perhaps be rolled into something the > Websec WG should work on? Probably. I asked Sal a similar question. That said, we don't want to = hold up the WF spec. Somebody interested in generalizing such security = recommendations should write an RFC that future specs can reference. Paul > -- > Cyrus Daboo >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Wed Dec 12 09:42:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB331F0CC9 for ; Wed, 12 Dec 2012 09:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKBNQZZGMuvG for ; Wed, 12 Dec 2012 09:42:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8341F0CC5 for ; Wed, 12 Dec 2012 09:42:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBCHg5Rk031268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 12:42:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355334126; bh=y0zqknvHTTxX1T+ESPuEhHw6aeYFS18p0I6GG2SjT5A=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YZMUYXiqH7hA6WCKM0VZg4iJoXpmbk4++twPjfo9CFM2LVu/AILy5HG85dUIRQFdW it7LFymYzRy4Eew7holfT+jovbg2MI102nWoxQLf5l2ZmBFs/7cS+1fZB5zwjUytmU 3HM2Gja9hAOELIYVjFTxYRjOBz089BVtWDZhWX5E= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'Salvatore Loreto'" , References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> In-Reply-To: <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> Date: Wed, 12 Dec 2012 12:42:15 -0500 Message-ID: <039f01cdd890$066401c0$132c0540$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgs3uWOXh1f7Eiv72bV+v1Wv2RMQNXOuP9AsmTS+4DDVLYVJcmR6rA Content-Language: en-us Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:42:10 -0000 Typos... > That might be true if the transport layer below the WF client has been > configured by the user to ignore certificate errors and the client code > is oblivious to this fact. We cannot fix that, but we can at least > provide guidance to those who do have some control over the transport or > when there is an error. "for when there is an error" > > A better statement is: > > > > If client security requirements require the use of HTTPS, then > > clients MUST use HTTPS and MUST NOT fall back to HTTP connections > > either as a result of internal failure handling or as a result of > a > > server-redirect. > > > > I think my proposed text is something clients can reasonably and > > reliably do. > > This does not address your stated concern with certificates. This is > more-or-less a re-wording of the first paragraph in Sal's message. > Personally, I would prefer to not introduce the words "fall back", > because there is "fall back" concept in WebFinger. A client may use > HTTPS or HTTP. So, what's written now is: "there is no "fall back" concept" Paul From bradfitz@google.com Wed Dec 12 09:44:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8310421E804D for ; Wed, 12 Dec 2012 09:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT9WkJxkQ-kS for ; Wed, 12 Dec 2012 09:44:12 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id AC43521E8047 for ; Wed, 12 Dec 2012 09:44:11 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so379196wgb.13 for ; Wed, 12 Dec 2012 09:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HL/28wTJ1w6f+b/2ypz8imNy0vhZkiVgUoR5uAP+QkI=; b=TzeFCX36YBeOB3Jorvmlqnb3ZiYgXNZJvM8c+Wu8dA+12P4EgIa8kvmF7spPyubcWN an7rkpJOa5CN9gt25XgqpRM5HOfVlAdRWRioeQLGvDgT/DH5KK8iXrkKVrsJvrfZHN/d HJQxPJ6EgYh8sVwt47NE6Q7V9GrEF0aqux8gjACQJ1S3TgUC78gZDliyrLHykcWL3g8d xavpSBX+IkLwaHxKRdVDvPY0gPwTXQuaN4p2h887GnD9itGJ+HsWtRY3EElU5sG4NUJA m0mstxftSAZDqyDjA4IrQlZP7sn7YSxMXfMu1e9dZEhOGdgHc1KL5AoSFjv/QGi4dvaN 6Sxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=HL/28wTJ1w6f+b/2ypz8imNy0vhZkiVgUoR5uAP+QkI=; b=BVuNb7ProhkCb3e/VFOOT9zfygXhp9JIMKRODQqPBPHVM6pssq/PmLwO7SSwawMOeB WTF2z5L9FOvoJxuCQrZIVtuSZL3aWjlqkqlwWYMzFGvv0tnrWUmTGc+FjQCyV3AKd++q MU8Lmr8qs0SkiUCCVj/c+3J/3Yrju6vyEyYQNVSTMmd4cKvfs8o+HQnp4LcQiUrCsVzj dEqXVKEBb45wgrnIozosKDpgAwOgohe2St9q3D4DD6gzVN79+uJP9vbwyEhb8vQ/Z0Hv qQdNFyx7xOagd9jfysNk7wR4hyArvop7jP1hIhQVM6VXlakNFS9O0okGbmkk/PQdJqBZ wePA== MIME-Version: 1.0 Received: by 10.180.107.130 with SMTP id hc2mr23200791wib.12.1355334250584; Wed, 12 Dec 2012 09:44:10 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 12 Dec 2012 09:44:10 -0800 (PST) Date: Wed, 12 Dec 2012 09:44:10 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@ietf.org, webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3baa6f8eda6b04d0ab58b5 X-Gm-Message-State: ALoCoQkSDS/rLNFgvCyzC/8BuO0oNQrG63MAhmg39/MiaaPNlM9PqURCNYdPwM/AotAo2PrvQRAf51ltqdzQ+jgZMnbuxGMpPkC+jIlUtEghzCGIwY+iWIEckDeVAIF9WtE8LGk+/JdVBszGi9Y6QurpyHeIb2Dgt++JSgLk7ojwUEUbjDsqUJHuKnbKm+UdSu8DCrRrL1Hu Subject: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:44:13 -0000 --e89a8f3baa6f8eda6b04d0ab58b5 Content-Type: text/plain; charset=UTF-8 Thinking about the current HTTPS impasse, I thought of another avenue which I don't recall having been discussed: What if we, * define some links as "secure links" (any link whose with a "rel" value beginning with the substring "https:") * say WebFinger servers can run on HTTPS or HTTP (making the $5/month hosting & RootCA hater camp happy), but noting that HTTPS is recommended and then required if "secure links" need to be returned * say WebFinger clients MUST try to hit HTTPS first (either serially first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is unreachable, but NOT if bad cert). * (new) say WebFinger clients using plain HTTP MUST filter out any "secure links" from the "links" list before giving it to their caller. So a caller that wanted, say, "OpenID Connect" (a secure user of WebFinger) could just write code like: wc = new WebFingerClient() server = wc.LookupHref("foo@example.com", " https://openid.net/connect/server") // Note "https:" prefix // use server, if non-empty So rather than configuring the WebFingerClient with a requested fallback policy, the policy is implicit in the rel requested. This still leaves the HTTPS-only camp arguing that "there will be so many crappy WebFinger client implementations out there" (those not doing the secure link filtering), but the counter-argument from earlier swayed me sufficiently: they're easily auditable, and anybody writing security software should audit their dependencies anyway. The "client" code is also so simple in the grand scheme of things, this mailing list could go bust out proper implementations in all popular languages and advertise them loudly. This is a bit of a compromise personally (it adds client complexity), but I'm willing to give some of that up in exchange for WebFinger being used more widely, for all sorts of applications. Thoughts? --e89a8f3baa6f8eda6b04d0ab58b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
T= hinking about the current HTTPS impasse, I thought of another avenue which = I don't recall having been discussed:

What if we,

* define some links as "secure links" (any li= nk whose with a "rel" value beginning with the substring "ht= tps:")

* say WebFinger servers can run on HTT= PS or HTTP (making the $5/month hosting & RootCA hater camp happy), but= noting that HTTPS is recommended and then required if "secure links&q= uot; need to be returned

*=C2=A0say=C2=A0WebFinger clients MUST try to hit HTTPS= first (either serially first or in parallel with HTTP), with a fallback to= HTTP (if HTTPS is unreachable, but NOT if bad cert).

<= div>* (new)=C2=A0say=C2=A0WebFinger clients using plain HTTP MUST filter ou= t any "secure links" from the "links" list before givin= g it to their caller.


So a caller that wanted, say, "Open= ID Connect" (a secure user of WebFinger) could just write code like:
=C2=A0 =C2=A0 =C2=A0wc =3D new WebFingerClient()
=C2=A0 =C2=A0 =C2=A0server =3D wc.LookupHref("foo@example.com", "https://openid.net/connect/server") =C2=A0// Note = "https:" prefix
=C2=A0 =C2=A0 =C2=A0// use server, if non-empty

So rather than configuring the WebFingerClient with a requested fallback= policy, the policy is implicit in the rel requested.

<= div>This still leaves the HTTPS-only camp arguing that "there will be = so many crappy WebFinger client implementations out there" (those not = doing the secure link filtering), but the counter-argument from earlier swa= yed me sufficiently: they're easily auditable, and anybody writing secu= rity software should audit their dependencies anyway. =C2=A0The "clien= t" code is also so simple in the grand scheme of things, this mailing = list could go bust out proper implementations in all popular languages and = advertise them loudly.

This is a bit of a compromise personally (it adds clien= t complexity), but I'm willing to give some of that up in exchange for = WebFinger being used more widely, for all sorts of applications.

Thoughts?

--e89a8f3baa6f8eda6b04d0ab58b5-- From jasnell@gmail.com Wed Dec 12 10:04:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0403621E80C0 for ; Wed, 12 Dec 2012 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHblY7zW-Jyz for ; Wed, 12 Dec 2012 10:04:42 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id E029221E805A for ; Wed, 12 Dec 2012 10:04:41 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so2296395iea.38 for ; Wed, 12 Dec 2012 10:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jLLKKxmNgbR1PrDO1A9kHHEft4rd8nrYDwiAFCSB0Xw=; b=ESWEqNUI1d2MFTEC0SbaDCyYQbXQ0pU7cs+7b35O6Z2vcUJR7bTWTu3Ux112henmtG V3Edv1lSfsu6k3Qn2ne3KF95p0DHVdwcRSMoXZ/FmZGkxQYIUp7Xv4IDZXDhj/pao3lJ cPEt66crRnU+9dYhD1nJIuf3RKs71uBiVkjYM2Tgi1huzSdaa8rsTl3Jgm0qPafySzwd JAqt7HLNIXKoCURD9Lz/synBVZgf/mKdsghoFc7U1jRRXPv6cR4egvh6gEhKmNyu62X5 ELiRMeZqILVWHjDa685mwTWv3zSF7O3vQk8a9h9geGEKAR75k1Bq/eqJU0W7d3lqjkUh FmPg== Received: by 10.50.151.238 with SMTP id ut14mr14340804igb.72.1355335480395; Wed, 12 Dec 2012 10:04:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Wed, 12 Dec 2012 10:04:20 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Wed, 12 Dec 2012 10:04:20 -0800 Message-ID: To: webfinger@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3b9f7ddc47ef04d0aba171 Subject: [webfinger] Fwd: Outstanding WF Security Concerns X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:04:43 -0000 --e89a8f3b9f7ddc47ef04d0aba171 Content-Type: text/plain; charset=UTF-8 I had sent this before but I believe it went out before many people had moved over to the new list. Item #1 has already been discussed but still needs to be addressed in the draft. The other issues, as far as I can tell, have not yet been dealt with. ---------- Forwarded message ---------- From: James M Snell Date: Tue, Dec 4, 2012 at 1:48 PM Subject: Outstanding WF Security Concerns To: webfinger@ietf.org In the current draft -07 spec there are a handful of fairly important security issues that have yet to be dealt with. I summarized these in a separate note to Paul and the other authors while waiting for this new list to be set up and wanted to call them out here for discussion as well. 1. Potential Mixed-session hijack vulnerability When accessing an authenticated WebFinger service via HTTPS, there is a potential session-hijacking vulnerability if the returned JRD contains non-HTTPS URLs to the same domain as the WebFinger server and session cookies are not properly secured. As a best practice, if the JRD is served over a HTTPS connection, any links to the same domain contained within the JRD SHOULD also use HTTPS and server implementations need to make sure that all session cookies are properly secured against hijacking. (This issue is no different than your typical mixed-session vulnerability) 2. 3xx Redirects to insecure targets WebFinger explicitly allows a WebFinger server to redirect requests to a separate third party service provider. It does not, however, require the use of HTTPS with the redirected target. For example, imagine sending a GET request to: https://example.org/.well-known/webfinger?r... And getting back... HTTP/1.1 302 Found Location: http://example.net/wf?r=... The redirected request will no longer be protected, negating the point of using HTTPS in the first request and putting the client at risk. Redirects returned by the server for requests issued over HTTPS ought to be required to point to HTTPS secured URLs... e.g. HTTP/1.1 302 Found Location: https://example.net/wf?r=... 3. Also with regards to third party redirects, how is the client able to determine that the redirection was appropriately authorized by the original WF provider? If the server (or vulnerable intermediary) has been compromised, a client can be tricked into redirecting to a malicious server providing false information. If, for instance, a fake Identity Provider URL is provided, the client may not be capable of detecting the intrusion. Use of HTTPS will not prevent such attacks. One reliable solution is to require the use of cryptographic integrity checks on the JRD resource. That is, if Server A redirects to Server B, then the JRD provided by Server B needs to be signed by a key trusted by both Server A and the client. However it is done, the client needs to be able to determine that Server B is authorized by Server A to provide WebFinger data on it's behalf... a redirect served over HTTPS does not, by itself, provide sufficient assurance. 4. When a client sends an unauthorized WebFinger request for a resource, a 404 Not Found response needs to be returned to make such responses indistinguishable from requests for resources the service has no information about. - James --e89a8f3b9f7ddc47ef04d0aba171 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had sent this before but I believe i= t went out before many people had moved over to the new list. Item #1 has a= lready been discussed but still needs to be addressed in the draft. The oth= er issues, as far as I can tell, have not yet been dealt with.

---------- Forwarded message --------= --
From: James M Snell <jasnell@gmail.com>
Date: Tue, Dec 4, 2012 at 1:48 PM
Subject: Outstanding WF Security Conce= rns
To: webfinger@ietf.org
=

In the current draft -07 spec= there are a handful of fairly important security issues that have yet to b= e dealt with. I summarized these in a separate note to Paul and the other a= uthors while waiting for this new list to be set up and wanted to call them= out here for discussion as well.=C2=A0

1. Potential Mixed-session hijack vulnerability

=C2=A0 =C2=A0When accessing an authenti= cated WebFinger service via HTTPS,
=C2=A0 =C2=A0there is a potentia= l session-hijacking vulnerability if the=C2=A0
=C2=A0 =C2=A0returned JRD contains non-HTTPS UR= Ls to the same domain as=C2=A0
=C2=A0 =C2=A0the WebFinger serve= r and session cookies are not properly=C2=A0
=C2=A0 =C2=A0secured. As a best practice, if the J= RD is served over a=C2=A0
=C2=A0 =C2=A0HTTPS connection, a= ny links to the same domain contained=C2=A0
=C2=A0 =C2=A0within the JRD SHOULD also use HTTPS a= nd server implementations
=C2=A0 =C2=A0need to make sure t= hat all session cookies are properly=C2=A0
=C2=A0 =C2=A0secured against hijacking. (This issue = is no different than=C2=A0
=C2=A0 =C2=A0your typical mixed-= session vulnerability)

2. 3xx Redir= ects to insecure targets

=C2=A0 =C2=A0WebFinger explicitly allows a WebF= inger server to redirect=C2=A0
=C2=A0 =C2=A0requests to a separate third party service provider= . It=C2=A0
=C2=A0 =C2=A0does not, however, = require the use of HTTPS with the redirected
=C2=A0 =C2=A0target.=C2=A0

=C2=A0 =C2=A0For ex= ample, imagine sending a GET request to:


=C2=A0 =C2=A0And getting back...

=C2=A0 =C2=A0 =C2= =A0HTTP/1.1 302 Found
=C2=A0 =C2=A0 =C2=A0Location: http://example.net/= wf?r=3D...

<= /font>
=C2=A0 =C2=A0The red= irected request will no longer be protected, negating=C2=A0
=C2=A0 =C2=A0the point of using = HTTPS in the first request and putting the
=C2=A0 =C2=A0client at risk.=C2=A0
=
=C2=A0 =C2=A0Redire= cts returned by the server for requests issued over HTTPS
= =C2=A0 =C2=A0ought to be required to = point to HTTPS secured URLs... e.g.

=C2=A0 =C2=A0 =C2=A0HTTP/1.1 302 Found
=C2=A0 =C2=A0 =C2=A0Location= : https://exampl= e.net/wf?r=3D...

3. Also with regards to third party redirects,= =C2=A0how is the client=C2=A0
=C2=A0 =C2=A0able to determine that the redirection was appr= opriately=C2=A0
=C2=A0 =C2=A0authorized b= y the original WF provider? If the server (or=C2=A0
=C2=A0 =C2=A0vulnerable intermediary) has been compromised, = a client can be=C2=A0
=C2=A0 =C2=A0tricke= d into redirecting to a malicious server providing false=C2=A0
=C2=A0 =C2=A0information. If, for instance, a fake Identity = Provider URL is=C2=A0
=C2=A0 =C2=A0provid= ed, the client may not be capable of detecting the intrusion.=C2=A0<= /span>
=C2=A0 =C2=A0Use of HTTPS will not prevent such attacks. One= reliable=C2=A0
=C2=A0 =C2=A0solution is = to require the use of cryptographic integrity checks on=C2=A0=
=C2=A0 =C2=A0the JRD resource. That is, if Server A redirect= s to Server B, then=C2=A0
=C2=A0 =C2=A0th= e JRD provided by Server B needs to be signed by a key trusted by=C2=A0
=C2=A0 =C2=A0both Server A and the client. However it is don= e, the client needs
=C2=A0 =C2=A0to be ab= le to determine that Server B is authorized by Server A
=C2=A0 =C2=A0to provide WebFinger data on it's behalf...= a redirect served over
=C2=A0 =C2=A0HTTP= S does not, by itself, provide sufficient assurance.

4. When a client send= s an unauthorized WebFinger request for a=C2=A0
=C2=A0 =C2=A0resource, a 404 Not Found response needs to be = returned to make
=C2=A0 =C2=A0such respon= ses indistinguishable from requests for resources the
=C2=A0 =C2=A0service has no information about.=

- James

--e89a8f3b9f7ddc47ef04d0aba171-- From romeda@gmail.com Wed Dec 12 10:35:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE21F0CC2 for ; Wed, 12 Dec 2012 10:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnXtkb9jLc8K for ; Wed, 12 Dec 2012 10:35:36 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 519611F0CBE for ; Wed, 12 Dec 2012 10:35:36 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so332309dae.31 for ; Wed, 12 Dec 2012 10:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gc2RPbUlf0Ovwk4GipYJjqMVY9bBktqZYBuxtEH/jVg=; b=d4nzxOKnUaoBXuvn0wovVR0F1LoFsrhRMv663GGxp1uISB+29Hglbi6t5COccysNko 8dwYwohwpVlxxTpDCWGq/L6cyeTzWz3G2vyP2wyWztFjxb1WDQPYoBVkBLgSdXJ8/m5J REyKtsdUoksd1KDZxeVeG7HwCZBIMddwvhLl6R4XlGDj/bJZ1idUs9bKnY738ZTAvXnM ejW4qGhz1op+LBkLKvqa9CaujoHaPnrRlqHMqe5U3yCOO0wvC/qrgcCVKKuqzF2eFZBz LH8sDo3ZgxsO2LfF4mxlOCY7paMnru3E/k9aaxYj6OpouuzlIGV3puXi5CR+y3sso3pH QSEQ== Received: by 10.66.80.202 with SMTP id t10mr4385975pax.81.1355337335613; Wed, 12 Dec 2012 10:35:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Wed, 12 Dec 2012 10:35:15 -0800 (PST) In-Reply-To: References: From: Blaine Cook Date: Wed, 12 Dec 2012 18:35:15 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d042ef4ff70a82b04d0ac10d6 Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:35:37 -0000 --f46d042ef4ff70a82b04d0ac10d6 Content-Type: text/plain; charset=UTF-8 Works for me. On 12 December 2012 18:34, Breno wrote: > Works for me. > On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick" wrote: > >> Thinking about the current HTTPS impasse, I thought of another avenue >> which I don't recall having been discussed: >> >> What if we, >> >> * define some links as "secure links" (any link whose with a "rel" value >> beginning with the substring "https:") >> >> * say WebFinger servers can run on HTTPS or HTTP (making the $5/month >> hosting & RootCA hater camp happy), but noting that HTTPS is recommended >> and then required if "secure links" need to be returned >> >> * say WebFinger clients MUST try to hit HTTPS first (either serially >> first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is >> unreachable, but NOT if bad cert). >> >> * (new) say WebFinger clients using plain HTTP MUST filter out any >> "secure links" from the "links" list before giving it to their caller. >> >> >> So a caller that wanted, say, "OpenID Connect" (a secure user of >> WebFinger) could just write code like: >> >> wc = new WebFingerClient() >> server = wc.LookupHref("foo@example.com", " >> https://openid.net/connect/server") // Note "https:" prefix >> // use server, if non-empty >> >> So rather than configuring the WebFingerClient with a requested fallback >> policy, the policy is implicit in the rel requested. >> >> This still leaves the HTTPS-only camp arguing that "there will be so many >> crappy WebFinger client implementations out there" (those not doing the >> secure link filtering), but the counter-argument from earlier swayed me >> sufficiently: they're easily auditable, and anybody writing security >> software should audit their dependencies anyway. The "client" code is also >> so simple in the grand scheme of things, this mailing list could go bust >> out proper implementations in all popular languages and advertise them >> loudly. >> >> This is a bit of a compromise personally (it adds client complexity), but >> I'm willing to give some of that up in exchange for WebFinger being used >> more widely, for all sorts of applications. >> >> Thoughts? >> >> --f46d042ef4ff70a82b04d0ac10d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me.


= On 12 December 2012 18:34, Breno <breno.demedeiros@gmail.com&= gt; wrote:

Works for me.

On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick&= quot; <bradfitz= @google.com> wrote:
Thinki= ng about the current HTTPS impasse, I thought of another avenue which I don= 't recall having been discussed:

What if we,

* define some links as "secure links" (any li= nk whose with a "rel" value beginning with the substring "ht= tps:")

* say WebFinger servers can run on HTT= PS or HTTP (making the $5/month hosting & RootCA hater camp happy), but= noting that HTTPS is recommended and then required if "secure links&q= uot; need to be returned

*=C2=A0say=C2=A0WebFinger clients MUST try to hit HTTPS= first (either serially first or in parallel with HTTP), with a fallback to= HTTP (if HTTPS is unreachable, but NOT if bad cert).

<= div>* (new)=C2=A0say=C2=A0WebFinger clients using plain HTTP MUST filter ou= t any "secure links" from the "links" list before givin= g it to their caller.


So a caller that wanted, say, "Open= ID Connect" (a secure user of WebFinger) could just write code like:
=C2=A0 =C2=A0 =C2=A0wc =3D new WebFingerClient()
=C2=A0 =C2=A0 =C2=A0server =3D wc.LookupHref("foo@example.com", "https://openid.net/conn= ect/server") =C2=A0// Note "https:" prefix
=C2=A0 =C2=A0 =C2=A0// use server, if non-empty

So rather than configuring the WebFingerClient with a requested fallback= policy, the policy is implicit in the rel requested.

<= div>This still leaves the HTTPS-only camp arguing that "there will be = so many crappy WebFinger client implementations out there" (those not = doing the secure link filtering), but the counter-argument from earlier swa= yed me sufficiently: they're easily auditable, and anybody writing secu= rity software should audit their dependencies anyway. =C2=A0The "clien= t" code is also so simple in the grand scheme of things, this mailing = list could go bust out proper implementations in all popular languages and = advertise them loudly.

This is a bit of a compromise personally (it adds clien= t complexity), but I'm willing to give some of that up in exchange for = WebFinger being used more widely, for all sorts of applications.

Thoughts?


--f46d042ef4ff70a82b04d0ac10d6-- From laurentwalter.goix@telecomitalia.it Wed Dec 12 10:40:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24A21F0CD9 for ; Wed, 12 Dec 2012 10:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf9ZEotcvnTm for ; Wed, 12 Dec 2012 10:40:11 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id D74591F0CBE for ; Wed, 12 Dec 2012 10:40:10 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 12 Dec 2012 19:40:08 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 12 Dec 2012 19:40:08 +0100 From: Goix Laurent Walter To: "Paul E. Jones" Date: Wed, 12 Dec 2012 19:40:02 +0100 Thread-Topic: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) Thread-Index: Ac3YmBvqHyNaUY8kQzyYPSxeykNj1w== Message-ID: References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> In-Reply-To: <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Cyrus Daboo , Salvatore Loreto , "webfinger@ietf.org" Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:40:13 -0000 KzEuIEluIGdlbmVyYWwgaSB3b3VsZCBiZSBjYXJlZnVsL3ByYWdtYXRpYyB3aGVuIHVzaW5nIE1V U1QgTk9UIG9uIHRoZSBjbGllbnQgc2lkZS4NCkFzIFBhdWwgc2FpZCBpdCBtYXkgYmUgZGlmZmlj dWx0IHRvIHByZXZlbnQgc29tZSBhdXRvbWF0aWMgYmVoYXZpb3VyIG9mIGh0dHAgc3RhY2tzIHdo ZW4gaGFuZGxpbmcgcmVkaXJlY3RzLg0KDQpCdXQgaXQgd291bGQgYWxzbyBiZSBkaWZmaWN1bHQg dG8gcHJldmVudCBhIGNsaWVudCB0byBpc3N1ZSAyIHdmIHJlcXVlc3RzIGluIHBhcmFsbGVsIG9y IGluIHNlcXVlbmNlLiBJJ20gbm90IHRhbGtpbmcgYWJvdXQgZmFsbGJhY2sgYnV0IHNpbXBsZS9z dHVwaWQgYmVoYXZpb3VyOiB3aGF0IHdvdWxkIGluZGVlZCBoYXBwZW4gaWYgYSBjbGllbnQgZG8g c28/IEkgZG9uJ3QgdGhpbmsgc2VydmVycyB3b3VsZCBhbHdheXMgaW1wbGVtZW50IGEgbG9naWMg c2F5aW5nIHRoYXQgaWYgYSBjbGllbnQganVzdCBpc3N1ZWQgYSByZXF1ZXN0IG9uIG9uZSBwcm90 b2NvbCB0aGVuIEknbGwgcmVjb2duaXplIHRoZSBzZWNvbmQgYW5kIHJlamVjdCBpdC4gSWYgdGhp cyBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIHRoZW4gdGhlIHNlcnZlci1zaWRlIHByb2NlZHVy ZSBzaG91bGQgYmUgY2xhcmlmaWVkLiBPdGhlcndpc2Ugc3VjaCBnZW5lcmljIHN0YXRlbWVudCBp cyB1bnJlYWxpc3RpYyBhbmQgc2hvdWxkIGJldHRlciBjYWxsIG91dCB0aGUgZmFsbGJhY2sgdXNl IGNhc2UgZXhwbGljaXRseSAoZWcgImNsaWVudHMgU0hPVUxEIE5PVCB1c2UgaHR0cCBhcyBmYWxs YmFjayBhZnRlciByZWNlaXZpbmcgYW4gZXJyb3IgdXBvbiBhbiBodHRwcyByZXF1ZXN0IGZvciB0 aGUgc2FtZSByZXNvdXJjZSIpDQoNCldhbHRlcg0KDQpMZSAxMiBkw6ljLiAyMDEyIMOgIDE4OjAz LCAiUGF1bCBFLiBKb25lcyIgPHBhdWxlakBwYWNrZXRpemVyLmNvbT4gYSDDqWNyaXQgOg0KDQo+ IEN5cnVzLA0KPg0KPj4+IENsaWVudHMgTUFZIGlzc3VlIGEgcXVlcnkgdG8gdGhlIFdlYkZpbmdl ciBzZXJ2ZXIgdXNpbmcgZWl0aGVyIEhUVFBTDQo+Pj4gb3IgSFRUUCwgIGJ1dCBNVVNUIE5PVCBh dHRlbXB0IHRvIHVzZSBib3RoLCBlaXRoZXIgc2VyaWFsbHkgb3IgaW4NCj4+PiBwYXJhbGxlbC4N Cj4+PiBUaGUgY2hvaWNlIG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgZGVwZW5kcyBvbiB0aGUgY2xp ZW504oCZcyBzZWN1cml0eQ0KPj4+IHJlcXVpcmVtZW50cywgdGhvdWdoIHVzZSBvZiBIVFRQUyBp cyBSRUNPTU1FTkRFRCBpbiBtb3N0IHNpdHVhdGlvbnMuDQo+Pg0KPj4gT0suDQo+Pg0KPj4+IElm IGEgcXVlcnkgaXMgaXNzdWVkIHVzaW5nIEhUVFBTIGFuZCB0aGUgc2VydmVyIGhhcyBhbiBpbnZh bGlkDQo+Pj4gY2VydGlmaWNhdGUsIHRoZSBjbGllbnQgTVVTVCBhY2NlcHQgdGhhdCB0aGUgV2Vi RmluZ2VyIHF1ZXJ5IGhhcw0KPj4+IGZhaWxlZC4NCj4+DQo+PiBJIGRvbid0IHNlZSBob3cgeW91 IGNhbiBlbmZvcmNlIHRoaXMuIE9mdGVuIHRpbWVzIGNlcnRpZmljYXRlIGNoZWNraW5nDQo+PiBp cyBkb25lIGF0IGEgbGF5ZXIgYmVsb3cgdGhlIGFwcGxpY2F0aW9uIGNvZGUgLSBhIHVzZXIgbWF5 IGhhdmUNCj4+IHByZXZpb3VzbHkgImFjY2VwdGVkIiBhbiBpbnZhbGlkIGNlcnRpZmljYXRlIGZv ciBhIHBhcnRpY3VsYXIgZG9tYWluIGFuZA0KPj4gaW4gdGhhdCBjYXNlIHN1YnNlcXVlbnQgYXBw bGljYXRpb24gbGF5ZXIgSFRUUFMgY29ubmVjdGlvbnMgY2FuIHN1Y2NlZWQNCj4+IHdpdGhvdXQg YW55IGtpbmQgb2YgImludmFsaWQgY2VydGlmaWNhdGUiIG5vdGlmaWNhdGlvbi4NCj4NCj4gVGhh dCBtaWdodCBiZSB0cnVlIGlmIHRoZSB0cmFuc3BvcnQgbGF5ZXIgYmVsb3cgdGhlIFdGIGNsaWVu dCBoYXMgYmVlbiBjb25maWd1cmVkIGJ5IHRoZSB1c2VyIHRvIGlnbm9yZSBjZXJ0aWZpY2F0ZSBl cnJvcnMgYW5kIHRoZSBjbGllbnQgY29kZSBpcyBvYmxpdmlvdXMgdG8gdGhpcyBmYWN0LiAgV2Ug Y2Fubm90IGZpeCB0aGF0LCBidXQgd2UgY2FuIGF0IGxlYXN0IHByb3ZpZGUgZ3VpZGFuY2UgdG8g dGhvc2Ugd2hvIGRvIGhhdmUgc29tZSBjb250cm9sIG92ZXIgdGhlIHRyYW5zcG9ydCBvciB3aGVu IHRoZXJlIGlzIGFuIGVycm9yLg0KPg0KPj4gQSBiZXR0ZXIgc3RhdGVtZW50IGlzOg0KPj4NCj4+ ICAgIElmIGNsaWVudCBzZWN1cml0eSByZXF1aXJlbWVudHMgcmVxdWlyZSB0aGUgdXNlIG9mIEhU VFBTLCB0aGVuDQo+PiAgICBjbGllbnRzIE1VU1QgdXNlIEhUVFBTIGFuZCBNVVNUIE5PVCBmYWxs IGJhY2sgdG8gIEhUVFAgY29ubmVjdGlvbnMNCj4+ICAgIGVpdGhlciBhcyBhIHJlc3VsdCBvZiBp bnRlcm5hbCBmYWlsdXJlIGhhbmRsaW5nIG9yIGFzIGEgcmVzdWx0IG9mIGENCj4+ICAgIHNlcnZl ci1yZWRpcmVjdC4NCj4+DQo+PiBJIHRoaW5rIG15IHByb3Bvc2VkIHRleHQgaXMgc29tZXRoaW5n IGNsaWVudHMgY2FuIHJlYXNvbmFibHkgYW5kDQo+PiByZWxpYWJseSBkby4NCj4NCj4gVGhpcyBk b2VzIG5vdCBhZGRyZXNzIHlvdXIgc3RhdGVkIGNvbmNlcm4gd2l0aCBjZXJ0aWZpY2F0ZXMuICBU aGlzIGlzIG1vcmUtb3ItbGVzcyBhIHJlLXdvcmRpbmcgb2YgdGhlIGZpcnN0IHBhcmFncmFwaCBp biBTYWwncyBtZXNzYWdlLiAgUGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIgdG8gbm90IGludHJv ZHVjZSB0aGUgd29yZHMgImZhbGwgYmFjayIsIGJlY2F1c2UgdGhlcmUgaXMgImZhbGwgYmFjayIg Y29uY2VwdCBpbiBXZWJGaW5nZXIuICBBIGNsaWVudCBtYXkgdXNlIEhUVFBTIG9yIEhUVFAuICBT bywgd2hhdCdzIHdyaXR0ZW4gbm93IGlzOg0KPg0KPiAgICBDbGllbnRzIE1BWSBpc3N1ZSBhIHF1 ZXJ5IHRvIHRoZSBXZWJGaW5nZXIgc2VydmVyIHVzaW5nIGVpdGhlcg0KPiAgICBIVFRQUyBvciBI VFRQLCBidXQgTVVTVCBOT1QgYXR0ZW1wdCB0byB1c2UgYm90aCwgZWl0aGVyIHNlcmlhbGx5DQo+ ICAgIG9yIGluIHBhcmFsbGVsLiAgVGhlIGNob2ljZSBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzIGRl cGVuZHMgb24gdGhlDQo+ICAgIGNsaWVudOKAmXMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLCB0aG91 Z2ggdXNlIG9mIEhUVFBTIGlzIFJFQ09NTUVOREVEDQo+ICAgIGluIG1vc3Qgc2l0dWF0aW9ucy4N Cj4NCj4+PiBXZWJGaW5nZXIgc2VydmVycyBvcGVyYXRpbmcgb24gSFRUUCBNQVkgcmVkaXJlY3Qg YSBjbGllbnQgdXNpbmcgSFRUUA0KPj4+IHN0YXR1cyBjb2RlcyAzMDEsIDMwMiwgb3IgMzA3IHRv IGFub3RoZXIgSFRUUCBvciBhbiBIVFRQUyBVUkkgYW5kIHRoZQ0KPj4+IGNsaWVudCBNVVNUDQo+ Pg0KPj4gRG9uJ3QgcXVvdGUgc3BlY2lmaWMgcmVzcG9uc2UgY29kZXMgLSBuZXcgcmVkaXJlY3Qg Y29kZXMgY2FuIGJlIGRlZmluZWQNCj4+IChlLmcuIDMwODoNCj4+IDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZXNjaGtlLWh0dHAtc3RhdHVzLTMwOC8+KQ0KPg0KPiBU aGF0J3MgcHJvYmFibHkgYSBnb29kIGlkZWEuICBTaG91bGQgd2Ugc2F5ICJzdGF0dXMgY29kZXMg M3h4Ij8gIEhvdyBpcyB0aGlzIHVzdWFsbHkgcGhyYXNlcz8NCj4NCj4+PiBmb2xsb3cgdGhlIHJl ZGlyZWN0aW9uLA0KPj4+IGlzc3VpbmcgYSBxdWVyeSB0byB0aGUgVVJJIGluIHRoZSBMb2NhdGlv biBoZWFkZXIuDQo+Pj4gTGlrZXdpc2UsIFdlYkZpbmdlciBzZXJ2ZXJzIG9wZXJhdGluZyBvbiBI VFRQUyBNQVkgcmVkaXJlY3QgYSBjbGllbnQNCj4+PiB0byBhbm90aGVyIEhUVFBTIFVSSSBhbmQg dGhlIGNsaWVudCBNVVNUIGZvbGxvdyB0aGUgcmVkaXJlY3Rpb24uDQo+Pg0KPj4gSSBhbSBub3Qg c3VyZSB3ZSBzaG91bGQgZW5mb3JjZSAiTVVTVCBmb2xsb3cgdGhlIHJlZGlyZWN0aW9uIi4gRmly c3Qgb2ZmDQo+PiByZWRpcmVjdCBiZWhhdmlvciBpcyBidWlsdCBpbnRvIEhUVFAgc28gdGhlcmUg aXMgbm8gbmVlZCB0byByZXBlYXQgYW55DQo+PiAyMTE5IGxhbmd1YWdlLiBTZWNvbmQsIHRoZXJl IG1heSBiZSBhZGRpdGlvbmFsIGNsaWVudCBzZWN1cml0eQ0KPj4gcmVxdWlyZW1lbnRzIHRoYXQg cmVzdHJpY3Qgd2hhdCBzb3VyY2VzIGl0IGlzIHdpbGxpbmcgdG8gdHJ1c3QgYW5kIHRoZQ0KPj4g Y2xpZW50IHNob3VsZCBiZSBhbGxvd2VkIHRvIHJlamVjdCBhIHJlZGlyZWN0IHRvIGFuIHVudHJ1 c3RlZCBzb3VyY2UuDQo+DQo+IFJlZGlyZWN0aW9uIGJlaGF2aW9yIGlzIGRlZmluZWQgaW4gMjEx OSBhbmQgdGhpcyBkb2VzIG5vdCByZS1kZWZpbmUgaXQuICBJdCBqdXN0IHNheXMgImRvIGl0Ii4g IFdlIGNhbiBzb2Z0ZW4gdGhhdCB3b3JkIHRvICJTSE9VTEQiLiAgRG9lcyB0aGF0IGhlbHA/ICBD bGVhcmx5LCBiYXJyaW5nIGFueSBnb29kIHJlYXNvbiB0byBub3QgcmVkaXJlY3QsIGEgY2xpZW50 IFNIT1VMRCBhZGhlcmUgdG8gYSByZWRpcmVjdGlvbiByZXF1ZXN0Lg0KPg0KPj4+IEhvd2V2ZXIs IFdlYkZpbmdlciBzZXJ2ZXJzIG9wZXJhdGluZyBvbiBIVFRQUyBNVVNUIE5PVCByZWRpcmVjdCBh DQo+Pj4gY2xpZW50IHRvIGFuIEhUVFAgVVJJLg0KPj4NCj4+IFRoZSBsYXN0IHJlcXVpcmVtZW50 ICJzZXJ2ZXJzIE1VU1QgTk9UIHJlZGlyZWN0IEhUVFBTIHRvIEhUVFAiIG5lZWRzIHRvDQo+PiBi ZSBiYWNrZWQgdXAgYnkgYSBzdGF0ZW1lbnQgb24gdGhlIGNsaWVudCBzaWRlIHRoYXQgImNsaWVu dHMgTVVTVCBOT1QNCj4+IGZvbGxvdyBIVFRQUyB0byBIVFRQIHJlZGlyZWN0cyIgKHdoaWNoIGlz IHdoYXQgSSBpbmNsdWRlZCBpbiBteSBwcm9wb3NhbA0KPj4gYWJvdmUpLg0KPg0KPiBIb3cgYWJv dXQgdGhpcyBhZGRpdGlvbmFsIHNlbnRlbmNlPw0KPg0KPiAgICBGdXJ0aGVyLCBhIGNsaWVudCB0 aGF0IGlzc3VlcyBhIHJlcXVlc3QgdXNpbmcgSFRUUFMgTVVTVCBOT1QNCj4gICAgZm9sbG93IGEg cmVkaXJlY3Rpb24gdG8gYW4gSFRUUCBVUkkuDQo+DQo+IE5vdGUsIHRob3VnaCwgdGhhdCBhIGNs aWVudCBpbiBhIHdlYiBicm93c2VyIGl0IHRvdGFsbHkgcG93ZXJsZXNzIHRvIHByZXZlbnQgdGhh dCBmcm9tIGhhcHBlbmluZy4NCj4NCj4+IEFsc28sIHRoaXMgYmVoYXZpb3Igc2VlbXMgbGlrZSBp dCBtaWdodCBiZSBhcHBsaWNhYmxlIHRvIG1vcmUgdGhhbiBqdXN0DQo+PiB3ZWJmaW5nZXIgYXBw cy4gQXBwcyB3aXRoIHNpbWlsYXIgc2VjdXJpdHkvdHJ1c3QgcmVxdWlyZW1lbnRzIHByb2JhYmx5 DQo+PiBleGlzdCwgc28gc2hvdWxkbid0IHRoaXMgYmVoYXZpb3IgcGVyaGFwcyBiZSByb2xsZWQg aW50byBzb21ldGhpbmcgdGhlDQo+PiBXZWJzZWMgV0cgc2hvdWxkIHdvcmsgb24/DQo+DQo+IFBy b2JhYmx5LiAgSSBhc2tlZCBTYWwgYSBzaW1pbGFyIHF1ZXN0aW9uLiAgVGhhdCBzYWlkLCB3ZSBk b24ndCB3YW50IHRvIGhvbGQgdXAgdGhlIFdGIHNwZWMuICBTb21lYm9keSBpbnRlcmVzdGVkIGlu IGdlbmVyYWxpemluZyBzdWNoIHNlY3VyaXR5IHJlY29tbWVuZGF0aW9ucyBzaG91bGQgd3JpdGUg YW4gUkZDIHRoYXQgZnV0dXJlIHNwZWNzIGNhbiByZWZlcmVuY2UuDQo+DQo+IFBhdWwNCj4NCj4+ IC0tDQo+PiBDeXJ1cyBEYWJvbw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiB3ZWJmaW5nZXIgbWFpbGluZyBsaXN0DQo+PiB3ZWJmaW5n ZXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2Vi ZmluZ2VyDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHdlYmZpbmdlciBtYWlsaW5nIGxpc3QNCj4gd2ViZmluZ2VyQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2ViZmluZ2VyDQoNClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0 aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9y aXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIg YnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo= From nick@silverbucket.net Wed Dec 12 10:47:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC5621E80F0 for ; Wed, 12 Dec 2012 10:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WS1byCRVg+e for ; Wed, 12 Dec 2012 10:47:36 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7821E804D for ; Wed, 12 Dec 2012 10:47:36 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so948894lah.31 for ; Wed, 12 Dec 2012 10:47:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=DEc6HPlCiCtHt4GXsLCClHvQtlCzfyVHB1CBSENuJds=; b=JabYxMC8AWtAWYkmygjcqDKZ+7Al9z1tDM0wa/BNX1Oysxb8/+TdGe6te2gvptPUJu VCCV6xfPDvSBWCPb8xGHuf32Fvs9xCuO8MizptI90yB4SN1HYaEHrcdSAHkFHasG6jjU gjMHezmwOMhnoL786JzaNJwb3e5HPTm0hL76gtukSgqvODeYGkrhyJ8Wur8YQjAxv/mc 4y4XYnzhQYYep/65BLVYQu0z/3LAreX9LVyRsalyVUTGcTWJIr70kA74XMxFFRERzRyG MDSONotmzh/wRizhSX+gPYsAI6xS2o2JL15NrPDGjbG7enrefwtWrLVese+zdAF0NC/d 3RMg== Received: by 10.112.29.10 with SMTP id f10mr862099lbh.4.1355338055079; Wed, 12 Dec 2012 10:47:35 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id pg5sm9571833lab.6.2012.12.12.10.47.33 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 10:47:34 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so961078lbk.31 for ; Wed, 12 Dec 2012 10:47:33 -0800 (PST) Received: by 10.152.108.48 with SMTP id hh16mr2023515lab.25.1355338053752; Wed, 12 Dec 2012 10:47:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 12 Dec 2012 10:47:03 -0800 (PST) In-Reply-To: References: From: Nick Jennings Date: Wed, 12 Dec 2012 19:47:03 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlP4sDF+pjgLN7vyq+ylZvJCMkAcTu2s4w8dXNN4XGpny6KXgFWkUIRYo6sGf3jUaCEx/9o Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:47:39 -0000 Brad, I actually had a somewhat similar thought the other day (about specifying 'secure' links) and I agree it makes sense. I don't understand why there still has to be the "you must try HTTPS first" rule? It defeats the purpose of most cases where you'd want to use HTTP. -Nick On Wed, Dec 12, 2012 at 7:35 PM, Blaine Cook wrote: > Works for me. > > > On 12 December 2012 18:34, Breno wrote: >> >> Works for me. >> >> On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick" wrote: >>> >>> Thinking about the current HTTPS impasse, I thought of another avenue >>> which I don't recall having been discussed: >>> >>> What if we, >>> >>> * define some links as "secure links" (any link whose with a "rel" value >>> beginning with the substring "https:") >>> >>> * say WebFinger servers can run on HTTPS or HTTP (making the $5/month >>> hosting & RootCA hater camp happy), but noting that HTTPS is recommended and >>> then required if "secure links" need to be returned >>> >>> * say WebFinger clients MUST try to hit HTTPS first (either serially >>> first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is >>> unreachable, but NOT if bad cert). >>> >>> * (new) say WebFinger clients using plain HTTP MUST filter out any >>> "secure links" from the "links" list before giving it to their caller. >>> >>> >>> So a caller that wanted, say, "OpenID Connect" (a secure user of >>> WebFinger) could just write code like: >>> >>> wc = new WebFingerClient() >>> server = wc.LookupHref("foo@example.com", >>> "https://openid.net/connect/server") // Note "https:" prefix >>> // use server, if non-empty >>> >>> So rather than configuring the WebFingerClient with a requested fallback >>> policy, the policy is implicit in the rel requested. >>> >>> This still leaves the HTTPS-only camp arguing that "there will be so many >>> crappy WebFinger client implementations out there" (those not doing the >>> secure link filtering), but the counter-argument from earlier swayed me >>> sufficiently: they're easily auditable, and anybody writing security >>> software should audit their dependencies anyway. The "client" code is also >>> so simple in the grand scheme of things, this mailing list could go bust out >>> proper implementations in all popular languages and advertise them loudly. >>> >>> This is a bit of a compromise personally (it adds client complexity), but >>> I'm willing to give some of that up in exchange for WebFinger being used >>> more widely, for all sorts of applications. >>> >>> Thoughts? >>> > From bradfitz@google.com Wed Dec 12 10:53:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6244621F87A2 for ; Wed, 12 Dec 2012 10:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8WXLpiQXsSl for ; Wed, 12 Dec 2012 10:53:04 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2ECC21F871A for ; Wed, 12 Dec 2012 10:53:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so487305wey.31 for ; Wed, 12 Dec 2012 10:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ho/tKjVevsZGKxnR1z89GykTv2dhaS7bLwnCpmdzKOc=; b=Rim8gFO6QWvgwlMzWO3/kUXR1GRfYXcgeNa8m0BCzXh5ZDoA7gPJ37HDDLFEuxLJi3 usr4xLpePFz82EtUjlCwwYEuffzdd0cWQh0r9HRSbtPaSFG/KEEW26Q+vJwUqxpccFMH jdDcis4Bm3zRNW1IPkBw67hOZpdMFegJm8JezFSEZpVvd14ity3+I7MFhDTQzqJC9Aw9 t1eYSCAjCY6mBGn2J5uqJsVEokoTc65kRQNKMJcjtxGBfleSgoKg9YvCKx0Pyf+3qSRw ZEhh/b0c1Eurkm4TJbwS6lOoXWYlzSOzFTAb87ZAUo0bRA/6y6Hc1XfDC/4skA2b0kP4 83Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ho/tKjVevsZGKxnR1z89GykTv2dhaS7bLwnCpmdzKOc=; b=QeJRiC0ojXCAq+G6VGYb4X531nQipPVZbqgC2Kl85fp3YuMP0Vfcj8cDdXqoRYwvWV Cu0HV6gluYxNRYCRoQACePg4UD/COHarSs1sYcb8R/akRNKj0vX0XniZ0Qmhpzs23v5e ePeJRw2UkSDRy4vP2wehQq2JPI4w+LV/I5wWdoGJh/SuBfwdxnIZftnf2qmj8nDqTFnO PV7/V4Fwe3ItJYuFHj0pbY6vuV8gX6oAKDLJHe8sYU3tClCmRoCMphrAYGcmA0S5jplD WL/kNbA7orssZ4X4O//ogWgPJ774fKMN47sxSigh1oOiNXux7ukbDWYt7T6NNdBsxXJH ThZg== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr3729914wjz.19.1355338382307; Wed, 12 Dec 2012 10:53:02 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 12 Dec 2012 10:53:02 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 10:53:02 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=089e0102e102d3ef3004d0ac4e95 X-Gm-Message-State: ALoCoQkiIJG8OA/lQXGl3BK3U2DCRf/pTE4nBuAngUUESZOX/gT469WoU11R5Qya4vVsy+oG5NNT8jru4oeaN3JvTm/gkmdVhE0uAFAta4kMepCzsySn/2KV9lMy1MPQmXrXEU/LewtVDh0h6cQBn/3suaY4LcUpwmaMYT5AXpJl5lzAwIaGzq9t7xeSsVajsA6CmORKvsqM Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:53:07 -0000 --089e0102e102d3ef3004d0ac4e95 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 12, 2012 at 10:47 AM, Nick Jennings wrote: > Brad, > I actually had a somewhat similar thought the other day (about > specifying 'secure' links) and I agree it makes sense. I don't > understand why there still has to be the "you must try HTTPS first" > rule? It defeats the purpose of most cases where you'd want to use > HTTP. > The order doesn't matter so much. What matter is that the client MUST try both to find one that succeeds. It can't fail just after finding that just HTTP is down or just HTTPS is down. If you have two parties (server & client) and two options, you can't write specs that let both parties choose just one. If we're having two options (HTTP and HTTPS), we either need the server to MUST listen on both HTTP and HTTPS (which we've seen was undesirable), or we need to push the complexity to the client (unfortunate, but less offensive to many here). --089e0102e102d3ef3004d0ac4e95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 12, 2012 at 10:47 AM, Nick Jennings <nick@silverbucket.net<= /a>> wrote:
Brad,
I actually had a somewhat similar thought the other day (about
specifying 'secure' links) and I agree it makes sense. I don't<= br> understand why there still has to be the "you must try HTTPS first&quo= t;
rule? It defeats the purpose =C2=A0of most cases where you'd want to us= e
HTTP.

The order doesn't matter so m= uch. =C2=A0What matter is that the client MUST try both to find one that su= cceeds. =C2=A0It can't fail just after finding that just HTTP is down o= r just HTTPS is down.

If you have two parties (server & client) and two o= ptions, you can't write specs that let both parties choose just one. = =C2=A0If we're having two options (HTTP and HTTPS), we either need the = server to MUST listen on both HTTP and HTTPS (which we've seen was unde= sirable), or we need to push the complexity to the client (unfortunate, but= less offensive to many here).

--089e0102e102d3ef3004d0ac4e95-- From breno.demedeiros@gmail.com Wed Dec 12 10:34:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0201F0CCB for ; Wed, 12 Dec 2012 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVP1tf1cr4oa for ; Wed, 12 Dec 2012 10:34:26 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B01F0CC9 for ; Wed, 12 Dec 2012 10:34:25 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so247394ggn.31 for ; Wed, 12 Dec 2012 10:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yPrYP33SVwHC9ftucA5nbZI1pym4YRrN2/SAhedeTKQ=; b=WIuFLE4e5DyzlvtA06igLzwQSKng9XHoGswTW60AQjbte9+gwz0Kde7AHCFx3IthZD AUHUmBV5aynj/a99qu6JjzvopkuXjmKyn+GotcgjGksijB67n863XtNfThB2tJH6ztqj sHr1cbeP3kRwd+vHFQg03jbAUVDPvFYeojMno2etn+7HA4jqyR5MGbIloPQL772AR6uQ 5nO3gHeNUItuhzzxb4oIVSsvFVmxRCfpKY4wPFkivqXXfCOdjtcV8ejEa6a+f6HAmJXT w18aJIgeCAr2kVeYQwc+HAMGmPORSOQs5skEa3IMg7UQQVsFAf123aEecS8Kn+XO0t1W YZ8w== MIME-Version: 1.0 Received: by 10.58.48.231 with SMTP id p7mr1091016ven.11.1355337264642; Wed, 12 Dec 2012 10:34:24 -0800 (PST) Received: by 10.58.11.130 with HTTP; Wed, 12 Dec 2012 10:34:24 -0800 (PST) Received: by 10.58.11.130 with HTTP; Wed, 12 Dec 2012 10:34:24 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 10:34:24 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=089e01182b2635b9b204d0ac0ce5 X-Mailman-Approved-At: Wed, 12 Dec 2012 10:55:25 -0800 Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:34:27 -0000 --089e01182b2635b9b204d0ac0ce5 Content-Type: text/plain; charset=ISO-8859-1 Works for me. On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick" wrote: > Thinking about the current HTTPS impasse, I thought of another avenue > which I don't recall having been discussed: > > What if we, > > * define some links as "secure links" (any link whose with a "rel" value > beginning with the substring "https:") > > * say WebFinger servers can run on HTTPS or HTTP (making the $5/month > hosting & RootCA hater camp happy), but noting that HTTPS is recommended > and then required if "secure links" need to be returned > > * say WebFinger clients MUST try to hit HTTPS first (either serially first > or in parallel with HTTP), with a fallback to HTTP (if HTTPS is > unreachable, but NOT if bad cert). > > * (new) say WebFinger clients using plain HTTP MUST filter out any "secure > links" from the "links" list before giving it to their caller. > > > So a caller that wanted, say, "OpenID Connect" (a secure user of > WebFinger) could just write code like: > > wc = new WebFingerClient() > server = wc.LookupHref("foo@example.com", " > https://openid.net/connect/server") // Note "https:" prefix > // use server, if non-empty > > So rather than configuring the WebFingerClient with a requested fallback > policy, the policy is implicit in the rel requested. > > This still leaves the HTTPS-only camp arguing that "there will be so many > crappy WebFinger client implementations out there" (those not doing the > secure link filtering), but the counter-argument from earlier swayed me > sufficiently: they're easily auditable, and anybody writing security > software should audit their dependencies anyway. The "client" code is also > so simple in the grand scheme of things, this mailing list could go bust > out proper implementations in all popular languages and advertise them > loudly. > > This is a bit of a compromise personally (it adds client complexity), but > I'm willing to give some of that up in exchange for WebFinger being used > more widely, for all sorts of applications. > > Thoughts? > > --089e01182b2635b9b204d0ac0ce5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Works for me.

On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick&= quot; <bradfitz@google.com>= ; wrote:
Thinki= ng about the current HTTPS impasse, I thought of another avenue which I don= 't recall having been discussed:

What if we,

* define some links as "secure links" (any li= nk whose with a "rel" value beginning with the substring "ht= tps:")

* say WebFinger servers can run on HTT= PS or HTTP (making the $5/month hosting & RootCA hater camp happy), but= noting that HTTPS is recommended and then required if "secure links&q= uot; need to be returned

*=A0say=A0WebFinger clients MUST try to hit HTTPS first= (either serially first or in parallel with HTTP), with a fallback to HTTP = (if HTTPS is unreachable, but NOT if bad cert).

* = (new)=A0say=A0WebFinger clients using plain HTTP MUST filter out any "= secure links" from the "links" list before giving it to thei= r caller.


So a caller that wanted, say, "Open= ID Connect" (a secure user of WebFinger) could just write code like:
=A0 =A0 =A0wc =3D new WebFingerClient()
=A0 =A0 = =A0server =3D wc.LookupHref("foo@example.com", "https://openid.net/connect/server&quo= t;) =A0// Note "https:" prefix
=A0 =A0 =A0// use server, if non-empty

So rat= her than configuring the WebFingerClient with a requested fallback policy, = the policy is implicit in the rel requested.

This = still leaves the HTTPS-only camp arguing that "there will be so many c= rappy WebFinger client implementations out there" (those not doing the= secure link filtering), but the counter-argument from earlier swayed me su= fficiently: they're easily auditable, and anybody writing security soft= ware should audit their dependencies anyway. =A0The "client" code= is also so simple in the grand scheme of things, this mailing list could g= o bust out proper implementations in all popular languages and advertise th= em loudly.

This is a bit of a compromise personally (it adds clien= t complexity), but I'm willing to give some of that up in exchange for = WebFinger being used more widely, for all sorts of applications.

Thoughts?

--089e01182b2635b9b204d0ac0ce5-- From jpanzer@google.com Wed Dec 12 12:19:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B841F0CC7 for ; Wed, 12 Dec 2012 12:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xujLj+Gd76I for ; Wed, 12 Dec 2012 12:19:26 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80A0121F8826 for ; Wed, 12 Dec 2012 12:19:23 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1047666lbk.31 for ; Wed, 12 Dec 2012 12:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xEIRI1oJ8V4qL5rsHQrmqH8bX8jAiBuxtVgAZ+sCP44=; b=T3RPox+bBD8wmtVPIDEwDBX3iVXbrpybhkPK/A0EPF/yHC7uLXB2AflvfOHZXHg4rN NspBKFglVgr0XNjwyBH/iQZvjYtXZWq52XZ14HMrQ0EAaXP78pHWhGk8uZ1HzvsJE75C IYEjx65bSXCzJPnSVY30wQkIPv+GPXyBfpf0ZDubd9Vf8hQIHpO79j6u1RFxCOwyo8YY dSQ9KJr2ad590HQr9V+WVqWqoEnZVUAjwfncWvc4cjAaUsJRSuMqdz/W0tDEIMR2m93W gDaUP18L28PUroqivLoBPotVj57oodb/GI6NiGPqj83tVKNM9gQKFGP+ssAImDNIii6k vU4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xEIRI1oJ8V4qL5rsHQrmqH8bX8jAiBuxtVgAZ+sCP44=; b=g4rjk1FZ254wyraQbtszaCg5fxAm4bJ4RrpxuMO5oZN/VaILWVaj9QjC9SBqHpXhB3 xXXTsPD0EfKL8ge11dN+uCT+2fmkMTXh3zCwnvMdDw/kQPAo/9Up/qY/prFQ2OpCiTcR 0e+t+Il6FEbnTwKLO22dy2QFekAVr6pkRL26yxpYUYIC0oEgommitdDjNrX15YDs7K6p lh9w1DDA2gKSDIcOyPXo4ileLGIp7v7dFoCrCxP9qdW/3JUsab1Rrx/msxSrf8KRz8J2 RUYYJ6/sa5hvMtPfWjvK8z7LiyaZiF7a9t0GCvG5/Ts5iIlJ1UEZZdc9/otSu4h8eBXY Zisw== Received: by 10.152.111.41 with SMTP id if9mr2277699lab.23.1355343562544; Wed, 12 Dec 2012 12:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.5.3 with HTTP; Wed, 12 Dec 2012 12:19:01 -0800 (PST) In-Reply-To: References: From: John Panzer Date: Wed, 12 Dec 2012 12:19:01 -0800 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d040715299815d404d0ad832f X-Gm-Message-State: ALoCoQlp3mwXe6IBng/29IVXppjCVcp/ICL/4++t02Z4eVEfBzWzTB3iG24HhsCca1FBw+1i68TTezTP2cdFQNh1ZYGQd/RQA/GKDoOzhWNaWQ3XOFlnMgXaA4SvvcgjH0EuRF8nskOIeowditifowvIpUVbtYJRQ7epi9Nf49qaFX1FV+HtWB9ZTF/Sn0XA78z0g7hic0ig Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:19:28 -0000 --f46d040715299815d404d0ad832f Content-Type: text/plain; charset=ISO-8859-1 Does this handle property data too? (I think so.) On first reading I thought you were saying that the value of the target starting with https:// would trigger this, so I was confused. Then I re-read and realized you were saying that rel="https://foo" is secure but rel="http://foo" is not, which makes sense. How would a non-http rel value be treated? (E.g., rel="canonical"). On Wed, Dec 12, 2012 at 9:44 AM, Brad Fitzpatrick wrote: > Thinking about the current HTTPS impasse, I thought of another avenue > which I don't recall having been discussed: > > What if we, > > * define some links as "secure links" (any link whose with a "rel" value > beginning with the substring "https:") > > * say WebFinger servers can run on HTTPS or HTTP (making the $5/month > hosting & RootCA hater camp happy), but noting that HTTPS is recommended > and then required if "secure links" need to be returned > > * say WebFinger clients MUST try to hit HTTPS first (either serially first > or in parallel with HTTP), with a fallback to HTTP (if HTTPS is > unreachable, but NOT if bad cert). > > * (new) say WebFinger clients using plain HTTP MUST filter out any "secure > links" from the "links" list before giving it to their caller. > > > So a caller that wanted, say, "OpenID Connect" (a secure user of > WebFinger) could just write code like: > > wc = new WebFingerClient() > server = wc.LookupHref("foo@example.com", " > https://openid.net/connect/server") // Note "https:" prefix > // use server, if non-empty > > So rather than configuring the WebFingerClient with a requested fallback > policy, the policy is implicit in the rel requested. > > This still leaves the HTTPS-only camp arguing that "there will be so many > crappy WebFinger client implementations out there" (those not doing the > secure link filtering), but the counter-argument from earlier swayed me > sufficiently: they're easily auditable, and anybody writing security > software should audit their dependencies anyway. The "client" code is also > so simple in the grand scheme of things, this mailing list could go bust > out proper implementations in all popular languages and advertise them > loudly. > > This is a bit of a compromise personally (it adds client complexity), but > I'm willing to give some of that up in exchange for WebFinger being used > more widely, for all sorts of applications. > > Thoughts? > > --f46d040715299815d404d0ad832f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does t= his handle property data too? =A0(I think so.)

On first = reading I thought you were saying that the value of the target starting wit= h https:// would trigger this, so I was confused. =A0Then I re-read and rea= lized you were saying that rel=3D"https://foo<= /a>" is secure but rel=3D"http://foo&q= uot; is not, which makes sense.

How would a non-http rel value be treated? =A0(E.g., re= l=3D"canonical").


On Wed, Dec 12, 2012 at 9:44 AM, Brad Fitzpatrick <bradf= itz@google.com> wrote:
Thinking about the current HTTPS impasse, I though= t of another avenue which I don't recall having been discussed:

What if we,

* define some links as "secure links" (any li= nk whose with a "rel" value beginning with the substring "ht= tps:")

* say WebFinger servers can run on HTT= PS or HTTP (making the $5/month hosting & RootCA hater camp happy), but= noting that HTTPS is recommended and then required if "secure links&q= uot; need to be returned

*=A0say=A0WebFinger clients MUST try to hit HTTPS first= (either serially first or in parallel with HTTP), with a fallback to HTTP = (if HTTPS is unreachable, but NOT if bad cert).

* = (new)=A0say=A0WebFinger clients using plain HTTP MUST filter out any "= secure links" from the "links" list before giving it to thei= r caller.


So a caller that wanted, say, "Open= ID Connect" (a secure user of WebFinger) could just write code like:
=A0 =A0 =A0wc =3D new WebFingerClient()
=A0 =A0 = =A0server =3D wc.LookupHref("foo@example.com", "https://openid.net/connect/server&quo= t;) =A0// Note "https:" prefix
=A0 =A0 =A0// use server, if non-empty

So rat= her than configuring the WebFingerClient with a requested fallback policy, = the policy is implicit in the rel requested.

This = still leaves the HTTPS-only camp arguing that "there will be so many c= rappy WebFinger client implementations out there" (those not doing the= secure link filtering), but the counter-argument from earlier swayed me su= fficiently: they're easily auditable, and anybody writing security soft= ware should audit their dependencies anyway. =A0The "client" code= is also so simple in the grand scheme of things, this mailing list could g= o bust out proper implementations in all popular languages and advertise th= em loudly.

This is a bit of a compromise personally (it adds clien= t complexity), but I'm willing to give some of that up in exchange for = WebFinger being used more widely, for all sorts of applications.

Thoughts?


--f46d040715299815d404d0ad832f-- From nick@silverbucket.net Wed Dec 12 12:25:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD11F0CDF for ; Wed, 12 Dec 2012 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZqq+8YNmv5s for ; Wed, 12 Dec 2012 12:25:36 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01DC61F0CC1 for ; Wed, 12 Dec 2012 12:25:29 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1053580lbk.31 for ; Wed, 12 Dec 2012 12:25:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AUDlQc7DS66pMWPUx0kYS+pZ+1BKH1fTUX3tLIH0j3M=; b=En8cYYneH59kNRGp3AQr85bD6and2Esb024pudX6sRvaal0dbLk5lU2PG66IZJNTmj onDUh6+4GJxlEhzXfIIeSA9ctEz2GpToricThhuROEzVXztNaZtI9eLFOKe7+oRYvFny 0m0ZNVUgv66HMZD/3/Jub9qwk6XPxNrRyN3qVWgrro9soy1aCIeJMohiO94qncVs2DHq kaUUng9/vtcyGOIhp3o0T9buSRnVA6028sIazJ00TJjEYL7aUutNyIFh7/ugMVmGkvpX d1QDPWRPZIOXwR67PGv/f1BqbKpVNy1C7DKZlYNV6VhyxqfDENe0r7VVJsNHNqe84NnA 6qHg== Received: by 10.152.144.38 with SMTP id sj6mr2288276lab.48.1355343921678; Wed, 12 Dec 2012 12:25:21 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id ml1sm8042260lab.15.2012.12.12.12.25.20 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 12:25:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1053564lbk.31 for ; Wed, 12 Dec 2012 12:25:20 -0800 (PST) Received: by 10.112.87.194 with SMTP id ba2mr1003328lbb.84.1355343920487; Wed, 12 Dec 2012 12:25:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Wed, 12 Dec 2012 12:24:49 -0800 (PST) In-Reply-To: References: From: Nick Jennings Date: Wed, 12 Dec 2012 21:24:49 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkaRmT8lbUNvFqExDiWl+oSQGFi9+8i0T6fG1AET8ArrIuhKPll3BeAja/ur6+nJCDWRHZg Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:25:42 -0000 On Wed, Dec 12, 2012 at 7:53 PM, Brad Fitzpatrick wrote: > On Wed, Dec 12, 2012 at 10:47 AM, Nick Jennings > wrote: >> >> Brad, >> I actually had a somewhat similar thought the other day (about >> specifying 'secure' links) and I agree it makes sense. I don't >> understand why there still has to be the "you must try HTTPS first" >> rule? It defeats the purpose of most cases where you'd want to use >> HTTP. > > > The order doesn't matter so much. What matter is that the client MUST try > both to find one that succeeds. It can't fail just after finding that just > HTTP is down or just HTTPS is down. > > If you have two parties (server & client) and two options, you can't write > specs that let both parties choose just one. If we're having two options > (HTTP and HTTPS), we either need the server to MUST listen on both HTTP and > HTTPS (which we've seen was undesirable), or we need to push the complexity > to the client (unfortunate, but less offensive to many here). > If the order doesn't matter so much, then I'm OK with it. Another thought about specifying secure links. What about the idea of filtering this data on the server when it's responding to the request? ie. if the request is coming in over HTTP, filter out the 'secure' links. -Nick From bradfitz@google.com Wed Dec 12 12:29:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E6E21F86CA for ; Wed, 12 Dec 2012 12:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLwfIZrvEyRh for ; Wed, 12 Dec 2012 12:29:37 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD54221F88DE for ; Wed, 12 Dec 2012 12:29:28 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so537823wey.31 for ; Wed, 12 Dec 2012 12:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MMhEa0ToX7UvneELYLS24dhF6+pxL3IAIFrNaa/300w=; b=c3PaMu2IJ1CBY5r6GryJeIRYmLCQ9VIbVf4BjADeXRKJfzRXXUthadu/0atDs3vLcr n8/7ZYnXPPoaGn+hseRb1nDQytSNUnR7369PJhDRrrFldqvKhi9Y2NIpXdb4YkRU88Yy b7j/HeWJZzkw97ZplP8TFBmBVXZrzw0B70FxS195wzvH36t+IExmU/p9eFLtshz7OoqZ qXxvNtYnVkEm4zNL4CMHIRSz+dSUNuyvNt6tPBaxm3UXD02U0SC8lvN4XwnpciMnT4We kVUhl3m20C+8TdILeK2s4MEVBMXqvluzWFCWo760iWXdWJde0GQkmAuhqZcvnC+6zT8S ukBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MMhEa0ToX7UvneELYLS24dhF6+pxL3IAIFrNaa/300w=; b=Q1Gu/Rlb6Pt4oae+dUL2beRQn9QyA+kavWkctr+Rk/nfJqr6iY/L2vwsHH/JbRmbTZ JJ7pMqpcy+osvDPr/qYt94OEKzM2o+FWWMLq6YtGWfLMh2DRKZKa3bHfm5kmlCCVoQYH UCcKJMn+c667mcTNi7nucNDoHiHZ/RtVMuWg2ge18tY0qoXkhyXLEw3f39qCkpu54HaH YFwlvZpwJxni1Zsmx0Wo6ddnCJVqB4u5X/OC56VEFI5OEsVcBJ4TeOiy34NRE66QlP68 yULpUTDE5nHcBvd8vkgGBWjMdXAqfoDY/Qgf21jFaonUpfgjBEldcqIIw393CNYP7bI+ C00A== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr4153456wjb.10.1355344165657; Wed, 12 Dec 2012 12:29:25 -0800 (PST) Received: by 10.194.166.100 with HTTP; Wed, 12 Dec 2012 12:29:25 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 12:29:25 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=047d7bf10b2c8ada3704d0ada726 X-Gm-Message-State: ALoCoQlkyAtKhAsN4KaN/URMRavqzbAcdFMcQx6CKxeWZTbSuMVhXMbN0zYNtoV6ffbLmX5s2iLiJz2slQOPcQwYZF7at6+BQY/fK9sA2JIHZKKb3sYyDKQHjhDD23Q8EODehiiLo1ZYnE6r+1eTDFZOuD90oQaKAgucEkFaqcnDpZ0Ch4hbqL8S8HNB9hgJZu7rCCboI0gN Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:29:38 -0000 --047d7bf10b2c8ada3704d0ada726 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 12, 2012 at 12:24 PM, Nick Jennings wrote: > On Wed, Dec 12, 2012 at 7:53 PM, Brad Fitzpatrick > wrote: > > On Wed, Dec 12, 2012 at 10:47 AM, Nick Jennings > > wrote: > >> > >> Brad, > >> I actually had a somewhat similar thought the other day (about > >> specifying 'secure' links) and I agree it makes sense. I don't > >> understand why there still has to be the "you must try HTTPS first" > >> rule? It defeats the purpose of most cases where you'd want to use > >> HTTP. > > > > > > The order doesn't matter so much. What matter is that the client MUST > try > > both to find one that succeeds. It can't fail just after finding that > just > > HTTP is down or just HTTPS is down. > > > > If you have two parties (server & client) and two options, you can't > write > > specs that let both parties choose just one. If we're having two options > > (HTTP and HTTPS), we either need the server to MUST listen on both HTTP > and > > HTTPS (which we've seen was undesirable), or we need to push the > complexity > > to the client (unfortunate, but less offensive to many here). > > > > If the order doesn't matter so much, then I'm OK with it. > > Another thought about specifying secure links. What about the idea of > filtering this data on the server when it's responding to the request? > ie. if the request is coming in over HTTP, filter out the 'secure' > links. > That can be a SHOULD if people really want. It's unnecessary, adds complexity (more words in spec, more things for server authors to do), and doesn't solve the downgrade attack problem. Only a client MUST can fix that. But outside of extra words & effort, it doesn't hurt to also filter out secure links on the server. --047d7bf10b2c8ada3704d0ada726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 12, 2012 at 12:24 PM, Nick Jennings <nick@silverbucket.net<= /a>> wrote:
On Wed, Dec 12, 2012 at 7:53 PM, Brad Fitzpatrick &l= t;bradfitz@google.com> wrote:=
> On Wed, Dec 12, 2012 at 10:47 AM, Nick Jennings <nick@silverbucket.net>
> wrote:
>>
>> Brad,
>> I actually had a somewhat similar thought the other day (about
>> specifying 'secure' links) and I agree it makes sense. I d= on't
>> understand why there still has to be the "you must try HTTPS = first"
>> rule? It defeats the purpose =C2=A0of most cases where you'd w= ant to use
>> HTTP.
>
>
> The order doesn't matter so much. =C2=A0What matter is that the cl= ient MUST try
> both to find one that succeeds. =C2=A0It can't fail just after fin= ding that just
> HTTP is down or just HTTPS is down.
>
> If you have two parties (server & client) and two options, you can= 't write
> specs that let both parties choose just one. =C2=A0If we're having= two options
> (HTTP and HTTPS), we either need the server to MUST listen on both HTT= P and
> HTTPS (which we've seen was undesirable), or we need to push the c= omplexity
> to the client (unfortunate, but less offensive to many here).
>

If the order doesn't matter so much, then I'm OK with i= t.

Another thought about specifying secure links. What about the idea of
filtering this data on the server when it's responding to the request?<= br> ie. if the request is coming in over HTTP, filter out the 'secure'<= br> links.

That can be a SHOULD if people r= eally want. =C2=A0It's unnecessary, adds complexity (more words in spec= , more things for server authors to do), and doesn't solve the downgrad= e attack problem. =C2=A0Only a client MUST can fix that.

But outside of extra words & effort, it doesn't= hurt to also filter out secure links on the server.
--047d7bf10b2c8ada3704d0ada726-- From paulej@packetizer.com Wed Dec 12 23:23:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE17221F86C7 for ; Wed, 12 Dec 2012 23:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q5l0R6HdCgR for ; Wed, 12 Dec 2012 23:23:05 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 03BC121F8AD4 for ; Wed, 12 Dec 2012 23:23:04 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBD7N3Mx003322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 02:23:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355383383; bh=gUR9BnEeZf53QfK/6IBvoc+UXf5BDAASNqsS6hLKySw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=iajHUvben5nq5eIVFJY2fkWz6Igo0Ys0na9cPusCtn/72ycorUfs9wfI5zcsZP6Wt IO2oqCYBqrSwLOo0mLvT1tpFrrmsYUOMJ1NE+3lTWrBoxAdVikLJNLc29/qn8ghTNH qEIuOOFH/sYoIrUNrujiIdZmbV1VVALIK7Yvg++c= From: "Paul E. Jones" To: , References: In-Reply-To: Date: Thu, 13 Dec 2012 02:23:13 -0500 Message-ID: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04A6_01CDD8D8.CDF82660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rJkOpW9g Content-Language: en-us Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:23:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04A6_01CDD8D8.CDF82660 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But what if I=E2=80=99m not looking for a specific link, but just want = all of the links related to foo@example.com? I might be building a = =E2=80=9Cprofile=E2=80=9D type page or I might accept a number of = different pieces of data (vcard, hcard, xcard, portable contact, avatar, = =E2=80=9Cpreferred name=E2=80=9D, etc.). Then what? =20 =20 From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Brad Fitzpatrick Sent: Wednesday, December 12, 2012 12:44 PM To: webfinger@ietf.org; webfinger@googlegroups.com Subject: secure links with https rels =20 Thinking about the current HTTPS impasse, I thought of another avenue = which I don't recall having been discussed: =20 What if we, =20 * define some links as "secure links" (any link whose with a "rel" value = beginning with the substring "https:") =20 * say WebFinger servers can run on HTTPS or HTTP (making the $5/month = hosting & RootCA hater camp happy), but noting that HTTPS is recommended = and then required if "secure links" need to be returned =20 * say WebFinger clients MUST try to hit HTTPS first (either serially = first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is = unreachable, but NOT if bad cert). =20 * (new) say WebFinger clients using plain HTTP MUST filter out any = "secure links" from the "links" list before giving it to their caller. =20 =20 So a caller that wanted, say, "OpenID Connect" (a secure user of = WebFinger) could just write code like: wc =3D new WebFingerClient() server =3D wc.LookupHref("foo@example.com", = "https://openid.net/connect/server") // Note "https:" prefix // use server, if non-empty =20 So rather than configuring the WebFingerClient with a requested fallback = policy, the policy is implicit in the rel requested. =20 This still leaves the HTTPS-only camp arguing that "there will be so = many crappy WebFinger client implementations out there" (those not doing = the secure link filtering), but the counter-argument from earlier swayed = me sufficiently: they're easily auditable, and anybody writing security = software should audit their dependencies anyway. The "client" code is = also so simple in the grand scheme of things, this mailing list could go = bust out proper implementations in all popular languages and advertise = them loudly. =20 This is a bit of a compromise personally (it adds client complexity), = but I'm willing to give some of that up in exchange for WebFinger being = used more widely, for all sorts of applications. =20 Thoughts? =20 ------=_NextPart_000_04A6_01CDD8D8.CDF82660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

But what if I=E2=80=99m not looking for a specific link, but just = want all of the links related to foo@example.com?=C2=A0 I might be = building a =E2=80=9Cprofile=E2=80=9D type page or I might accept a = number of different pieces of data (vcard, hcard, xcard, portable = contact, avatar, =E2=80=9Cpreferred name=E2=80=9D, etc.).=C2=A0 Then = what?

 

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Brad Fitzpatrick
Sent: Wednesday, December 12, = 2012 12:44 PM
To: webfinger@ietf.org; = webfinger@googlegroups.com
Subject: secure links with https = rels

 

Thinking = about the current HTTPS impasse, I thought of another avenue which I = don't recall having been discussed:

 

What if = we,

 

* define = some links as "secure links" (any link whose with a = "rel" value beginning with the substring = "https:")

 

* say = WebFinger servers can run on HTTPS or HTTP (making the $5/month hosting = & RootCA hater camp happy), but noting that HTTPS is recommended and = then required if "secure links" need to be = returned

 

* say&nb= sp;WebFinger clients MUST try to hit HTTPS first (either serially first = or in parallel with HTTP), with a fallback to HTTP (if HTTPS is = unreachable, but NOT if bad cert).

 

* = (new) say WebFinger clients using plain HTTP MUST filter out = any "secure links" from the "links" list before = giving it to their caller.

 

 

So a caller = that wanted, say, "OpenID Connect" (a secure user of = WebFinger) could just write code = like:

  =    wc =3D new = WebFingerClient()

  =    server =3D wc.LookupHref("foo@example.com", "https://openid.net/connect/ser= ver")  // Note "https:" = prefix

  =    // use server, if = non-empty

 

So rather = than configuring the WebFingerClient with a requested fallback policy, = the policy is implicit in the rel = requested.

 

This still = leaves the HTTPS-only camp arguing that "there will be so many = crappy WebFinger client implementations out there" (those not doing = the secure link filtering), but the counter-argument from earlier swayed = me sufficiently: they're easily auditable, and anybody writing security = software should audit their dependencies anyway.  The = "client" code is also so simple in the grand scheme of things, = this mailing list could go bust out proper implementations in all = popular languages and advertise them = loudly.

 

This is a = bit of a compromise personally (it adds client complexity), but I'm = willing to give some of that up in exchange for WebFinger being used = more widely, for all sorts of = applications.

 

Thoughts?

 

------=_NextPart_000_04A6_01CDD8D8.CDF82660-- From paulej@packetizer.com Wed Dec 12 23:45:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8727521F87EC for ; Wed, 12 Dec 2012 23:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WeTRhe9gZJQ for ; Wed, 12 Dec 2012 23:45:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD1821F864D for ; Wed, 12 Dec 2012 23:45:36 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBD7jYZr004328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 02:45:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355384735; bh=vBShR5frBdWEQ3cZR8Gi+1kiF7BDCiUSCngJmVWJp+0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XoNjm4fIJERp9TId4ITNLdqoegwPc8RoYS6kZwhdfcKh5W3QUdbzqTXQuGzpCMhfO I/l0DrTa2D2Vf/EsSDnM1KO2TCfIX+DwGUGpvAoJUOsH/5dkHkEo1ftIAvEFfo6O7z cQEPDjnWmlrs89SVXyBXzyuKG3LBXdG257D0aaP8= From: "Paul E. Jones" To: "'James M Snell'" , References: In-Reply-To: Date: Thu, 13 Dec 2012 02:45:45 -0500 Message-ID: <04c101cdd905$dc3c0fc0$94b42f40$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C2_01CDD8DB.F367B570" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL/HfTlrGHDEpu9rSeHRgHsj0+TuQK3HDA9lZ4R1IA= Content-Language: en-us Subject: Re: [webfinger] Fwd: Outstanding WF Security Concerns X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:45:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04C2_01CDD8DB.F367B570 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, =20 1. =E2=80=9CPotential Mixed-session hijack vulnerability=E2=80=9D = =E2=80=93 WebFinger does not define a =E2=80=9Csession=E2=80=9D. The = client requests a document and get a reply. That=E2=80=99s it. We must = allow non-HTTPS URIs in the document, because lots of people store lots = of things in places that do not need to be secure. Security = requirements related to these other resources is really outside the = scope of WF. WF just tells a client where the information can be found. =20 2. =E2=80=9C3xx Redirects to insecure targets=E2=80=9D - I think the = language in the new proposal will address this. =20 3. This can occur with any protocol and there=E2=80=99s not a thing we = can do. A query might go to the right server and even the server itself = is compromised and serving up bogus information. The best we can do is = recommend HTTPS and even then there are no guarantees. We could = disallow redirects, but that seems harsh. I would personally like to = use a redirect from HTTP to HTTPS, just as a means of forcing queries to = use HTTPS.=20 =20 4. What is an =E2=80=9Can unauthorized WebFinger request=E2=80=9D? If a = query is sent to a server for resource/subject for which the server = knows nothing about, it returns a 404. If a client is truly not = authorized, as in a client must provide credentials to even query the WF = server, then a 401 (or 403) would be sent. This would be standard HTTP = behavior, not WF-specific behavior. Is that what you=E2=80=99re getting = at? =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of James M Snell Sent: Wednesday, December 12, 2012 1:04 PM To: webfinger@ietf.org Subject: [webfinger] Fwd: Outstanding WF Security Concerns =20 I had sent this before but I believe it went out before many people had = moved over to the new list. Item #1 has already been discussed but still = needs to be addressed in the draft. The other issues, as far as I can = tell, have not yet been dealt with. ---------- Forwarded message ---------- From: James M Snell Date: Tue, Dec 4, 2012 at 1:48 PM Subject: Outstanding WF Security Concerns To: webfinger@ietf.org In the current draft -07 spec there are a handful of fairly important = security issues that have yet to be dealt with. I summarized these in a = separate note to Paul and the other authors while waiting for this new = list to be set up and wanted to call them out here for discussion as = well.=20 =20 1. Potential Mixed-session hijack vulnerability =20 When accessing an authenticated WebFinger service via HTTPS, there is a potential session-hijacking vulnerability if the=20 returned JRD contains non-HTTPS URLs to the same domain as=20 the WebFinger server and session cookies are not properly=20 secured. As a best practice, if the JRD is served over a=20 HTTPS connection, any links to the same domain contained=20 within the JRD SHOULD also use HTTPS and server implementations need to make sure that all session cookies are properly=20 secured against hijacking. (This issue is no different than=20 your typical mixed-session vulnerability) =20 2. 3xx Redirects to insecure targets =20 WebFinger explicitly allows a WebFinger server to redirect=20 requests to a separate third party service provider. It=20 does not, however, require the use of HTTPS with the redirected target.=20 =20 For example, imagine sending a GET request to: =20 https://example.org/.well-known/webfinger?r... =20 And getting back... =20 HTTP/1.1 302 Found Location: http://example.net/wf?r=3D... =20 The redirected request will no longer be protected, negating=20 the point of using HTTPS in the first request and putting the client at risk.=20 =20 Redirects returned by the server for requests issued over HTTPS ought to be required to point to HTTPS secured URLs... e.g. =20 HTTP/1.1 302 Found Location: https://example.net/wf?r=3D... =20 3. Also with regards to third party redirects, how is the client=20 able to determine that the redirection was appropriately=20 authorized by the original WF provider? If the server (or=20 vulnerable intermediary) has been compromised, a client can be=20 tricked into redirecting to a malicious server providing false=20 information. If, for instance, a fake Identity Provider URL is=20 provided, the client may not be capable of detecting the intrusion.=20 Use of HTTPS will not prevent such attacks. One reliable=20 solution is to require the use of cryptographic integrity checks on=20 the JRD resource. That is, if Server A redirects to Server B, then=20 the JRD provided by Server B needs to be signed by a key trusted by=20 both Server A and the client. However it is done, the client needs to be able to determine that Server B is authorized by Server A to provide WebFinger data on it's behalf... a redirect served over HTTPS does not, by itself, provide sufficient assurance. =20 4. When a client sends an unauthorized WebFinger request for a=20 resource, a 404 Not Found response needs to be returned to make such responses indistinguishable from requests for resources the service has no information about. =20 - James =20 ------=_NextPart_000_04C2_01CDD8DB.F367B570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James,

 

1. =E2=80=9CPotential Mixed-session hijack vulnerability=E2=80=9D = =E2=80=93 WebFinger does not define a =E2=80=9Csession=E2=80=9D.=C2=A0 = The client requests a document and get a reply.=C2=A0 That=E2=80=99s it. = We must allow non-HTTPS URIs in the document, because lots of people = store lots of things in places that do not need to be secure. = =C2=A0Security requirements related to these other resources is really = outside the scope of WF.=C2=A0 WF just tells a client where the = information can be found.

 

2. =E2=80=9C3xx Redirects to insecure targets=E2=80=9D - =C2=A0I = think the language in the new proposal will address = this.

 

3. This can occur with any protocol and there=E2=80=99s not a thing = we can do.=C2=A0 A query might go to the right server and even the = server itself is compromised and serving up bogus information.=C2=A0 The = best we can do is recommend HTTPS and even then there are no = guarantees.=C2=A0 We could disallow redirects, but that seems = harsh.=C2=A0 I would personally like to use a redirect from HTTP to = HTTPS, just as a means of forcing queries to use HTTPS. =

 

4. What is an =E2=80=9Can unauthorized WebFinger = request=E2=80=9D?=C2=A0 If a query is sent to a server for = resource/subject for which the server knows nothing about, it returns a = 404.=C2=A0 If a client is truly not authorized, as in a client must = provide credentials to even query the WF server, then a 401 (or 403) = would be sent.=C2=A0 This would be standard HTTP behavior, not = WF-specific behavior.=C2=A0 Is that what you=E2=80=99re getting = at?

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of James M Snell
Sent: Wednesday, December 12, 2012 = 1:04 PM
To: webfinger@ietf.org
Subject: [webfinger] = Fwd: Outstanding WF Security = Concerns

 

I had sent this before but I believe it went out before many = people had moved over to the new list. Item #1 has already been = discussed but still needs to be addressed in the draft. The other = issues, as far as I can tell, have not yet been dealt = with.

---------- = Forwarded message ----------
From: James M Snell <jasnell@gmail.com>
Date: = Tue, Dec 4, 2012 at 1:48 PM
Subject: Outstanding WF Security = Concerns
To: webfinger@ietf.org


In the current draft -07 spec = there are a handful of fairly important security issues that have yet to = be dealt with. I summarized these in a separate note to Paul and the = other authors while waiting for this new list to be set up and wanted to = call them out here for discussion as = well. 

 

1. Potential = Mixed-session hijack vulnerability

 

  =  When accessing an authenticated WebFinger service via = HTTPS,

   there is a potential = session-hijacking vulnerability if = the 

   returned JRD contains = non-HTTPS URLs to the same domain = as 

   the WebFinger server = and session cookies are not = properly 

  =  secured. As a best practice, if the JRD is served over = a 

   HTTPS connection, any = links to the same domain = contained 

  =  within the JRD SHOULD also use HTTPS and server = implementations

  =  need to make sure that all session cookies are = properly 

  =  secured against hijacking. (This issue is no different = than 

   your typical = mixed-session vulnerability)

 

2. 3xx = Redirects to insecure targets

 

  =  WebFinger explicitly allows a WebFinger server to = redirect 

  =  requests to a separate third party service provider. = It 

   does not, however, = require the use of HTTPS with the = redirected

  =  target. 

 

  =  For example, imagine sending a GET request = to:

 

 

  =  And getting back...

 

  =    HTTP/1.1 302 Found

  =    Location: http://example.net/wf?r=3D...

=

 

  =  The redirected request will no longer be protected, = negating 

  =  the point of using HTTPS in the first request and putting = the

   client at = risk. 

 

  =  Redirects returned by the server for requests issued over = HTTPS

   ought to be required to = point to HTTPS secured URLs... e.g.

 

  =    HTTP/1.1 302 Found

  =    Location: https://example.net/wf?r=3D...

 

3. Also with = regards to third party redirects, how is the = client 

   able = to determine that the redirection was = appropriately 

   authorized by the original WF provider? If the server = (or 

  =  vulnerable intermediary) has been compromised, a client can = be 

  =  tricked into redirecting to a malicious server providing = false 

  =  information. If, for instance, a fake Identity Provider URL = is 

  =  provided, the client may not be capable of detecting the = intrusion. 

   Use of HTTPS will not prevent such attacks. One = reliable 

   solution is to require the use of cryptographic = integrity checks on 

   the JRD resource. That is, if Server A redirects to = Server B, then 

   the JRD provided by Server B needs to be signed by a = key trusted by 

   both Server A and the client. However it is done, the = client needs

   to be = able to determine that Server B is authorized by Server = A

   to = provide WebFinger data on it's behalf... a redirect served = over

   HTTPS = does not, by itself, provide sufficient = assurance.

 

4. When a client sends an unauthorized WebFinger request for = a 

  =  resource, a 404 Not Found response needs to be returned to = make

   such = responses indistinguishable from requests for resources = the

  =  service has no information = about.

 

- James

 

------=_NextPart_000_04C2_01CDD8DB.F367B570-- From Axel.Nennker@telekom.de Thu Dec 13 02:26:12 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37A221F89AF for ; Thu, 13 Dec 2012 02:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHnAX9MZAMth for ; Thu, 13 Dec 2012 02:26:11 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9121F894D for ; Thu, 13 Dec 2012 02:26:11 -0800 (PST) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 13 Dec 2012 11:25:09 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Thu, 13 Dec 2012 11:25:09 +0100 From: To: Date: Thu, 13 Dec 2012 11:25:08 +0100 Thread-Topic: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP Thread-Index: Ac3ZHBWCupvBGHvNT3yr88cD3fpSpg== Message-ID: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:26:12 -0000 +1 HTTPS only Axel From lef.mutualauth@gmail.com Thu Dec 13 06:34:44 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2483D21F8AF9 for ; Thu, 13 Dec 2012 06:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2+0Cf+Oymq4 for ; Thu, 13 Dec 2012 06:34:43 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA321F8AF8 for ; Thu, 13 Dec 2012 06:34:43 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1081232bku.31 for ; Thu, 13 Dec 2012 06:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=DgAEyzlxQxX8WpF598m9RS0m0s+zk0wRzeQTFjFZAdQ=; b=XM8qoR/b4An7QMrnJDaN2vfQRS7QupO5XsU80TszepULmrtu/Alc/icFjWWCGKMQVH DsNTh+ICdg+FiClMgLyhMLUsNZFIv1l2kqHBP8cDFnEHk5hO8HuKNlIcu1YFxIyJkUnC TLg11CzEVhwNPaeSdGbL4dIquM+tkE/td7tQwfr8C0Q3XM9fco9E8voU5sKDyiSK1U4b w6u1yljJdNkrRUhC1TYUGFNw5E02jHiewaqVUJrDlbTiZHQHzNwtD+KpacL6h4Jo0A63 Upf5q54FWKjgRpRW7xwp6J+0DBZ6cKV7Zyw0++0JAzrPQtqZXOrT3qZvd1QIG0Ts0XlU 0s/A== Received: by 10.204.149.86 with SMTP id s22mr1144452bkv.57.1355409282340; Thu, 13 Dec 2012 06:34:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.37.205 with HTTP; Thu, 13 Dec 2012 06:34:22 -0800 (PST) From: "HAYASHI, Tatsuya" Date: Thu, 13 Dec 2012 23:34:22 +0900 Message-ID: To: webfinger@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:34:44 -0000 +1 HTTPS only -- HAYASHI, Tatsuya Lepidum Co. Ltd. From cyrus@daboo.name Thu Dec 13 06:58:19 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A309321F8B11 for ; Thu, 13 Dec 2012 06:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwEtFCPmvYdZ for ; Thu, 13 Dec 2012 06:58:18 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id A0FAC21F8B0F for ; Thu, 13 Dec 2012 06:58:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1DACA37E0E12; Thu, 13 Dec 2012 09:58:18 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAm952Xd8utQ; Thu, 13 Dec 2012 09:58:17 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 2CF1B37E0E03; Thu, 13 Dec 2012 09:58:15 -0500 (EST) Date: Thu, 13 Dec 2012 09:58:12 -0500 From: Cyrus Daboo To: "Paul E. Jones" , 'Salvatore Loreto' , webfinger@ietf.org Message-ID: <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> In-Reply-To: <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2348 Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:58:19 -0000 Hi Paul, --On December 12, 2012 12:02:59 PM -0500 "Paul E. Jones" wrote: >> I don't see how you can enforce this. Often times certificate checking >> is done at a layer below the application code - a user may have >> previously "accepted" an invalid certificate for a particular domain and >> in that case subsequent application layer HTTPS connections can succeed >> without any kind of "invalid certificate" notification. > > That might be true if the transport layer below the WF client has been > configured by the user to ignore certificate errors and the client code > is oblivious to this fact. We cannot fix that, but we can at least > provide guidance to those who do have some control over the transport or > when there is an error. > This does not address your stated concern with certificates. This is > more-or-less a re-wording of the first paragraph in Sal's message. > Personally, I would prefer to not introduce the words "fall back", > because there is "fall back" concept in WebFinger. A client may use > HTTPS or HTTP. So, what's written now is: So I really don't know why the text has to callout the unverified certificate error case over any sort of TLS failure. Given that, as you say, some clients might have knowledge of it and others not, there is no consistent way to give proper advice beyond what general TLS recommendations already do. >> > WebFinger servers operating on HTTP MAY redirect a client using HTTP >> > status codes 301, 302, or 307 to another HTTP or an HTTPS URI and the >> > client MUST >> >> Don't quote specific response codes - new redirect codes can be defined >> (e.g. 308: >> ) > > That's probably a good idea. Should we say "status codes 3xx"? How is > this usually phrases? How about the following for the entire paragraph of redirects: WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. -- Cyrus Daboo From mmn@hethane.se Thu Dec 13 07:03:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192BA21F88FB for ; Thu, 13 Dec 2012 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJwV6L4JBezl for ; Thu, 13 Dec 2012 07:03:28 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04A21F88F2 for ; Thu, 13 Dec 2012 07:03:27 -0800 (PST) From: Mikael Nordfeldth To: Cyrus Daboo , "Paul E. Jones" , 'Salvatore Loreto' , webfinger@ietf.org X-Mailer: Modest 3.90.7 References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> In-Reply-To: <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> Content-Type: text/plain; charset=utf-8 Content-ID: <1355411610.27381.1.camel@Nokia-N900> Date: Thu, 13 Dec 2012 16:13:30 +0100 Message-Id: <1355411610.27381.2.camel@Nokia-N900> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mikael Nordfeldth List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:03:29 -0000 I very much like the phrasing below by Cyrus Daboo. Also I fully respect that https must not 3xx redirect to non-encrypted http resources. > How about the following for the entire paragraph of redirects: > >        WebFinger servers operating on HTTP MAY redirect a client using an >        appropriate HTTP status code to another HTTP or an HTTPS URI. > Likewise,      WebFinger servers operating on HTTPS MAY redirect a client > to another      HTTPS URI but MUST NOT redirect a client to an HTTP URI. > Further,      clients MUST NOT follow a redirection from an HTTPS URI to > an HTTP URI,      but SHOULD automatically follow all other server > redirects. From bradfitz@google.com Thu Dec 13 07:30:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6941421F8B6C for ; Thu, 13 Dec 2012 07:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.865 X-Spam-Level: X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plmk0ToefisH for ; Thu, 13 Dec 2012 07:30:05 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 809B121F8B67 for ; Thu, 13 Dec 2012 07:30:04 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so876695wgb.13 for ; Thu, 13 Dec 2012 07:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Zpwd9jUI1PU6k+t/4VAzvtKg38VXOPJX1Vv/A8AHyA=; b=JACWIVF4DoRcBv3hVGLI8wTcT1E36kflLo2QmM7L5R8Cp6E9MalPkqpiX0uSg0kVq9 lbS5IZF8Vc9z257BfE2xWN+bT+evBzKmTHQgXwrvr2q7HFPvCHO7WsGr/1uIurfF2oEw JCqohgJvSZ6XYF+anVgUZLN1OkCrO+ocWnHPNSFCBmC2y+vWKsdH/Jz9PvXzNmDooXO6 yFra8L32qz9S9x8yuTV14dEqcpIrWwVzB2sbBcdDybAvLwn/Xt4T3vnQvDgNFGEpN8Nt d8Z7NJEej0ZRcK0Z6Q2xpqSKGOHx+lD4r8ARnohBaQtoz5qudhuKWeMqjgFe98ElzvSO YFlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1Zpwd9jUI1PU6k+t/4VAzvtKg38VXOPJX1Vv/A8AHyA=; b=g2PDpqjrioGfzpE/Ks9KDtaVqF5RKN794UYHtpQFsOo0NztgeYcKeRmTGvs4M7OJDm IaL0WFeUhkb6hlZ12HV5xJvNIPgfpCz0GVjhkJ9DS+JwWkRtlkKH4VjnK3aQZq0jfR4i exBdRvzTQTivaJjdEPmCO3Qc7rwsWriBn0FBhbCdLGd9nXWN59SJX6xcI1RyDR+7CBRN t8KPDucgLgroqvr+n79UXolYbnr5/YGt0rYab5DYWb84U5+we/SW1Bt2TwANMxeGTL8t mQFAIe0nbS0NwfpKtFheS7U6ntaouNPCPa4FnTmHtzZ4cZX7iQYiL2VRSdtwrhPFqUXG tfXw== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr9073518wjz.19.1355412601313; Thu, 13 Dec 2012 07:30:01 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 07:30:01 -0800 (PST) In-Reply-To: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> Date: Thu, 13 Dec 2012 07:30:01 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=089e0102e102a01a8a04d0bd96b0 X-Gm-Message-State: ALoCoQkFuGS0rx5p1tU+0Z2sDXT5uFAtiiAimwE+oN51xk9Sf2088IqBWACiWS7C3O4mjhARedjGRR8FV82ved4e91dWRb3z4wsp1jiqZxIxXHUSe3jNea85DSGFAIkQ3mDITvitz95FshWzvdhDIsHZC/vkuJzPbuchLp0E8tSfX97ST6hwC5oaaTJkb2ttA1gmoUei619n Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:30:06 -0000 --089e0102e102a01a8a04d0bd96b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones wrot= e: > But what if I=E2=80=99m not looking for a specific link, but just want al= l of the > links related to foo@example.com? I might be building a =E2=80=9Cprofile= =E2=80=9D type > page or I might accept a number of different pieces of data (vcard, hcard= , > xcard, portable contact, avatar, =E2=80=9Cpreferred name=E2=80=9D, etc.).= Then what? > If a successful connection to HTTPS was made, all the links would be returned. If plain HTTP was used, all links beginning with "https:" would be filtered out by the client. (just like in the single rel lookup case) I thought that followed obviously from the proposal, sorry. --089e0102e102a01a8a04d0bd96b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

But what if I=E2=80=99m not looking for a specific link, bu= t just want all of the links related to foo@example.com?=C2=A0 I might be building a =E2=80= =9Cprofile=E2=80=9D type page or I might accept a number of different piece= s of data (vcard, hcard, xcard, portable contact, avatar, =E2=80=9Cpreferre= d name=E2=80=9D, etc.).=C2=A0 Then what?


If a successful connection to = HTTPS was made, all the links would be returned.

I= f plain HTTP was used, all links beginning with "https:" would be= filtered out by the client. =C2=A0(just like in the single rel lookup case= )

I thought that followed obviously from the proposa= l, sorry.
--089e0102e102a01a8a04d0bd96b0-- From paulej@packetizer.com Thu Dec 13 07:47:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C03D21F8B67 for ; Thu, 13 Dec 2012 07:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyogscpEIPUr for ; Thu, 13 Dec 2012 07:47:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C5AAB21F8B7F for ; Thu, 13 Dec 2012 07:47:32 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDFlTle028854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 10:47:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355413649; bh=oQBId/atI9Sfstgkhi+Xwb19RhAoS18aWPjg+ye0TrY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zh4nuEUyPd0fyc9oiCphwYLoZQ9RMfJTkx1dghp69q6Zwz1hRDp+SuYDME0nn4DLK 2sOsMJdDFqfzURNByxUan9iihKobhQLLWDpfAJjwV3wCD71NkgqBTUoj8lmGvwWyuj Rc/q7nQ7i5hR3ji53sZt/qxYkV4IViVaKxU3Tkzk= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'Salvatore Loreto'" , References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> In-Reply-To: <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> Date: Thu, 13 Dec 2012 10:47:40 -0500 Message-ID: <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgs3uWOXh1f7Eiv72bV+v1Wv2RMQNXOuP9AsmTS+4DDVLYVAJAapUflxWzUzA= Content-Language: en-us Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:47:34 -0000 Cyrus, > So I really don't know why the text has to callout the unverified > certificate error case over any sort of TLS failure. Given that, as you > say, some clients might have knowledge of it and others not, there is no > consistent way to give proper advice beyond what general TLS > recommendations already do. I think the reason is that if a client knows the certificate produces an error, it should not ignore that. Many clients would know, directly or indirectly. At least clients would not try to go around the error with this language. The text should call out other errors. The older text said to assume HTTPS has issues if: * A connection cannot be established * There is an invalid certificate * HTTP server returns a status code indicating some error (e.g., 4xx or 5xx) This language was necessary when we had the "fall back" logic. Now the proposed text recommends that a client use either HTTP or HTTPS, not both. So, if the client elects to use HTTPS, the only error condition we really need to speak to is certificate errors. > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. > Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to > another > HTTPS URI but MUST NOT redirect a client to an HTTP URI. Further, > clients MUST NOT follow a redirection from an HTTPS URI to an HTTP > URI, > but SHOULD automatically follow all other server redirects. This sounds OK, though I think some might ask what an "appropriate" HTTP status code is. That's why I suggested using "3xx", since the HTTP spec uses that language. Paul From bradfitz@google.com Thu Dec 13 07:55:31 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C72321F8B5B for ; Thu, 13 Dec 2012 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIYNSPk27WuC for ; Thu, 13 Dec 2012 07:55:30 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1221F8433 for ; Thu, 13 Dec 2012 07:55:30 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4178545wib.13 for ; Thu, 13 Dec 2012 07:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3BydSlv6ego2UElO4lAjMnisCRiqTjUfP1UjSXCuIfM=; b=ejfk0VYopV+kdq6OgAGSax/sq5VqFehO9tuypdYCffvY/ljUaUEfycLhQjaZavKpf0 9ZSLuXPPlo3Ip77t9ktzPZaTb2HuyXpMV64cO/l/e27SAVQlOp1uz4FNQKMkR+y2SSr1 4Z7tAMG1wP2KdxyV3l7MMVwYjVMlrd5stIOmKaNToOjCJuzW1fFtIOysb+dCnt0qu6CS CF1b5tKNORwnbRsX8sSc6VVMAk+6awOeiMV3Oa0AmjXyGUuH2jWZAK1ry20Kbqmt88Fk iKViBllkA3wPptEmtnzjYNGLEEWFb5gKRTmNiJBHUBhKAbvI89ZPttG93/0kH1sed8uA +TMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3BydSlv6ego2UElO4lAjMnisCRiqTjUfP1UjSXCuIfM=; b=nwWsPIdQ0i7DDf4+UhSvyrFwn2jiotoBvrPCmVWPch9lvyYR0VQmmCIT/axZ89vw+x NFUXdLGp0yq8A/bXY0rTf8YCyxfXIWsCFdplgirIrXrFfwKR4omLAa9frPbn32imOWZw 1dRYS+6RLcvzLRwpj1/65heZzhCUL+37dBqdkZUNUyg4OMBeuyBZeOfYVECTqGmiiyB2 Eug9pxwOOqWcLYe1HRy/DJvmYvI+QhgVo+BTWEfJ8DOpxyWLGVraEIaT5GnYVKSZy22j /0oYRAZ6D0AAkbs8i3YE5G6jrw/YkLehAyrJSAVchLqJcNnyh2clKQsNLCLyJ8qmQl0F URLQ== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr9222870wjz.19.1355414129229; Thu, 13 Dec 2012 07:55:29 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 07:55:29 -0800 (PST) In-Reply-To: <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> Date: Thu, 13 Dec 2012 07:55:29 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e0102e102b23ff204d0bdf1bc X-Gm-Message-State: ALoCoQl75SzRh3yNMpk7rzDBuz0eBcEOvHw/CTiivHbLZCE1SFMllPKX5HJMaVWuAQLA/5PvSk3asszeIX6+JKmBx+QegrKWJisH0YZ2KmumhIvnn2PKhGNGnJsY6khzOIQ5CeT+PKHngpwSgvucUTISBViwVc+upHPKGOfdnzaSymtsGZPrNZbqx/gq8nbs77r0Z/nxsf1t Cc: Cyrus Daboo , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:55:31 -0000 --089e0102e102b23ff204d0bdf1bc Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones wrote: > This language was necessary when we had the "fall back" logic. Now the > proposed text recommends that a client use either HTTP or HTTPS, not both. > I've yet to understand how this is not going to be totally broken: you're saying that both the server and the client get to pick HTTP or HTTPS? That seems like the most broken thing ever: HTTPS server & HTTPS client: ok HTTPS server & HTTP client: FAIL HTTP server & HTTPS client: FAIL HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the server was also running on HTTPS, but the client just got unlucky in which it picked. That proposal looks like mostly fail. If people on this list want to run HTTP servers (which many apparently do), then we're going to need to push complexity to clients. It's unfortunate, but it's not going to work otherwise. Or what am I missing? --089e0102e102b23ff204d0bdf1bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones <paulej@packetizer.com> wrote:
This language was= necessary when we had the "fall back" logic. =C2=A0Now the
proposed text recommends that a client use either HTTP or HTTPS, not both.<= br>

I've yet to understand how this is = not going to be totally broken: you're saying that both the server and = the client get to pick HTTP or HTTPS? =C2=A0That seems like the most broken= thing ever:

HTTPS server & HTTPS client: ok
HTTPS server & H= TTP client: FAIL
HTTP server & HTTPS client: FAIL
H= TTP server & HTTP client: ok, but=C2=A0susceptible=C2=A0to MITM, and ma= ybe the server was also running on HTTPS, but the client just got unlucky i= n which it picked.

That proposal looks like mostly fail.

If people on this list want to run HTTP servers (which many apparen= tly do), then we're going to need to push complexity to clients. It'= ;s unfortunate, but it's not going to work otherwise.

Or what am I missing?

--089e0102e102b23ff204d0bdf1bc-- From paulej@packetizer.com Thu Dec 13 07:58:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0421F8B82 for ; Thu, 13 Dec 2012 07:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZdky-LsLCeS for ; Thu, 13 Dec 2012 07:58:42 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EAF0621F8B66 for ; Thu, 13 Dec 2012 07:58:41 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDFwdKS029426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 10:58:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355414320; bh=zUAWc1ZZfrxDbRVwxDqn+4eMhr3ilPFtbTVcqtENLRY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=NSR9mZXFMwrJjftKpMH3miy6uFCXR+jPV1c+Eny6j/ImeghDkQmITHKc3vZhKpQ9U N7s3J31BofQRWPuehR1mWJ+TBBtSYSZ5DCqDPX6NsV8n83EMa6knhgTHuxDTi0ohUf WayMqAEazILYgbmpA0gJIo7nVhZejDJxTSfrmm0M= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 10:58:50 -0500 Message-ID: <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0534_01CDD920.D5CA7AD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkmY5m4PsA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:58:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0534_01CDD920.D5CA7AD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my = profile page on Google+. There=E2=80=99s no security-related issues = with that (as far as I=E2=80=99m concerned), but the URL scheme is = =E2=80=98https=E2=80=99 for Google+. (And I say =E2=80=9Cas far as = I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage today. I = don=E2=80=99t secure that, either.) =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 10:30 AM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones = wrote: But what if I=E2=80=99m not looking for a specific link, but just want = all of the links related to foo@example.com? I might be building a = =E2=80=9Cprofile=E2=80=9D type page or I might accept a number of = different pieces of data (vcard, hcard, xcard, portable contact, avatar, = =E2=80=9Cpreferred name=E2=80=9D, etc.). Then what? =20 If a successful connection to HTTPS was made, all the links would be = returned. =20 If plain HTTP was used, all links beginning with "https:" would be = filtered out by the client. (just like in the single rel lookup case) =20 I thought that followed obviously from the proposal, sorry. ------=_NextPart_000_0534_01CDD920.D5CA7AD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Oh, I don=E2=80=99t like that.=C2=A0 Suppose I want to provide a URL = to my profile page on Google+.=C2=A0 There=E2=80=99s no security-related = issues with that (as far as I=E2=80=99m concerned), but the URL scheme = is =E2=80=98https=E2=80=99 for Google+.=C2=A0 (And I say =E2=80=9Cas far = as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage = today.=C2=A0 I don=E2=80=99t secure that, = either.)

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, = 2012 10:30 AM
To: webfinger@googlegroups.com
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] secure links with = https rels

 

On Wed, Dec = 12, 2012 at 11:23 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

But what if I=E2=80=99m not looking for a specific link, but just = want all of the links related to foo@example.com?  I might be building a = =E2=80=9Cprofile=E2=80=9D type page or I might accept a number of = different pieces of data (vcard, hcard, xcard, portable contact, avatar, = =E2=80=9Cpreferred name=E2=80=9D, etc.).  Then = what?

 

If a = successful connection to HTTPS was made, all the links would be = returned.

 

If plain = HTTP was used, all links beginning with "https:" would be = filtered out by the client.  (just like in the single rel lookup = case)

 

I thought = that followed obviously from the proposal, = sorry.

------=_NextPart_000_0534_01CDD920.D5CA7AD0-- From bradfitz@google.com Thu Dec 13 08:00:08 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592C021F8B81 for ; Thu, 13 Dec 2012 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaAoX3Bcqdgg for ; Thu, 13 Dec 2012 08:00:07 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 88A5121F8B75 for ; Thu, 13 Dec 2012 08:00:07 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4183491wib.13 for ; Thu, 13 Dec 2012 08:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lPxpA7Cx92hLgGgx9/9MR3F6p1qoKsrCi8oYSKfF/XA=; b=f5oufKqBQIqp5QuSu/+O9WDoz/9IWvzdy1s+Oiv97PRHqhtmLTAfIMVaDucYijRj7T IosqtatRiP7O+TGiSnfhTLsOmq2u47TLH41yYs9THB9Dys4plg7FyaMawR9S8WiBvZQv 47dkpzRHNgCV2QHh5jSigizHNEzNjGoe5f8lgeQg1KlAeEskQF+83qhwN4mwSRV9SKRw vDpizc66WC+6hFpVJesfzvWggiDxsVNOZ1yCF6Pp+9O4cgqAA8jWYpvMBAD4CHc5uSsC rmJnhLXj6dOcwG0sHM+y3FP1WUwdEgzSPuuaW4/CQ+A2rTieUxvo9B4ARQfsu9mvFs6D r50A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lPxpA7Cx92hLgGgx9/9MR3F6p1qoKsrCi8oYSKfF/XA=; b=b3G8TtwyJOD6gnnk9dV+orcUeTS4/r9Wvfko6+xl31Npt+ymJybHk4JmWDgadTw43e 4Zv2Pq2mQxq73HK2z8ptwDA6DW1RNfCIAOmQim4vOS3U9pU0m9lcT2pSrpL2hFlp0/LD iaj/6DFq6bouHW41wFA+PjvSAfmfkvoXpo858s/ycE4IKUclT5w/ZMiQBQsExQogQazE tlcCkJjCKKhbK7hhrHT4VY68p3OxTi0CUnMOxp6zw+MXE+d6la9Fhj/3lfd1FXBBw2MJ RZ/f5dgUzJxvTazPH1HDcXMJKIZwdEQIo2reScSIJTNOp4BDz7LEoooEKgwM2mM65xTJ aijw== MIME-Version: 1.0 Received: by 10.180.107.197 with SMTP id he5mr4273880wib.1.1355414404283; Thu, 13 Dec 2012 08:00:04 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:00:04 -0800 (PST) In-Reply-To: <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 08:00:04 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f13eaf8173e7504d0be022d X-Gm-Message-State: ALoCoQmGjlz91VVMTVJoOPwz1YAgAMNZgEOs63+l5sAIdZyv+gyoFv1VRu1T9YSEJSJNuDk219NbOSnPYMj3ZQBswAmFfZiaXi/gpfJOAZYtSh7DTDJrqqrYoxkciMshfG2oIipHS28+L0MEMzCRO3prG+FfTYM7hTfmPhf6j6Jx6XqTcKcRBAwxI57XL53Ld70CDZEcl/A1 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:00:08 -0000 --e89a8f13eaf8173e7504d0be022d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 7:58 AM, Paul E. Jones wrote= : > Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my pro= file page > on Google+. There=E2=80=99s no security-related issues with that (as far= as I=E2=80=99m > concerned), but the URL scheme is =E2=80=98https=E2=80=99 for Google+. (= And I say =E2=80=9Cas far > as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my prof= ile page and end > up at the wrong place due to a hacker=E2=80=99s actions, it=E2=80=99s no = different than > visiting my homepage today. I don=E2=80=99t secure that, either.) > Okay, so denote a "secure rel" with a new "secure: true" attribute instead of using the href's "https:" prefix? --e89a8f13eaf8173e7504d0be022d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --e89a8f13eaf8173e7504d0be022d-- From sakimura@gmail.com Thu Dec 13 08:04:32 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00621F8BC3 for ; Thu, 13 Dec 2012 08:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWCy6unMKzk0 for ; Thu, 13 Dec 2012 08:04:32 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6EE321F8B18 for ; Thu, 13 Dec 2012 08:04:31 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1396872eek.31 for ; Thu, 13 Dec 2012 08:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N/DR0HaMOqHa8NGb9IF+jWM/3Q1yzB+cDSXE60A3A/Q=; b=pceIdUfFq3O8KxMLzapkhUPFmHC+n1skJkso9gpAcWFgGiUE07W7GXkBiGn3bKQDI5 SP8n0PcvmWVvcr6bbbv1QTjMmGu1y89UflIJcXDiSWm2Mf2H6qeYeaF0ZDoHOrTC2HYb ARMLD7hrmpRmnVEOlKSqWAE+3Sv2Y7UbNpqr31BMd7Ho8+bHStZ+QFTFGjHRF/MAStHj KvBgbEGhgYMtnqlKtBXVJe1oI4jR98B3PGRuUm4VycATn4TqmoGwhT8CsjdEvEUoIaQH Fv3jHVzm85ISGlGecbQGvp8hXJAihR2B8DPWloZdWBVkdbCOTVGm73YM9msanm3O2X5L JyKw== MIME-Version: 1.0 Received: by 10.14.216.70 with SMTP id f46mr6556377eep.12.1355414670947; Thu, 13 Dec 2012 08:04:30 -0800 (PST) Received: by 10.14.215.66 with HTTP; Thu, 13 Dec 2012 08:04:30 -0800 (PST) Date: Fri, 14 Dec 2012 01:04:30 +0900 Message-ID: From: Nat Sakimura To: webfinger@ietf.org Content-Type: multipart/alternative; boundary=047d7b603c1efc346e04d0be113e Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:04:32 -0000 --047d7b603c1efc346e04d0be113e Content-Type: text/plain; charset=ISO-8859-1 +1 for HTTPS only, please. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b603c1efc346e04d0be113e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for HTTPS only, please.=A0

--
Nat Sa= kimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--047d7b603c1efc346e04d0be113e-- From paulej@packetizer.com Thu Dec 13 08:07:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E763021F8B80 for ; Thu, 13 Dec 2012 08:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHrkzPNGlEyp for ; Thu, 13 Dec 2012 08:07:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D17D321F8B6B for ; Thu, 13 Dec 2012 08:07:24 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDG7Llv029907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 11:07:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355414842; bh=pH3TDImMCCu9skbqURTv6vPGytq5/kftxGAGQkg1W1A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kuaD0Fs6a0U4bN3HxgXthrhpOznovR++ZeFHCzY/bE6bQKtMgPEfnyDRU32dZzox5 SK5h6WrWVtm57pZPKHBcomKpIymtIFhgfg/FYmossZS2pgRJA3CRc7ldxmz1ZxTVC1 JHvzNmkizyxFQQ2fLTCVt7dr0mtPr2FcZQxyMBB4= From: "Paul E. Jones" To: , "'Brad Fitzpatrick'" References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> In-Reply-To: <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 11:07:32 -0500 Message-ID: <054301cdd94b$f60b9060$e222b120$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0544_01CDD922.0D3672C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYspjSm1zg Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:07:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0544_01CDD922.0D3672C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me add=E2=80=A6 =20 If you wish to define =E2=80=9Csecure links=E2=80=9D within the server = itself, I=E2=80=99d be OK with that. That=E2=80=99s what I thought you = meant. For example, when I put in my OpenID Provider URI, I would = indicate whether that content should be returned over a secure link or = not. The server can return only the links that are not marked = =E2=80=9Csecure=E2=80=9D internally. The server can even automatically = classify some link relation types as =E2=80=9Csecure=E2=80=9D. =20 It=E2=80=99s not automatic, but servers could definitely choose to serve = different content over different transports. =20 Paul =20 From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Paul E. Jones Sent: Thursday, December 13, 2012 10:59 AM To: 'Brad Fitzpatrick'; webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: RE: [webfinger] secure links with https rels =20 Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my = profile page on Google+. There=E2=80=99s no security-related issues = with that (as far as I=E2=80=99m concerned), but the URL scheme is = =E2=80=98https=E2=80=99 for Google+. (And I say =E2=80=9Cas far as = I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage today. I = don=E2=80=99t secure that, either.) =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 10:30 AM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones = wrote: But what if I=E2=80=99m not looking for a specific link, but just want = all of the links related to foo@example.com? I might be building a = =E2=80=9Cprofile=E2=80=9D type page or I might accept a number of = different pieces of data (vcard, hcard, xcard, portable contact, avatar, = =E2=80=9Cpreferred name=E2=80=9D, etc.). Then what? =20 If a successful connection to HTTPS was made, all the links would be = returned. =20 If plain HTTP was used, all links beginning with "https:" would be = filtered out by the client. (just like in the single rel lookup case) =20 I thought that followed obviously from the proposal, sorry. ------=_NextPart_000_0544_01CDD922.0D3672C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Let me add=E2=80=A6

 

If you wish to define =E2=80=9Csecure links=E2=80=9D within the = server itself, I=E2=80=99d be OK with that.=C2=A0 That=E2=80=99s what I = thought you meant.=C2=A0 For example, when I put in my OpenID Provider = URI, I would indicate whether that content should be returned over a = secure link or not.=C2=A0 The server can return only the links that are = not marked =E2=80=9Csecure=E2=80=9D internally.=C2=A0 The server can = even automatically classify some link relation types as = =E2=80=9Csecure=E2=80=9D.

 

It=E2=80=99s not automatic, but servers could definitely choose to = serve different content over different = transports.

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Paul E. Jones
Sent: Thursday, December 13, 2012 = 10:59 AM
To: 'Brad Fitzpatrick'; = webfinger@googlegroups.com
Cc: = webfinger@ietf.org
Subject: RE: [webfinger] secure links with = https rels

 

Oh, I don=E2=80=99t like that.  Suppose I want to provide a URL = to my profile page on Google+.  There=E2=80=99s no security-related = issues with that (as far as I=E2=80=99m concerned), but the URL scheme = is =E2=80=98https=E2=80=99 for Google+.  (And I say =E2=80=9Cas far = as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage = today.  I don=E2=80=99t secure that, = either.)

 

Paul

 

From:= = webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On Behalf Of Brad Fitzpatrick
Sent: Thursday, = December 13, 2012 10:30 AM
To: webfinger@googlegroups.com=
Cc: webfinger@ietf.org
Subject:<= /b> Re: [webfinger] secure links with https = rels

 

On Wed, Dec = 12, 2012 at 11:23 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

But what if I=E2=80=99m not looking for a specific link, but just = want all of the links related to foo@example.com?  I might be building a = =E2=80=9Cprofile=E2=80=9D type page or I might accept a number of = different pieces of data (vcard, hcard, xcard, portable contact, avatar, = =E2=80=9Cpreferred name=E2=80=9D, etc.).  Then = what?

 

If a = successful connection to HTTPS was made, all the links would be = returned.

 

If plain = HTTP was used, all links beginning with "https:" would be = filtered out by the client.  (just like in the single rel lookup = case)

 

I thought = that followed obviously from the proposal, = sorry.

------=_NextPart_000_0544_01CDD922.0D3672C0-- From nick@silverbucket.net Thu Dec 13 08:16:32 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0221F89F8 for ; Thu, 13 Dec 2012 08:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQCmc30rUp8B for ; Thu, 13 Dec 2012 08:16:32 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7EB21F89E9 for ; Thu, 13 Dec 2012 08:16:31 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1902374lah.31 for ; Thu, 13 Dec 2012 08:16:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=LCly1BC740TXkFuPX5/NUI1Q9TqXjn9eb/iaqahlVkA=; b=lzWTbmWSXUrBZTw2yXFU+auAD0yxMebyC9Y2MqnM08ITVxn1E7I8Z0oWc3kquBlM4F gUeIgmM4Lx6xJxMZYtbSEjvm12daMbamyTq/YQXgwfohdRnKM9Sh8EUoCDkXKQDeieen lD0fgNXu2L5pe07wghi3y+K4IOI3hSxzoWFJHzufz4rR5LwjtaV2O/WOsmjNF+kq5ZkR lcoMWhESv8cRXz+rkeZ1dAjqXGVAcqNaDy90lOcpOObjcsNL81rgzWTPGVJXTm4uQrlZ OXy6dbIwUi5kFg33V4WPUJkK9a26uYtkfn1cL1P4eOyJi70X8Fwt0nR+k0H+WD6MUsFy ZSYw== Received: by 10.112.27.97 with SMTP id s1mr1129562lbg.97.1355415390527; Thu, 13 Dec 2012 08:16:30 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id fb1sm920440lbb.15.2012.12.13.08.16.29 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:16:29 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1916750lbk.31 for ; Thu, 13 Dec 2012 08:16:28 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr1156703lbd.54.1355415388823; Thu, 13 Dec 2012 08:16:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 08:15:58 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 17:15:58 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnuTYnwfUFiuNg+VjrYSNsTi2IRtvbndwwWupEviV4ZmQeQuJ1E5E21JVW1p5sFfd0RIpQP Cc: Cyrus Daboo , "Paul E. Jones" , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:16:32 -0000 On Thu, Dec 13, 2012 at 4:55 PM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones > wrote: >> >> This language was necessary when we had the "fall back" logic. Now the >> proposed text recommends that a client use either HTTP or HTTPS, not both. > > > I've yet to understand how this is not going to be totally broken: you're > saying that both the server and the client get to pick HTTP or HTTPS? That > seems like the most broken thing ever: I agree, I would personally want to run both on my server. Then either can be used for a varied number of use-cases, where appropriate. > HTTPS server & HTTPS client: ok > HTTPS server & HTTP client: FAIL > HTTP server & HTTPS client: FAIL > HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the server > was also running on HTTPS, but the client just got unlucky in which it > picked. If all you're getting is a vcard, name, avatar picture, then who cares? If you are retrieving sensitive information that could be dangerous if tampered with, then you're just going to use HTTPS from the client library. From bradfitz@google.com Thu Dec 13 08:19:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E10A21F8A85 for ; Thu, 13 Dec 2012 08:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxaqFXFTKnva for ; Thu, 13 Dec 2012 08:19:10 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1679621F8A28 for ; Thu, 13 Dec 2012 08:19:09 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so2581632wgb.1 for ; Thu, 13 Dec 2012 08:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=msJZzBCI+D/HZKy4tNRCpjLYEntnC6EXrHm+ZvwA2lg=; b=Xy57D4Z+iAqA015hUu6Tqt5UXxj1Ba8aAX8ll3nPt6qjmFvVMcIj9ATueUUMUEZQ+X EnbHnVlxvNZqcXHGeLAWzMSe1yv4HZsdB5Hl85GIooJEVAabM/SDLZHIB0KCVxWAazIs jxm0CkgEXYSyK0QP5ZSW3gow9qnmX8tnQuhR1Aq0pMILDXemfSwW75uPBslLbmZru4Xh zA81mB+8AP+eJKgNKyl2so57Qg/fwPGWsUFxFwveu2dlCkhKKKTPrtWUWrYeYmUJUVKi NyWElXu/k+GutzF6lpK0PKBfFu1R8ogaxcDt7UKKEghi+2M7tXt23tdnXWthECA/JIFh A2cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=msJZzBCI+D/HZKy4tNRCpjLYEntnC6EXrHm+ZvwA2lg=; b=Gl/qSejEFPUZd2TR1dyksKChqQ8XbTcMcomLn9+86NALZ6vy2QkwBR38w13QkcwD+b DrgEVGdczvAArzTI3ARBbj8NEar6BhY7fdNE2BvmMKU0yhF+YOFc5ee9GksHwFCp0LR0 J0ByPkoO06QZNG+ivDGRIpZGq3znh/YjlkC4URP1EnF48ygroPc+C3baDf5z2oa6XIbH ItuMiFLFxZ+kmVtqKypfLWvFQBC5fGYKCGRIsDLpu74To27uaPvSGGehwr31zyoS+TQQ T37Fk3QXzhhyUSgSJilY5vAk6D3E9KRz4r+zKYfaixCXFACRc+Ty13tVvDrkRDIGV/W4 Li4g== MIME-Version: 1.0 Received: by 10.180.86.39 with SMTP id m7mr30079018wiz.1.1355415548906; Thu, 13 Dec 2012 08:19:08 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:19:08 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 08:19:08 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04428e1050ce9004d0be4692 X-Gm-Message-State: ALoCoQlrGcEEKh7gjud9g5qpDHd1PrmicWV60M5q+ZauzjPCn1ojZ3uuYkD6Xg36Jtd6bPYT66/cbauMqkk4ahl4IHBttneFaH2TbBway7rxKPYHhCWiyQS3F9V6IozXYgznjDqzqs2smMEQLATZXF1hdPAZcNFtYf+ysMu7kSJ8gjFhorFjgoyavlEhDMmSdvEFj1tr74/p Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:19:11 -0000 --f46d04428e1050ce9004d0be4692 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:00 AM, Brad Fitzpatrick wrot= e: > On Thu, Dec 13, 2012 at 7:58 AM, Paul E. Jones wro= te: > >> Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my pr= ofile >> page on Google+. There=E2=80=99s no security-related issues with that (= as far as >> I=E2=80=99m concerned), but the URL scheme is =E2=80=98https=E2=80=99 fo= r Google+. (And I say =E2=80=9Cas >> far as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my= profile page and >> end up at the wrong place due to a hacker=E2=80=99s actions, it=E2=80=99= s no different than >> visiting my homepage today. I don=E2=80=99t secure that, either.) >> > > Okay, so denote a "secure rel" with a new "secure: true" attribute instea= d > of using the href's "https:" prefix? > duh, of course this doesn't work. a MITM downgrading this to HTTP just wouldn't put that attribute in. This proposal only works if security is part of the rel. Paul, you were confused by where I meant looking for "https:" --- it's not in the href (not the link target), but the link rel itself. { "rel" : "my_blog", "type" : "text/html", "href" : "https://plus.google.com/...." }, .... is not secure, because "my_blog" doesn't start with "https:". But: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "http://insecure.com/" }, ... *is* a secure link (because the OpenID Connect rel starts with "https:"), regardless of where the target is. or even: { "rel" : "https://openpgp.net/public-key", "href" : "data:xxxxxxxxxxxxxxxxxxxxxx" }, Sorry, I'm sick and out of it and got confused by your confusion and sent the stupid email proposing a "secure" attribute, which is totally broken. --f46d04428e1050ce9004d0be4692 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HTTPS, on the other hand, is well-understood and widely implemen= ted.

WebFinger isn't supposed to be about designing a new= PKI or crypto system. =C2=A0It's supposed to be a simple mechanism to = read some key/value pairs.


Last post on th= e topic because I've said basically everything I think needs to be said= on it: I never said this is WebFinger specific. I'm not suggesting tha= t anything be "lumped into WebFinger". Nor am I suggesting that W= F be "about designing a new PKI or crypto system". If, however, W= ebFinger is going to be used in cases where verifying the integrity of the = provided information is critical, then the specification needs to properly = address how the integrity of the information can be verified. HTTPS does no= t provide for that. Neither does any notion of a "secure link relation= ".=C2=A0

O= n Thu, Dec 13, 2012 at 8:00 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Th= u, Dec 13, 2012 at 7:58 AM, Paul E. Jones <paulej@packetizer.com&g= t; wrote:

Oh, I don=E2=80=99t like that.=C2=A0 Suppose I w= ant to provide a URL to my profile page on Google+.=C2=A0 There=E2=80=99s n= o security-related issues with that (as far as I=E2=80=99m concerned), but = the URL scheme is =E2=80=98https=E2=80=99 for Google+.=C2=A0 (And I say =E2= =80=9Cas far as I=E2=80=99m concerned=E2=80=9D, since if you issue a query = for my profile page and end up at the wrong place due to a hacker=E2=80=99s= actions, it=E2=80=99s no different than visiting my homepage today.=C2=A0 = I don=E2=80=99t secure that, either.)


Okay, so denote a "= secure rel" with a new "secure: true" attribute instead of u= sing the href's "https:" prefix?

duh, of course this doesn't work. =C2=A0 a MITM dow= ngrading this to HTTP just wouldn't put that attribute in. =C2=A0This p= roposal only works if security is part of the rel.

Paul, you were confused by where I meant looking for "https:" --= - it's not in the href (not the link target), but the link rel itself.<= /div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : "my_blog"= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type" : &qu= ot;text/html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quo= t;href" : "https://plus.g= oogle.com/...."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

..= .. is not secure, because "my_blog" doesn't start with "= https:".

But:

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"rel" : "https://openid.net/connect/server",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type" : "text= /html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"href&= quot; : "http://insecure.com/&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

... *is* a secure link (because the OpenID Connect rel starts with &q= uot;https:"), regardless of where the target is.

or even:

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;rel" : "https://op= enpgp.net/public-key",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"href" : "data:xxxxxxxxxxxxxxxxxxxxxx"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

Sorry, I'm sick and out of it and got confused by your con= fusion and sent the stupid email proposing a "secure" attribute, = which is totally broken.
--f46d04428e1050ce9004d0be4692-- From bradfitz@google.com Thu Dec 13 08:19:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1821F8A85 for ; Thu, 13 Dec 2012 08:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DARTDgxTh-76 for ; Thu, 13 Dec 2012 08:19:35 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0EC21F8A28 for ; Thu, 13 Dec 2012 08:19:35 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1049066wey.31 for ; Thu, 13 Dec 2012 08:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E3tslLYGmum274HBuszWMut/04fIV6tmYxsWtcMeQW0=; b=eYzG+nQHoD/e/mNdkyXTYKYEvx67MUCVWlgDg+CYc17feZ7A/bXd19YAvVvjuXefEK W7alANDOkOpKVQGC/JeGi/rV/gEKsOxjoQud1QC6kgtvkswXI6D2BcA2C4iWuiddMFd1 I6RJJjzkJUbxu+ui3RWJqAJTPyXwWc+Xqm+AQdgqHBWsE9ZYelA6OmyP5eeWiISz3fTe DlVxdoF+CFJeTcE0tl7nozKusuiGl1Na+GlgsfrJGdcAybcxnqOA9XTma+jugsoqtL7a gJ7DtY2+fizRzWGXeJN3i7G9FwbM7xScGlTOhpHENgoWEojgqjWLG3mRbTfNWAJF5VZX 01iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=E3tslLYGmum274HBuszWMut/04fIV6tmYxsWtcMeQW0=; b=EyQBw6hfI20TbfFPhHZTVVWH03VcT5nUfE+OwVuHJErm1K9dLRdvFKwqtOR94AUanH zbMx99D1wVvVnpNJ0b7Xb3JTdNQFk5S+xO3iorNC+v/gn3CldDz/nHQvsb+DkNqQWoo3 309LYJrdVFTB6f+8NQswhLy3ClcTRHa5SdCC/LqEvOULB9nB7BrIbPBamLkRoxNeI2SN 9jxesxfOyDxSD8tjHFSC1kf//OX48IZZAgAriHkO4N5sBYvx/FAFcZ4AYxXizRkSssQ1 OZGOpbCchtx2CDPZJ5CDpkEFDPPSw1y8MexV4Kj28DEQQxvqVuX/HzyHh3av9stnOoi6 qPTA== MIME-Version: 1.0 Received: by 10.180.99.227 with SMTP id et3mr4374282wib.6.1355415574501; Thu, 13 Dec 2012 08:19:34 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:19:34 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 08:19:34 -0800 Message-ID: From: Brad Fitzpatrick To: Zellyn Hunter Content-Type: multipart/alternative; boundary=f46d041826aad7581b04d0be47eb X-Gm-Message-State: ALoCoQlYj1m/kM+NfkTqz0cIJuGzApW/v5MeJCxHyGb+4ND7SttQa5ihBQ8EN1sfKkTraIuu1LzRLDIwAQBo/wm/bCNXmVCZlVCKL6UuhNqggAJCexbVv45pRwvsb6ZS64YzjtCrhFp+vSHB/LDY0orfd/JpOqun1JJcQmcK3LzwIsobGIXfnh5VuqGguJcxOsrc/saIqJ9G Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:19:36 -0000 --f46d041826aad7581b04d0be47eb Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 8:17 AM, Zellyn Hunter wrote: > The http links seem to work okay... > http://profiles.google.com/zellyn > http://plus.google.com/110196407167832022215 > See my previous email. This isn't the issue. --f46d041826aad7581b04d0be47eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:17 AM, Zellyn Hunter <zellyn@gmail.com> wrote:
The http lin= ks seem to work okay...

See my previous email. =C2=A0This isn't the iss= ue.

--f46d041826aad7581b04d0be47eb-- From nick@silverbucket.net Thu Dec 13 08:19:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7721F8A28 for ; Thu, 13 Dec 2012 08:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEqIQX9lOy0D for ; Thu, 13 Dec 2012 08:19:45 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8998321F8A85 for ; Thu, 13 Dec 2012 08:19:44 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1920632lbk.31 for ; Thu, 13 Dec 2012 08:19:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=BgY6F3fivNojsGqNKLlxaVCRZQskbLof3TfqSam5UXc=; b=gJrKHchLkQ5UW2Y+vnnV7qTepbEVza5ED6XJKfNP+0whknaoFDxO30RMS0empECBFf gJAlR/d6J9mWezWzk7HOfu9aDcN+xh4GFPJIVKpam4z1g6CWoDTXKEOuctg30SL+4c9L pT9Kcu7YLHOuwYpBIxOyhCoYL4F9V8oFRn4SQqsfh486CUJsB1qPJ+FMo9ptMyxXORfd q2YJ7rNAcaRpjPig3q711QGjezgMOlQjAf80AgbsVZ5VRYKgJtPzsVkkyi8sY9iK1ZgX E18jsQa4lKp/XTjGlNwd2ca8qyXmf6Fh8pa0n7lv4v3Jzhb1HsEruuheenlrUBhg6H1M EMiA== Received: by 10.152.113.66 with SMTP id iw2mr194586lab.37.1355415583197; Thu, 13 Dec 2012 08:19:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id v7sm925101lbj.13.2012.12.13.08.19.42 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:19:42 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1920600lbk.31 for ; Thu, 13 Dec 2012 08:19:42 -0800 (PST) Received: by 10.152.162.1 with SMTP id xw1mr99765lab.3.1355415581873; Thu, 13 Dec 2012 08:19:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 08:19:10 -0800 (PST) In-Reply-To: <054301cdd94b$f60b9060$e222b120$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 17:19:10 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkujtwuMg8wc308eyTWxjGusGuSygRtiPGxoAB5Ebqha8TH4fHdejvwU0yepQ0E7RrppCPp Cc: Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:19:45 -0000 On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones wrot= e: > Let me add=E2=80=A6 > > If you wish to define =E2=80=9Csecure links=E2=80=9D within the server it= self, I=E2=80=99d be OK > with that. That=E2=80=99s what I thought you meant. For example, when I= put in my > OpenID Provider URI, I would indicate whether that content should be > returned over a secure link or not. The server can return only the links > that are not marked =E2=80=9Csecure=E2=80=9D internally. The server can = even automatically > classify some link relation types as =E2=80=9Csecure=E2=80=9D. Yes, this is how I would like it as well. I think it' solves a lot of these issues, and even helps to take less burden off the client. From bradfitz@google.com Thu Dec 13 08:21:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7D621F8AA0 for ; Thu, 13 Dec 2012 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S4LmcP6rteE for ; Thu, 13 Dec 2012 08:21:04 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2855621F8AA6 for ; Thu, 13 Dec 2012 08:21:03 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so903122wgb.13 for ; Thu, 13 Dec 2012 08:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IC/eD5YG0hnOGU2cRu20p0jWyFrQfGKkRuQWKtF2Xz8=; b=gFEJyXoN5/OEXS/lxX6Hx1MlOyv0xjwZcKKHpSzdt/qAefgdhJ0kso/LPGtGccT1cN dRv0D+vdCF3jsNm+BofOTG0E713GsuyiR/gbUNSOu33hi1Na3qUXmxyQUqVqCUWzSmpG 1D7BH7Be7LAzpIVY4GzLF6KXknuz5L56kPDfGqpXaoyVZ3To64i4K2QOJRFIyKt8PZbI dsmqwshdJaWT23iv3qsMaY5fZRKWH1jwMi6bNFopP9y/l98epCXvThcYPJ45x6/hyNpR bs11Puwn2jxg2AmaFLeVXKFNXL9V695xzci3Q+ZK20lAbaMCKrW6/II3gCtlb6wT+N8U DINw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IC/eD5YG0hnOGU2cRu20p0jWyFrQfGKkRuQWKtF2Xz8=; b=gWNKQzO2sUOw2mDZUlGP/a+4S7d3I5wFlY5yHYDj5ZvIGy0/YU+HWdOUKiIg/wnKsY 4mQxYSfzJ9PDBkqB0rt89YRqxP+Sv2oBl9JJf3T5UUTIyJkK/BJylY98cwSHMgWNQbWe RWzd40O1SFHfd0HElaDQBrWwMWT7V1lKHXt7cuTJijRxniT0WxxrGtEdIp7MeXl6ryCn uHRiZLc1VI6UuoECxvPpHCAj+HWP6gVFxj5wkTi9uytGuVxDcwx2aynXnj6h7mGb8gGR o2BZHbe9sCXcqMk81e3OnnO4a91o+fQnTnGhY1SWJB2KQnLdyk9PcrDT6XWgNOSgTBRp 7E4w== MIME-Version: 1.0 Received: by 10.180.107.197 with SMTP id he5mr4400166wib.1.1355415662989; Thu, 13 Dec 2012 08:21:02 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:21:02 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> Date: Thu, 13 Dec 2012 08:21:02 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=e89a8f13eaf81d903a04d0be4dfa X-Gm-Message-State: ALoCoQl411gd4M2CRkLbEAqeU2zLGcdgBLCMOeCk8H0DtxL51E6euo1UsKJw3SQnEStuPeSUYy1HVFjygK6jsDFERhf+tjeo0mC2ulEAh/apzcx3WBMNkF43fw4jGtSx3GOuBm7bL3Y5IFlqm50/MAhPN74z/m30BQhGl3xlWeGHZCC/Jg11feb7/9us8W+CgD9Hf61G8DBG Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:21:05 -0000 --e89a8f13eaf81d903a04d0be4dfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings wrote= : > On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones > wrote: > > Let me add=E2=80=A6 > > > > If you wish to define =E2=80=9Csecure links=E2=80=9D within the server = itself, I=E2=80=99d be OK > > with that. That=E2=80=99s what I thought you meant. For example, when= I put in > my > > OpenID Provider URI, I would indicate whether that content should be > > returned over a secure link or not. The server can return only the lin= ks > > that are not marked =E2=80=9Csecure=E2=80=9D internally. The server ca= n even > automatically > > classify some link relation types as =E2=80=9Csecure=E2=80=9D. > > Yes, this is how I would like it as well. I think it' solves a lot of > these issues, and even helps to take less burden off the client. > A server can do whatever it wants but it doesn't help if the client is talking to a different server. (after a downgrade attack) If you want security in the whole system, it needs to have a client component. --e89a8f13eaf81d903a04d0be4dfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Thu, Dec 13, 2012 at 8:19 AM, Nick Jen= nings <nick@silverbucket.net> wrote:
On Thu, Dec 13, 2012 at 5:= 07 PM, Paul E. Jones <paulej@pa= cketizer.com> wrote:
> Let me add=E2=80=A6
>
> If you wish to define =E2=80=9Csecure links=E2=80=9D within the server= itself, I=E2=80=99d be OK
> with that. =C2=A0That=E2=80=99s what I thought you meant. =C2=A0For ex= ample, when I put in my
> OpenID Provider URI, I would indicate whether that content should be > returned over a secure link or not. =C2=A0The server can return only t= he links
> that are not marked =E2=80=9Csecure=E2=80=9D internally. =C2=A0The ser= ver can even automatically
> classify some link relation types as =E2=80=9Csecure=E2=80=9D.

Yes, this is how I would like it as well. I think it' solves a lo= t of
these issues, and even helps to take less burden off the client.

A server can do whatever it wants but it doesn= 9;t help if the client is talking to a different server. =C2=A0(after a dow= ngrade attack)

If you want security in the whole system, it needs to h= ave a client component.
--e89a8f13eaf81d903a04d0be4dfa-- From bradfitz@google.com Thu Dec 13 08:25:16 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBD21F8AF9 for ; Thu, 13 Dec 2012 08:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lW6hmjoW3Ir for ; Thu, 13 Dec 2012 08:25:14 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id C82E321F8AA5 for ; Thu, 13 Dec 2012 08:25:13 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1760560wib.13 for ; Thu, 13 Dec 2012 08:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8mzsKl9N9xoUya5Lv3ZIPL7y3XkpoFI0qE3ZjajZ0og=; b=g5PKzRSjemDld5XdSF3irl1MSl+Vz9qQrj2qt1+gfhGsW09XHStmNK/T28+EiGR8nM 7sY4v9u5s4G40HyPCHtRUidU39rnPkAZ9zjjhXgukozfN2epleyu6mXMkQ3opXWgvwEc nq9Sj2ZCBsszn5JFORmlGwTAUBocW7kVWL5+vp/MmH8DHea2lucdhEVp8L9Q3oaCuRYr +37ZpL+6Ddx7Co1EVS9quCkuaxHUh5rQKJyyg0bO3h1/YGn/yM9F+erAOmTDerZ4zcCc FSVgxNKM41I0FpkhdxbWmZ27sRKoLWpx3KWVs+WoXhAYXFxS6/Qe4y4zHjbVTsHzilKg OMqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8mzsKl9N9xoUya5Lv3ZIPL7y3XkpoFI0qE3ZjajZ0og=; b=OuZ56txeI9h7+kUyiUcvm/SCpnwF6yf4+Bh/cvY1wYCZtihCZ+gGpHE7sF6dO7yOTS oYgjox1ltWOENUJTxj4a9LHOl/ZB5NXQSj7/Rc5OO7Fwo05J2mQAaoaZ1G2nAnRZIHvX e0N/zYqW4V1pXzxLypR8dvYXdAownuUuCdAbzI3/e29Su9RYbTkiJ9cO0vzldpyWMELl hnUh0xszTnc46PI1qxhVRuSI15m5BEJxVhaayeX+TDP5nkzcFXorgtqa0Ojhg7ul8wqt OiKlyvI7ei8RMaQjPMgGxuLaQklZT3sEnz3XW4HFdT4eahbwa30JGq0LmySU/9/tJB74 i0jA== MIME-Version: 1.0 Received: by 10.180.90.106 with SMTP id bv10mr4385585wib.12.1355415903098; Thu, 13 Dec 2012 08:25:03 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:25:03 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> Date: Thu, 13 Dec 2012 08:25:03 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=f46d043c81e86d557104d0be5bff X-Gm-Message-State: ALoCoQlisMMyyTpsYni7lYvj8M9eduiGEohqul4xorID3Y/zdSn8Zy3uc8Fwcy8wEZjztFatEv8DUZm0/MShudDtSTDjtyiqU8hK5LHrEFC/tXfbk7aSXg7IR19Q94HuMUDYPT+nfS7DV2Fo22uO4UkNi4fQSod/bHogZNFjUHtgmRUDQFivLGVYD1gJKYcIEEfDhVqpJcgW Cc: Cyrus Daboo , "Paul E. Jones" , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:25:16 -0000 --f46d043c81e86d557104d0be5bff Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 8:15 AM, Nick Jennings wrote: > On Thu, Dec 13, 2012 at 4:55 PM, Brad Fitzpatrick > wrote: > > On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones > > wrote: > >> > >> This language was necessary when we had the "fall back" logic. Now the > >> proposed text recommends that a client use either HTTP or HTTPS, not > both. > > > > > > I've yet to understand how this is not going to be totally broken: you're > > saying that both the server and the client get to pick HTTP or HTTPS? > That > > seems like the most broken thing ever: > > I agree, I would personally want to run both on my server. Then either > can be used for a varied number of use-cases, where appropriate. > You agree it's the most broken thing ever. But because it's the most broken thing ever, you personally will run servers on both ports. What about everybody else running a server? > HTTPS server & HTTPS client: ok > > HTTPS server & HTTP client: FAIL > > HTTP server & HTTPS client: FAIL > > > HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the > server > > was also running on HTTPS, but the client just got unlucky in which it > > picked. > > If all you're getting is a vcard, name, avatar picture, then who > cares? If you are retrieving sensitive information that could be > dangerous if tampered with, then you're just going to use HTTPS from > the client library. > What if I want to say "all links"? How do I get a mix of secure links and insecure links? --f46d043c81e86d557104d0be5bff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:15 AM, Nick Jennings <nick@silverbucket.net> wrote:
On Thu, Dec 13, 2012 at 4:55 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
> On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones <paulej@packetizer.com>
> wrote:
>>
>> This language was necessary when we had the "fall back" = logic. =C2=A0Now the
>> proposed text recommends that a client use either HTTP or HTTPS, n= ot both.
>
>
> I've yet to understand how this is not going to be totally broken:= you're
> saying that both the server and the client get to pick HTTP or HTTPS? = =C2=A0That
> seems like the most broken thing ever:

I agree, I would personally want to run both on my server. Then eithe= r
can be used for a varied number of use-cases, where appropriate.

You agree it's the most broken thing ever. = =C2=A0But because it's the most broken thing ever, you personally will = run servers on both ports. What about everybody else running a server?

> HTTPS server & HTTPS client: ok
> HTTPS server & HTTP client: FAIL
> HTTP server & HTTPS client: FAIL

> HTTP server & HTTP client: ok, but susceptible to MITM, and maybe = the server
> was also running on HTTPS, but the client just got unlucky in which it=
> picked.

If all you're getting is a vcard, name, avatar picture, then who<= br> cares? If you are retrieving sensitive information that could be
dangerous if tampered with, then you're just going to use HTTPS from the client library.

What if I want to s= ay "all links"? =C2=A0How do I get a mix of secure links and inse= cure links?
--f46d043c81e86d557104d0be5bff-- From nick@silverbucket.net Thu Dec 13 08:33:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1123021F8ACA for ; Thu, 13 Dec 2012 08:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbaYYq2oqewz for ; Thu, 13 Dec 2012 08:33:09 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B57C421F8A86 for ; Thu, 13 Dec 2012 08:33:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1935404lbk.31 for ; Thu, 13 Dec 2012 08:33:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=d9hkoTINSzyxdGPKeGosoNKgx7wF9VNmoVtcLHKwBFI=; b=ZwD/IzxF6EPkAproOkl2K9DFVyffDwBLgF6+OKYC83hbvU1MwlVPdgBn5k0aKDnkwd hEsELLoOt4CVA5rxtWYzIbBZ7xzo4hT8UbyhAzdSf0pI73IK4C/m7RSLZBAT2gdDpzVg BmBA5nvPMtUIMPgFiLH6IaoSJ+Mj0lejpkWHulGRVxTH96l+SvSan4KporYeQZQA6FjN 44OQ+AJbEw5AKb3MtkH/yqoQLzC8EttZlLz5tRskjp33pjnnsDZR/amK5yJQIyonNxYA ISyICzUAot/82EJhe4PDhpgqcv89SgQia35/NAfyeIk/VnON9thRiFlXbWbxZ0AkBJSe lRCA== Received: by 10.152.148.4 with SMTP id to4mr159567lab.39.1355416387651; Thu, 13 Dec 2012 08:33:07 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id ti4sm872344lab.1.2012.12.13.08.33.06 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:33:06 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1920898lah.31 for ; Thu, 13 Dec 2012 08:33:06 -0800 (PST) Received: by 10.112.24.161 with SMTP id v1mr1180914lbf.28.1355416386255; Thu, 13 Dec 2012 08:33:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 08:32:34 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 17:32:34 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm/HxMrLmLt72qBA+DPqkWBrtMTEjwzbKNS0cRSoPrTNemTgGfrRtwXA1zWRJJDKarKhsag Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:33:10 -0000 On Thu, Dec 13, 2012 at 5:21 PM, Brad Fitzpatrick wro= te: > On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings > wrote: >> On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones >> wrote: >> > Let me add=E2=80=A6 >> > >> > If you wish to define =E2=80=9Csecure links=E2=80=9D within the server= itself, I=E2=80=99d be OK >> > with that. That=E2=80=99s what I thought you meant. For example, whe= n I put in >> > my >> > OpenID Provider URI, I would indicate whether that content should be >> > returned over a secure link or not. The server can return only the >> > links >> > that are not marked =E2=80=9Csecure=E2=80=9D internally. The server c= an even >> > automatically >> > classify some link relation types as =E2=80=9Csecure=E2=80=9D. >> >> Yes, this is how I would like it as well. I think it' solves a lot of >> these issues, and even helps to take less burden off the client. > > > A server can do whatever it wants but it doesn't help if the client is > talking to a different server. (after a downgrade attack) > > If you want security in the whole system, it needs to have a client > component. Can you give me an example of the downgrade attack where an HTTP call is made initially to a server? From bradfitz@google.com Thu Dec 13 08:35:28 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5111521F8B21 for ; Thu, 13 Dec 2012 08:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS1slmLQukhn for ; Thu, 13 Dec 2012 08:35:27 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0AE21F8A70 for ; Thu, 13 Dec 2012 08:35:26 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so4378784wib.1 for ; Thu, 13 Dec 2012 08:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z984iI4PNys6B7CPffD517ywVCHFCYDFVXJI7iRt+lc=; b=RTJ3IfT5yqxaaBIQuFG4zts9JOGHtsjczoUV+/6yAVbo02QftqWo2+xSBwvIayDbTd 1oQMEMkIf63qM+33C29kwJ++RZ+0DxXZUsHrimt+dnNG49HDChMg5JznWk3rzpDMiP5Q qvd9BCzW/Y0keLNcTUXEwU3/j1UmLy+r43NbecOIk31x0rwCDLPsqj1fdl8c0rGStovp AerM+diL1sckbfDyc03n3MeLZwBPYwL65UZbxRYqA38fomsfPbQiERQAT0WllYPnXgRV Id/N1/GTcBfB7+/Z1yxH1ck6HJ2rGbwYVZdvn5GDuWjWtO5hLV5tnx/DW2UKfG4GztGE FV1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Z984iI4PNys6B7CPffD517ywVCHFCYDFVXJI7iRt+lc=; b=H9d2d9VtMI8ftgMnslVk3mkb0qVuldnvLui4CcRWd3DMiJDkPDOqK1TbqXoOBkl69e djU2l95/ev1BWw0e2S4PWtJqXgHbDnm6PjWVY6wpK0EriohGWmIe8QKSDSZxwHQHcXIq 8MUC8Y1zVsSGY85Ele7dB5eTw6aqIKK8hSqBtW6sJfpbddw2pmO51N3V1bGQI8OHDtGb Fm12DoBL5H41OL1HTMjm/PlksIyRxK/KLhzMoOa2MPo75LUyU4CFIv3SFUbeSQN9thBt oPaTevpoehgsWNyIakdxM4BBuI9LvK4KMNIPOkouYZvaJextKYxyhobC5LQRRUe6PHkB BPaw== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr9499007wjb.10.1355416526201; Thu, 13 Dec 2012 08:35:26 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:35:26 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> Date: Thu, 13 Dec 2012 08:35:26 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=047d7bf10b2c91219304d0be80cb X-Gm-Message-State: ALoCoQnRsks1svyDsJZ3iCdsJcO9yKFJWYIw0AW/1K9iLpCVVAdXd0VaQ0GyWpq1+aCJtrvePYugqyqaNNbHybAF+gjmCuF8Mx3fmmhGwTERBxDeuLIrhpHze05HYzjiytnXbKx/OcM9q/QUf8NksOKYNBHD80prYDwU7m4hkGYCVlZf3TYrtVMg3BJwjVu+CGrceGtMe1ak Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:35:28 -0000 --047d7bf10b2c91219304d0be80cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:32 AM, Nick Jennings wrote= : > On Thu, Dec 13, 2012 at 5:21 PM, Brad Fitzpatrick > wrote: > > On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings > > wrote: > >> On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones > >> wrote: > >> > Let me add=E2=80=A6 > >> > > >> > If you wish to define =E2=80=9Csecure links=E2=80=9D within the serv= er itself, I=E2=80=99d be > OK > >> > with that. That=E2=80=99s what I thought you meant. For example, w= hen I put > in > >> > my > >> > OpenID Provider URI, I would indicate whether that content should be > >> > returned over a secure link or not. The server can return only the > >> > links > >> > that are not marked =E2=80=9Csecure=E2=80=9D internally. The server= can even > >> > automatically > >> > classify some link relation types as =E2=80=9Csecure=E2=80=9D. > >> > >> Yes, this is how I would like it as well. I think it' solves a lot of > >> these issues, and even helps to take less burden off the client. > > > > > > A server can do whatever it wants but it doesn't help if the client is > > talking to a different server. (after a downgrade attack) > > > > If you want security in the whole system, it needs to have a client > > component. > > Can you give me an example of the downgrade attack where an HTTP call > is made initially to a server? > There's no example of a downgrade attack with HTTP-only because there's nowhere "down" to go... you're already at the bottom and can't trust anything. --047d7bf10b2c91219304d0be80cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:32 AM, Nick Jennings <nick@silverbucket.net> wrote:
On Thu, Dec 13, 2012 at 5:21 PM, Brad Fitzpatrick &l= t;bradfitz@google.com> wrote:=
> On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings <nick@silverbucket.net>
> wrote:
>> On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones <paulej@packetizer.com>
>> wrote:
>> > Let me add=E2=80=A6
>> >
>> > If you wish to define =E2=80=9Csecure links=E2=80=9D within t= he server itself, I=E2=80=99d be OK
>> > with that. =C2=A0That=E2=80=99s what I thought you meant. =C2= =A0For example, when I put in
>> > my
>> > OpenID Provider URI, I would indicate whether that content sh= ould be
>> > returned over a secure link or not. =C2=A0The server can retu= rn only the
>> > links
>> > that are not marked =E2=80=9Csecure=E2=80=9D internally. =C2= =A0The server can even
>> > automatically
>> > classify some link relation types as =E2=80=9Csecure=E2=80=9D= .
>>
>> Yes, this is how I would like it as well. I think it' solves a= lot of
>> these issues, and even helps to take less burden off the client. >
>
> A server can do whatever it wants but it doesn't help if the clien= t is
> talking to a different server. =C2=A0(after a downgrade attack)
>
> If you want security in the whole system, it needs to have a client > component.

Can you give me an example of the downgrade attack where an HTT= P call
is made initially to a server?

There= 9;s no example of a downgrade attack with HTTP-only because there's now= here "down" to go... you're already at the bottom and can'= ;t trust anything.


--047d7bf10b2c91219304d0be80cb-- From evan@status.net Thu Dec 13 08:38:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E027B21F8822 for ; Thu, 13 Dec 2012 08:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o2qlU6aCVeU for ; Thu, 13 Dec 2012 08:38:22 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE0721F8540 for ; Thu, 13 Dec 2012 08:38:12 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 188638D4559 for ; Thu, 13 Dec 2012 16:50:46 +0000 (UTC) Message-ID: <50CA0473.4070305@status.net> Date: Thu, 13 Dec 2012 11:38:11 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020509090703050302090006" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:38:23 -0000 This is a multi-part message in MIME format. --------------020509090703050302090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brad, Some quick impressions. 1. I'm happy to live with this compromise if it's what it takes to get us finished. 2. I continue to be uncomfortable with specifying function signatures for "Open Source client libraries". First, because I think it's the wrong level of abstraction for this specification, and second, because I think it's a narrow view of how people are going to use Webfinger. 3. The compromise proposal feels like something you do with a well-established protocol that you can't change. That seems different from what we're doing here. The signal of using an "https://" url for the rel is clever, but could we have a more explicit signal? -Evan On 12-12-12 12:44 PM, Brad Fitzpatrick wrote: > Thinking about the current HTTPS impasse, I thought of another avenue > which I don't recall having been discussed: > > What if we, > > * define some links as "secure links" (any link whose with a "rel" > value beginning with the substring "https:") > > * say WebFinger servers can run on HTTPS or HTTP (making the $5/month > hosting & RootCA hater camp happy), but noting that HTTPS is > recommended and then required if "secure links" need to be returned > > * say WebFinger clients MUST try to hit HTTPS first (either serially > first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is > unreachable, but NOT if bad cert). > > * (new) say WebFinger clients using plain HTTP MUST filter out any > "secure links" from the "links" list before giving it to their caller. > > > So a caller that wanted, say, "OpenID Connect" (a secure user of > WebFinger) could just write code like: > > wc = new WebFingerClient() > server = wc.LookupHref("foo@example.com > ", "https://openid.net/connect/server") // > Note "https:" prefix > // use server, if non-empty > > So rather than configuring the WebFingerClient with a requested > fallback policy, the policy is implicit in the rel requested. > > This still leaves the HTTPS-only camp arguing that "there will be so > many crappy WebFinger client implementations out there" (those not > doing the secure link filtering), but the counter-argument from > earlier swayed me sufficiently: they're easily auditable, and anybody > writing security software should audit their dependencies anyway. The > "client" code is also so simple in the grand scheme of things, this > mailing list could go bust out proper implementations in all popular > languages and advertise them loudly. > > This is a bit of a compromise personally (it adds client complexity), > but I'm willing to give some of that up in exchange for WebFinger > being used more widely, for all sorts of applications. > > Thoughts? > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------020509090703050302090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brad,

Some quick impressions.
  1. I'm happy to live with this compromise if it's what it takes to get us finished.
  2. I continue to be uncomfortable with specifying function signatures for "Open Source client libraries". First, because I think it's the wrong level of abstraction for this specification, and second, because I think it's a narrow view of how people are going to use Webfinger.
  3. The compromise proposal feels like something you do with a well-established protocol that you can't change. That seems different from what we're doing here. The signal of using an "https://" url for the rel is clever, but could we have a more explicit signal?
-Evan

On 12-12-12 12:44 PM, Brad Fitzpatrick wrote:
Thinking about the current HTTPS impasse, I thought of another avenue which I don't recall having been discussed:

What if we,

* define some links as "secure links" (any link whose with a "rel" value beginning with the substring "https:")

* say WebFinger servers can run on HTTPS or HTTP (making the $5/month hosting & RootCA hater camp happy), but noting that HTTPS is recommended and then required if "secure links" need to be returned

* say WebFinger clients MUST try to hit HTTPS first (either serially first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is unreachable, but NOT if bad cert).

* (new) say WebFinger clients using plain HTTP MUST filter out any "secure links" from the "links" list before giving it to their caller.


So a caller that wanted, say, "OpenID Connect" (a secure user of WebFinger) could just write code like:

     wc = new WebFingerClient()
     server = wc.LookupHref("foo@example.com", "https://openid.net/connect/server")  // Note "https:" prefix
     // use server, if non-empty

So rather than configuring the WebFingerClient with a requested fallback policy, the policy is implicit in the rel requested.

This still leaves the HTTPS-only camp arguing that "there will be so many crappy WebFinger client implementations out there" (those not doing the secure link filtering), but the counter-argument from earlier swayed me sufficiently: they're easily auditable, and anybody writing security software should audit their dependencies anyway.  The "client" code is also so simple in the grand scheme of things, this mailing list could go bust out proper implementations in all popular languages and advertise them loudly.

This is a bit of a compromise personally (it adds client complexity), but I'm willing to give some of that up in exchange for WebFinger being used more widely, for all sorts of applications.

Thoughts?



_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------020509090703050302090006-- From paulej@packetizer.com Thu Dec 13 08:41:02 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C250321F8B5D for ; Thu, 13 Dec 2012 08:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsWhIekkG2De for ; Thu, 13 Dec 2012 08:40:57 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11B21F8B50 for ; Thu, 13 Dec 2012 08:40:57 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDGerwt031690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 11:40:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355416853; bh=8B12bK+NEpeJaOFGZ7eer944k4qZkqfKObKM5lXKM94=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=EzZ7H77Wa0NkpvNMHwGN5pPKbMh7tnbHy/c+piiCP5Vr+uryVgzAOonpVBkqs7aLS Wd3NvI3zob1ezWCoEjMlF2PQojCa6mvxKwJvlStyRPXlebEFu5ILwL19fDsynZTl2w z067NGEVfEfDjpboif2qTq4SfYqLlN/CKjPLce18= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 11:41:04 -0500 Message-ID: <059101cdd950$a4e64d60$eeb2e820$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0592_01CDD926.BC1108B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgs3uWOXh1f7Eiv72bV+v1Wv2RMQNXOuP9AsmTS+4DDVLYVAJAapUfAbbdNcwCFonY35b3V7QA Content-Language: en-us Cc: 'Cyrus Daboo' , 'Salvatore Loreto' , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:41:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0592_01CDD926.BC1108B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 My assumption is that if one runs an HTTPS server, he or she will either = respond to either HTTP or HTTPS requests, or redirect HTTP requests to = the HTTP server. So the only scenario that I think is broken is when an = HTTPS client issues a request to an HTTP-only server. =20 In any case, you=E2=80=99re right that there is at least one broken = scenario and the only solution is to push that to the client or let it = fail. We tried suggesting use both and people rejected that due to = complexity. The new text recommends use of HTTPS, but HTTP is there = because some wanted to use that. I would expect the =E2=80=9Cgeneral = purpose=E2=80=9D WF client to use HTTPS. But, perhaps = =E2=80=9Cspecialized=E2=80=9D clients would use HTTP only? =20 Anyway, yes=E2=80=A6 this could present issues for some, but primarily = for those clients that are HTTPS only. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 10:55 AM To: Paul E. Jones Cc: Cyrus Daboo; Salvatore Loreto; webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs = HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) =20 On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones = wrote: This language was necessary when we had the "fall back" logic. Now the proposed text recommends that a client use either HTTP or HTTPS, not = both. =20 I've yet to understand how this is not going to be totally broken: = you're saying that both the server and the client get to pick HTTP or = HTTPS? That seems like the most broken thing ever: =20 HTTPS server & HTTPS client: ok HTTPS server & HTTP client: FAIL HTTP server & HTTPS client: FAIL HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the = server was also running on HTTPS, but the client just got unlucky in = which it picked. =20 That proposal looks like mostly fail. =20 If people on this list want to run HTTP servers (which many apparently = do), then we're going to need to push complexity to clients. It's = unfortunate, but it's not going to work otherwise. =20 Or what am I missing? =20 ------=_NextPart_000_0592_01CDD926.BC1108B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

My assumption is that if one runs an HTTPS server, he or she will = either respond to either HTTP or HTTPS requests, or redirect HTTP = requests to the HTTP server.=C2=A0 So the only scenario that I think is = broken is when an HTTPS client issues a request to an HTTP-only = server.

 

In any case, you=E2=80=99re right that there is at least one broken = scenario and the only solution is to push that to the client or let it = fail.=C2=A0 We tried suggesting use both and people rejected that due to = complexity.=C2=A0 The new text recommends use of HTTPS, but HTTP is = there because some wanted to use that.=C2=A0 I would expect the = =E2=80=9Cgeneral purpose=E2=80=9D WF client to use HTTPS. =C2=A0But, = perhaps =E2=80=9Cspecialized=E2=80=9D clients would use HTTP = only?

 

Anyway, yes=E2=80=A6 this could present issues for some, but = primarily for those clients that are HTTPS only.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 10:55 AM
To: Paul E. Jones
Cc: = Cyrus Daboo; Salvatore Loreto; webfinger@ietf.org
Subject: Re: = [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP = (was Re: Consensus call: HTTPS only vs = HTTPS-and-HTTP)

 

On Thu, Dec = 13, 2012 at 7:47 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

This = language was necessary when we had the "fall back" logic. =  Now the
proposed text recommends that a client use either HTTP = or HTTPS, not both.

 

I've yet to = understand how this is not going to be totally broken: you're saying = that both the server and the client get to pick HTTP or HTTPS? =  That seems like the most broken thing = ever:

 

HTTPS server = & HTTPS client: ok

HTTPS server = & HTTP client: FAIL

HTTP server = & HTTPS client: FAIL

HTTP server = & HTTP client: ok, but susceptible to MITM, and maybe the = server was also running on HTTPS, but the client just got unlucky in = which it picked.

 

That = proposal looks like mostly fail.

 

If people on = this list want to run HTTP servers (which many apparently do), then = we're going to need to push complexity to clients. It's unfortunate, but = it's not going to work otherwise.

 

Or what am I = missing?

 

------=_NextPart_000_0592_01CDD926.BC1108B0-- From nick@silverbucket.net Thu Dec 13 08:41:30 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD621F8B50 for ; Thu, 13 Dec 2012 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDejRmO9UUbP for ; Thu, 13 Dec 2012 08:41:30 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9580C21F8B03 for ; Thu, 13 Dec 2012 08:41:29 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1929878lah.31 for ; Thu, 13 Dec 2012 08:41:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=RwYvbxk8c2oGRfg+2Yt+hVdCfKifj0vL0fmZs6MVdks=; b=f7tImxS+75XecuZnzz2IilYNkgS+EtfWJ2GmvZiBlWbsaToGlTye0ehUdjCoXvwCu9 r2Ipfxhhn+gb5dssBtPQwOVibtZJydApXjrx+7cJRti04y+tqGdOx80+EZQx2ZxXgtBj JId5FoA1abj7oQmi//FwJc+2VVrdnbvgk/7/nL0kH+AoLr+74iPXWJ2kK0twsPhkr42L hpweJq/DQblsuYCd4NH5B8+XA7TJk5dUS0qwwAtcJuKCa3zH5uzhcXmgaSNmW1Fi//aH RykhjxWGGuctpuXsZmJx55ZoH+I25bFTa2acBDYJRqaSjB2iIJhDgNHtRmIYKePZPhrw JgpQ== Received: by 10.152.108.42 with SMTP id hh10mr49569lab.4.1355416888615; Thu, 13 Dec 2012 08:41:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id er8sm949941lbb.9.2012.12.13.08.41.27 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:41:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1929853lah.31 for ; Thu, 13 Dec 2012 08:41:27 -0800 (PST) Received: by 10.112.87.194 with SMTP id ba2mr1190083lbb.84.1355416887536; Thu, 13 Dec 2012 08:41:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 08:40:57 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 17:40:57 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkhKcCIZCmC4B5nxo1qcLXda7dkt6Be9DYhQdGaf/kP51uguXIhT0MLV+eRBIcfbtRjb5Da Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:41:30 -0000 On Thu, Dec 13, 2012 at 5:35 PM, Brad Fitzpatrick wro= te: > On Thu, Dec 13, 2012 at 8:32 AM, Nick Jennings > wrote: >> >> On Thu, Dec 13, 2012 at 5:21 PM, Brad Fitzpatrick >> wrote: >> > On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings >> > wrote: >> >> On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones >> >> wrote: >> >> > Let me add=E2=80=A6 >> >> > >> >> > If you wish to define =E2=80=9Csecure links=E2=80=9D within the ser= ver itself, I=E2=80=99d be >> >> > OK >> >> > with that. That=E2=80=99s what I thought you meant. For example, = when I put >> >> > in >> >> > my >> >> > OpenID Provider URI, I would indicate whether that content should b= e >> >> > returned over a secure link or not. The server can return only the >> >> > links >> >> > that are not marked =E2=80=9Csecure=E2=80=9D internally. The serve= r can even >> >> > automatically >> >> > classify some link relation types as =E2=80=9Csecure=E2=80=9D. >> >> >> >> Yes, this is how I would like it as well. I think it' solves a lot of >> >> these issues, and even helps to take less burden off the client. >> > >> > >> > A server can do whatever it wants but it doesn't help if the client is >> > talking to a different server. (after a downgrade attack) >> > >> > If you want security in the whole system, it needs to have a client >> > component. >> >> Can you give me an example of the downgrade attack where an HTTP call >> is made initially to a server? > > > There's no example of a downgrade attack with HTTP-only because there's > nowhere "down" to go... you're already at the bottom and can't trust > anything. > > That's kind of my point. I was saying, that if the server filters out secure links during HTTP requests, then it takes out a lot of client complexity (ie. you make an HTTP request, you get only trivial data). The client doesn't need to worry about it. From paulej@packetizer.com Thu Dec 13 08:42:30 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F71621F8B07 for ; Thu, 13 Dec 2012 08:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmjR6cnQuPb5 for ; Thu, 13 Dec 2012 08:42:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 63DAB21F8B3D for ; Thu, 13 Dec 2012 08:42:29 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDGgOYY031819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 11:42:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355416944; bh=ZqCz0rk49TAvWp+TG2K6SbbbPUYZ4Cdrh+DgY1mNRpI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=DgC9WG8exJZHLg4YN2R33KNE8Re7zYnOf4azW5XK7Ldw8aI9bC/gXD5PpbCkLDpwE tqYwe5btSHgmAmBShc0G/MMSN5IpRsHJNI7v6nQ5YRlRYbm/oFRYxJxvk8pAskUePg fFMidq7J6IA86wR1ABfH9YEUNP62VnGWQIemMYL8= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 11:42:35 -0500 Message-ID: <059e01cdd950$db1219a0$91364ce0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_059F_01CDD926.F23CADE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWmL/TtlA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:42:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_059F_01CDD926.F23CADE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, though it would not have to be in the protocol. In my database, I = could mark each link relation as =E2=80=9Csecure=E2=80=9D or I could = classify certain link relations as =E2=80=9Csecure=E2=80=9D. Those so = marked would only be sent via HTTPS. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 11:00 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Thu, Dec 13, 2012 at 7:58 AM, Paul E. Jones = wrote: Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my = profile page on Google+. There=E2=80=99s no security-related issues = with that (as far as I=E2=80=99m concerned), but the URL scheme is = =E2=80=98https=E2=80=99 for Google+. (And I say =E2=80=9Cas far as = I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage today. I = don=E2=80=99t secure that, either.) =20 Okay, so denote a "secure rel" with a new "secure: true" attribute = instead of using the href's "https:" prefix? ------=_NextPart_000_059F_01CDD926.F23CADE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yeah, though it would not have to be in the protocol.=C2=A0 In my = database, I could mark each link relation as =E2=80=9Csecure=E2=80=9D or = I could classify certain link relations as = =E2=80=9Csecure=E2=80=9D.=C2=A0 =C2=A0Those so marked would only be sent = via HTTPS.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 11:00 AM
To: Paul E. Jones
Cc: = webfinger@googlegroups.com; webfinger@ietf.org
Subject: Re: = [webfinger] secure links with https = rels

 

On Thu, Dec = 13, 2012 at 7:58 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Oh, I don=E2=80=99t like that.  Suppose I want to provide a URL = to my profile page on Google+.  There=E2=80=99s no security-related = issues with that (as far as I=E2=80=99m concerned), but the URL scheme = is =E2=80=98https=E2=80=99 for Google+.  (And I say =E2=80=9Cas far = as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage = today.  I don=E2=80=99t secure that, = either.)

 

Okay, so = denote a "secure rel" with a new "secure: true" = attribute instead of using the href's "https:" = prefix?

------=_NextPart_000_059F_01CDD926.F23CADE0-- From paulej@packetizer.com Thu Dec 13 08:46:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C975D21F8B84 for ; Thu, 13 Dec 2012 08:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi8D5Rd1IEe2 for ; Thu, 13 Dec 2012 08:45:50 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5C21F8B03 for ; Thu, 13 Dec 2012 08:45:49 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDGjmwL031977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 11:45:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355417148; bh=oILzZ+j7iFyW4oKgsWICrMZskwx3EJpRTWZwqPvJWRI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=X0KSgmknwRlyn0U8zwUJsck+Uk0bpDZ8oy9DenWNvWtLjxadwzw7GUAXCmbQFMr3z o2c8EDQZ5zmBV/D/4AYaGYt9cTNlHVcIyPTCE9AkV4rvzZti067Qlp+hfst0Og4SAo tZpNTLV+MHLMd0nBkc2s696PAy2Ko/enCyRoaNjk= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 11:45:59 -0500 Message-ID: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05AC_01CDD927.6BCCD3B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvGYrFd6UA== Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:46:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05AC_01CDD927.6BCCD3B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Don=E2=80=99t put it on the wire. You want the server to filter before = sending a reply. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 11:19 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Thu, Dec 13, 2012 at 8:00 AM, Brad Fitzpatrick = wrote: On Thu, Dec 13, 2012 at 7:58 AM, Paul E. Jones = wrote: Oh, I don=E2=80=99t like that. Suppose I want to provide a URL to my = profile page on Google+. There=E2=80=99s no security-related issues = with that (as far as I=E2=80=99m concerned), but the URL scheme is = =E2=80=98https=E2=80=99 for Google+. (And I say =E2=80=9Cas far as = I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage today. I = don=E2=80=99t secure that, either.) =20 Okay, so denote a "secure rel" with a new "secure: true" attribute = instead of using the href's "https:" prefix? =20 duh, of course this doesn't work. a MITM downgrading this to HTTP just = wouldn't put that attribute in. This proposal only works if security is = part of the rel. =20 Paul, you were confused by where I meant looking for "https:" --- it's = not in the href (not the link target), but the link rel itself. =20 { "rel" : "my_blog", "type" : "text/html", "href" : "https://plus.google.com/...." }, =20 .... is not secure, because "my_blog" doesn't start with "https:". =20 But: =20 { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "http://insecure.com/" }, =20 ... *is* a secure link (because the OpenID Connect rel starts with = "https:"), regardless of where the target is. =20 or even: =20 { "rel" : "https://openpgp.net/public-key", "href" : "data:xxxxxxxxxxxxxxxxxxxxxx" }, =20 =20 Sorry, I'm sick and out of it and got confused by your confusion and = sent the stupid email proposing a "secure" attribute, which is totally = broken. ------=_NextPart_000_05AC_01CDD927.6BCCD3B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Don=E2=80=99t put it on the wire.=C2=A0 You want the server to filter = before sending a reply.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 11:19 AM
To: Paul E. Jones
Cc: = webfinger@googlegroups.com; webfinger@ietf.org
Subject: Re: = [webfinger] secure links with https = rels

 

On Thu, Dec = 13, 2012 at 8:00 AM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

On Thu, Dec = 13, 2012 at 7:58 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Oh, I don=E2=80=99t like that.  Suppose I want to provide a URL = to my profile page on Google+.  There=E2=80=99s no security-related = issues with that (as far as I=E2=80=99m concerned), but the URL scheme = is =E2=80=98https=E2=80=99 for Google+.  (And I say =E2=80=9Cas far = as I=E2=80=99m concerned=E2=80=9D, since if you issue a query for my = profile page and end up at the wrong place due to a hacker=E2=80=99s = actions, it=E2=80=99s no different than visiting my homepage = today.  I don=E2=80=99t secure that, = either.)

 

Okay, so = denote a "secure rel" with a new "secure: true" = attribute instead of using the href's "https:" = prefix?

 

duh, of = course this doesn't work.   a MITM downgrading this to HTTP just = wouldn't put that attribute in.  This proposal only works if = security is part of the rel.

 

Paul, you = were confused by where I meant looking for "https:" --- it's = not in the href (not the link target), but the link rel = itself.

 

  =        {

  =          "rel" : = "my_blog",

  =          "type" : = "text/html",

  =          "href" : "https://plus.google.com/....&quo= t;

  =        },

 

.... is not = secure, because "my_blog" doesn't start with = "https:".

 

But:

 

  =        {

  =          "rel" : "https://openid.net/connect/ser= ver",

  =          "type" : = "text/html",

  =          "href" : "http://insecure.com/"

  =        },

 

... *is* a = secure link (because the OpenID Connect rel starts with = "https:"), regardless of where the target = is.

 

or = even:

 

------=_NextPart_000_05AC_01CDD927.6BCCD3B0-- From bradfitz@google.com Thu Dec 13 08:47:56 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F4221F8722 for ; Thu, 13 Dec 2012 08:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg3cyc1SgsQF for ; Thu, 13 Dec 2012 08:47:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5677D21F871D for ; Thu, 13 Dec 2012 08:47:55 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1066669wey.31 for ; Thu, 13 Dec 2012 08:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fyKKCJq8CInNtikVjEaA49EBzk5ZkGvlNp1k6gD6UNY=; b=mbXa6D7wwwaLu5rJMhRhP29TBFcBu5YJAO+cDbKDCqAVMRE6t0YiF8c58D/uZXj3Gb SnIJw9EkKNV48dkBRylFqJhCvdd19vE7nWPf9cbZZtRf3pF/+mX6nXfP0j3Zkz5wLPRF xE69TuB+WHCvayVn5BTnVwbKR9rxjmg+olgDck5RC1N0bdFbmNiBcBqcJVpcdkeGN3ln oXiXOx847/GJHI+fxocuWxTMJn5G3pKxE6xGVa3OH2NzV5f8WdnJgYevjiyKhupEBL7c BFjx7fINp0fVey+Ok/woKha43L4LfdR9dhVqgzvPGDVw2AjgH3OxQ+yio5/VRSewjUFi pAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fyKKCJq8CInNtikVjEaA49EBzk5ZkGvlNp1k6gD6UNY=; b=hA7ysH/DbHQbFYfR426wrrfp5yXJkQx2wKZeUU9mhAA22/fqJgswwzMYCt5eZHbbr+ DPoC+CbVDlPFyilbVK8a03rJ7sVFGLi5NvSqEqcvUu3aKtdYWmQNgP3qquSe23H9EiQK h7Gl7eH5eOJ9VbX7N8auEavHfNMzzVD9dLAQbqpENYo+Lxu8nkVJjKkYHTyQ5tEFYRHY yVYnFUPG7ZSaF8rqAMdJ5o6Nk8kN4dW1TVNP5gRz4UCc1IBvKjWtwTvwNj2xC1Y93s3+ YBpYVVKJO3IXoSzSyJi1jexk8RwMqjtdcfcc6FHr26rDpaHlxTrpftfgVhRa5ftA4j3w OWUQ== MIME-Version: 1.0 Received: by 10.194.81.73 with SMTP id y9mr8633328wjx.31.1355417274249; Thu, 13 Dec 2012 08:47:54 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:47:54 -0800 (PST) In-Reply-To: <50CA0473.4070305@status.net> References: <50CA0473.4070305@status.net> Date: Thu, 13 Dec 2012 08:47:54 -0800 Message-ID: From: Brad Fitzpatrick To: Evan Prodromou Content-Type: multipart/alternative; boundary=047d7bea3a2027737a04d0bead4a X-Gm-Message-State: ALoCoQk14eG2PTsEi4/zc3IISUnmwvjZsbnn7N8Izkkg8j1offHsZmvMnZb+GlQ9nEACvynhdV3iI3PUcMxEeZK8m0vWOJ6Mk8jRPvwj767TQ2imqV+97B5i2QLLkKQKP/m3f/jcVPC5pHYLOufFHGE9RQgsghg2A8vvJZRs9zAXYdubI3A7QOcEDg2j1+yWsQYnfbr8rgyY Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:47:56 -0000 --047d7bea3a2027737a04d0bead4a Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 8:38 AM, Evan Prodromou wrote: > Brad, > > Some quick impressions. > > 1. I'm happy to live with this compromise if it's what it takes to get > us finished. > 2. I continue to be uncomfortable with specifying function signatures > for "Open Source client libraries". First, because I think it's the wrong > level of abstraction for this specification, and second, because I think > it's a narrow view of how people are going to use Webfinger. > > No, quite the contrary: this proposal doesn't advocate ANY client API signatures. There's no "secure-only" or "fallback-policy" configuration like before. You just get all links or get a specific link, however you want your API to work. But the webfinger client MUST not return rels beginning with "https:" if they were retrieved over HTTP. I think you're only thinking this because I showed pseudocode in my earlier email. Please confirm? > > 1. The compromise proposal feels like something you do with a > well-established protocol that you can't change. That seems different from > what we're doing here. The signal of using an "https://" url for the > rel is clever, but could we have a more explicit signal? > > Anything more explicit could be tweaked by an HTTPS->HTTP downgrade attack. Putting it in the rel is the only safe place I can think of. --047d7bea3a2027737a04d0bead4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:38 AM, Evan Prodromou <evan@status.net> wrote:
=20 =20 =20
Brad,

Some quick impressions.
  1. I'm happy to live with this compromise if it's what it = takes to get us finished.
  2. I continue to be uncomfortable with specifying function signatures for "Open Source client libraries". First, b= ecause I think it's the wrong level of abstraction for this specification, and second, because I think it's a narrow view of how people are going to use Webfinger.
No, quite the contrary: =C2=A0this proposal doesn't adv= ocate ANY client API signatures. =C2=A0There's no "secure-only&quo= t; or "fallback-policy" configuration like before. =C2=A0You just= get all links or get a specific link, however you want your API to work. = =C2=A0But the webfinger client MUST not return rels beginning with "ht= tps:" if they were retrieved over HTTP.

I think you're only thinking this because I showed = pseudocode in my earlier email. =C2=A0Please confirm?
  1. The compromise proposal feels like something you do with a well-established protocol that you can't change. That seems different from what we're doing here. The signal of using an "https://" url for the rel is clever, but could = we have a more explicit signal?
Anyth= ing more explicit could be tweaked by an HTTPS->HTTP downgrade attack. = =C2=A0Putting it in the rel is the only safe place I can think of.

--047d7bea3a2027737a04d0bead4a-- From bradfitz@google.com Thu Dec 13 08:54:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F021F8B2A for ; Thu, 13 Dec 2012 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usmzpG9ijshO for ; Thu, 13 Dec 2012 08:54:16 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 496EB21F8A0C for ; Thu, 13 Dec 2012 08:54:16 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1070296wey.31 for ; Thu, 13 Dec 2012 08:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g09HKa/zs2wpPBw2nzteRbxpa6wfdwnNnms7vzr7BbM=; b=P2ETB4btZMgMrDFE3x50ZxsGwOGRXICz7fS4iH+XLaGsNUYA/++C3nmnG3DkZ3ysmQ cr67Qy3qi1UnwMZselQOI040yRcWN7S7P9F25mw6sM9h6Ev6Cs8nukrN7hG83Rz/xnzA xpFgTVqLRevyxoT7c44E5TmG2kgRmP97KtRUdJKhP7PbS9Tvs8oYgreXOeGYkX8xVnLj N/w1SI4FArBYkJDKw3bRm0FoPmZ8FxTlxwBIJXsDqF5Vw7cvlbQaAyHp2nVHEOfrarP+ F0Gn4liN6Zc5OEfijircvPcEFQJ+iyokEdc4fc48kZlIUiOuZbhXcUs6tkOQwOVBfQw+ w1fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=g09HKa/zs2wpPBw2nzteRbxpa6wfdwnNnms7vzr7BbM=; b=JT6yeGJCv3z+J4X6DRCtTBIDXOxB5GJcb+uTLfvxBTKvpCjbtbwqVrbsd11o0AxumO w2UO6GCLhiH1WXrMplF+pnHKINXXQ3//QYhQTbQYk2V9bP/Y6mdMiWRvlF/EkGHD5dwn IhxIxpMDEXPrjHAR/zN1SXJxHxtXGNzyp+3pNpgTuvWgKxY93yR7FG8lOcA2Iv+RYRWO DG3fd3jcU3zqjVOu2Vir5jmY3J7LE7YIR4/qBBt7p2dUi/fdt0qit2THa07W6qKOq4rV c5xSWcpVP+nsaG99dU/E2gFdQpG3muMGbJj4/qdsUiIp/QDYceqMchubfoM60vaFhFas xSWw== MIME-Version: 1.0 Received: by 10.180.74.108 with SMTP id s12mr4559954wiv.12.1355417655476; Thu, 13 Dec 2012 08:54:15 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 08:54:15 -0800 (PST) In-Reply-To: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 08:54:15 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043c81e6e0807e04d0bec369 X-Gm-Message-State: ALoCoQn3SLWZAv5GIJKal86EdLtEOlB7z7VUjBBChWTbHqWByoBjZGR9vKmVnpV/utpJyF5Xt+j+q9X3r7TpKiuQnbWC5KVGroS1TC74hJwuBL1yBRpZwi0uIs5ChDgi9oY36RGxHglOwZWbnUKfolGxcKEVj/Bx53eCoFvrVVlG6D4XL5eBVaML9NHXHFyLy4SW73ay2Vk7 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:54:18 -0000 --f46d043c81e6e0807e04d0bec369 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wrote= : > Don=E2=80=99t put it on the wire. You want the server to filter before s= ending a > reply. > I'm concerned you're still confused about how a downgrade attack works. Again: it DOES NOT MATTER what the server thinks it's filtering if the client has been tricked into talking to a DIFFERENT SERVER which is then returning malicious results. Such as: -- client wants "all links" for foo@example.com. -- client requests secure https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com -- EVIL HIJACKER BLOCKS PORT 443 -- client then requests plain http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "https://attacker.openid.server/" }, See what happened there? We need the *client* to say "whoa whoa, wait a minute... I contacted this webfinger server over HTTP---- what's it doing returning rels starting with https:? I'm gonna skip over those (or just return an error)." The real webfinger server _was never even contacted_, so it doesn't matter whether it was filtering or not. --f46d043c81e6e0807e04d0bec369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Don=E2=80=99t put it on the wire.=C2=A0 You want the server= to filter before sending a reply.


I'm concerned you're s= till confused about how a downgrade attack works.

= Again: it DOES NOT MATTER what the server thinks it's filtering if the = client has been tricked into talking to a DIFFERENT SERVER which is then re= turning malicious results.

Such as:

=
-- EVIL HIJACKER BLOCKS PORT 443
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WAN= T:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : "https://openid.net/connect/server"= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type" : "text= /html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"href&= quot; : "https://attacker.= openid.server/"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

See what happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this webfinge= r server over HTTP---- what's it doing returning rels starting with htt= ps:? I'm gonna skip over those (or just return an error)."

The real webfinger server _was never even contacted_, s= o it doesn't matter whether it was filtering or not.

--f46d043c81e6e0807e04d0bec369-- From bradfitz@google.com Thu Dec 13 09:01:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0321F8B97 for ; Thu, 13 Dec 2012 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyZoUtmixY-j for ; Thu, 13 Dec 2012 09:00:44 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E753221F8B7C for ; Thu, 13 Dec 2012 09:00:30 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so4412423wib.1 for ; Thu, 13 Dec 2012 09:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u89RZJM8POEc2huOaiZ2+w8Xe3JrmhJgl2desjeuxhE=; b=jqx1G/w3ffC6GJoddTuNShw9/bmnVcv1KQn7VgkhRorAQPd4OmFaiRtYa1wqq8F2nx yn/F0fU91WxM+1mzO/sYCpNXUZnvprd5xgA440axk82TETYnB1Jb80I2dL35dCrv3UQV UaON91CqF8BXG1Gn0Y+kuhkSMJTNyzuYVyd+C+YoclvLAr000/O1Bk7rU90dkWnn47QY ZSbttu3uQ3PnyHxEACjFhu6HLuNShjMGGCWozFCSjpb/trnYzCaGQGjHPOFEu0N5g/xk b8nuLgQ7k7nmlSsgxdKbeXsGlCwJNZmy+dJsZUya7/zhzeI7LwbDOLk7ojyA/yx964eU Je9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=u89RZJM8POEc2huOaiZ2+w8Xe3JrmhJgl2desjeuxhE=; b=cFTGBOr0g8xvw3FDaDD2eR2FNvmTWe9IpKv7hAoSft4rV5wANX6Xrh6zApu6yguww3 nvajjcopKIjRsgLpp2tIwZQfNVCddkoD9GqgwQK7hNMn09OxOM2ufNSg1eLLyryGp7Uy vlYHzkchmMNqeL+v52eNpnB+YbLbmt+m5AatRuY5vHIEL+jWIMjLc5XeIQ/jMNQAC18i N0vOFd+0/sAldf0cnwhf/HV8RRtJ0RXaT+e49ouysvXDmBaWzO0OZZKxSyKYlzBJAdNq 3vRtbLznqBlpjyTh/iFJm86MGbKob9SQ/hdRLYjnpovYCHXwqYHqMxDdEEu27WmvTitR MWBA== MIME-Version: 1.0 Received: by 10.180.107.197 with SMTP id he5mr4634060wib.1.1355418024738; Thu, 13 Dec 2012 09:00:24 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 09:00:24 -0800 (PST) In-Reply-To: <059101cdd950$a4e64d60$eeb2e820$@packetizer.com> References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> <059101cdd950$a4e64d60$eeb2e820$@packetizer.com> Date: Thu, 13 Dec 2012 09:00:24 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f13eaf8e3007804d0bed9ad X-Gm-Message-State: ALoCoQlhNufl3UvuUJ/sJ9HWlmugPioZWeDt49iUq62AyzFrFYUeYJbv2q17XQKU1rNP2B5a/3KIIq1Lyc8vzA9+Q6xZy/HJpRe3A5KBzwmitKr0lIJomYysZdlvLiPTN3YVnilqvIkZL0mwVUdQglDargPSZL+uSWp/iPOLq5nHaGn7/kneBcQrbt/rrJiI7jXB0WUQizHx Cc: Cyrus Daboo , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:01:10 -0000 --e89a8f13eaf8e3007804d0bed9ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:41 AM, Paul E. Jones wrote= : > Brad,**** > > ** ** > > My assumption is that if one runs an HTTPS server, he or she will either > respond to either HTTP or HTTPS requests, or redirect HTTP requests to th= e > HTTP server. > Rather than assuming, it should be specified as required for servers, but I don't think we should do that. So the only scenario that I think is broken is when an HTTPS client issues > a request to an HTTP-only server.**** > > ** ** > > In any case, you=E2=80=99re right that there is at least one broken scena= rio and > the only solution is to push that to the client or let it fail. We tried > suggesting use both and people rejected that due to complexity. > And I think we're compromising on client complexity. Client simplicity was a nice bonus effect with HTTPS-only, but the big win was security. If we're going to allow HTTP, we at least still need security (my "https:"-prefix secure rel proposal). We can't also get client simplicity with HTTPS-and-HTTP. > The new text recommends use of HTTPS, but HTTP is there because some > wanted to use that. I would expect the =E2=80=9Cgeneral purpose=E2=80=9D= WF client to use > HTTPS. But, perhaps =E2=80=9Cspecialized=E2=80=9D clients would use HTTP= only? > Seems like that'd be a wart in the spec that nobody knew the definition of and never worked in practice. I'm all about making people happy, but I don't want to put words in a spec that pacify certain people, but don't actually work in the wild for them. It reads like "If you're, um, 'specialized', use HTTP? Maybe it'll work sometimes, in your own little environment, but not with anybody else." > **** > > ** ** > > Anyway, yes=E2=80=A6 this could present issues for some, but primarily fo= r those > clients that are HTTPS only.**** > > ** ** > > Paul**** > > ** ** > > *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] > *Sent:* Thursday, December 13, 2012 10:55 AM > *To:* Paul E. Jones > *Cc:* Cyrus Daboo; Salvatore Loreto; webfinger@ietf.org > *Subject:* Re: [webfinger] a compromise proposal about HTTPS only vs > HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP)**** > > ** ** > > On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones > wrote:**** > > This language was necessary when we had the "fall back" logic. Now the > proposed text recommends that a client use either HTTP or HTTPS, not both= . > **** > > ** ** > > I've yet to understand how this is not going to be totally broken: you're > saying that both the server and the client get to pick HTTP or HTTPS? Th= at > seems like the most broken thing ever:**** > > ** ** > > HTTPS server & HTTPS client: ok**** > > HTTPS server & HTTP client: FAIL**** > > HTTP server & HTTPS client: FAIL**** > > HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the > server was also running on HTTPS, but the client just got unlucky in whic= h > it picked.**** > > ** ** > > That proposal looks like mostly fail.**** > > ** ** > > If people on this list want to run HTTP servers (which many apparently > do), then we're going to need to push complexity to clients. It's > unfortunate, but it's not going to work otherwise.**** > > ** ** > > Or what am I missing?**** > > ** ** > --e89a8f13eaf8e3007804d0bed9ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 8:41 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Brad,

=C2=A0

My assumption is th= at if one runs an HTTPS server, he or she will either respond to either HTT= P or HTTPS requests, or redirect HTTP requests to the HTTP server.=C2=A0


Rather than assuming, it shoul= d be specified as required for servers, but I don't think we should do = that.

So the only scenario that I think is broken= is when an HTTPS client issues a request to an HTTP-only server.=

=C2=A0

In any case, you=E2= =80=99re right that there is at least one broken scenario and the only solu= tion is to push that to the client or let it fail.=C2=A0 We tried suggestin= g use both and people rejected that due to complexity.


And I think we're compromi= sing on client complexity. =C2=A0Client simplicity was a nice bonus effect = with HTTPS-only, but the big win was security.

If = we're going to allow HTTP, we at least still need security (my "ht= tps:"-prefix secure rel proposal). =C2=A0We can't also get client = simplicity with HTTPS-and-HTTP.

=C2=A0

=C2=A0 The new text recommends use of HTTPS, but HTTP is= there because some wanted to use that.=C2=A0 I would expect the =E2=80=9Cg= eneral purpose=E2=80=9D WF client to use HTTPS. =C2=A0But, perhaps =E2=80= =9Cspecialized=E2=80=9D clients would use HTTP only?


Seems like that'd be a war= t in the spec that nobody knew the definition of and never worked in practi= ce. =C2=A0I'm all about making people happy, but I don't want to pu= t words in a spec that pacify certain people, but don't actually work i= n the wild for them.

It reads like "If you're, um, 'specialized= ', use HTTP? Maybe it'll work sometimes, in your own little environ= ment, but not with anybody else."

=C2=A0

=C2=A0

Anyway, yes=E2=80= =A6 this could present issues for some, but primarily for those clients tha= t are HTTPS only.

=C2=A0

Paul<= /span>

=C2=A0

=C2=A0<= /u>

On Thu, Dec 13, 2012 at 7:47 = AM, Paul E. Jones <paulej@packetizer.com> wrote:

This language was necessary when we had the "fall back= " logic. =C2=A0Now the
proposed text recommends that a client use either HTTP or HTTPS, not both.<= u>

=C2=A0

I've yet to understand how= this is not going to be totally broken: you're saying that both the se= rver and the client get to pick HTTP or HTTPS? =C2=A0That seems like the mo= st broken thing ever:

=C2=A0

HTTPS server & HTTPS client: ok=

HTTPS server & HTTP client: FAI= L

HTTP= server & HTTPS client: FAIL

HTTP server & HTTP client:= ok, but=C2=A0susceptible=C2=A0to MITM, and maybe the server was also runni= ng on HTTPS, but the client just got unlucky in which it picked.<= /u>

=C2=A0

That proposal looks like most= ly fail.

=C2=A0

If people on this list want t= o run HTTP servers (which many apparently do), then we're going to need= to push complexity to clients. It's unfortunate, but it's not goin= g to work otherwise.

=C2=A0

Or what am I missing?<= u>

=C2=A0


--e89a8f13eaf8e3007804d0bed9ad-- From jpanzer@google.com Thu Dec 13 09:18:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3868B21F8BA7 for ; Thu, 13 Dec 2012 09:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW8oQqprt+HE for ; Thu, 13 Dec 2012 09:18:41 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B023B21F8B9F for ; Thu, 13 Dec 2012 09:18:40 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1967681lah.31 for ; Thu, 13 Dec 2012 09:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C1BYumMyDn3S31SNEITRjP1DLYa77S8Gxx3mL5eI7go=; b=EvmqWgWCbpxxipbXiT4kg+22p0eBGiq2x111OBQ6YghgtfZJlh9SRgn4QxPIME29BJ IILw4JcICm2/Mq2arrjMpX5hk6Cz3fflxi+XtwfbsJlDsV5LE1fuMXEYOxMtrLH2n+lt EzORrCB0oNTmLtnbvvVJdUToNa26qSKimqnwIxwh2FMWpkqIfRZfacNsEfdhTHUebqum QMmzHQdD6pNieljtRXGda6yhWIsdfnuwmPQUrdE8cJ2Z/FIguZsgbkHCLpULEEFMLpdV 8HQbQdHyMAO6esWkSZtEr8LbbaLh0sw3N2Ke5Du4yhWaFgu1Hobaj60VMX4RNcMSfzDT 7NGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=C1BYumMyDn3S31SNEITRjP1DLYa77S8Gxx3mL5eI7go=; b=FVPNzbp8JOsD57vjKED+AjteVSi7E86YjwViU4LRBqXeob6n7FheKhItXy1/49IsjH wD8wpwdUnzkt7O39hz+I0ipyvJ2+qS7qDSW9JYpwbfIr9VBfW1sxpa2fHGp4RNR1zRWN 1QSv5k5zJUuszeQ2Tu4iddaNTbVvJOEMCBpY5yDIdij/Odd1omwElUh7qNsC/XnFH+NZ G0ynmVii7RQHpZdCrRH1deOYR5NCu0H1ZdMvfCbRwKcsSLPnzm3K/tjPhuUGEZHbOOZa MYG9ih2pD/OgNVZI9B5GFRFnAbZWtG2k883o3MABRXdo7eD3fvg5dI4B9pzdHx5aDX5J PjLw== Received: by 10.152.132.137 with SMTP id ou9mr45965lab.7.1355419119616; Thu, 13 Dec 2012 09:18:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.5.3 with HTTP; Thu, 13 Dec 2012 09:18:19 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> From: John Panzer Date: Thu, 13 Dec 2012 09:18:19 -0800 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d042c6aed25843404d0bf1b56 X-Gm-Message-State: ALoCoQkkRpPNzwfTLtOOvlca0wm0sP6raGVJpviCLWxZv6SEHidqVlL79cowjqzPx5hvw7Fl5rMy/O8vurPbJrDhK9sG9XkSA9pw23sqB5XXvZYL+S4s79zJTXmR5s++J2j8tvFwSYl8gXPS+ZMYvtjkcV7GPzhoa5LWLLAwMu3c0+2UHcbghXgzduKYPo/FniO7ZD1sWL+7 Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:18:42 -0000 --f46d042c6aed25843404d0bf1b56 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right. This is also why you need this attribute as part of the official "name" of the link relation, so the client knows which ones are supposed to be secure with a simple .startsWith("https") type of check. Anything more complicated will create more security issues. (A registry of relations which tells you which link relations are secure-only might work but only if it could be kept up to date on all clients...) I still don't understand what the client will do with rel=3D"canonical" though. Does WebFinger exclude registered rel-values? They don't have to be URIs. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick wrot= e: > On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wro= te: > >> Don=92t put it on the wire. You want the server to filter before sendin= g a >> reply. >> > > I'm concerned you're still confused about how a downgrade attack works. > > Again: it DOES NOT MATTER what the server thinks it's filtering if the > client has been tricked into talking to a DIFFERENT SERVER which is then > returning malicious results. > > Such as: > > -- client wants "all links" for foo@example.com. > -- client requests secure > https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com > -- EVIL HIJACKER BLOCKS PORT 443 > -- client then requests plain > http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com > -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: > > { > "rel" : "https://openid.net/connect/server", > "type" : "text/html", > "href" : "https://attacker.openid.server/" > }, > > See what happened there? > > We need the *client* to say "whoa whoa, wait a minute... I contacted this > webfinger server over HTTP---- what's it doing returning rels starting wi= th > https:? I'm gonna skip over those (or just return an error)." > > The real webfinger server _was never even contacted_, so it doesn't matte= r > whether it was filtering or not. > > --f46d042c6aed25843404d0bf1b56 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Right.= =A0This is also why you need this attribute as part of the official "= name" of the link relation, so the client knows which ones are suppose= d to be secure with a simple .startsWith("https") type of check. = =A0Anything more complicated will create more security issues. =A0(A regist= ry of relations which tells you which link relations are secure-only might = work but only if it could be kept up to date on all clients...)

I still don't understand what the client will do with re= l=3D"canonical" though. =A0Does WebFinger exclude registered rel-= values? =A0They don't have to be URIs.
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Thu, Dec 13, 2012 at 8:54 AM, Brad Fi= tzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones <paulej@pac= ketizer.com> wrote:

Don=92t put it on the wire.=A0 You want the serv= er to filter before sending a reply.


I'm concerned you= 9;re still confused about how a downgrade attack works.

Again: it DOES NOT MATTER what the server thinks it's filtering i= f the client has been tricked into talking to a DIFFERENT SERVER which is t= hen returning malicious results.

Such as:

-- client wants "all li= nks" for foo@exam= ple.com.
-- EVIL HIJACKER BLOCKS PORT 443
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WAN= T:

=A0 =A0 =A0 =A0 =A0{
= =A0 =A0 =A0 =A0 =A0 =A0"rel" : "https://openid.net/connect/server&q= uot;,
=A0 =A0 =A0 =A0 =A0 =A0"type" : "text/html",
=
=A0 =A0 =A0 =A0 =A0 =A0"href" : "https://attacker.openid.serve= r/"
=A0 =A0 =A0 =A0 =A0},

See what happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this webfinge= r server over HTTP---- what's it doing returning rels starting with htt= ps:? I'm gonna skip over those (or just return an error)."

The real webfinger server _was never even contacted_, s= o it doesn't matter whether it was filtering or not.


--f46d042c6aed25843404d0bf1b56-- From laurentwalter.goix@telecomitalia.it Thu Dec 13 09:22:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD521F8BD8 for ; Thu, 13 Dec 2012 09:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGW14OU1j+vr for ; Thu, 13 Dec 2012 09:21:58 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0106521F8BD7 for ; Thu, 13 Dec 2012 09:21:57 -0800 (PST) Content-Type: multipart/mixed; boundary="_81bf0b48-aa25-4d71-b77f-a66b82055e41_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 13 Dec 2012 18:21:53 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 13 Dec 2012 18:21:53 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 13 Dec 2012 18:21:51 +0100 Thread-Topic: [webfinger] secure links with https rels Thread-Index: Ac3ZVeYsog7XSdazQwe4h59/DXHX1wAADjlw Message-ID: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: [webfinger] R: secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:22:01 -0000 --_81bf0b48-aa25-4d71-b77f-a66b82055e41_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA8725GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA8725GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed =AB href =BB should be checked instead of =AB rel =BB in order to su= pport registered values as well. Plus some link rels may not be http (think= at acct:, sip:, ws:, ecc). So the client may need to check as well for sip= s:, wss:, accts:? Although I can understand the issue I'm starting to get confused as well... Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] Per cont= o di John Panzer Inviato: gioved=EC 13 dicembre 2012 18.18 A: webfinger@googlegroups.com Cc: Paul E. Jones; webfinger@ietf.org Oggetto: Re: [webfinger] secure links with https rels Right. This is also why you need this attribute as part of the official "n= ame" of the link relation, so the client knows which ones are supposed to b= e secure with a simple .startsWith("https") type of check. Anything more c= omplicated will create more security issues. (A registry of relations whic= h tells you which link relations are secure-only might work but only if it = could be kept up to date on all clients...) I still don't understand what the client will do with rel=3D"canonical" tho= ugh. Does WebFinger exclude registered rel-values? They don't have to be = URIs. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick > wrote: On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones > wrote: Don't put it on the wire. You want the server to filter before sending a r= eply. I'm concerned you're still confused about how a downgrade attack works. Again: it DOES NOT MATTER what the server thinks it's filtering if the clie= nt has been tricked into talking to a DIFFERENT SERVER which is then return= ing malicious results. Such as: -- client wants "all links" for foo@example.com. -- client requests secure https://example.com/.well-known/webfinger?resourc= e=3Dacct:foo@example.com -- EVIL HIJACKER BLOCKS PORT 443 -- client then requests plain http://example.com/.well-known/webfinger?reso= urce=3Dacct:foo@example.com -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "https://attacker.openid.server/" }, See what happened there? We need the *client* to say "whoa whoa, wait a minute... I contacted this w= ebfinger server over HTTP---- what's it doing returning rels starting with = https:? I'm gonna skip over those (or just return an error)." The real webfinger server _was never even contacted_, so it doesn't matter = whether it was filtering or not. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA8725GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Indeed =AB href =BB should be checked instead of = =AB rel =BB in order to support registered values as well. Plus s= ome link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sip= s:, wss:, accts:?

Although I can understand the issue I’m starting to ge= t confused as well…

 

Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups= .com] Per conto di John Panzer
Inviato: gioved=EC 13 dicembre 2012 18.18
A: webfinger@googlegroups.com
Cc: Paul E. Jones; webfinger@ietf.org
Oggetto: Re: [webfinger] secure links with https rels

 

Right.  This is also why you need th= is attribute as part of the official "name" of the link relation,= so the client knows which ones are supposed to be secure with a simple .startsWith("https") type of check.  Anything more complica= ted will create more security issues.  (A registry of relations which = tells you which link relations are secure-only might work but only if it co= uld be kept up to date on all clients...)

 

I still don't understand what the client = will do with rel=3D"canonical" though.  Does WebFinger exclu= de registered rel-values?  They don't have to be URIs.

--
John Panzer / Google
jpanzer@google.com<= /a> / abstractioneer.org / @jpanzer



On Thu, Dec 13, 2012 at 8:54 AM, Brad Fit= zpatrick <bradf= itz@google.com> wrote:

On Thu, Dec 13, 2012 at 8:45 AM, Paul E. = Jones <paulej= @packetizer.com> wrote:

Don’t put it on the wire.  You want the server to= filter before sending a reply.

 

I'm concerned you're still confused about= how a downgrade attack works.

 

Again: it DOES NOT MATTER what the server= thinks it's filtering if the client has been tricked into talking to a DIF= FERENT SERVER which is then returning malicious results.<= /p>

 

Such as:

-- client wants "all links" for foo@example.com.

-- EVIL HIJACKER BLOCKS PORT 443

-- EVIL HIJACKER MITM= s that HTTP request and RETURNS WHATEVER THEY WANT:

           = "href" : "https://attacker.openid.server/"

         },=

 

See what happened the= re?

We need the *client* to say "whoa wh= oa, wait a minute... I contacted this webfinger server over HTTP---- what's= it doing returning rels starting with https:? I'm gonna skip over those (or just return an error)."

 

The real webfinger server _was never even= contacted_, so it doesn't matter whether it was filtering or not.

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA8725GRFMBX704BA02_-- --_81bf0b48-aa25-4d71-b77f-a66b82055e41_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_81bf0b48-aa25-4d71-b77f-a66b82055e41_-- From bradfitz@google.com Thu Dec 13 09:28:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1262821F8694 for ; Thu, 13 Dec 2012 09:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlI-sNyzaOe7 for ; Thu, 13 Dec 2012 09:28:10 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6421F860D for ; Thu, 13 Dec 2012 09:28:10 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1090444wey.31 for ; Thu, 13 Dec 2012 09:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ld5iwJECFHIIqQ3TO3ToCIyb/nEZV8B5PNFDr4cgVAw=; b=PkWYR0QGsicgzuJ+7oqP045eujUmMXfxLzmRPM+CRDTfp8yXL9FqTO4zp5ov3Tjr41 8LxvOxbvSw1vq105zmNAsPZpFaznrnM4mJwJzBFCPvm97Fa3/isgBeHm04i8ALmMBDHx sncVfXhH+EVtq5kQ198saCRKEEn4Ty2PQ6zBbuyS4tHTJwk4drl/g1znb3CNoqh5V4ct OkVuJG/m2incM2iXjsutLj+ATVoDRbJOXpob+JfOKGl9+u+IBCl+CAfAMEwiupjnl7f0 u+YKZGFjO5mNXXel61//Bjh7yUpmqXXvStGw+EIfkhs+j1GYwKASu2FIiHgnaqyL1gbB TZ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Ld5iwJECFHIIqQ3TO3ToCIyb/nEZV8B5PNFDr4cgVAw=; b=N8Ij+pHTcOun0nK5b3lBc6fBUrhu3GI2MdDMmQmigrmxnh7wqssZfx2BwoTM8Jhx2C OSGXjFNaYeFJMrix5G+EdtJomTRordKsktYxSrtBfzxpdI4++cO2ub+bSutg6oiuLIRy PxJYed9+n4UzhVFx/PrFCSwv8XaY7EHjeUSl0ku1crEmLxHSdaMEEHhr1J3uuJfy0LiU tWrkJOVHhbnvgTOg+nAY4xnuB1h9iYfaInR5256NmU9x2uPDYXBURWSlb8w44Otj/29A WJ2wijuEehjk1+h8onbrp0zPElyQCazoAhG0K4+Of83AbFSMKp1EXcPViK0KtEhG/OK1 IZhQ== MIME-Version: 1.0 Received: by 10.180.90.106 with SMTP id bv10mr4751692wib.12.1355419689206; Thu, 13 Dec 2012 09:28:09 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 09:28:09 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 09:28:09 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d043c81e818c1a604d0bf3d78 X-Gm-Message-State: ALoCoQkyaf/5W4EqUfgj3mMiNtyzAEeKhAYnZTuNiubu7kkAr7z41I6sJFhSov5qt4N+j/iCwBVTILRDSAV53gTiyLrTA75voKNEKUzCHO2XPW7wPlWKZ/pOkFgUqt0bzpGnHyp1dHKi/NUpuDU2hx9c2PvdxUQ40wDXVe2Ygppx0UJELgizxMy6ReIYRtQ/ygj9fN2DEe8w Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:28:11 -0000 --f46d043c81e818c1a604d0bf3d78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Indeed =C2=AB href =C2=BB should be checked instead of =C2=AB rel =C2=BB= in order to support > registered values as well. Plus some link rels may not be http (think at > acct:, sip:, ws:, ecc). So the client may need to check as well for sips:= , > wss:, accts:? **** > > Although I can understand the issue I=E2=80=99m starting to get confused = as well=E2=80=A6 > No, the key (the link.rel) is what is secure, not the value (the link.href)= . So all of acct:, sip:, ws:, data:, etc can be used as as the value, since that's not the part that is checked for an "https:" prefix. --f46d043c81e818c1a604d0bf3d78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <<= a href=3D"mailto:laurentwalter.goix@telecomitalia.it" target=3D"_blank">lau= rentwalter.goix@telecomitalia.it> wrote:

Indeed =C2= =AB=C2=A0href=C2=A0=C2=BB should be checked instead of =C2=AB=C2=A0rel=C2= =A0=C2=BB in order to support registered values as well. Plus some link rel= s may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sip= s:, wss:, accts:?

Although I= can understand the issue I=E2=80=99m starting to get confused as well=E2= =80=A6


No, the key (the link.rel) is what i= s secure, not the value (the link.href).

So all of= acct:, sip:, ws:, data:, etc can be used as as the value, since that's= not the part that is checked for an "https:" prefix.

--f46d043c81e818c1a604d0bf3d78-- From jasnell@gmail.com Thu Dec 13 10:10:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F16021F8B0E for ; Thu, 13 Dec 2012 10:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THGXAZ2QJ1+Q for ; Thu, 13 Dec 2012 10:10:32 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5364F21F8A99 for ; Thu, 13 Dec 2012 10:10:32 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e13so4462904iej.32 for ; Thu, 13 Dec 2012 10:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XoR020zHfS9YV4eynfB9l0ZHWlGQ+5UqPQrthS2FViE=; b=Vz4J/l8ztl0aT3iRnDZEbsYJP/KU3U+vyWOuA9dJn5qtTdz+XRlwovIf1HddSl2HuW vZly7Uwqd9PkIuqL8jaHWxtydqRlG7AQFapITT3tH4/BQiGsLtG6EchSsVS8huFka3im Ddl45gW/G5NtlGVCW0PNJbQLdIbVQMEf6GEN3Z6NDsXZaQG9pAd28RfTXb84fgu0JBO1 joxapuz4yr5iaMjFvEY0xFLS8pQq/hyTAvymHDGT2dFkmc53+z/uNzHJWqNfYpcgdcbB VUzH1OlyTQ6Av49Y+efGoCNMWITNGyQGQ21vyXKD/apV8e1H9Dqrii2cqiA6OompOgVQ ir1g== Received: by 10.50.178.106 with SMTP id cx10mr17962536igc.24.1355422231786; Thu, 13 Dec 2012 10:10:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:10:10 -0800 (PST) In-Reply-To: <04c101cdd905$dc3c0fc0$94b42f40$@packetizer.com> References: <04c101cdd905$dc3c0fc0$94b42f40$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 10:10:10 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f5036c8a576bf04d0bfd4c3 Cc: webfinger@ietf.org Subject: Re: [webfinger] Fwd: Outstanding WF Security Concerns X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:10:35 -0000 --e89a8f5036c8a576bf04d0bfd4c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 11:45 PM, Paul E. Jones wrot= e: > James,**** > > ** ** > > 1. =E2=80=9CPotential Mixed-session hijack vulnerability=E2=80=9D =E2=80= =93 WebFinger does not > define a =E2=80=9Csession=E2=80=9D. The client requests a document and g= et a reply. > That=E2=80=99s it. We must allow non-HTTPS URIs in the document, because = lots of > people store lots of things in places that do not need to be secure. > Security requirements related to these other resources is really outside > the scope of WF. WF just tells a client where the information can be fou= nd. > **** > > ** > Suggested text for the Security Considerations: ---START TEXT--- While this specification does not define any notion of a persistent "session" and does not directly require the use of client or server authentication, it is expected that the WebFinger protocol will be used within applications that do require persistent authentication and access to secure resources. In such cases, WebFinger implementations that use non-secured HTTP cookies as a means of exchanging authenticated session identifiers are vulnerable to a variety of session hijacking and cross-site scripting attacks. Such attacks are not specific to the WebFinger protocol and are considered beyond the scope of this specification. That said, however, the threat can be mitigated by properly securing cookies as defined in [RFC6265] Sections 5.2.5 and 5.2.6. ---END TEXT--- Note that this vulnerability only exists under the following conditions: 1. Access to the WebFinger document requires authentication or results in the creation of a "session" on the server. 2. Cookies are used to return the session identifier to the client 3. The Cookies are not properly secured with HttpOnly/Secure flags 4. The WebFinger document contains insecure links to the *same domain* as the WebFinger servic. Insecure links to other domains contained within the document are not affected. Obviously, this is not a risk that is specific to WebFinger, but it needs to be acknowledged as something that was considered and explicitly ruled out of scope per BCP 72, Section 5. (http://tools.ietf.org/html/bcp72) > ** > > 2. =E2=80=9C3xx Redirects to insecure targets=E2=80=9D - I think the lan= guage in the new > proposal will address this.**** > > ** > Based on what I've been able to follow so far, I think you're right. Good to see this one being addressed. > ** > > 3. This can occur with any protocol and there=E2=80=99s not a thing we ca= n do. A > query might go to the right server and even the server itself is > compromised and serving up bogus information. The best we can do is > recommend HTTPS and even then there are no guarantees. We could disallow > redirects, but that seems harsh. I would personally like to use a redire= ct > from HTTP to HTTPS, just as a means of forcing queries to use HTTPS. **** > > ** > There is something we can do... Per BCP72 Section 5 it needs to be mentioned as a potential vulnerability so implementers are properly aware... The current final paragraph in the Security Considerations gets us most of the way there but something also needs to be said about the risks involved in entrusting non-verified third parties to provide WebFinger data. Also, it must be indicated that dealing with such issues is explicitly out of the scope of the WebFinger specification. > ** > > 4. What is an =E2=80=9Can unauthorized WebFinger request=E2=80=9D? If a = query is sent to > a server for resource/subject for which the server knows nothing about, i= t > returns a 404. If a client is truly not authorized, as in a client must > provide credentials to even query the WF server, then a 401 (or 403) woul= d > be sent. This would be standard HTTP behavior, not WF-specific behavior. > Is that what you=E2=80=99re getting at?**** > > ** > What I'm saying is that a particular user might not be authorized to use a particular WebFinger server. For such users, I do not want them being able to find out ANY information about any of that servers resources. For instance, suppose we have a spammer who wishes to target a particular organization. His first step is to generate a database of potential target email addresses. The second step is to weed out all of the accounts that are invalid. If the WebFinger server returns a 404 for all invalid accounts; but a 401 for valid accounts that require authentication, the attacker will have learned some very important information about the target organization, making their job significantly easier in the end. In order to keep from making the attackers job any easier, a WebFinger server that requires authentication ought to return 404 for ALL non-authenticated requests, even if the target resource is known to the server (see BCP72 4.6.3.1, "Make your attacker do more work than you do"). Again, yes, this is not a problem that is specific to WebFinger, but given the core use cases that WebFinger is intended to address it needs to be discussed. - James > ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *James M Snell > *Sent:* Wednesday, December 12, 2012 1:04 PM > *To:* webfinger@ietf.org > *Subject:* [webfinger] Fwd: Outstanding WF Security Concerns**** > > ** ** > > I had sent this before but I believe it went out before many people had > moved over to the new list. Item #1 has already been discussed but still > needs to be addressed in the draft. The other issues, as far as I can tel= l, > have not yet been dealt with.**** > > ---------- Forwarded message ---------- > From: *James M Snell* > Date: Tue, Dec 4, 2012 at 1:48 PM > Subject: Outstanding WF Security Concerns > To: webfinger@ietf.org > > > In the current draft -07 spec there are a handful of fairly important > security issues that have yet to be dealt with. I summarized these in a > separate note to Paul and the other authors while waiting for this new li= st > to be set up and wanted to call them out here for discussion as well. ***= * > > ** ** > > 1. Potential Mixed-session hijack vulnerability**** > > ** ** > > When accessing an authenticated WebFinger service via HTTPS,**** > > there is a potential session-hijacking vulnerability if the **** > > returned JRD contains non-HTTPS URLs to the same domain as **** > > the WebFinger server and session cookies are not properly **** > > secured. As a best practice, if the JRD is served over a **** > > HTTPS connection, any links to the same domain contained **** > > within the JRD SHOULD also use HTTPS and server implementations**** > > need to make sure that all session cookies are properly **** > > secured against hijacking. (This issue is no different than **** > > your typical mixed-session vulnerability)**** > > ** ** > > 2. 3xx Redirects to insecure targets**** > > ** ** > > WebFinger explicitly allows a WebFinger server to redirect **** > > requests to a separate third party service provider. It **** > > does not, however, require the use of HTTPS with the redirected**** > > target. **** > > ** ** > > For example, imagine sending a GET request to:**** > > ** ** > > https://example.org/.well-known/webfinger?r...**** > > ** ** > > And getting back...**** > > ** ** > > HTTP/1.1 302 Found**** > > Location: http://example.net/wf?r=3D...**** > > ** ** > > The redirected request will no longer be protected, negating **** > > the point of using HTTPS in the first request and putting the**** > > client at risk. **** > > ** ** > > Redirects returned by the server for requests issued over HTTPS**** > > ought to be required to point to HTTPS secured URLs... e.g.**** > > ** ** > > HTTP/1.1 302 Found**** > > Location: https://example.net/wf?r=3D...**** > > ** ** > > 3. Also with regards to third party redirects, how is the client **** > > able to determine that the redirection was appropriately **** > > authorized by the original WF provider? If the server (or **** > > vulnerable intermediary) has been compromised, a client can be **** > > tricked into redirecting to a malicious server providing false **** > > information. If, for instance, a fake Identity Provider URL is **** > > provided, the client may not be capable of detecting the intrusion. **= * > * > > Use of HTTPS will not prevent such attacks. One reliable **** > > solution is to require the use of cryptographic integrity checks on **= * > * > > the JRD resource. That is, if Server A redirects to Server B, then ***= * > > the JRD provided by Server B needs to be signed by a key trusted by **= * > * > > both Server A and the client. However it is done, the client needs**** > > to be able to determine that Server B is authorized by Server A**** > > to provide WebFinger data on it's behalf... a redirect served over**** > > HTTPS does not, by itself, provide sufficient assurance.**** > > ** ** > > 4. When a client sends an unauthorized WebFinger request for a **** > > resource, a 404 Not Found response needs to be returned to make**** > > such responses indistinguishable from requests for resources the**** > > service has no information about.**** > > ** ** > > - James**** > > ** ** > --e89a8f5036c8a576bf04d0bfd4c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Wed, Dec 12, 2012 at 11:45 PM, Paul E= . Jones <paulej@packetizer.com> wrote:
James,

=C2=A0<= u>

1. =E2=80=9CPotential Mixed-session hijack vulnerabil= ity=E2=80=9D =E2=80=93 WebFinger does not define a =E2=80=9Csession=E2=80= =9D.=C2=A0 The client requests a document and get a reply.=C2=A0 That=E2=80= =99s it. We must allow non-HTTPS URIs in the document, because lots of peop= le store lots of things in places that do not need to be secure. =C2=A0Secu= rity requirements related to these other resources is really outside the sc= ope of WF.=C2=A0 WF just tells a client where the information can be found.=


<= /div>
Suggested text for the Security Considerations:

---START TEXT---
=C2=A0 While this specification does not de= fine any notion of a persistent "session" and does not directly r= equire the use of client or server authentication, it is expected that the = WebFinger protocol will be used within applications that do require persist= ent authentication and access to secure resources. In such cases, WebFinger= implementations that use non-secured HTTP cookies as a means of exchanging= authenticated session identifiers are vulnerable to a variety of session h= ijacking and cross-site scripting attacks. Such attacks are not specific to= the WebFinger protocol and are considered beyond the scope of this specifi= cation. That said, however, the threat can be mitigated by properly securin= g cookies as defined in [RFC6265] Sections 5.2.5 and 5.2.6.
---END TEXT---

Note that this vulnerability o= nly exists under the following conditions:

=C2=A01= . Access to the WebFinger document requires authentication or results in th= e creation of a "session" on the server.
=C2=A02. Cookies are used to return the session identifier to the clie= nt
=C2=A03. The Cookies are not properly secured with HttpOnly/Se= cure flags
=C2=A04. The WebFinger document contains insecure link= s to the *same domain* as the WebFinger servic. Insecure links to other dom= ains contained within the document are not affected.

Obviously, this is not a risk that is specific to WebFi= nger, but it needs to be acknowledged as something that was considered and = explicitly ruled out of scope per BCP 72, Section 5. (http://tools.ietf.org/html/bcp72)
=C2=A0

=C2=A0

2. =E2= =80=9C3xx Redirects to insecure targets=E2=80=9D - =C2=A0I think the langua= ge in the new proposal will address this.


<= /div>
Based on what I've been able to follow so far, I think you= 9;re right. Good to see this one being addressed.
=C2=A0

=C2=A0

3. This= can occur with any protocol and there=E2=80=99s not a thing we can do.=C2= =A0 A query might go to the right server and even the server itself is comp= romised and serving up bogus information.=C2=A0 The best we can do is recom= mend HTTPS and even then there are no guarantees.=C2=A0 We could disallow r= edirects, but that seems harsh.=C2=A0 I would personally like to use a redi= rect from HTTP to HTTPS, just as a means of forcing queries to use HTTPS. <= u>

=C2=A0


There is something we can do... Per BCP72 Section 5 it need= s to be mentioned as a potential vulnerability so implementers are properly= aware... The current final paragraph in the Security Considerations gets u= s most of the way there but something also needs to be said about the risks= involved in entrusting non-verified third parties to provide WebFinger dat= a. Also, it must be indicated that dealing with such issues is explicitly o= ut of the scope of the WebFinger specification.
=C2=A0

4. What = is an =E2=80=9Can unauthorized WebFinger request=E2=80=9D?=C2=A0 If a query= is sent to a server for resource/subject for which the server knows nothin= g about, it returns a 404.=C2=A0 If a client is truly not authorized, as in= a client must provide credentials to even query the WF server, then a 401 = (or 403) would be sent.=C2=A0 This would be standard HTTP behavior, not WF-= specific behavior.=C2=A0 Is that what you=E2=80=99re getting at?<= /u>

=C2=A0


What I'm saying is that a particular user might not be = authorized to use a particular WebFinger server. For such users, I do not w= ant them being able to find out ANY information about any of that servers r= esources. For instance, suppose we have a spammer who wishes to target a pa= rticular organization. His first step is to generate a database of potentia= l target email addresses. The second step is to weed out all of the account= s that are invalid. If the WebFinger server returns a 404 for all invalid a= ccounts; but a 401 for valid accounts that require authentication, the atta= cker will have learned some very important information about the target org= anization, making their job significantly easier in the end. In order to ke= ep from making the attackers job any easier, a WebFinger server that requir= es authentication ought to return 404 for ALL non-authenticated requests, e= ven if the target resource is known to the server (see BCP72 4.6.3.1, "= ;Make your attacker do more work than you do").

Again, yes, this is not a problem that is specific to W= ebFinger, but given the core use cases that WebFinger is intended to addres= s it needs to be discussed.

- James
=C2=A0

Paul

=C2=A0

From: webfinger-bounces@ietf.org = [mailto:web= finger-bounces@ietf.org] On Behalf Of James M Snell
Sent: Wednesday, December 12, 2012 1:04 PM
To: webfinger@ietf.org
S= ubject: [webfinger] Fwd: Outstanding WF Security Concerns=

=C2=A0

I had sent this before but I believe it went out before man= y people had moved over to the new list. Item #1 has already been discussed= but still needs to be addressed in the draft. The other issues, as far as = I can tell, have not yet been dealt with.

---------- Forwarded message ----------
From: Jame= s M Snell <ja= snell@gmail.com>
Date: Tue, Dec 4, 2012 at 1:48 PM
Subject: Ou= tstanding WF Security Concerns
To: webfinger@ietf.= org


In the= current draft -07 spec there are a handful of fairly important security is= sues that have yet to be dealt with. I summarized these in a separate note = to Paul and the other authors while waiting for this new list to be set up = and wanted to call them out here for discussion as well.=C2=A0

=C2=A0

1. Potential Mixed-session hijac= k vulnerability

=C2= =A0

= =C2=A0 =C2=A0When accessing an authenticated WebFinger service via HTTPS,

=C2=A0 =C2=A0there is a potential session-hijacking = vulnerability if the=C2=A0

= =C2=A0 =C2=A0returned JRD contains non-HTTPS URLs to the same domain as=C2= =A0

=C2=A0 =C2=A0the WebFinger server and session c= ookies are not properly=C2=A0

= =C2=A0 =C2=A0secured. As a best practice, if the JRD is served over a=C2=A0=

=C2=A0 =C2=A0HTTPS connection, any links to the sa= me domain contained=C2=A0

= =C2=A0 =C2=A0within the JRD SHOULD also use HTTPS and server implementation= s

=C2=A0 =C2=A0need to make sure that all session c= ookies are properly=C2=A0

= =C2=A0 =C2=A0secured against hijacking. (This issue is no different than=C2= =A0

=C2=A0 =C2=A0your typical mixed-session vulnera= bility)

=C2=A0

<= span style=3D"font-family:'Courier New'">2. 3xx Redirects to insecu= re targets

=C2=A0

=C2=A0= =C2=A0WebFinger explicitly allows a WebFinger server to redirect=C2=A0

=C2=A0 =C2=A0requests to a separate third party servic= e provider. It=C2=A0

= =C2=A0 =C2=A0does not, however, require the use of HTTPS with the redirecte= d

=C2=A0 =C2=A0target.=C2=A0

=C2=A0

<= span style=3D"font-family:'Courier New'">=C2=A0 =C2=A0For example, = imagine sending a GET request to:

=C2=A0

=C2=A0

<= span style=3D"font-family:'Courier New'">=C2=A0 =C2=A0And getting b= ack...

=C2=A0

=C2=A0 =C2=A0 =C2=A0HTTP/= 1.1 302 Found

=C2=A0 =C2=A0 =C2=A0Location: http://example.net/wf?r= =3D...

=C2=A0

<= span style=3D"font-family:'Courier New'">=C2=A0 =C2=A0The redirecte= d request will no longer be protected, negating=C2=A0<= /p>

=C2=A0 =C2=A0the point of= using HTTPS in the first request and putting the

<= /div>

= =C2=A0 =C2=A0client at risk.=C2=A0

=C2=A0

<= span style=3D"font-family:'Courier New'">=C2=A0 =C2=A0Redirects ret= urned by the server for requests issued over HTTPS

=

=C2=A0 =C2=A0ought to be = required to point to HTTPS secured URLs... e.g.

=C2=A0

=C2=A0 =C2=A0 =C2=A0HTTP/1.1 = 302 Found

= =C2=A0 =C2=A0 =C2=A0Location: https://example.net/wf?r=3D...

=C2=A0

= 3. Also with regards to third party redirects,=C2=A0how is the client=C2=A0

=C2=A0 =C2=A0able to determine that the redirection was appr= opriately=C2=A0

=C2=A0 =C2=A0authori= zed by the original WF provider? If the server (or=C2=A0

=C2=A0 =C2=A0vulnerable intermediary) has been compromised, = a client can be=C2=A0

=C2=A0 =C2=A0t= ricked into redirecting to a malicious server providing false=C2=A0<= u>

=C2=A0 =C2=A0information. If, for instance, a fake Identity = Provider URL is=C2=A0

=C2=A0 =C2=A0p= rovided, the client may not be capable of detecting the intrusion.=C2=A0

=C2=A0 =C2=A0Use of HTTPS will not prevent such attacks. One= reliable=C2=A0

=C2=A0 =C2=A0solutio= n is to require the use of cryptographic integrity checks on=C2=A0

=C2=A0 =C2=A0the JRD resource. That is, if Server A redirect= s to Server B, then=C2=A0

= =C2=A0 =C2= =A0the JRD provided by Server B needs to be signed by a key trusted by=C2= =A0

=C2=A0 =C2=A0both Server A and the client. However it is don= e, the client needs

=C2=A0 =C2=A0to = be able to determine that Server B is authorized by Server A<= u>

=C2=A0 =C2=A0to provide WebFinger data on it's behalf...= a redirect served over

=C2=A0 =C2= =A0HTTPS does not, by itself, provide sufficient assurance.

=C2=A0

<= span style=3D"font-size:10pt;font-family:'Courier New'">4. When a c= lient sends an unauthorized WebFinger request for a=C2=A0<= /u>

=C2=A0 =C2=A0resource, a 404 Not Found response needs to be return= ed to make

=C2=A0 =C2=A0such respons= es indistinguishable from requests for resources the

=C2=A0 =C2=A0service has no information about.=

= =C2=A0

- James

=C2=A0


--e89a8f5036c8a576bf04d0bfd4c3-- From nick@silverbucket.net Thu Dec 13 10:15:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5219421F8A99 for ; Thu, 13 Dec 2012 10:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwFyShRJ+Q-Q for ; Thu, 13 Dec 2012 10:15:34 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C92E621F89B6 for ; Thu, 13 Dec 2012 10:15:32 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2034640lbk.31 for ; Thu, 13 Dec 2012 10:15:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=prIOvSwM2u8x/RNJp0xp4NcSDP0yJrnmTNaNpVMsfPY=; b=M3LSnHhDqvUyYgYT6umlAMl1BhQXC/2w1k9jTL/nAsiuzogAvdwWFuJ58BYq4y8QPw 7wy+yglUV5JiFO5mIZPzc53a4vz7v92XwZ3qwRCgNpZPAjoPO5d7S8R/KT7z1mAPp1qX QUVVlXMTCUm4AaVbFNvsbeLqjR/gprZDNcQahv4kNmVhpJE9iZ1deHyonJN88XC7XYbL VYh99WgC2YjRDaLbqvKhYC8PAOX7zWTeBW7mmd2XMW35U6gqZmRMoreylI6SSneOSXdp IFa840zwo+tp6NMXIq4CwBJMM7RQSi48axES32RnjJlsobTlZQws4YrzhBO1pzlHIoKo sVgQ== Received: by 10.112.50.109 with SMTP id b13mr1298303lbo.8.1355422529834; Thu, 13 Dec 2012 10:15:29 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id sr6sm960723lab.4.2012.12.13.10.15.28 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 10:15:29 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2034616lbk.31 for ; Thu, 13 Dec 2012 10:15:28 -0800 (PST) Received: by 10.112.38.66 with SMTP id e2mr1238846lbk.90.1355422528504; Thu, 13 Dec 2012 10:15:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 10:14:58 -0800 (PST) In-Reply-To: References: <50BF612D.3070001@ericsson.com> <50C8A746.3030209@ericsson.com> <039d01cdd88a$8a3fdce0$9ebf96a0$@packetizer.com> <6D611DC83007B78DDDC90C87@caldav.corp.apple.com> <050e01cdd949$2f3a43c0$8daecb40$@packetizer.com> <059101cdd950$a4e64d60$eeb2e820$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 19:14:58 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmU7ga9tDVuQk3OrHWFAjvqvVy2/v7g19rl6c8jjDtYQHWrH5wEhlZmRefnahJYb8wss4+2 Cc: Cyrus Daboo , "Paul E. Jones" , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:15:35 -0000 On Thu, Dec 13, 2012 at 6:00 PM, Brad Fitzpatrick wro= te: > On Thu, Dec 13, 2012 at 8:41 AM, Paul E. Jones > wrote: >> >> Brad, >> >> My assumption is that if one runs an HTTPS server, he or she will either >> respond to either HTTP or HTTPS requests, or redirect HTTP requests to t= he >> HTTP server. > > Rather than assuming, it should be specified as required for servers, but= I > don't think we should do that. > >> So the only scenario that I think is broken is when an HTTPS client issu= es >> a request to an HTTP-only server. >> >> In any case, you=E2=80=99re right that there is at least one broken scen= ario and >> the only solution is to push that to the client or let it fail. We trie= d >> suggesting use both and people rejected that due to complexity. > > And I think we're compromising on client complexity. Client simplicity w= as > a nice bonus effect with HTTPS-only, but the big win was security. > > If we're going to allow HTTP, we at least still need security (my > "https:"-prefix secure rel proposal). We can't also get client simplicit= y > with HTTPS-and-HTTP. > > >> >> The new text recommends use of HTTPS, but HTTP is there because some >> wanted to use that. I would expect the =E2=80=9Cgeneral purpose=E2=80= =9D WF client to use >> HTTPS. But, perhaps =E2=80=9Cspecialized=E2=80=9D clients would use HTT= P only? > > > Seems like that'd be a wart in the spec that nobody knew the definition o= f > and never worked in practice. I'm all about making people happy, but I > don't want to put words in a spec that pacify certain people, but don't > actually work in the wild for them. > > It reads like "If you're, um, 'specialized', use HTTP? Maybe it'll work > sometimes, in your own little environment, but not with anybody else." That's what I'm worried about as well. With all this "answering on HTTP but upgrading to HTTPS" or simply not answering on HTTP... it defeats the purpose of the initial HTTP request for those use-cases where it would be beneficial (as I've described before). If out in the wild, I'm not going to be able to realistically use HTTP to get public information on a user without a high rate of failures or HTTPS upgrades, then I'd much rather use HTTPS only. However, my point was to have servers implement both HTTPS and HTTP (it's not difficult, afterall) with filtering for HTTP calls. Is that a possibility or is there no way that will fly? -Nick From ve7jtb@ve7jtb.com Thu Dec 13 10:16:56 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4E21F899A for ; Thu, 13 Dec 2012 10:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMSPXt+HLeS for ; Thu, 13 Dec 2012 10:16:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7062F21F89B6 for ; Thu, 13 Dec 2012 10:16:51 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1115817wey.31 for ; Thu, 13 Dec 2012 10:16:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=GFCmLtkA3vwL3Aw3w8JiFZFY+PMHIWdnLxBOIVuJxxM=; b=pL1v3IjYyxvO10BybjCXYIWsThpA1w77nVmSAL0ShSkz06AlQwc8iODe7wFw5A3dSK jhKRZU79zd8UGJixXwVo0C56KqZ+r4amSSWCDQahDtamZtuRV88g0ykL9ll68sloi7DP +QQDc1Ndl2ZD/1xTOkB/HY/LXgm5PnjX5wxXyzA6wSeJKZR3MDWqvUDhFTUa11cc9icr lE6gQDXpwgjXBK1QjnLg+Ae1EfLuhlV+vT15xiP7UR8QKyfq1t8MFxxA3ggzmr9WKx02 S7cSS5A4+NMRSmop6qMmEP31MV57Fe03EdWOw+LwRmMTWFUK5T4027K2WVbJPCWAkBoB CPLw== Received: by 10.180.73.80 with SMTP id j16mr5003673wiv.5.1355422610489; Thu, 13 Dec 2012 10:16:50 -0800 (PST) Received: from [10.234.42.9] ([109.144.21.29]) by mx.google.com with ESMTPS id bd7sm3755459wib.8.2012.12.13.10.16.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 10:16:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E8894AB4-23EB-46D0-B670-95CBF2BDE9AF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 13 Dec 2012 18:16:45 +0000 Message-Id: <644FD471-391B-41C7-94CE-5902E799366B@ve7jtb.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlg9Pcwz7jFtrHKW6Xm/iSbjq0xyfQdWWPp5Dz69VTkigiLsi88xy9DEh1FqPXZBZ7sA7kF Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:16:56 -0000 --Apple-Mail=_E8894AB4-23EB-46D0-B670-95CBF2BDE9AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think some people want to use acct: ass the link relation between WF = documents. That is probably a bad idea for other reasons but I think that might be = confusing some people about the rel https: filter. Having the server filter https: rels out of responses from http: = endpoints is nice but as was pointed out won't on it's own stop a = downgrade. The only effective rule would be to have the client do the filtering. I still think https: only is the only way to not make the client a = horrible mess and have acceptable security. I would rather see WF as http only than try and do both. John B. On 2012-12-13, at 5:28 PM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter = wrote: > Indeed =AB href =BB should be checked instead of =AB rel =BB in order = to support registered values as well. Plus some link rels may not be = http (think at acct:, sip:, ws:, ecc). So the client may need to check = as well for sips:, wss:, accts:? >=20 > Although I can understand the issue I=92m starting to get confused as = well=85 >=20 >=20 > No, the key (the link.rel) is what is secure, not the value (the = link.href). >=20 > So all of acct:, sip:, ws:, data:, etc can be used as as the value, = since that's not the part that is checked for an "https:" prefix. >=20 --Apple-Mail=_E8894AB4-23EB-46D0-B670-95CBF2BDE9AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think some people want to use acct: ass the link relation between WF = documents.

That is probably a bad idea for other = reasons but I think that might be confusing some people about the rel = https: filter.

Having the server filter https: = rels out of responses from http: endpoints is nice but as was pointed = out won't on it's own stop a downgrade.

The = only effective rule would be to have the client do the = filtering.

I still think https: only is the = only way to not make the client a horrible mess and have acceptable = security.

I would rather see WF as http only = than try and do both.

John = B.


On 2012-12-13, at 5:28 PM, = Brad Fitzpatrick <bradfitz@google.com> = wrote:

On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter = <laurentwalter.goix@telecomitalia.it> = wrote:

Indeed =AB href =BB should be checked = instead of =AB rel =BB in order to support registered values = as well. Plus some link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for = sips:, wss:, accts:?

Although I can understand the issue I=92m starting = to get confused as well=85


No, the key (the link.rel) is = what is secure, not the value (the = link.href).

So all of acct:, sip:, ws:, data:, = etc can be used as as the value, since that's not the part that is = checked for an "https:" prefix.


= --Apple-Mail=_E8894AB4-23EB-46D0-B670-95CBF2BDE9AF-- From perpetual-tripper@wwelves.org Thu Dec 13 10:19:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C6E21F89DF for ; Thu, 13 Dec 2012 10:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVQVujRR8L2v for ; Thu, 13 Dec 2012 10:19:22 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD321F897E for ; Thu, 13 Dec 2012 10:19:22 -0800 (PST) X-Originating-IP: 217.70.178.150 Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id F1BF7A80B2; Thu, 13 Dec 2012 19:19:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lNJ3IF-aZcZd; Thu, 13 Dec 2012 19:19:09 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 60C81A804E; Thu, 13 Dec 2012 19:19:09 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Nick Jennings In-reply-to: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <054301cdd94b$f60b9060$e222b120$@packetizer.com> Date: Thu, 13 Dec 2012 18:19:08 +0000 Message-Id: <1355422449-sup-6060@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: Brad Fitzpatrick , webfinger , webfinger Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:19:23 -0000 Excerpts from Nick Jennings's message of 2012-12-13 16:40:57 +0000: > On Thu, Dec 13, 2012 at 5:35 PM, Brad Fitzpatrick = wrote: > > On Thu, Dec 13, 2012 at 8:32 AM, Nick Jennings > > wrote: > >> > >> On Thu, Dec 13, 2012 at 5:21 PM, Brad Fitzpatrick > >> wrote: > >> > On Thu, Dec 13, 2012 at 8:19 AM, Nick Jennings > >> > wrote: > >> >> On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones > >> >> wrote: > >> >> > Let me add=E2=80=A6 > >> >> > > >> >> > If you wish to define =E2=80=9Csecure links=E2=80=9D within the= server itself, I=E2=80=99d be > >> >> > OK > >> >> > with that. That=E2=80=99s what I thought you meant. For examp= le, when I put > >> >> > in > >> >> > my > >> >> > OpenID Provider URI, I would indicate whether that content shou= ld be > >> >> > returned over a secure link or not. The server can return only= the > >> >> > links > >> >> > that are not marked =E2=80=9Csecure=E2=80=9D internally. The s= erver can even > >> >> > automatically > >> >> > classify some link relation types as =E2=80=9Csecure=E2=80=9D. > >> >> > >> >> Yes, this is how I would like it as well. I think it' solves a lo= t of > >> >> these issues, and even helps to take less burden off the client. > >> > > >> > > >> > A server can do whatever it wants but it doesn't help if the clien= t is > >> > talking to a different server. (after a downgrade attack) > >> > > >> > If you want security in the whole system, it needs to have a clien= t > >> > component. > >> > >> Can you give me an example of the downgrade attack where an HTTP cal= l > >> is made initially to a server? > > > > > > There's no example of a downgrade attack with HTTP-only because there= 's > > nowhere "down" to go... you're already at the bottom and can't trust > > anything. > > > > >=20 > That's kind of my point. I was saying, that if the server filters out > secure links during HTTP requests, then it takes out a lot of client > complexity (ie. you make an HTTP request, you get only trivial data). > The client doesn't need to worry about it. to my understanding we talk about situation when *(wo)man in the middle* = controls which server your HTTP requests goes to and (s)he has full contr= ol over it! in such case client needs to take care of security *on it's own* and wou= ld use logic: if I get profile from request made over HTTP, i should disregard any link= s which have /^https/ in their *rel* attribute... otherwise please count me in as yet another confused person ;D From jasnell@gmail.com Thu Dec 13 10:20:53 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A181121F8AE2 for ; Thu, 13 Dec 2012 10:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.805 X-Spam-Level: X-Spam-Status: No, score=-3.805 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGyo4T0ZQ+3F for ; Thu, 13 Dec 2012 10:20:53 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF7AF21F8AD6 for ; Thu, 13 Dec 2012 10:20:52 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2305051iaz.31 for ; Thu, 13 Dec 2012 10:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oIA4UYPQBuU+1qskU4Hz44Puu2J1aeMe2qrr2W9TKiI=; b=rrYI3biBMt9I9p74oIx56ip+9SOlPJmm7Ht6KRbziVaO35Cm4uBpsSxp5dKe9fK3Lo lKUbCGMs2HLxS8PIsRCJwaTEfZhCvc5pP3yE44chkpwj+e7kTinOUM46u7BqPQLDjeSp Ac4g9ysrgM0bDUbjGah4rPtTixtNVoGunTpxYIAblonboP6xHD7TiTAAEpK9dfAPd6Fu OePiGwlKkgHXwlNnkp78/1RDTWukUmgVCQ8PMgf2ysvVePzN42PJLbeQIaTAAHz4N6jK 5P1IYywMaA41Ia8xV8pS/P2YoWNYA//Orz2kUXV/G0yHuZgUVaLcu8wx/VnoEVSx1zaE u7dw== Received: by 10.42.51.142 with SMTP id e14mr2381432icg.2.1355422852448; Thu, 13 Dec 2012 10:20:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:20:32 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 10:20:32 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=20cf30223999a4019304d0bff99c Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:20:53 -0000 --20cf30223999a4019304d0bff99c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Huh? This particular conversation is extremely confusing at this point. Link rel values are neither secure nor insecure. They're JUST labels. They provide no information at all about the security requirements of the linked resource. If I have... (A) { "rel": "canonical", "href": "http://example.org/foo" } (B) { "rel": "canonical", "href": "https://example.org/foo" } Then (A) is insecure and (B) is secure. It's that simple. All this talk of checking rel values for "https:" is nonsense. The real question here appears to be one of integrity: how does the client know that the information provided in the WebFinger document is the right information from a trusted source? HTTPS isn't enough to verify that. If you want to do it right, you add a cryptographic signature to the document generated with a key that the client trusts. Once the client verifies that the information is trustworthy, it can scan through looking for the links it wants. If it needs a secure link, it looks for ones whose href attributes specify "https". - James On Thu, Dec 13, 2012 at 9:28 AM, Brad Fitzpatrick wrot= e: > On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > >> Indeed =C2=AB href =C2=BB should be checked instead of =C2=AB rel =C2= =BB in order to >> support registered values as well. Plus some link rels may not be http >> (think at acct:, sip:, ws:, ecc). So the client may need to check as wel= l >> for sips:, wss:, accts:? **** >> >> Although I can understand the issue I=E2=80=99m starting to get confused= as well=E2=80=A6 >> > > No, the key (the link.rel) is what is secure, not the value (the > link.href). > > So all of acct:, sip:, ws:, data:, etc can be used as as the value, since > that's not the part that is checked for an "https:" prefix. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --20cf30223999a4019304d0bff99c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Huh? This = particular conversation is extremely confusing at this point. Link rel valu= es are neither secure nor insecure. They're JUST labels. They provide n= o information at all about the security requirements of the linked resource= .

If I have...

(A)
{
=C2=A0 "rel": "canonical",
=C2=A0 "href": &= quot;http://example.org/foo"
}

(B)
{
=C2=A0 "rel": "can= onical",=C2=A0
= =C2=A0 "href": "https://= example.org/foo"
}

Then (A) is insecure and (B) is secure. It's that simple. All th= is talk of checking rel values for "https:" is nonsense.

The real question here appears to be one of inte= grity: how does the client know that the information provided in the WebFin= ger document is the right information from a trusted source? HTTPS isn'= t enough to verify that. If you want to do it right, you add a cryptographi= c signature to the document generated with a key that the client trusts. On= ce the client verifies that the information is trustworthy, it can scan thr= ough looking for the links it wants. If it needs a secure link, it looks fo= r ones whose href attributes specify "https".

- James
<= br>
On Thu, Dec 13, 2012 at 9:28 AM, Brad Fit= zpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 9:21 AM,= Goix Laurent Walter <laurentwalter.goix@telecomitalia.i= t> wrote:

Indeed =C2= =AB=C2=A0href=C2=A0=C2=BB should be checked instead of =C2=AB=C2=A0rel=C2= =A0=C2=BB in order to support registered values as well. Plus some link rel= s may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sip= s:, wss:, accts:?

Although I= can understand the issue I=E2=80=99m starting to get confused as well=E2= =80=A6


No, the key (the link.rel) is = what is secure, not the value (the link.href).

So = all of acct:, sip:, ws:, data:, etc can be used as as the value, since that= 's not the part that is checked for an "https:" prefix.


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--20cf30223999a4019304d0bff99c-- From laurentwalter.goix@telecomitalia.it Thu Dec 13 10:25:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB67721F8B01 for ; Thu, 13 Dec 2012 10:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEAO5L80zoAX for ; Thu, 13 Dec 2012 10:25:07 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id EF2EF21F8A99 for ; Thu, 13 Dec 2012 10:25:04 -0800 (PST) Content-Type: multipart/mixed; boundary="_fa841517-1bab-47c5-8612-1a23bc7d449a_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 13 Dec 2012 19:25:03 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 13 Dec 2012 19:25:02 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 13 Dec 2012 19:24:52 +0100 Thread-Topic: [webfinger] secure links with https rels Thread-Index: Ac3ZXyobifK/e+iJSmuUXQN/0YHPgg== Message-ID: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:25:09 -0000 --_fa841517-1bab-47c5-8612-1a23bc7d449a_ Content-Type: multipart/alternative; boundary="_000_B77570D7A7DA4F18A305082A28F5D131telecomitaliait_" --_000_B77570D7A7DA4F18A305082A28F5D131telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmlsbCAoTWlsbHMpIGlzIHByb3Bvc2luZyB0byByZWdpc3RlciBzb21lIG9hdXRoKiBsaW5rIHJl bHMgdGhhdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGF1dG9jb25maWd1cmF0aW9uLiBUaGVzZSB3b3Vs ZCBub3QgYmUgcHJlZml4ZWQgYnkgaHR0cHMgYXMga2V5cywgYnV0IHRoZSB2YWx1ZXMgY2VydGFp bmx5Li4uIChBbmQgSSdkIGxpa2UgY29uc2lkZXJpbmcgdGhlbSBhcyAnc2VjdXJlIGxpbmtzJykN Cg0KTGUgMTMgZMOpYy4gMjAxMiDDoCAxODoyOCwgIkJyYWQgRml0enBhdHJpY2siIDxicmFkZml0 ekBnb29nbGUuY29tPG1haWx0bzpicmFkZml0ekBnb29nbGUuY29tPj4gYSDDqWNyaXQgOg0KDQpP biBUaHUsIERlYyAxMywgMjAxMiBhdCA5OjIxIEFNLCBHb2l4IExhdXJlbnQgV2FsdGVyIDxsYXVy ZW50d2FsdGVyLmdvaXhAdGVsZWNvbWl0YWxpYS5pdDxtYWlsdG86bGF1cmVudHdhbHRlci5nb2l4 QHRlbGVjb21pdGFsaWEuaXQ+PiB3cm90ZToNCkluZGVlZCDCqyBocmVmIMK7IHNob3VsZCBiZSBj aGVja2VkIGluc3RlYWQgb2YgwqsgcmVsIMK7IGluIG9yZGVyIHRvIHN1cHBvcnQgcmVnaXN0ZXJl ZCB2YWx1ZXMgYXMgd2VsbC4gUGx1cyBzb21lIGxpbmsgcmVscyBtYXkgbm90IGJlIGh0dHAgKHRo aW5rIGF0IGFjY3Q6LCBzaXA6LCB3czosIGVjYykuIFNvIHRoZSBjbGllbnQgbWF5IG5lZWQgdG8g Y2hlY2sgYXMgd2VsbCBmb3Igc2lwczosIHdzczosIGFjY3RzOj8NCkFsdGhvdWdoIEkgY2FuIHVu ZGVyc3RhbmQgdGhlIGlzc3VlIEnigJltIHN0YXJ0aW5nIHRvIGdldCBjb25mdXNlZCBhcyB3ZWxs 4oCmDQoNCk5vLCB0aGUga2V5ICh0aGUgbGluay5yZWwpIGlzIHdoYXQgaXMgc2VjdXJlLCBub3Qg dGhlIHZhbHVlICh0aGUgbGluay5ocmVmKS4NCg0KU28gYWxsIG9mIGFjY3Q6LCBzaXA6LCB3czos IGRhdGE6LCBldGMgY2FuIGJlIHVzZWQgYXMgYXMgdGhlIHZhbHVlLCBzaW5jZSB0aGF0J3Mgbm90 IHRoZSBwYXJ0IHRoYXQgaXMgY2hlY2tlZCBmb3IgYW4gImh0dHBzOiIgcHJlZml4Lg0KDQpRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZh bWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxz aWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGlu Zm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJp Y2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHBy b3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFt cGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_B77570D7A7DA4F18A305082A28F5D131telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkJpbGwgKE1pbGxzKSBpcyBwcm9wb3NpbmcgdG8gcmVnaXN0ZXIgc29tZSBvYXV0aCogbGlu ayByZWxzIHRoYXQgd291bGQgYmUgdXNlZnVsIGZvciBhdXRvY29uZmlndXJhdGlvbi4gVGhlc2Ug d291bGQgbm90IGJlIHByZWZpeGVkIGJ5IGh0dHBzIGFzIGtleXMsIGJ1dCB0aGUgdmFsdWVzIGNl cnRhaW5seS4uLiAoQW5kIEknZCBsaWtlIGNvbnNpZGVyaW5nIHRoZW0gYXMgJ3NlY3VyZSBsaW5r cycpPGJyPg0KPGJyPg0KTGUgMTMgZMOpYy4gMjAxMiDDoCAxODoyOCwgJnF1b3Q7QnJhZCBGaXR6 cGF0cmljayZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyYWRmaXR6QGdvb2dsZS5jb20iPmJy YWRmaXR6QGdvb2dsZS5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQiPk9uIFRo dSwgRGVjIDEzLCAyMDEyIGF0IDk6MjEgQU0sIEdvaXggTGF1cmVudCBXYWx0ZXINCjxzcGFuIGRp cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmxhdXJlbnR3YWx0ZXIuZ29peEB0ZWxlY29taXRh bGlhLml0IiB0YXJnZXQ9Il9ibGFuayI+bGF1cmVudHdhbHRlci5nb2l4QHRlbGVjb21pdGFsaWEu aXQ8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9 IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5 N2QiPkluZGVlZCDCqyZuYnNwO2hyZWYmbmJzcDvCuyBzaG91bGQgYmUgY2hlY2tlZCBpbnN0ZWFk IG9mIMKrJm5ic3A7cmVsJm5ic3A7wrsgaW4gb3JkZXIgdG8gc3VwcG9ydCByZWdpc3RlcmVkIHZh bHVlcyBhcyB3ZWxsLiBQbHVzIHNvbWUgbGluayByZWxzIG1heSBub3QgYmUgaHR0cCAodGhpbmsN CiBhdCBhY2N0Oiwgc2lwOiwgd3M6LCBlY2MpLiBTbyB0aGUgY2xpZW50IG1heSBuZWVkIHRvIGNo ZWNrIGFzIHdlbGwgZm9yIHNpcHM6LCB3c3M6LCBhY2N0czo/DQo8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkFsdGhvdWdoIEkgY2FuIHVuZGVyc3RhbmQgdGhl IGlzc3VlIEnigJltIHN0YXJ0aW5nIHRvIGdldCBjb25mdXNlZCBhcyB3ZWxs4oCmPC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5ObywgdGhlIGtleSAodGhlIGxpbmsucmVsKSBpcyB3aGF0IGlzIHNlY3VyZSwgbm90IHRoZSB2 YWx1ZSAodGhlIGxpbmsuaHJlZikuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TbyBh bGwgb2YgYWNjdDosIHNpcDosIHdzOiwgZGF0YTosIGV0YyBjYW4gYmUgdXNlZCBhcyBhcyB0aGUg dmFsdWUsIHNpbmNlIHRoYXQncyBub3QgdGhlIHBhcnQgdGhhdCBpcyBjaGVja2VkIGZvciBhbiAm cXVvdDtodHRwczomcXVvdDsgcHJlZml4LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ DQo8IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9 DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWw7 IGZvbnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0i Mzk1Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWduPSJq dXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 OyBsaW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxzcGFu IGNsYXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28t YW5zaS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFuPjwv cD4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZlcmRh bmEiPjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEkuRGlz Y2xhaW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0iNDAi PlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg bmVjZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B77570D7A7DA4F18A305082A28F5D131telecomitaliait_-- --_fa841517-1bab-47c5-8612-1a23bc7d449a_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_fa841517-1bab-47c5-8612-1a23bc7d449a_-- From jasnell@gmail.com Thu Dec 13 10:26:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7297321F8B0C for ; Thu, 13 Dec 2012 10:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC56UPo8KlEN for ; Thu, 13 Dec 2012 10:26:03 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4994D21F8AAC for ; Thu, 13 Dec 2012 10:25:57 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4529122ieb.31 for ; Thu, 13 Dec 2012 10:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=onVVMlNo0iJ/YtJRAULlKTxSen28SEsHYth8O70pp94=; b=SMjjmO/+RLkXUy+m8uLFlR/v57AlgIQIkkLfjsHDL8Imjt2OX1fmAzR7wNOX5dgEkO +OH4QenWTq899PQ69PfTs6JkgRIPjP2HoyQMx5mUtVNc51/jkNlwwZ0U8BBSqCSEfzW0 s/w6Mxy35vxcFk8him/ykYf08GCHiGX/HC67CuWzw4vTmAqJW42rbZ9VmoMTqb4mqJEx PYrgoHXLOT1fHXgeGadrDTAiov8xvE8H3po+Wk9ZD6tDSPjLtaHPfAmuaHlxxrqcLDl6 WWcFWgAX7UaqfShVnfp2jjv4/0STgyndBORUWA7EJj7SOxN0phMkOI8FeAxRI59lfDDQ IZ2g== Received: by 10.50.178.106 with SMTP id cx10mr18008145igc.24.1355423154532; Thu, 13 Dec 2012 10:25:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:25:34 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 10:25:34 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f5036c8a570cb04d0c00b26 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:26:10 -0000 --e89a8f5036c8a570cb04d0c00b26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick wrot= e: > On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wro= te: > >> Don=E2=80=99t put it on the wire. You want the server to filter before = sending a >> reply. >> > > I'm concerned you're still confused about how a downgrade attack works. > > Again: it DOES NOT MATTER what the server thinks it's filtering if the > client has been tricked into talking to a DIFFERENT SERVER which is then > returning malicious results. > > Such as: > > -- client wants "all links" for foo@example.com. > -- client requests secure > https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com > -- EVIL HIJACKER BLOCKS PORT 443 > -- client then requests plain > http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com > -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: > > { > "rel" : "https://openid.net/connect/server", > "type" : "text/html", > "href" : "https://attacker.openid.server/" > }, > > See what happened there? > > We need the *client* to say "whoa whoa, wait a minute... I contacted this > webfinger server over HTTP---- what's it doing returning rels starting wi= th > https:? I'm gonna skip over those (or just return an error)." > > No... that's just nonsense. The real issue here is that the client has absolutely no way of detecting that the evil hijacker intercepted the request and provided false information in the first place. It should not matter at all if the returned document contains link rels with "https:" in them or not. - James > The real webfinger server _was never even contacted_, so it doesn't matte= r > whether it was filtering or not. > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8f5036c8a570cb04d0c00b26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1= 3, 2012 at 8:54 AM, Brad Fitzpatrick <bradfitz@google.com>= wrote:
On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones <pau= lej@packetizer.com> wrote:

Don=E2=80=99t put it on the wire.=C2=A0 You want= the server to filter before sending a reply.


I'm concerned you= 9;re still confused about how a downgrade attack works.

Again: it DOES NOT MATTER what the server thinks it's filtering i= f the client has been tricked into talking to a DIFFERENT SERVER which is t= hen returning malicious results.

Such as:

-- client wants "all li= nks" for foo@exam= ple.com.
-- EVIL HIJACKER BLOCKS PORT 443
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WAN= T:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : &= quot;https:= //openid.net/connect/server",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type" : "text= /html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= ;href" : "https://attacker.openid.server/"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

See what happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this webfinge= r server over HTTP---- what's it doing returning rels starting with htt= ps:? I'm gonna skip over those (or just return an error)."


No... that's just nonsense= . The real issue here is that the client has absolutely no way of detecting= that the evil hijacker intercepted the request and provided false informat= ion in the first place. It should not matter at all if the returned documen= t contains link rels with "https:" in them or not.=C2=A0

=
- James
=C2=A0
The real webfinger server _was never e= ven contacted_, so it doesn't matter whether it was filtering or not.


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8f5036c8a570cb04d0c00b26-- From bradfitz@google.com Thu Dec 13 10:30:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531D921F8B0E for ; Thu, 13 Dec 2012 10:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKHW7QAPC2xh for ; Thu, 13 Dec 2012 10:30:41 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1A21F8B0C for ; Thu, 13 Dec 2012 10:30:40 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1122878wey.31 for ; Thu, 13 Dec 2012 10:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bj/2JcEEKJKYXQNYEe9iiFpzylUyoJg4LKx2Dm0zxdo=; b=Chx3zP7OxOXxx35KCMEeRWnUcgI/dV2y/toZ97rbsXH5k0qiRECAc+Us+e0yz1u+ZF IvG+AsQeFZ2AQxsEx+oZtu6JJ3jwcf7Xcz7NeZ5kEfBzfhPXrhVUsDeWcMb0HRnxGKbw nRI3FsfmNtbGsue0kMCo7pvcDneLYoUe4tjsC4kOEoCbPQsMij8JDIj+FV3odw/PdnWi KYrqaTwe8xja6hHPAi+orjr7g6G0bJBItf59+wsXlacA2hSpbUBSc6D4e1NmV2fE/S1I 785RxVXPhVfXLLNEG4dat9GlmPTkkkRod/yqYUPVX7pA0fmUWb9F5NeY17CAp8OyP5VV jocQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Bj/2JcEEKJKYXQNYEe9iiFpzylUyoJg4LKx2Dm0zxdo=; b=aLMr+OeytXMfEPU27pePTEDT2B4gKEvJ60F0CTUDO+qTplbCQ24OUdXmXZLoUd9Nml q9FAVQoXyPbK6YdAQyj7Nlz/N8a691XGe2+8NKEYgg7sQGtLq1nL+Tr+I2hL4FQJQmIh 2zbsgA3Xw2Sm9H43o7lRWDp6ym3qPAObdXlpN5EpNmcOrDxTa973d6qDBCQ9P9BocF9x oVxmi9g7sqpT3TOI+HKnF4+Y4sks23oSFjikGDJ5V3nCYIwrepGZXV7uAu1IniLLg5/O TN8X2DW+xIVzo+SSDwHpjF0bvxnDHhvgzMSN42X9QaNkKOEz6q25Fl9bGZg/qtZeW+3p jaRQ== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr10124666wjb.10.1355423439116; Thu, 13 Dec 2012 10:30:39 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 10:30:39 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 10:30:39 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7bf10b2c9bdb3104d0c01ce9 X-Gm-Message-State: ALoCoQk1q2lWx5zG4hZ99G8d93klzCY2LG+1X9qs+mEtFDyC/f/NIkzbz5eCYIjR8rg5+NawY3kAAU9yrLG1ZQPiB8CAXPGWXyeJBwieP1kGZkZBxXSU3p+fx5064n93oQSdGPQfiaqB2rSo7YrmY3ZAxq49zVLVSsfXeituFQskflFNKdSPhktDzGj0bmziz/qHp66uYweu Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:30:42 -0000 --047d7bf10b2c9bdb3104d0c01ce9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 10:25 AM, James M Snell wrote: > > > On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick wr= ote: > >> On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wr= ote: >> >>> Don=E2=80=99t put it on the wire. You want the server to filter before= sending >>> a reply. >>> >> >> I'm concerned you're still confused about how a downgrade attack works. >> >> Again: it DOES NOT MATTER what the server thinks it's filtering if the >> client has been tricked into talking to a DIFFERENT SERVER which is then >> returning malicious results. >> >> Such as: >> >> -- client wants "all links" for foo@example.com. >> -- client requests secure >> https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.co= m >> -- EVIL HIJACKER BLOCKS PORT 443 >> -- client then requests plain >> http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com >> -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: >> >> { >> "rel" : "https://openid.net/connect/server", >> "type" : "text/html", >> "href" : "https://attacker.openid.server/" >> }, >> >> See what happened there? >> >> We need the *client* to say "whoa whoa, wait a minute... I contacted thi= s >> webfinger server over HTTP---- what's it doing returning rels starting w= ith >> https:? I'm gonna skip over those (or just return an error)." >> >> > No... that's just nonsense. The real issue here is that the client has > absolutely no way of detecting that the evil hijacker intercepted the > request and provided false information in the first place. It should not > matter at all if the returned document contains link rels with "https:" i= n > them or not. > You can never detect with HTTP that the connection was intercepted. That doesn't matter, because the client does know one thing: that it used HTTP (and not HTTPS). So the client can filter out links which should not ever appear over plain HTTP. I'm proposing that rels which begin with "https:" should never go over HTTP, and I've started calling those "secure rels". Maybe that's a bad name, if enough people (including you now, in your earlier email) assume that I'm talking about the value (the href). I'm open to alternative name suggestions. --047d7bf10b2c9bdb3104d0c01ce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Thu, Dec 13, 2012 at 10:25 AM, James M= Snell <jasnell@gmail.com> wrote:


On Thu, Dec 13, 2012 at 8:54 AM, B= rad Fitzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:

Don=E2=80=99t put it on the wire.=C2=A0 You want the server= to filter before sending a reply.


I'm concerned you= 9;re still confused about how a downgrade attack works.

Again: it DOES NOT MATTER what the server thinks it's filtering i= f the client has been tricked into talking to a DIFFERENT SERVER which is t= hen returning malicious results.

Such as:

-- client wants "all li= nks" for foo@exam= ple.com.
-- EVIL HIJACKER BLOCKS PORT 443
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WAN= T:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : "https://openid.net= /connect/server",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type" : "text= /html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= ;href" : "https://attacker.openid.server/"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},

See what happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this webfinge= r server over HTTP---- what's it doing returning rels starting with htt= ps:? I'm gonna skip over those (or just return an error)."


No... that's j= ust nonsense. The real issue here is that the client has absolutely no way = of detecting that the evil hijacker intercepted the request and provided fa= lse information in the first place. It should not matter at all if the retu= rned document contains link rels with "https:" in them or not.=C2= =A0

You can never detect with HTTP= that the connection was intercepted. =C2=A0That doesn't matter, becaus= e the client does know one thing: =C2=A0that it used HTTP (and not HTTPS). = =C2=A0So the client can filter out links which should not ever appear over = plain HTTP. =C2=A0I'm proposing that rels which begin with "https:= " should never go over HTTP, and I've started calling those "= secure rels". =C2=A0Maybe that's a bad name, if enough people (inc= luding you now, in your earlier email) assume that I'm talking about th= e value (the href).

I'm open to alternative name suggestions.

--047d7bf10b2c9bdb3104d0c01ce9-- From bradfitz@google.com Thu Dec 13 10:33:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C021F89BE for ; Thu, 13 Dec 2012 10:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vntRXn8bVK8L for ; Thu, 13 Dec 2012 10:33:47 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38A0E21F897E for ; Thu, 13 Dec 2012 10:33:47 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1124463wey.31 for ; Thu, 13 Dec 2012 10:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lqxq43vW89TxbgN1DZfWpdZCn+5/mR4AS+EXB/RdgXA=; b=DfFnk42VWYJS04PxpM24QW1mXSAJ/D41/RzVeip00ugE7hcKUB0ZhVuEA77pcE+p4Z Xp8w+iE3FlF8edoRVDTIbJ9GWn8vIYv1Nr6SxZ97kHgHYQ8DSbxiTEM6A86qZDDsU0DB N67wXHed1KmFgj8OzCYB+KRcepSZqtHiSf0PSL3okiMjdcUdufbSjIDGTyLCuByGoJ+1 67rjsiP6hyqFi993Vwb+7kTbGLKKvs1sfXRy1HZLx/LtYQ1HtrV3jXWwETBt4P6qRwJw oNMhAhjfrfy6yC3v27YxdZQllOYyyicH6Y1Aa02N2AQqYzZxAgOU4Vd29m5XbIr0QO4N ep8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lqxq43vW89TxbgN1DZfWpdZCn+5/mR4AS+EXB/RdgXA=; b=E3Z3ZNhXtJQzPhug88n7PDViM4q9nwANGyAypZVUsaO5/PGsT422hCoXvsHEjIVbeO purKk/NrzXMC8IThmWa3R1cUk5MGVY/PraWE9Llb/HRc82sWU9dcIaw/8ICF4ocGRPnc 4glAhV0Qk3JT3i0QoOcFRSJBPlIlwCKBkm8URxW+TpY2xLQcbUBVeI19zZtFdVK9ivDw e51IsH8D34PQslzCTRzawJMxeFKK4QogGZmhJDTyC/dmp0ZslYRGOakiWTBn3n9y//Am ivULe8ZQ4PCJz1Sc97BGWsmgSvP8Wd/nl/6Yh3Q0kzAaLqlWHXBRmRVkf+0zqR3EpC5y 1+Mw== MIME-Version: 1.0 Received: by 10.180.107.130 with SMTP id hc2mr29678940wib.12.1355423625540; Thu, 13 Dec 2012 10:33:45 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 10:33:45 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 10:33:45 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3baa6fb872c104d0c027e7 X-Gm-Message-State: ALoCoQkxPj9NJE/dDiDHPSS7UtyhwCzH1jSTkAjCFWasfQPNAWEAL6vCqktufpqK9mTLKljFL3VTaxZh/IRLRkUTpwzGLXM9x7S5X0ewhRd6UnNeKZ8fhtfEEhgeo1Du0Tmyq4L8yx1oHAlYBZS91l2OSsZWkHjLpUWilW6oE6KomWVk24BtN6dp87D25H/+BPEsx/vIdTKn Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:33:48 -0000 --e89a8f3baa6fb872c104d0c027e7 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:24 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Bill (Mills) is proposing to register some oauth* link rels that would > be useful for autoconfiguration. These would not be prefixed by https as > keys, but the values certainly... (And I'd like considering them as 'secure > links') > That wouldn't work. Try it out with the downgrade attack scenario I described earlier to Paul. The client is only looking for and assigning meaning to keys (the "rel" values), so marking a rel as "secure" in the value can be faked by the attacker, and marking the rel as secure in a new attribute can also be faked by the attacker. --e89a8f3baa6fb872c104d0c027e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 10:24 AM, Goix Laurent Walter <= la= urentwalter.goix@telecomitalia.it> wrote:
Bill (Mills) is proposing to register some oauth* link rels that would= be useful for autoconfiguration. These would not be prefixed by https as k= eys, but the values certainly... (And I'd like considering them as '= ;secure links')

That wouldn't work. =C2=A0= Try it out with the downgrade attack scenario I described earlier to Paul.<= /div>

The client is only looking for and assigning meani= ng to keys (the "rel" values), so marking a rel as "secure&q= uot; in the value can be faked by the attacker, and marking the rel as secu= re in a new attribute can also be faked by the attacker.

--e89a8f3baa6fb872c104d0c027e7-- From jasnell@gmail.com Thu Dec 13 10:36:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387221F8A53 for ; Thu, 13 Dec 2012 10:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4kxQfOrfDeM for ; Thu, 13 Dec 2012 10:36:48 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA79E21F89DF for ; Thu, 13 Dec 2012 10:36:47 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4549249ieb.31 for ; Thu, 13 Dec 2012 10:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tVVBXLgq/x+xCJkKEJ0O2a8mULhgOjUUaj9X09xYAo4=; b=cjI/EqlX9WwZXfyK6PVlcwBlnuzbg6vwO24xOaR+kh5jElqgaVh1Ww77EqFqf+VTc5 qYGX14SzDENHzX8lu5MAPy9lm0KqQVwx/ikSjguA1tU56/khxc3aXLwBFzUN+7uIOYZe wBFq5QyLsXznGXZnrQEkE17e0jwqZwUCE2XVjtaPm6C3lwcWhccDRS+JfStKauz/yYkF DhMS+VXx4DL1qzBsmxEhW2YcCp+0O5oN+eKMwz7QbvAFmbIPTej+ccKN+qRZfNqxCUPD L2F7AkthiD8SVBMwTZaFL9AuGjdlJaMBc893s0gA5BHh4lzM2L0H5DP8Zdt4xsDvZe2u CWiw== Received: by 10.50.0.193 with SMTP id 1mr2736042igg.0.1355423805039; Thu, 13 Dec 2012 10:36:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:36:24 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 10:36:24 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f502f8e6b649304d0c03266 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:36:48 -0000 --e89a8f502f8e6b649304d0c03266 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick wrote: > [snip] > >> >> No... that's just nonsense. The real issue here is that the client has >> absolutely no way of detecting that the evil hijacker intercepted the >> request and provided false information in the first place. It should not >> matter at all if the returned document contains link rels with "https:" in >> them or not. >> > > You can never detect with HTTP that the connection was intercepted. That > doesn't matter, because the client does know one thing: that it used HTTP > (and not HTTPS). So the client can filter out links which should not ever > appear over plain HTTP. I'm proposing that rels which begin with "https:" > should never go over HTTP, and I've started calling those "secure rels". > Maybe that's a bad name, if enough people (including you now, in your > earlier email) assume that I'm talking about the value (the href). > > I'm open to alternative name suggestions. > > I'm -1 on the whole proposal. The notion of "insecure" and "secure" link relations makes absolutely no sense at all. It may not be possible to detect if the HTTP connection was intercepted, but it is possible to determine if the information provided is trustworthy. That is what cryptographic signatures are for. - James --e89a8f502f8e6b649304d0c03266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Dec 13, 2012 at 10:30 AM, Brad F= itzpatrick <bradfitz@google.com> wrote:
[snip]

No... that's just= nonsense. The real issue here is that the client has absolutely no way of = detecting that the evil hijacker intercepted the request and provided false= information in the first place. It should not matter at all if the returne= d document contains link rels with "https:" in them or not.=C2=A0=

You can never detect wit= h HTTP that the connection was intercepted. =C2=A0That doesn't matter, = because the client does know one thing: =C2=A0that it used HTTP (and not HT= TPS). =C2=A0So the client can filter out links which should not ever appear= over plain HTTP. =C2=A0I'm proposing that rels which begin with "= https:" should never go over HTTP, and I've started calling those = "secure rels". =C2=A0Maybe that's a bad name, if enough peopl= e (including you now, in your earlier email) assume that I'm talking ab= out the value (the href).

I'm open to alternative name suggestions.


I'm -1 on the w= hole proposal. The notion of "insecure" and "secure" li= nk relations makes absolutely no sense at all. It may not be possible to de= tect if the HTTP connection was intercepted, but it is possible to determin= e if the information provided is trustworthy. That is what cryptographic si= gnatures are for.

- James --e89a8f502f8e6b649304d0c03266-- From bradfitz@google.com Thu Dec 13 10:37:00 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3421F89BE for ; Thu, 13 Dec 2012 10:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5op2ObYxoo1I for ; Thu, 13 Dec 2012 10:37:00 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDC2C21F897E for ; Thu, 13 Dec 2012 10:36:59 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4335605wib.13 for ; Thu, 13 Dec 2012 10:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZgW2DGVk7enGeD0jghiwACmQDXGH7mG5ZcpQP61lhyQ=; b=P9vb8SF5bFXF0AjJRsFj/PdT6sskI7hePYhAmtSr/3jM/KKCPQ7WGzyRfQJ4JYNF0B fQ7j7ZXUxZc+NZSAxksr6l81IkJvmLt095e6EY7i953M0wfwIUdqlTMK9dDWxui0AXMt puwbwDsisGcRZPPnqqXW6Jhc8GQ6d1D21yKSQmt4J9MOD0q6oBJxvxTW61H/E+o080Gh R17rFfdGBOw90abKSXFNjSn0bGFMpznrmptkl6/8YEhaIbsuqFToraiJu1VwbpwnxdMV C06TnUx8zgRxzhk2KZzut5Y0/Ju3XqZAmZW5KY2e8EVTWc+xIWTdNnXR/Bj9rcmr3bv5 hY5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZgW2DGVk7enGeD0jghiwACmQDXGH7mG5ZcpQP61lhyQ=; b=ZyQxW7Tkup7FVy8gmYsdaPqzbz5mjNdGmQyF8l05DtYTR4RTCh5JdqTvFgt35fngPn 9I+P2LNBuUM+zPS/GPxDA5c55ucU9uCCspQNjk9PwKc6QOOYnazTaBsdU8kdzYO6yC/4 y/6Dci/8x3txIheZ2llyYiDhyutZArP8TNCWB/fQnkpnG+FvF5R/MXrheVZNdk+0r6te glY5JG58UqpnS/Lj9YZ0o0a0NiyGf9p48aKLF7LgVFd0uI8KOCSPfX40z3Si5QHUN24t JsI7fLrSdq4yW/axc/yic+KLkGQpQbUMZKxQNSmBJ+BD4L/HhlAx1Svx4OEjKYQs3n9T fMDQ== MIME-Version: 1.0 Received: by 10.194.81.73 with SMTP id y9mr9209536wjx.31.1355423819076; Thu, 13 Dec 2012 10:36:59 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 10:36:59 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 10:36:59 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7bea3a2041932504d0c03372 X-Gm-Message-State: ALoCoQnJX21MXztfwwJzUNIZ83fsudQbtjz+kTnbIER934WsxTpOlXGQFIhqI7Z7wjbja+tpPvLEx3TxpN06NZ4ti05yJXksMhCyEL5xf9SnGwM0k0YVqNjzjOzJuCQzJqvokrnSFXLH+NbCGdEhXRVsIE62Ro7yisKd5E9k3UYzH2lxouOSgYQAvBEA9jFKJwy2F+xTsF4F Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:37:00 -0000 --047d7bea3a2041932504d0c03372 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:20 AM, James M Snell wrote: > Huh? This particular conversation is extremely confusing at this point. > Link rel values are neither secure nor insecure. They're JUST labels. They > provide no information at all about the security requirements of the linked > resource. > That has been the case so far. This thread is a proposal about changing that, and now assigning meaning to the labels. If the label beings with "https:", we consider it a "secure rel" and never expect it to be transmitted over plain HTTP. That means servers SHOULD filter it from their responses over HTTP, but most importantly, and paramount to the security: clients MUST NOT accept secure rels over HTTP. If they see one, they must filter it out. If I have... > > (A) > { > "rel": "canonical", > "href": "http://example.org/foo" > } > > (B) > { > "rel": "canonical", > "href": "https://example.org/foo" > } > > Then (A) is insecure and (B) is secure. It's that simple. > That's not my proposal at all. Maybe I should use a new term. My proposal is attaching meaning to the "rel", not the "href". --047d7bea3a2041932504d0c03372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 10:20 AM, James M Snell <jasnell@gmail.com><= /span> wrote:
Huh? This = particular conversation is extremely confusing at this point. Link rel valu= es are neither secure nor insecure. They're JUST labels. They provide n= o information at all about the security requirements of the linked resource= .

That has been the case so far.
<= br>
This thread is a proposal about changing that, and now assign= ing meaning to the labels. =C2=A0If the label beings with "https:"= ;, we consider it a "secure rel" and never expect it to be transm= itted over plain HTTP. =C2=A0That means servers SHOULD filter it from their= responses over HTTP, but most importantly, and paramount to the security: = clients MUST NOT accept secure rels over HTTP. =C2=A0If they see one, they = must filter it out.

If I have...

(A)
{
=C2=A0 "rel": "canonical",
=C2=A0 "href": &= quot;http://example.or= g/foo"
}

(B)
{
=C2=A0 "rel": "can= onical",=C2=A0
= =C2=A0 "href": "https://example.org/foo"
}

Then (A) is insecure and (B) is secure. It's that simple.=

That's not my proposal at all. =C2=A0M= aybe I should use a new term. =C2=A0My proposal is attaching meaning to the= "rel", not the "href".


--047d7bea3a2041932504d0c03372-- From bradfitz@google.com Thu Dec 13 10:39:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616AF21F88D8 for ; Thu, 13 Dec 2012 10:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m15eIKmD1wWK for ; Thu, 13 Dec 2012 10:39:46 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0822A21F85C0 for ; Thu, 13 Dec 2012 10:39:45 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1880638wib.13 for ; Thu, 13 Dec 2012 10:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EibG0LK/p/TqcL9ZZzvIPPyWx42BK9VO4nnT0gdogWU=; b=BzZwPmUyt4NufTje+sQDgISD8NQp3U61fem14IcsVcknD6i0wuJznoL2cfWuCSkNag zZqJeuMRbhIjgZkovmQAHV5SKrCCuBWcZkQ+/e5sFnT89XsFMt29fthpA34fU5+2DLmA nfwxxpDSUQJW8nFPPpRuVr66iEQPftMrLirBWwuGXZJaLt8UmaigPfKntx9bNoPAYXeV J9QYm3EmdM8ssMCrjsioqnFXZAnD41wSg3gM3y67IzQpw+Z8D93+VLv1FYwwE9Hrw3/G LjrS6lDTSQ6YCTgKx62MW3lHVEITmP0P8H1YmR5LPdFU39rdN/fX7EIbX/YqT/KYClm+ 2qqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EibG0LK/p/TqcL9ZZzvIPPyWx42BK9VO4nnT0gdogWU=; b=JUH1ExSU6DRat1zBzk4KROYf7BWNu9se5Z00Ukha1IwQe1X8Ry8aEuiZW6MJrUFrlZ b3iSU6dCU3rqbSdKDi9ojPbirUmunlAhyS7AXtsaLhwOK9tSWg8J9rZRwOmhAqUP7SY3 CHNJZw4kH3NTy71qUUq6ZiGvqyI8UXWIzZk6pWuYoAycVZ0JEzfR++EuwITYmndvYepK ezT83XgCLHMV4AIxNWc7zMaBlMVlEqdQla13t0Qgh2FrrbVGX7WygD0p3MEaoCPmWGBH 85ugDodB5ettjiahTxFZESupc1xcU4RgQE42wTRAeXmduZDfWa2+Bl3WrTGsQ9qqF7R7 nSMQ== MIME-Version: 1.0 Received: by 10.180.99.227 with SMTP id et3mr5109402wib.6.1355423985133; Thu, 13 Dec 2012 10:39:45 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 10:39:45 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 10:39:45 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=f46d041826aa2766f104d0c03dd6 X-Gm-Message-State: ALoCoQnIWupCHKX5SStWKy52JOBYS2j5EN+DlOrq4wG35hPTO2tPw0+ySS0Tr7ayFva5DpJ9VeGy2BTR9VVJndlQSTed17MEcgmPRvn2pRmsK5HsjgLSPg/Nmo/xE0zCKvl/MFnK78rwV/GUdBpgN2jOciHYTwEGFaJ9GGHPdSPlybLQZwiP8EZ+IO7qpYpwd8vDCPN6j3P/ Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:39:47 -0000 --f46d041826aa2766f104d0c03dd6 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote: > > > > On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick wrote: > >> [snip] >> >> >>> No... that's just nonsense. The real issue here is that the client has >>> absolutely no way of detecting that the evil hijacker intercepted the >>> request and provided false information in the first place. It should not >>> matter at all if the returned document contains link rels with "https:" in >>> them or not. >>> >> >> You can never detect with HTTP that the connection was intercepted. That >> doesn't matter, because the client does know one thing: that it used HTTP >> (and not HTTPS). So the client can filter out links which should not ever >> appear over plain HTTP. I'm proposing that rels which begin with "https:" >> should never go over HTTP, and I've started calling those "secure rels". >> Maybe that's a bad name, if enough people (including you now, in your >> earlier email) assume that I'm talking about the value (the href). >> >> I'm open to alternative name suggestions. >> >> > I'm -1 on the whole proposal. The notion of "insecure" and "secure" link > relations makes absolutely no sense at all. > I'd like to ask that you think about and understand it before being so negative on it. I promise it makes sense. > It may not be possible to detect if the HTTP connection was intercepted, > but it is possible to determine if the information provided is trustworthy. > That is what cryptographic signatures are for. > That is outside the scope of WebFinger, and may be used in subsequent hops. We're trying to provide a secure basis for the first hop. If we can't get any attribute securely for foo@example.com, where are we getting the public key from to verify subsequent use of "cryptographic signatures". --f46d041826aa2766f104d0c03dd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 10:36 AM, James M Snell <jasnell@gmail.com><= /span> wrote:



On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com<= /a>> wrote:
[snip]


No... that's just= nonsense. The real issue here is that the client has absolutely no way of = detecting that the evil hijacker intercepted the request and provided false= information in the first place. It should not matter at all if the returne= d document contains link rels with "https:" in them or not.=C2=A0=

You can never detect wit= h HTTP that the connection was intercepted. =C2=A0That doesn't matter, = because the client does know one thing: =C2=A0that it used HTTP (and not HT= TPS). =C2=A0So the client can filter out links which should not ever appear= over plain HTTP. =C2=A0I'm proposing that rels which begin with "= https:" should never go over HTTP, and I've started calling those = "secure rels". =C2=A0Maybe that's a bad name, if enough peopl= e (including you now, in your earlier email) assume that I'm talking ab= out the value (the href).

I'm open to alternative name suggestions.


I'm -1 on the w= hole proposal. The notion of "insecure" and "secure" li= nk relations makes absolutely no sense at all.

I'd like to ask that you think about and understand it = before being so negative on it.

I promise it= makes sense.
=C2=A0
It may not be possible to detect if the HTTP co= nnection was intercepted, but it is possible to determine if the informatio= n provided is trustworthy. That is what cryptographic signatures are for.

That is outside the scope of WebFinger, an= d may be used in subsequent hops. =C2=A0We're trying to provide a secur= e basis for the first hop. =C2=A0If we can't get any attribute securely= for foo@example.com, where are we g= etting the public key from to verify subsequent use of "cryptographic = signatures".

--f46d041826aa2766f104d0c03dd6-- From perpetual-tripper@wwelves.org Thu Dec 13 10:41:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A250E21F89DF for ; Thu, 13 Dec 2012 10:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kZZW11zbMTy for ; Thu, 13 Dec 2012 10:41:13 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 13D2721F88D8 for ; Thu, 13 Dec 2012 10:41:13 -0800 (PST) X-Originating-IP: 217.70.178.131 Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D763F1720A1; Thu, 13 Dec 2012 19:41:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mGM7FP42ozbb; Thu, 13 Dec 2012 19:41:00 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 84430172070; Thu, 13 Dec 2012 19:41:00 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: James M Snell In-reply-to: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 18:40:59 +0000 Message-Id: <1355423834-sup-9480@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:41:13 -0000 Excerpts from James M Snell's message of 2012-12-13 18:20:32 +0000: =20 > The real question here appears to be one of integrity: how does the cli= ent > know that the information provided in the WebFinger document is the rig= ht > information from a trusted source? HTTPS isn't enough to verify that. I= f > you want to do it right, you add a cryptographic signature to the docum= ent > generated with a key that the client trusts. Once the client verifies t= hat > the information is trustworthy, it can scan through looking for the lin= ks > it wants. If it needs a secure link, it looks for ones whose href > attributes specify "https". how do you see implementing such cryptographic signatures from your scena= rio? From laurentwalter.goix@telecomitalia.it Thu Dec 13 10:43:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6721F89FD for ; Thu, 13 Dec 2012 10:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPoUrgRkcCuC for ; Thu, 13 Dec 2012 10:43:14 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 802F521F89F2 for ; Thu, 13 Dec 2012 10:43:13 -0800 (PST) Content-Type: multipart/mixed; boundary="_2f4962b8-0d53-40ba-b7cd-6a4b5e4417f6_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 13 Dec 2012 19:43:11 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 13 Dec 2012 19:43:11 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 13 Dec 2012 19:43:03 +0100 Thread-Topic: [webfinger] secure links with https rels Thread-Index: Ac3ZYbPIZGK5Kmp4Sri1to9rWshOKg== Message-ID: <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Brad Fitzpatrick , "webfinger@googlegroups.com" , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:43:15 -0000 --_2f4962b8-0d53-40ba-b7cd-6a4b5e4417f6_ Content-Type: multipart/alternative; boundary="_000_31369E3389A8491FA2D5D59ED63813FEtelecomitaliait_" --_000_31369E3389A8491FA2D5D59ED63813FEtelecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIHlvdSBzdWdnZXN0aW5nIEphbWVzIHRvIGFkZCBhICdzaWduYXR1cmUnIHByb3BlcnR5IHRv IGVhY2ggbGluayByZWwgY3JlYXRlZCB3aXRoIHRoZSBzZXJ2ZXIgcHJpdmF0ZSBrZXk/IEF0IGxl YXN0IGZvciB0aGUgc2VjdXJlIG9uZXMgd2hlbiBwcm92aWRlZCBvdmVyIHBsYWluIGh0dHA/DQpU aGlzIHdheSBhIGNsaWVudCByZXRyaWV2aW5nIGEgd2YganJkIG92ZXIgaHR0cCBNVVNUIGNoZWNr IHRoZSBzaWduYXR1cmUgcHJvcGVydHkgZm9yICdzZWN1cmUnIGhyZWZzIGFuZCBNVVNUIGRpc2Nh cmQgdGhlbSBpZiBzdWNoIHNpZ25hdHVyZSBpcyBub3QgcHJvdmlkZWQgPw0KSW4gdGhpcyBjYXNl IHRob3VnaCB0aGUgcHVibGljIGtleSBzaG91bGQgYmUgcHJvdmlkZWQgc29tZXdoZXJlIChpZiB3 ZSdyZSBub3QgdXNpbmcgaHR0cHMpLi4uDQoNCkkgcmVtZW1iZXIgc29tZXRoaW5nIHNpbWlsYXIg d2l0aCB4cmQgc2lnbmF0dXJlIGNoZWNrIGluIHRoZSBvcmlnaW5hbCB3ZiAnZXhwbGFuYXRpb24n IHNvbWUgeWVhcnMgYWdvLCBidXQgdGhhdCB3YXMgZm9yIHRoZSB3aG9sZSBkb2MgaWYgSSByZW1l bWJlciBjb3JyZWN0bHkuIFdlIHdvdWxkIHRoZW4gbmVlZCBlbmhhbmNlIGpyZCB3aXRoIGEgbmV3 IHByb3BlcnR5LCBpZiBhbGwgdGhpcyBtYWtlcyBzZW5zZS4NCg0KV2FsdGVyDQoNCg0KTGUgMTMg ZMOpYy4gMjAxMiDDoCAxOToyMCwgIkphbWVzIE0gU25lbGwiIDxqYXNuZWxsQGdtYWlsLmNvbTxt YWlsdG86amFzbmVsbEBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCkh1aD8gVGhpcyBwYXJ0aWN1 bGFyIGNvbnZlcnNhdGlvbiBpcyBleHRyZW1lbHkgY29uZnVzaW5nIGF0IHRoaXMgcG9pbnQuIExp bmsgcmVsIHZhbHVlcyBhcmUgbmVpdGhlciBzZWN1cmUgbm9yIGluc2VjdXJlLiBUaGV5J3JlIEpV U1QgbGFiZWxzLiBUaGV5IHByb3ZpZGUgbm8gaW5mb3JtYXRpb24gYXQgYWxsIGFib3V0IHRoZSBz ZWN1cml0eSByZXF1aXJlbWVudHMgb2YgdGhlIGxpbmtlZCByZXNvdXJjZS4NCg0KSWYgSSBoYXZl Li4uDQoNCihBKQ0Kew0KICAicmVsIjogImNhbm9uaWNhbCIsDQogICJocmVmIjogImh0dHA6Ly9l eGFtcGxlLm9yZy9mb28iDQp9DQoNCihCKQ0Kew0KICAicmVsIjogImNhbm9uaWNhbCIsDQogICJo cmVmIjogImh0dHBzOi8vZXhhbXBsZS5vcmcvZm9vIg0KfQ0KDQpUaGVuIChBKSBpcyBpbnNlY3Vy ZSBhbmQgKEIpIGlzIHNlY3VyZS4gSXQncyB0aGF0IHNpbXBsZS4gQWxsIHRoaXMgdGFsayBvZiBj aGVja2luZyByZWwgdmFsdWVzIGZvciAiaHR0cHM6IiBpcyBub25zZW5zZS4NCg0KVGhlIHJlYWwg cXVlc3Rpb24gaGVyZSBhcHBlYXJzIHRvIGJlIG9uZSBvZiBpbnRlZ3JpdHk6IGhvdyBkb2VzIHRo ZSBjbGllbnQga25vdyB0aGF0IHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZCBpbiB0aGUgV2ViRmlu Z2VyIGRvY3VtZW50IGlzIHRoZSByaWdodCBpbmZvcm1hdGlvbiBmcm9tIGEgdHJ1c3RlZCBzb3Vy Y2U/IEhUVFBTIGlzbid0IGVub3VnaCB0byB2ZXJpZnkgdGhhdC4gSWYgeW91IHdhbnQgdG8gZG8g aXQgcmlnaHQsIHlvdSBhZGQgYSBjcnlwdG9ncmFwaGljIHNpZ25hdHVyZSB0byB0aGUgZG9jdW1l bnQgZ2VuZXJhdGVkIHdpdGggYSBrZXkgdGhhdCB0aGUgY2xpZW50IHRydXN0cy4gT25jZSB0aGUg Y2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIHRydXN0d29ydGh5LCBpdCBj YW4gc2NhbiB0aHJvdWdoIGxvb2tpbmcgZm9yIHRoZSBsaW5rcyBpdCB3YW50cy4gSWYgaXQgbmVl ZHMgYSBzZWN1cmUgbGluaywgaXQgbG9va3MgZm9yIG9uZXMgd2hvc2UgaHJlZiBhdHRyaWJ1dGVz IHNwZWNpZnkgImh0dHBzIi4NCg0KLSBKYW1lcw0KDQoNCk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0 IDk6MjggQU0sIEJyYWQgRml0enBhdHJpY2sgPGJyYWRmaXR6QGdvb2dsZS5jb208bWFpbHRvOmJy YWRmaXR6QGdvb2dsZS5jb20+PiB3cm90ZToNCk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0IDk6MjEg QU0sIEdvaXggTGF1cmVudCBXYWx0ZXIgPGxhdXJlbnR3YWx0ZXIuZ29peEB0ZWxlY29taXRhbGlh Lml0PG1haWx0bzpsYXVyZW50d2FsdGVyLmdvaXhAdGVsZWNvbWl0YWxpYS5pdD4+IHdyb3RlOg0K SW5kZWVkIMKrIGhyZWYgwrsgc2hvdWxkIGJlIGNoZWNrZWQgaW5zdGVhZCBvZiDCqyByZWwgwrsg aW4gb3JkZXIgdG8gc3VwcG9ydCByZWdpc3RlcmVkIHZhbHVlcyBhcyB3ZWxsLiBQbHVzIHNvbWUg bGluayByZWxzIG1heSBub3QgYmUgaHR0cCAodGhpbmsgYXQgYWNjdDosIHNpcDosIHdzOiwgZWNj KS4gU28gdGhlIGNsaWVudCBtYXkgbmVlZCB0byBjaGVjayBhcyB3ZWxsIGZvciBzaXBzOiwgd3Nz OiwgYWNjdHM6Pw0KQWx0aG91Z2ggSSBjYW4gdW5kZXJzdGFuZCB0aGUgaXNzdWUgSeKAmW0gc3Rh cnRpbmcgdG8gZ2V0IGNvbmZ1c2VkIGFzIHdlbGzigKYNCg0KTm8sIHRoZSBrZXkgKHRoZSBsaW5r LnJlbCkgaXMgd2hhdCBpcyBzZWN1cmUsIG5vdCB0aGUgdmFsdWUgKHRoZSBsaW5rLmhyZWYpLg0K DQpTbyBhbGwgb2YgYWNjdDosIHNpcDosIHdzOiwgZGF0YTosIGV0YyBjYW4gYmUgdXNlZCBhcyBh cyB0aGUgdmFsdWUsIHNpbmNlIHRoYXQncyBub3QgdGhlIHBhcnQgdGhhdCBpcyBjaGVja2VkIGZv ciBhbiAiaHR0cHM6IiBwcmVmaXguDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCndlYmZpbmdlciBtYWlsaW5nIGxpc3QNCndlYmZpbmdlckBpZXRm Lm9yZzxtYWlsdG86d2ViZmluZ2VyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby93ZWJmaW5nZXINCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFs bGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGlj YXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZh bnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3Nh bWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8g cGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEg Y29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1 emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25m aWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQg Zm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRp bmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRo YW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFp bWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24g w6ggbmVjZXNzYXJpby4NCg0K --_000_31369E3389A8491FA2D5D59ED63813FEtelecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkFyZSB5b3Ugc3VnZ2VzdGluZyBKYW1lcyB0byBhZGQgYSAnc2lnbmF0dXJlJyBwcm9wZXJ0 eSB0byBlYWNoIGxpbmsgcmVsIGNyZWF0ZWQgd2l0aCB0aGUgc2VydmVyIHByaXZhdGUga2V5PyBB dCBsZWFzdCBmb3IgdGhlIHNlY3VyZSBvbmVzIHdoZW4gcHJvdmlkZWQgb3ZlciBwbGFpbiBodHRw PzwvZGl2Pg0KPGRpdj5UaGlzIHdheSBhIGNsaWVudCByZXRyaWV2aW5nIGEgd2YganJkIG92ZXIg aHR0cCBNVVNUIGNoZWNrIHRoZSBzaWduYXR1cmUgcHJvcGVydHkgZm9yICdzZWN1cmUnIGhyZWZz IGFuZCBNVVNUIGRpc2NhcmQgdGhlbSBpZiBzdWNoIHNpZ25hdHVyZSBpcyBub3QgcHJvdmlkZWQg PzwvZGl2Pg0KPGRpdj5JbiB0aGlzIGNhc2UgdGhvdWdoIHRoZSBwdWJsaWMga2V5IHNob3VsZCBi ZSBwcm92aWRlZCBzb21ld2hlcmUgKGlmIHdlJ3JlIG5vdCB1c2luZyBodHRwcykuLi48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgcmVtZW1iZXIgc29tZXRoaW5nIHNpbWlsYXIgd2l0 aCB4cmQgc2lnbmF0dXJlIGNoZWNrIGluIHRoZSBvcmlnaW5hbCB3ZiAnZXhwbGFuYXRpb24nIHNv bWUgeWVhcnMgYWdvLCBidXQgdGhhdCB3YXMgZm9yIHRoZSB3aG9sZSBkb2MgaWYgSSByZW1lbWJl ciBjb3JyZWN0bHkuIFdlIHdvdWxkIHRoZW4gbmVlZCBlbmhhbmNlIGpyZCB3aXRoIGEgbmV3IHBy b3BlcnR5LCBpZiBhbGwgdGhpcyBtYWtlcyBzZW5zZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PldhbHRlcjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQpMZSAxMyBkw6ljLiAyMDEyIMOg IDE5OjIwLCAmcXVvdDtKYW1lcyBNIFNuZWxsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amFz bmVsbEBnbWFpbC5jb20iPmphc25lbGxAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6 PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2 PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonY291cmllciBuZXcnLG1vbm9zcGFjZSI+SHVoPyBU aGlzIHBhcnRpY3VsYXIgY29udmVyc2F0aW9uIGlzIGV4dHJlbWVseSBjb25mdXNpbmcgYXQgdGhp cyBwb2ludC4gTGluayByZWwgdmFsdWVzIGFyZSBuZWl0aGVyIHNlY3VyZSBub3IgaW5zZWN1cmUu IFRoZXkncmUgSlVTVCBsYWJlbHMuIFRoZXkgcHJvdmlkZSBubyBpbmZvcm1hdGlvbiBhdCBhbGwg YWJvdXQgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cw0KIG9mIHRoZSBsaW5rZWQgcmVzb3VyY2Uu PC9zcGFuPjxicj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3Bh Y2UiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsbW9u b3NwYWNlIj5JZiBJIGhhdmUuLi48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJp ZXIgbmV3LG1vbm9zcGFjZSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJj b3VyaWVyIG5ldywgbW9ub3NwYWNlIj4oQSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 ImNvdXJpZXIgbmV3LG1vbm9zcGFjZSI+ezwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Y291cmllciBuZXcsbW9ub3NwYWNlIj4mbmJzcDsgJnF1b3Q7cmVsJnF1b3Q7OiAmcXVvdDtjYW5v bmljYWwmcXVvdDssPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxt b25vc3BhY2UiPiZuYnNwOyAmcXVvdDtocmVmJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwOi8v ZXhhbXBsZS5vcmcvZm9vIj5odHRwOi8vZXhhbXBsZS5vcmcvZm9vPC9hPiZxdW90OzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsbW9ub3NwYWNlIj59PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsbW9ub3NwYWNlIj4oQik8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LG1vbm9zcGFjZSI+ezwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsbW9ub3NwYWNlIj4mbmJzcDsg JnF1b3Q7cmVsJnF1b3Q7OiAmcXVvdDtjYW5vbmljYWwmcXVvdDssJm5ic3A7PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPiZuYnNwOyAmcXVvdDto cmVmJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUub3JnL2ZvbyI+aHR0cHM6 Ly9leGFtcGxlLm9yZy9mb288L2E+JnF1b3Q7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPn08L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 ImNvdXJpZXIgbmV3LG1vbm9zcGFjZSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPlRoZW4gKEEpIGlzIGluc2VjdXJlIGFuZCAoQikg aXMgc2VjdXJlLiBJdCdzIHRoYXQgc2ltcGxlLiBBbGwgdGhpcyB0YWxrIG9mIGNoZWNraW5nIHJl bCB2YWx1ZXMgZm9yICZxdW90O2h0dHBzOiZxdW90OyBpcyBub25zZW5zZS48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LG1vbm9zcGFjZSI+PGJyPg0KPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPlRoZSByZWFsIHF1 ZXN0aW9uIGhlcmUgYXBwZWFycyB0byBiZSBvbmUgb2YgaW50ZWdyaXR5OiBob3cgZG9lcyB0aGUg Y2xpZW50IGtub3cgdGhhdCB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQgaW4gdGhlIFdlYkZpbmdl ciBkb2N1bWVudCBpcyB0aGUgcmlnaHQgaW5mb3JtYXRpb24gZnJvbSBhIHRydXN0ZWQgc291cmNl PyBIVFRQUyBpc24ndCBlbm91Z2ggdG8gdmVyaWZ5IHRoYXQuDQogSWYgeW91IHdhbnQgdG8gZG8g aXQgcmlnaHQsIHlvdSBhZGQgYSBjcnlwdG9ncmFwaGljIHNpZ25hdHVyZSB0byB0aGUgZG9jdW1l bnQgZ2VuZXJhdGVkIHdpdGggYSBrZXkgdGhhdCB0aGUgY2xpZW50IHRydXN0cy4gT25jZSB0aGUg Y2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIHRydXN0d29ydGh5LCBpdCBj YW4gc2NhbiB0aHJvdWdoIGxvb2tpbmcgZm9yIHRoZSBsaW5rcyBpdCB3YW50cy4gSWYgaXQgbmVl ZHMgYSBzZWN1cmUNCiBsaW5rLCBpdCBsb29rcyBmb3Igb25lcyB3aG9zZSBocmVmIGF0dHJpYnV0 ZXMgc3BlY2lmeSAmcXVvdDtodHRwcyZxdW90Oy48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9ImNvdXJpZXIgbmV3LG1vbm9zcGFjZSI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiPi0gSmFtZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0IDk6MjggQU0sIEJyYWQgRml0enBhdHJpY2sgPHNwYW4g ZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpicmFkZml0ekBnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YnJhZGZpdHpAZ29vZ2xlLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+ DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMHB0 Ij4NCjxkaXYgY2xhc3M9ImltIj5PbiBUaHUsIERlYyAxMywgMjAxMiBhdCA5OjIxIEFNLCBHb2l4 IExhdXJlbnQgV2FsdGVyIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bGF1 cmVudHdhbHRlci5nb2l4QHRlbGVjb21pdGFsaWEuaXQiIHRhcmdldD0iX2JsYW5rIj5sYXVyZW50 d2FsdGVyLmdvaXhAdGVsZWNvbWl0YWxpYS5pdDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9ImltIj4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJGUiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5J bmRlZWQgwqsmbmJzcDtocmVmJm5ic3A7wrsgc2hvdWxkIGJlIGNoZWNrZWQgaW5zdGVhZCBvZiDC qyZuYnNwO3JlbCZuYnNwO8K7IGluIG9yZGVyIHRvIHN1cHBvcnQgcmVnaXN0ZXJlZCB2YWx1ZXMg YXMgd2VsbC4gUGx1cyBzb21lIGxpbmsgcmVscyBtYXkgbm90IGJlIGh0dHAgKHRoaW5rDQogYXQg YWNjdDosIHNpcDosIHdzOiwgZWNjKS4gU28gdGhlIGNsaWVudCBtYXkgbmVlZCB0byBjaGVjayBh cyB3ZWxsIGZvciBzaXBzOiwgd3NzOiwgYWNjdHM6Pw0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMWY0OTdkIj5BbHRob3VnaCBJIGNhbiB1bmRlcnN0YW5kIHRoZSBpc3N1 ZSBJ4oCZbSBzdGFydGluZyB0byBnZXQgY29uZnVzZWQgYXMgd2VsbOKApjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj5ObywgdGhlIGtleSAodGhlIGxpbmsucmVsKSBpcyB3aGF0IGlzIHNlY3VyZSwgbm90IHRo ZSB2YWx1ZSAodGhlIGxpbmsuaHJlZikuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5T byBhbGwgb2YgYWNjdDosIHNpcDosIHdzOiwgZGF0YTosIGV0YyBjYW4gYmUgdXNlZCBhcyBhcyB0 aGUgdmFsdWUsIHNpbmNlIHRoYXQncyBub3QgdGhlIHBhcnQgdGhhdCBpcyBjaGVja2VkIGZvciBh biAmcXVvdDtodHRwczomcXVvdDsgcHJlZml4LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCndlYmZpbmdlciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86d2ViZmluZ2VyQGlldGYub3JnIj53ZWJmaW5nZXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJmaW5nZXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYmZpbmdl cjwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0Kc3Bhbi5H cmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLS0+DQo8L3N0eWxl Pg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsOyBmb250LXNpemU6MTJw eDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9IjM5NSI+DQo8ZGl2IGFs aWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpq dXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBz b25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEg ZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRh bGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUg dmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVy cm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5p Y2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUs IEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0ianVzdGlmeSI+PHNwYW4g Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6 bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5UaGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpW ZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3BhbiBjbGFzcz0iR3JhbUUi PmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNv cHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlcg0KIGJ5IHJl dHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJkYW5hIj48aW1nIHNyYz0i Y2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXIiIGFsdD0i cmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQwIj5SaXNwZXR0YSBsJ2Ft YmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uPC9z cGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_31369E3389A8491FA2D5D59ED63813FEtelecomitaliait_-- --_2f4962b8-0d53-40ba-b7cd-6a4b5e4417f6_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_2f4962b8-0d53-40ba-b7cd-6a4b5e4417f6_-- From perpetual-tripper@wwelves.org Thu Dec 13 10:47:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8176121F8A0F for ; Thu, 13 Dec 2012 10:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePV+IWZ+LpTd for ; Thu, 13 Dec 2012 10:47:29 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id CE84621F8A00 for ; Thu, 13 Dec 2012 10:47:28 -0800 (PST) X-Originating-IP: 217.70.178.152 Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 2628DA8076; Thu, 13 Dec 2012 19:47:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ofbnTeB9C7dZ; Thu, 13 Dec 2012 19:47:16 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BB4E6A809E; Thu, 13 Dec 2012 19:47:16 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: James M Snell In-reply-to: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> Date: Thu, 13 Dec 2012 18:47:16 +0000 Message-Id: <1355424257-sup-6787@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:47:29 -0000 Excerpts from James M Snell's message of 2012-12-13 18:36:24 +0000: > On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick wrote: >=20 > > [snip] > > > >> > >> No... that's just nonsense. The real issue here is that the client h= as > >> absolutely no way of detecting that the evil hijacker intercepted th= e > >> request and provided false information in the first place. It should= not > >> matter at all if the returned document contains link rels with "http= s:" in > >> them or not. > >> > > > > You can never detect with HTTP that the connection was intercepted. = That > > doesn't matter, because the client does know one thing: that it used= HTTP > > (and not HTTPS). So the client can filter out links which should not= ever > > appear over plain HTTP. I'm proposing that rels which begin with "ht= tps:" > > should never go over HTTP, and I've started calling those "secure rel= s". > > Maybe that's a bad name, if enough people (including you now, in you= r > > earlier email) assume that I'm talking about the value (the href). > > > > I'm open to alternative name suggestions. > > > > > I'm -1 on the whole proposal. The notion of "insecure" and "secure" lin= k > relations makes absolutely no sense at all. It may not be possible to > detect if the HTTP connection was intercepted, but it is possible to > determine if the information provided is trustworthy. That is what > cryptographic signatures are for. -1 on statements like *makes absolutely no sense at all* unless explicitl= y stating in them *TO ME* ;) From laurentwalter.goix@telecomitalia.it Thu Dec 13 10:51:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035F621F88D1 for ; Thu, 13 Dec 2012 10:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHTNjoBWMSap for ; Thu, 13 Dec 2012 10:51:00 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7013521F88BF for ; Thu, 13 Dec 2012 10:50:58 -0800 (PST) Content-Type: multipart/mixed; boundary="_ab1223f1-0f71-4b0e-b3c5-46f99b4decbb_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 13 Dec 2012 19:50:54 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 13 Dec 2012 19:50:54 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 13 Dec 2012 19:50:47 +0100 Thread-Topic: [webfinger] secure links with https rels Thread-Index: Ac3ZYseuKrXNWzBlQFOJdFpyoT4ZuQ== Message-ID: <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:51:01 -0000 --_ab1223f1-0f71-4b0e-b3c5-46f99b4decbb_ Content-Type: multipart/alternative; boundary="_000_2C6600167BF94975B7B57EFC1BDF88AFtelecomitaliait_" --_000_2C6600167BF94975B7B57EFC1BDF88AFtelecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlbiBpdCBtZWFucyB0aGF0IG5vIGlhbmEtcmVnaXN0ZXJlZCBsaW5rIHJlbCBjb3VsZCBldmVy IGJlIGNvbnNpZGVyZWQgYXMgc2VjdXJlLCBjb3JyZWN0PyBUaGF0IHNlZW1zIHdheSB0b28gbGlt aXRpbmcgdG8gbWUuLi4NCg0KTGUgMTMgZMOpYy4gMjAxMiDDoCAxOTozMywgIkJyYWQgRml0enBh dHJpY2siIDxicmFkZml0ekBnb29nbGUuY29tPG1haWx0bzpicmFkZml0ekBnb29nbGUuY29tPj4g YSDDqWNyaXQgOg0KDQpPbiBUaHUsIERlYyAxMywgMjAxMiBhdCAxMDoyNCBBTSwgR29peCBMYXVy ZW50IFdhbHRlciA8bGF1cmVudHdhbHRlci5nb2l4QHRlbGVjb21pdGFsaWEuaXQ8bWFpbHRvOmxh dXJlbnR3YWx0ZXIuZ29peEB0ZWxlY29taXRhbGlhLml0Pj4gd3JvdGU6DQpCaWxsIChNaWxscykg aXMgcHJvcG9zaW5nIHRvIHJlZ2lzdGVyIHNvbWUgb2F1dGgqIGxpbmsgcmVscyB0aGF0IHdvdWxk IGJlIHVzZWZ1bCBmb3IgYXV0b2NvbmZpZ3VyYXRpb24uIFRoZXNlIHdvdWxkIG5vdCBiZSBwcmVm aXhlZCBieSBodHRwcyBhcyBrZXlzLCBidXQgdGhlIHZhbHVlcyBjZXJ0YWlubHkuLi4gKEFuZCBJ J2QgbGlrZSBjb25zaWRlcmluZyB0aGVtIGFzICdzZWN1cmUgbGlua3MnKQ0KDQpUaGF0IHdvdWxk bid0IHdvcmsuICBUcnkgaXQgb3V0IHdpdGggdGhlIGRvd25ncmFkZSBhdHRhY2sgc2NlbmFyaW8g SSBkZXNjcmliZWQgZWFybGllciB0byBQYXVsLg0KDQpUaGUgY2xpZW50IGlzIG9ubHkgbG9va2lu ZyBmb3IgYW5kIGFzc2lnbmluZyBtZWFuaW5nIHRvIGtleXMgKHRoZSAicmVsIiB2YWx1ZXMpLCBz byBtYXJraW5nIGEgcmVsIGFzICJzZWN1cmUiIGluIHRoZSB2YWx1ZSBjYW4gYmUgZmFrZWQgYnkg dGhlIGF0dGFja2VyLCBhbmQgbWFya2luZyB0aGUgcmVsIGFzIHNlY3VyZSBpbiBhIG5ldyBhdHRy aWJ1dGUgY2FuIGFsc28gYmUgZmFrZWQgYnkgdGhlIGF0dGFja2VyLg0KDQpRdWVzdG8gbWVzc2Fn Z2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxs ZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9u aSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUg YWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwg Y29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwM0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_2C6600167BF94975B7B57EFC1BDF88AFtelecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlRoZW4gaXQgbWVhbnMgdGhhdCBubyBpYW5hLXJlZ2lzdGVyZWQgbGluayByZWwgY291bGQg ZXZlciBiZSBjb25zaWRlcmVkIGFzIHNlY3VyZSwgY29ycmVjdD8gVGhhdCBzZWVtcyB3YXkgdG9v IGxpbWl0aW5nIHRvIG1lLi4uPGJyPg0KPGJyPg0KTGUgMTMgZMOpYy4gMjAxMiDDoCAxOTozMywg JnF1b3Q7QnJhZCBGaXR6cGF0cmljayZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyYWRmaXR6 QGdvb2dsZS5jb20iPmJyYWRmaXR6QGdvb2dsZS5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8 YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDEwcHQiPk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0IDEwOjI0IEFNLCBHb2l4IExhdXJlbnQg V2FsdGVyDQo8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpsYXVyZW50d2FsdGVy LmdvaXhAdGVsZWNvbWl0YWxpYS5pdCIgdGFyZ2V0PSJfYmxhbmsiPmxhdXJlbnR3YWx0ZXIuZ29p eEB0ZWxlY29taXRhbGlhLml0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5CaWxsIChNaWxscykgaXMgcHJvcG9zaW5nIHRv IHJlZ2lzdGVyIHNvbWUgb2F1dGgqIGxpbmsgcmVscyB0aGF0IHdvdWxkIGJlIHVzZWZ1bCBmb3Ig YXV0b2NvbmZpZ3VyYXRpb24uIFRoZXNlIHdvdWxkIG5vdCBiZSBwcmVmaXhlZCBieSBodHRwcyBh cyBrZXlzLCBidXQgdGhlIHZhbHVlcyBjZXJ0YWlubHkuLi4gKEFuZCBJJ2QgbGlrZSBjb25zaWRl cmluZyB0aGVtIGFzICdzZWN1cmUgbGlua3MnKTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IHdvdWxkbid0IHdvcmsuICZuYnNw O1RyeSBpdCBvdXQgd2l0aCB0aGUgZG93bmdyYWRlIGF0dGFjayBzY2VuYXJpbyBJIGRlc2NyaWJl ZCBlYXJsaWVyIHRvIFBhdWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgY2xp ZW50IGlzIG9ubHkgbG9va2luZyBmb3IgYW5kIGFzc2lnbmluZyBtZWFuaW5nIHRvIGtleXMgKHRo ZSAmcXVvdDtyZWwmcXVvdDsgdmFsdWVzKSwgc28gbWFya2luZyBhIHJlbCBhcyAmcXVvdDtzZWN1 cmUmcXVvdDsgaW4gdGhlIHZhbHVlIGNhbiBiZSBmYWtlZCBieSB0aGUgYXR0YWNrZXIsIGFuZCBt YXJraW5nIHRoZSByZWwgYXMgc2VjdXJlIGluIGEgbmV3IGF0dHJpYnV0ZSBjYW4gYWxzbyBiZSBm YWtlZCBieSB0aGUgYXR0YWNrZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwh LS0NCnNwYW4uR3JhbUUge21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0t Pg0KPC9zdHlsZT4NCjx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9u dC1zaXplOjEycHg7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUi Pg0KPGRpdiBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kg YWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5k aWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRl cml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdv cm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRp YXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp c3RydXppb25lLCBHcmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3Rp ZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxp bmUtaGVpZ2h0Om5vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xh c3M9IkdyYW1FIj5pczwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNp LWxhbmd1YWdlOkVOLUdCIj5jb25maWRlbnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0 aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXINCiBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+ PGltZyBzcmM9ImNpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFp bWVyIiBhbHQ9InJpc3BldHRhIGwnYW1iaWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+Umlz cGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNl c3NhcmlvLjwvc3Bhbj48L2I+DQo8cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2C6600167BF94975B7B57EFC1BDF88AFtelecomitaliait_-- --_ab1223f1-0f71-4b0e-b3c5-46f99b4decbb_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_ab1223f1-0f71-4b0e-b3c5-46f99b4decbb_-- From bradfitz@google.com Thu Dec 13 10:52:58 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98F721F85BA for ; Thu, 13 Dec 2012 10:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79rYHK2qQ1PW for ; Thu, 13 Dec 2012 10:52:57 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAA0C21F85A4 for ; Thu, 13 Dec 2012 10:52:55 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1134267wey.31 for ; Thu, 13 Dec 2012 10:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NfvoYKEaO5m4C9/XQD8sD0Fc557ZUftdR8/gjFit6oo=; b=W49g/d/Hg+kjORBYyaLMxSKbZpyMZwHTgjR/iNaPUPjvMAhr05SRCOZWAhn9RuNDLN BcG3cCXUpVEF0E0enmdjj82wGki17ieNLvjp7ZzXHG+GcRCAGIMkaa3l52SPbyCJWSw4 XpbT/qdvGaKYGPfPNa/94LraxdOfPEy+XjigbnMH1D1UwWZZbDT6S24qaDoV2tl5XuFU 8QWGbhN2N417bZbRy/xbsjAHzEeThuufypyb68ewKYAZV7PtWU4Ht4ijZEJYcrcuUbLy p8oz4SVkAw++LaWQbgXG+7kXl3lM7e4V0w06Una23F9dftFca0t2snbe6R3kaSBTN9Y5 fSeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NfvoYKEaO5m4C9/XQD8sD0Fc557ZUftdR8/gjFit6oo=; b=TOx2bCpdFnhoHx8vmt8eZZd25WRkE//lx2C8CsP3zDDgMW5z8n3899Y4go/EaKGSGR z+deNjezzZB+kIOSz87oDPrJ5LrVNJHQWcHQopwFOtVIZT1lNslmWf/LZtP2CxKjzf1+ WPjSoFjRH7gIHDj6/e7WWmxclum41fOt8CSh/1G+OJPVg7Q4+HNMhdh7K34AGJa2ou/K SZCymg3Ts5fZ8YqddhNkUiU6zeNcG9ifbsupimDDKguLd9lkkfQmiZK04YPabQj9Pl3L b8lbczAa1jgU5w2j8HPcHGf2LV5K4XBOSj3fI+Vz97bZdmBSjjdnWQb9tZXaS1DeTB1A eyRA== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr10229639wjb.10.1355424774933; Thu, 13 Dec 2012 10:52:54 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 10:52:54 -0800 (PST) In-Reply-To: <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> Date: Thu, 13 Dec 2012 10:52:54 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=047d7bf10b2c3acc0704d0c06cad X-Gm-Message-State: ALoCoQn4gl4L2etUc4pdl8vTb5iDK7ERdRjsJiFh+D7drpG3Qvqv+ID1FRlNW2TX5YjxxKSfgJRxqaWzuIzQ/PjVhyUzAqkdnsVEqt5UfBUu2cn98/A2E+Vn+ckq708QAp9u4tGy4U6mHkaqmS+qYofB8pJ9xMQLUBlCMiuzQr1cX7IqGq2miRM3lBNHbGqMV0QYgIUpe/31 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:52:58 -0000 --047d7bf10b2c3acc0704d0c06cad Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Then it means that no iana-registered link rel could ever be considered > as secure, correct? That seems way too limiting to me... > Correct, unless iana-registered can include those with an "https:" prefix. Any technical reason we couldn't register full URL rels with the IANA? --047d7bf10b2c3acc0704d0c06cad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter <= la= urentwalter.goix@telecomitalia.it> wrote:
Then it means that no iana-registered link rel could ever be considere= d as secure, correct? That seems way too limiting to me...
<= /blockquote>

Correct, unless iana-registered can include= those with an "https:" prefix. =C2=A0Any technical reason we cou= ldn't register full URL rels with the IANA?

--047d7bf10b2c3acc0704d0c06cad-- From jasnell@gmail.com Thu Dec 13 10:54:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E730521F8960 for ; Thu, 13 Dec 2012 10:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29PFqmK8BWVt for ; Thu, 13 Dec 2012 10:54:36 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5FC21F891F for ; Thu, 13 Dec 2012 10:54:36 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2339656iaz.31 for ; Thu, 13 Dec 2012 10:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B5C4GhfNXaTpCcQr1KxocUqv8d7eO8FRFDV6g4eS3eE=; b=ITdZkSP6Q9brb+AOBHUZVddWX/jx6ZMKGj0BXQY2N+GxP1otlKMDnFZGU/gV/wvmhQ 9UicrqBMsbO5h9jNXUcovuAaYHgaJ47kMI1renN8BV3GzGkYofzt30SxvFN6BL14kkdU wOh6l1IQlkaTCfKa3RqpCvJm4c2NWzJHnDX6LufufL9iI3FA9A8D7JkSRJ1qESNbSb3U rmpRk9qj1y4AuISBblaIGHEOMObKyFCpnzx+3id6qPqk/VBGhoVHZPjwcWMoroC5I1fx KUIKbx+/3df3kLiuGfGSecHpaJhro8kPKyXMEgh3pYe9ZViN4jO181aHQ1PxxsUq36Jm nu2w== Received: by 10.42.41.144 with SMTP id p16mr2346510ice.39.1355424876037; Thu, 13 Dec 2012 10:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:54:15 -0800 (PST) In-Reply-To: <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> From: James M Snell Date: Thu, 13 Dec 2012 10:54:15 -0800 Message-ID: To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=20cf301d423241864604d0c07218 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" , "Paul E. Jones" , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:54:38 -0000 --20cf301d423241864604d0c07218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What I'm saying is that there should be an option of adding a signature to the JRD document as a whole, generated using a key trusted by both the client and server. This can be provided either within the JRD document itself (perhaps leveraging JSON Web Signatures [1]) or using an external mechanism such as the proposed Integrity header [2]. Providing this information would be entirely optional on the part of the server. If it is provided, however, the client SHOULD verify it prior to consuming the data. A client could choose not to process any JRD unless the integrity check it provided. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 [2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 How the client and server determine which key to use to generate the signature is out of scope but for security purposes it cannot be the same key used to secure the HTTPS connection (if https is used at all)... since that would rather defeat the purpose of the check and could easily be spoofed by an attacker. Once the integrity of the document has been verified, the client can look for whichever links it wants in the document and ignore the ones it doesn't want. - James On Thu, Dec 13, 2012 at 10:43 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Are you suggesting James to add a 'signature' property to each link rel > created with the server private key? At least for the secure ones when > provided over plain http? > This way a client retrieving a wf jrd over http MUST check the signature > property for 'secure' hrefs and MUST discard them if such signature is no= t > provided ? > In this case though the public key should be provided somewhere (if we're > not using https)... > > I remember something similar with xrd signature check in the original wf > 'explanation' some years ago, but that was for the whole doc if I remembe= r > correctly. We would then need enhance jrd with a new property, if all thi= s > makes sense. > > Walter > > > Le 13 d=C3=A9c. 2012 =C3=A0 19:20, "James M Snell" a = =C3=A9crit : > > Huh? This particular conversation is extremely confusing at this point. > Link rel values are neither secure nor insecure. They're JUST labels. The= y > provide no information at all about the security requirements of the link= ed > resource. > > If I have... > > (A) > { > "rel": "canonical", > "href": "http://example.org/foo" > } > > (B) > { > "rel": "canonical", > "href": "https://example.org/foo" > } > > Then (A) is insecure and (B) is secure. It's that simple. All this talk > of checking rel values for "https:" is nonsense. > > The real question here appears to be one of integrity: how does the > client know that the information provided in the WebFinger document is th= e > right information from a trusted source? HTTPS isn't enough to verify tha= t. > If you want to do it right, you add a cryptographic signature to the > document generated with a key that the client trusts. Once the client > verifies that the information is trustworthy, it can scan through looking > for the links it wants. If it needs a secure link, it looks for ones whos= e > href attributes specify "https". > > - James > > > On Thu, Dec 13, 2012 at 9:28 AM, Brad Fitzpatrick wr= ote: > >> On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter < >> laurentwalter.goix@telecomitalia.it> wrote: >> >>> Indeed =C2=AB href =C2=BB should be checked instead of =C2=AB rel =C2= =BB in order to >>> support registered values as well. Plus some link rels may not be http >>> (think at acct:, sip:, ws:, ecc). So the client may need to check as we= ll >>> for sips:, wss:, accts:? **** >>> >>> Although I can understand the issue I=E2=80=99m starting to get confuse= d as well=E2=80=A6 >>> >> >> No, the key (the link.rel) is what is secure, not the value (the >> link.href). >> >> So all of acct:, sip:, ws:, data:, etc can be used as as the value, >> since that's not the part that is checked for an "https:" prefix. >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --20cf301d423241864604d0c07218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What I'm saying is that there shou= ld be an option of adding a signature to the JRD document as a whole, gener= ated using a key trusted by both the client and server. This can be provide= d either within the JRD document itself (perhaps leveraging JSON Web Signat= ures [1]) or using an external mechanism such as the proposed Integrity hea= der [2]. Providing this information would be entirely optional on the part = of the server. If it is provided, however, the client SHOULD verify it prio= r to consuming the data. A client could choose not to process any JRD unles= s the integrity check it provided.=C2=A0


How the client and s= erver determine which key to use to generate the signature is out of scope = but for security purposes it cannot be the same key used to secure the HTTP= S connection (if https is used at all)... since that would rather defeat th= e purpose of the check and could easily be spoofed by an attacker.

Once the integrity of the document has been veri= fied, the client can look for whichever links it wants in the document and = ignore the ones it doesn't want.=C2=A0

- James


On Thu= , Dec 13, 2012 at 10:43 AM, Goix Laurent Walter <laurent= walter.goix@telecomitalia.it> wrote:
Are you suggesting James to add a 'signature' property to each= link rel created with the server private key? At least for the secure ones= when provided over plain http?
This way a client retrieving a wf jrd over http MUST check the signatu= re property for 'secure' hrefs and MUST discard them if such signat= ure is not provided ?
In this case though the public key should be provided somewhere (if we= 're not using https)...

I remember something similar with xrd signature check in the original = wf 'explanation' some years ago, but that was for the whole doc if = I remember correctly. We would then need enhance jrd with a new property, i= f all this makes sense.

Walter


Le 13 d=C3=A9c. 2012 =C3=A0 19:20, "James M Snell" <jasnell@gmail.com> a = =C3=A9crit=C2=A0:

Huh? This = particular conversation is extremely confusing at this point. Link rel valu= es are neither secure nor insecure. They're JUST labels. They provide n= o information at all about the security requirements of the linked resource.

If I have...

(A)
{
=C2=A0 "rel": "can= onical",
=C2=A0 "href": "http://example.org/foo"
}

(B)
{
=C2=A0 "rel": "can= onical",=C2=A0
=C2=A0 "href": "https://example.org/foo= "
}

Then (A) is insecure and (B) is s= ecure. It's that simple. All this talk of checking rel values for "= ;https:" is nonsense.

The real question here appears to= be one of integrity: how does the client know that the information provide= d in the WebFinger document is the right information from a trusted source?= HTTPS isn't enough to verify that. If you want to do it right, you add a cryptographic signature to the docum= ent generated with a key that the client trusts. Once the client verifies t= hat the information is trustworthy, it can scan through looking for the lin= ks it wants. If it needs a secure link, it looks for ones whose href attributes specify "https".

- James


On Thu, Dec 13, 2012 at 9:28 AM, Brad Fitzpatric= k <bradfitz@googl= e.com> wrote:
On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:

Indeed =C2=AB=C2=A0href=C2=A0=C2=BB sh= ould be checked instead of =C2=AB=C2=A0rel=C2=A0=C2=BB in order to support = registered values as well. Plus some link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sip= s:, wss:, accts:?

Although I can understand the issue I= =E2=80=99m starting to get confused as well=E2=80=A6


No, the key (the link.rel) is what is secure, not the value (the link.= href).

So all of acct:, sip:, ws:, data:, etc can be used as as the value, si= nce that's not the part that is checked for an "https:" prefi= x.


_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


Questo mes= saggio e i suoi allegati sono indirizzati esclusivamente alle persone indic= ate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=C2=A0is=C2=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =C3=A8 necessario.


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--20cf301d423241864604d0c07218-- From jasnell@gmail.com Thu Dec 13 10:59:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F30921F8699 for ; Thu, 13 Dec 2012 10:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.782 X-Spam-Level: X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLGYxyDzyJ5A for ; Thu, 13 Dec 2012 10:59:10 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8F21F85E6 for ; Thu, 13 Dec 2012 10:59:10 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4588067ieb.31 for ; Thu, 13 Dec 2012 10:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xk62r/scsw3qGuL7qSyxgICQj3BnoDpT+UzCyzp7XEY=; b=BjE32fUDxAMH7HrXToiIqFHjWnaDmGDfu6T/JBJFeYWtyoy94MGPINUxZmQKGuFulx tEhEUla+ybDg31fONexSh1LuEJkQTYUZHl9/j+NXhnvJeldXjk5NiIHxbXNxBMFvIXyN 1EwxppMdDbN9HRMqvWxD0cI9ZYFCY4MNzQ4nGT1NLHvCCXfGMnMjIJ77phl/1deEqtel PSA1L6IbLkbcDVgCbqWUr4hFb+JskKEtqV/X73F3HLUR7VaffGrFaAxztCpcKE/b0ivD b6JO/kRNq+ZrONlXuV+DNibcAk5tXEASCPRr18jLLS+/M2/hAwx21e74jjkphOSQlwk2 o73w== Received: by 10.50.184.229 with SMTP id ex5mr2705063igc.72.1355425150082; Thu, 13 Dec 2012 10:59:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 10:58:50 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> From: James M Snell Date: Thu, 13 Dec 2012 10:58:50 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=14dae9340ddf971e8e04d0c082f2 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:59:11 -0000 --14dae9340ddf971e8e04d0c082f2 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > >> Then it means that no iana-registered link rel could ever be considered >> as secure, correct? That seems way too limiting to me... >> > > Correct, unless iana-registered can include those with an "https:" prefix. > Any technical reason we couldn't register full URL rels with the IANA? > > http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type names MUST conform to the reg-rel-type rule" LOALPHA = reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) You would have to update and obsolete RFC 5988 to register full URLs. I certainly would be -1 on any effort to do so. - James > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae9340ddf971e8e04d0c082f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Dec 13, 2012 at 10:52 AM, Brad F= itzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:<= br>
Then it means that no iana-registered link rel could ever be considere= d as secure, correct? That seems way too limiting to me...
<= /blockquote>

Correct, unless iana-registered can i= nclude those with an "https:" prefix. =C2=A0Any technical reason = we couldn't register full URL rels with the IANA?


http://tools.ietf.org/h= tml/rfc5988#section-4.1, "Registered relation type names MUST conform to the reg-rel-type rule= "

<= font color=3D"#000000">LOALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D <any US-AS= CII lowercase letter "a".."z">
= reg-rel-type =C2=A0 =3D LOALPHA *( LOALPHA | DIGIT = | "." | "-" )

You would have to update and obsolete RFC 5988 to= register full URLs. I certainly would be -1 on any effort to do so.=C2=A0<= /div>

- James=C2=A0

=C2=A0

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--14dae9340ddf971e8e04d0c082f2-- From bradfitz@google.com Thu Dec 13 11:01:33 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A169421F8A21 for ; Thu, 13 Dec 2012 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.909 X-Spam-Level: X-Spam-Status: No, score=-103.909 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnWqgLDmcqfW for ; Thu, 13 Dec 2012 11:01:33 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6021F8A10 for ; Thu, 13 Dec 2012 11:01:32 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1138583wey.31 for ; Thu, 13 Dec 2012 11:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qSQRMGh2H+HgIc/PKG7L0enoMHtckPmW6DVF7lz+Ji0=; b=ZZQXto0YJAHqSiXvoxMwxp8Wuqg98bXN4F2CLIMsNZ5nSrpVcJr2DWlCYk2t7iihmz u7LO1/TRk1loJVrEG+LN7qD6iuvEGaQNPNQLWg9zdjl3+zaH7fx7vmAGz1wj5GRHE7mx I+PG9lEfMyL+Id93c50PQ70UM6ekz50P3chVxSJBxSKefoETcWrY4UX+oGluwNabiDLp iAaKb+nIychXvhMFRzkWhdD2zRcNvKSieEUzuH7Hw2Sf+yMT31n1yjcTM4/sLk0+5PpY d3pvyu2LkQoF1ENEAUbFD/Yo3MGkTJ/FPu3R0j7SdVNR4EQe9kooEpILjBy/uxSsWvVW vEcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qSQRMGh2H+HgIc/PKG7L0enoMHtckPmW6DVF7lz+Ji0=; b=EdXsgIYnBWKTMo7DtQTaXWiNDx4hqT5+Ihe2pEENXyHSjKf+VnS3kwUDGTlBoFtAMb 2mzhzg4kB9ecP2gv3B+0V+NtCUN82QgjAcCrricK1MST/IDlDmLIosD4S2U5z8BTq7Wz Y8xyCrDjdbJIRgLmTWRBrCvB3uh4stUsEqOlROaQK87eUS9wWcqtbqi/bjFD04mgwfax 49/Ol7icF3HypPCxTwPw3XrSj7VQbOimOiS6tcUA9X6Yk9mWgSMvpJsGmA580Ds/8GRD IcXV1n7ISwUJrvMC/u9Dh8tUXIMn+LtF0MvotMMafSMBpPTkdReEtgtSpph1aApNDNSS sceg== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr10270593wjb.10.1355425291795; Thu, 13 Dec 2012 11:01:31 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 11:01:31 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> Date: Thu, 13 Dec 2012 11:01:31 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7bf10b2c097c1304d0c08b47 X-Gm-Message-State: ALoCoQkrg8BUcNOe4/F4ji5ZboOcErkKW1RsTkbVOhh6to24748Mq+qmrD1a7qO1MGAZurwdezhco58Xz8GrMSFVTtivIsRyVb94HZUe653WSB7ajzrsPpBYo+Rq7mAN4TRzOM2y+DiFJaj3zzQwW2vcJYjnjMouLxrt97N/u+yWdJJALzwAKRHCDkdrPuLtQLzyydhfsiV2 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:01:33 -0000 --047d7bf10b2c097c1304d0c08b47 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:58 AM, James M Snell wrote: > > > > On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick wrote: > >> On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter < >> laurentwalter.goix@telecomitalia.it> wrote: >> >>> Then it means that no iana-registered link rel could ever be >>> considered as secure, correct? That seems way too limiting to me... >>> >> >> Correct, unless iana-registered can include those with an "https:" >> prefix. Any technical reason we couldn't register full URL rels with the >> IANA? >> >> > http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type > names MUST conform to the reg-rel-type rule" > > LOALPHA = > reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) > > You would have to update and obsolete RFC 5988 to register full URLs. I > certainly would be -1 on any effort to do so. > Okay: begins with "https:" or begins with "secure-". --047d7bf10b2c097c1304d0c08b47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Thu, Dec 13, 2012 at 10:58 AM, James M= Snell <jasnell@gmail.com> wrote:



On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick <bradfitz@google.com<= /a>> wrote:
On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:
Then it means that no iana-registered link rel could ever be considere= d as secure, correct? That seems way too limiting to me...
<= /blockquote>

Correct, unless iana-registered can i= nclude those with an "https:" prefix. =C2=A0Any technical reason = we couldn't register full URL rels with the IANA?


http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type names MUST conform to the reg-r= el-type rule"

LOALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D <any US-ASCII lowercase let= ter "a".."z">
reg-rel-type =C2=A0 =3D LOALPHA *( LOALPHA | DIGIT | "." |= "-" )

You would have to update and obsolete RFC 5988 to= register full URLs. I certainly would be -1 on any effort to do so.=C2=A0<= /div>

Okay: begins with "h= ttps:" or begins with "secure-".
=C2=A0
--047d7bf10b2c097c1304d0c08b47-- From bradfitz@google.com Thu Dec 13 11:05:44 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A721F8A3E for ; Thu, 13 Dec 2012 11:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hec7mVAStAhW for ; Thu, 13 Dec 2012 11:05:44 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60C21F864D for ; Thu, 13 Dec 2012 11:05:43 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1900588wib.13 for ; Thu, 13 Dec 2012 11:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+QuE/70d0fuqLjjFH7ujV0fLwdiEZgox7nOnyCZmTzw=; b=DeylCNgsNug7EVNZAFHc5GD+Yz4ifir2rGRlxp0NQyhMegv6mI8mzXepnKeun0f37O pTPKh3G0fyKwwigVk58Xj1hCNzQ/UnNlqQHntECBTn3zYYOUrAKIf6flhsYt9HiOys6T y/AbbiLZICIhQbEbkVo31njUECm3WJTiIvalpMt+QPTt5vovk02QRkfcbhGbNAuCRBV3 f+CwYGUh97ZL/vqfOnhe7rVlAYVH6AckE3v3AatqFIYm8Qj6kcGG+j6jFLWBYEk+sb44 oIpWy9DdK+K+tKWbdhN27GMaooJEtkqLFu1M1ueUwn8yxaa9L17ifoXGiyZCmZxSyouv w4GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+QuE/70d0fuqLjjFH7ujV0fLwdiEZgox7nOnyCZmTzw=; b=T4mylIBta/G9oykqKixxCkAL5IhUEEiKo8YF9OfGR8fVRQZ220h1bcU8wiWyGqwf64 Hb2qPanLuC1DGSja8gtSpvU3Wa+3CDZLjbZ01YGQPXrz6SQxJHv2i3T5Y436f4cWxC1a XzEm2KmTYviZQPAC3FYjYxjzDc0OliOo8LVOyhcLNe1o6aLdz2UjVuQd0zEmkhRkqH/1 6FSQBJedhHn2w02r+XDCTIxvAbF4SQGmWWVb9gIzfnV0pb8ee/+/vZaDSmqGSPcrKOUC jMvfrMCQDVccGL0xHCLab5pYmTMvjpMZJRnmAvCcRh2+998jvdDEhJAIcKjSxjIqQ8qx EePw== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr10289945wjb.10.1355425542751; Thu, 13 Dec 2012 11:05:42 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 11:05:42 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> Date: Thu, 13 Dec 2012 11:05:42 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7bf10b2cfec6f504d0c0990b X-Gm-Message-State: ALoCoQmNk+JaIQuTmOemzWCSMn5JwlVRzXYTJOlPk06fcH55CnfbaPYjFz+2Ig1DRn6dn+ptELMqOGESJYzZCXt1WiZu318ofPLIJvoKGMveQD90Qd5+xXYf1NUV6oTeUbwN3PpCW+OPvmLpum1/aNf8J+q8zilc7XQtAcEooMH30vQxqHbc/pY9S0KAGqn7A+f/3FvWgVPy Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" , Goix Laurent Walter , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:05:44 -0000 --047d7bf10b2cfec6f504d0c0990b Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 10:54 AM, James M Snell wrote: > What I'm saying is that there should be an option of adding a signature to > the JRD document as a whole, generated using a key trusted by both the > client and server. This can be provided either within the JRD document > itself (perhaps leveraging JSON Web Signatures [1]) or using an external > mechanism such as the proposed Integrity header [2]. Providing this > information would be entirely optional on the part of the server. If it is > provided, however, the client SHOULD verify it prior to consuming the data. > A client could choose not to process any JRD unless the integrity check it > provided. > > [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 > [2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 > > How the client and server determine which key to use to generate the > signature is out of scope but > Which means nobody will use this. You can't just say "Here's a big optional mechanism, but key details are missing... figure it out, maybe." Also, what about this webfinger-specific? If you want to work on signing HTTP responses (a noble goal), that's great, but there's no reason it needs to be lumped into WebFinger. HTTPS, on the other hand, is well-understood and widely implemented. WebFinger isn't supposed to be about designing a new PKI or crypto system. It's supposed to be a simple mechanism to read some key/value pairs. --047d7bf10b2cfec6f504d0c0990b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 10:54 AM, James M Snell <jasnell@gmail.com><= /span> wrote:
What I'm saying is that there should be an option o= f adding a signature to the JRD document as a whole, generated using a key = trusted by both the client and server. This can be provided either within t= he JRD document itself (perhaps leveraging JSON Web Signatures [1]) or usin= g an external mechanism such as the proposed Integrity header [2]. Providin= g this information would be entirely optional on the part of the server. If= it is provided, however, the client SHOULD verify it prior to consuming th= e data. A client could choose not to process any JRD unless the integrity c= heck it provided.=C2=A0

How the client and s= erver determine which key to use to generate the signature is out of scope = but

Which means nobody w= ill use this. =C2=A0You can't just say "Here's a big optional = mechanism, but key details are missing... figure it out, maybe."

Also, what about this webfinger-specific? =C2=A0If you = want to work on signing HTTP responses (a noble goal), that's great, bu= t there's no reason it needs to be lumped into WebFinger.
HTTPS, on the other hand, is well-understood and widely implemen= ted.

WebFinger isn't supposed to be about designing a new= PKI or crypto system. =C2=A0It's supposed to be a simple mechanism to = read some key/value pairs.

--047d7bf10b2cfec6f504d0c0990b-- From jasnell@gmail.com Thu Dec 13 11:11:24 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5001521F880F for ; Thu, 13 Dec 2012 11:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.804 X-Spam-Level: X-Spam-Status: No, score=-4.804 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQHvL4P7AqVN for ; Thu, 13 Dec 2012 11:11:23 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7526D21F871D for ; Thu, 13 Dec 2012 11:11:23 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so4456791ieb.25 for ; Thu, 13 Dec 2012 11:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g2p/LTRcRjlvCbYKEMkUrvfEO9AKcuxAiZ9og0+d+3A=; b=aoJIrlznMlc6aIHQCdLMwLvGD7vohB0TC0fTUWb/41fv3IRtsnLC6OtQuuubDWpx2G dkYRMZLBMC5aO1N+aabJkD5iieZd2j9eWPGrFlk6YxRefmDZ69WQlW7Ufp6px5dYbleA NuEWpiWhsfB93rwjfRdPU2zY65dAtHqWwTUkDp3BuinoCMNbZ++CY5bFZWKlYYtbqMfI S8ZwTYtV8LZrG5N6reQDbddGt5RNU2JVgOgN8Iwnrg1XlIOuUX6bzfD4s+2qDzQ8Je49 Irp+x3di+3xcZU6DHfqJMOkhiYYUeU3EbpYpH7OJA9X1Ky7523GWHzxKEZZGgOrKAgdr MBXw== Received: by 10.50.151.238 with SMTP id ut14mr18144436igb.72.1355425882889; Thu, 13 Dec 2012 11:11:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 11:11:02 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> From: James M Snell Date: Thu, 13 Dec 2012 11:11:02 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f3b9f7d44df6504d0c0ae42 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:11:24 -0000 --e89a8f3b9f7d44df6504d0c0ae42 Content-Type: text/plain; charset=UTF-8 Per RFC5988, you are certainly free to register individual link relations that add constraints around the resources being linked to. Registering something like "secure-canonical" that indicates that the href must always point to an https: url would certainly be possible and well within what rfc5988 allows. Whether or not it's a good idea is separate issue. I don't believe it is. Consider: { "rel": "secure-canonical", "href": "https://example.org" } is no more or less secure in practice than { "rel": "canonical", "href": "https://example.org" } In either case, the browser still has to ultimately look at the href value. Further, it's not even clear exactly which problem would be addressed by this. Introducing some notion of a "Secure" link rel will not prevent or mitigate an attack. From the examples given in this thread, the attack occurs well before the client processes the JRD document at all. In such cases, *none* of the information in the JRD can be trusted and the client should simply refuse to process it at all. - James On Thu, Dec 13, 2012 at 11:01 AM, Brad Fitzpatrick wrote: > > > On Thu, Dec 13, 2012 at 10:58 AM, James M Snell wrote: > >> >> >> >> On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick wrote: >> >>> On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter < >>> laurentwalter.goix@telecomitalia.it> wrote: >>> >>>> Then it means that no iana-registered link rel could ever be >>>> considered as secure, correct? That seems way too limiting to me... >>>> >>> >>> Correct, unless iana-registered can include those with an "https:" >>> prefix. Any technical reason we couldn't register full URL rels with the >>> IANA? >>> >>> >> http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation >> type names MUST conform to the reg-rel-type rule" >> >> LOALPHA = >> reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) >> >> You would have to update and obsolete RFC 5988 to register full URLs. I >> certainly would be -1 on any effort to do so. >> > > Okay: begins with "https:" or begins with "secure-". > > --e89a8f3b9f7d44df6504d0c0ae42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Per RFC5988, you are certainly free to= register individual link relations that add constraints around the resourc= es being linked to. Registering something like "secure-canonical"= that indicates that the href must always point to an https: url would cert= ainly be possible and well within what rfc5988 allows. Whether or not it= 9;s a good idea is separate issue. I don't believe it is.

Consider:

{
=C2=A0 "rel": "sec= ure-canonical",
= =C2=A0 "href": "https://exam= ple.org"
}

is no more or less secure in practice than

{
<= div>=C2=A0 "rel": "cano= nical",
=C2=A0 &= quot;href": "https://example.org<= /a>"
}


- James
=

On Thu, Dec 13, 2012 at 11:01 AM, Brad F= itzpatrick <bradfitz@google.com> wrote:


On Thu, Dec 13, 2012 at 10:58 AM, James M Snell <jasnell@gmail.com&= gt; wrote:



On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick <bradfitz@google.com<= /a>> wrote:
On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:
Then it means that no iana-registered link rel could ever be considere= d as secure, correct? That seems way too limiting to me...
<= /blockquote>

Correct, unless iana-registered can i= nclude those with an "https:" prefix. =C2=A0Any technical reason = we couldn't register full URL rels with the IANA?


http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type names MUST conform to the reg-r= el-type rule"

LOALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D <any US-ASCII lowercase let= ter "a".."z">
reg-rel-type =C2=A0 =3D LOALPHA *( LOALPHA | DIGIT | "." |= "-" )

You would have to update and obsolete RFC 5988 to= register full URLs. I certainly would be -1 on any effort to do so.=C2=A0<= /div>

Okay: begins with &= quot;https:" or begins with "secure-".
=C2=A0

--e89a8f3b9f7d44df6504d0c0ae42-- From bradfitz@google.com Thu Dec 13 11:19:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62721F894F for ; Thu, 13 Dec 2012 11:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F15on3tmqEKq for ; Thu, 13 Dec 2012 11:19:33 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id D12F021F8901 for ; Thu, 13 Dec 2012 11:19:32 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4369210wib.13 for ; Thu, 13 Dec 2012 11:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mVdjsuEmv1kX+Qz+zN8C6EdRk/Vqu0riosop/YOudU=; b=QdJ6jjGaal9qZvz1JNrtaDWnqxHTZNIKM8qnnug8XFeuvSqzXzlifzZfI8KAcXRuz7 3ihuC0gTwKwqkaKt9vY+iKyslssc2Wb3oiX2zHBgrRY5e6/SZ8/rgJMPKHSPbA/MWt1p HUwWe0OhTgtQlMAI6JmGsL9aqdVheYweolnqjsvA59MRSCc8ikg96NlwPxizTkcx7R2h m1/bIle+ejmmjXb/sZSpkIUVSsxqCEtFC1WIuZSbbKNGBsKglN71jW392G/imOLJ5XA8 c/s0vF4hi65f/rSnJYe4CrUfaSysv+oJqDcWXpURm1merWk4MVzuihtR09NnHtUkhTiY 5ijA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4mVdjsuEmv1kX+Qz+zN8C6EdRk/Vqu0riosop/YOudU=; b=e/f1ivlDRDRLz4rPA46s0R0KEhYxvEuecM/hNr2IOqBpCC2EpuWQduMRbvX1DFkL97 tGQ2KuZA/OMlCJypxjmBxKPvH8HdRcepdHtki8xD0k190WWlLRCCNJj4o27OzInYjgnW czQJ6q93xz1CJmvzvZBxF3wNNLzfYRcrLHMGLkdwT5Wg21qoC3eQWRE/gCtZ/bHoASfX bG3cPM7RSD8kUaQUrYliyoLs1SKJqQg2xhh2ZrVraUBrezo1kWoHFpqqJsjsIEykicvs gamJlkTf2N6XclegZQw3y24XaPjXQ4+Y9HCE9URuV+AOPlfqfisp+cGczmr6aLeMYttq sNHw== MIME-Version: 1.0 Received: by 10.194.58.175 with SMTP id s15mr117404wjq.31.1355426371851; Thu, 13 Dec 2012 11:19:31 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 11:19:31 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> Date: Thu, 13 Dec 2012 11:19:31 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7ba9792469d60c04d0c0cba6 X-Gm-Message-State: ALoCoQnIP129u5jWGsrefBRsTI7KBRKWCQSwsyHoy/5p4aG6SDoNqF0wAkmXwkni/Dhj0uvUQzGDa0wUMYOobXZJwwlNe+1leDvW9liTv48IuWfyNaZX+PSxheGmTbD7sH9gRaqChznS6XLrnjy5T9/lLEr7jJLvtZrjX/k7VbaQLTX7veplfLfIo427LnvxjvqGXwtP2j9I Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:19:34 -0000 --047d7ba9792469d60c04d0c0cba6 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 11:11 AM, James M Snell wrote: > Per RFC5988, you are certainly free to register individual link relations > that add constraints around the resources being linked to. Registering > something like "secure-canonical" that indicates that the href must always > point to an https: url would certainly be possible and well within what > rfc5988 allows. Whether or not it's a good idea is separate issue. I don't > believe it is. > > Consider: > > { > "rel": "secure-canonical", > "href": "https://example.org" > } > > is no more or less secure in practice than > > { > "rel": "canonical", > "href": "https://example.org" > } > > In either case, the browser still has to ultimately look at the href > value. Further, it's not even clear exactly which problem would be > addressed by this. > Please see the previous messages in this thread, particularly the one where I give an example of how a MITM https-to-http downgrade attack works. In the case of "secure-key-server" (or e.g. " https://webfinger.net/rel/key-server"), the application using WebFinger knows that if they get a link for "secure-key-server", it arrived over HTTPS. Because their WebFinger client software filtered out any secure rels that arrived over HTTP. Whether the client application then trusts the href and the href's scheme depends on the rel & the application. Introducing some notion of a "Secure" link rel will not prevent or mitigate > an attack. > I've been arguing the opposite, actually. > From the examples given in this thread, the attack occurs well before the > client processes the JRD document at all. In such cases, *none* of the > information in the JRD can be trusted and the client should simply refuse > to process it at all. > You can't trust anything with HTTP. Which is why I'm proposing that clients filter out secure rels if HTTP was used. --047d7ba9792469d60c04d0c0cba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 11:11 AM, James M Snell <jasnell@gmail.com><= /span> wrote:
Per RFC5988, you are certainly free to register individ= ual link relations that add constraints around the resources being linked t= o. Registering something like "secure-canonical" that indicates t= hat the href must always point to an https: url would certainly be possible= and well within what rfc5988 allows. Whether or not it's a good idea i= s separate issue. I don't believe it is.

Consider:

{
=C2=A0 "rel": "sec= ure-canonical",
= =C2=A0 "href": "https://example.org"
}

is no more or less secure in practice than

{
<= div>=C2=A0 "rel": "cano= nical",
=C2=A0 &= quot;href": "ht= tps://example.org"
}

In either case, the browser still has to ultimately loo= k at the href value. Further, it's not even clear exactly which problem= would be addressed by this.

Please see the previous messages in t= his thread, particularly the one where I give an example of how a MITM http= s-to-http =C2=A0downgrade attack works.

In t= he case of "secure-key-server" (or e.g. "https://webfinger.net/rel/key-server"= ;), the application using WebFinger knows that if they get a link for "= ;secure-key-server", it arrived over HTTPS. =C2=A0Because their WebFin= ger client software filtered out any secure rels that arrived over HTTP.

Whether the client application then trusts the href and= the href's scheme depends on the rel & the application.
=

Introducing some notion of a &q= uot;Secure" link rel will not prevent or mitigate an attack.

I've been arguing the opposite, act= ually.
=C2=A0
From the examples given in this thread, the attack occurs = well before the client processes the JRD document at all. In such cases, *n= one* of the information in the JRD can be trusted and the client should sim= ply refuse to process it at all.

You can't trust anything with HTTP. = =C2=A0Which is why I'm proposing that clients filter out secure rels if= HTTP was used.

--047d7ba9792469d60c04d0c0cba6-- From jasnell@gmail.com Thu Dec 13 11:22:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5951F21F897E for ; Thu, 13 Dec 2012 11:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.825 X-Spam-Level: X-Spam-Status: No, score=-3.825 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbaxvEFObNlM for ; Thu, 13 Dec 2012 11:22:19 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 36CAA21F897D for ; Thu, 13 Dec 2012 11:22:19 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id s9so4659845iec.13 for ; Thu, 13 Dec 2012 11:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6W/Lhgxo7BbNz+98BuA8a+9XrttrkVaS70cz4iVJAOk=; b=t7GYLBFhZytECe8vWw9Ee1sOaVSAdNCsVh0tBM1nYHBk0qLxhllNT7mAf0YID0IOSZ rPraj77SQ6sYiXLs7/CGcldbDnm52z6yIlJ6mQ+8Aa+QsfqOFdUlTJMUjw6CG8jb9iyP YbLbbzP7SpP32tUExFYC5xmTyQM/t1rlgWaGm86U/9XTZfkMwx/1mgJ7tbb8At5q2ide G8vYOLboL/5Z3XhEAY90Hs9z+ARh5MLz1tkcW4FLoGoDqePwgpaqS2FLvm1FoVWynfIp iOh7tt+QYVSOAlRHo2puZr4Aje9K73fpRmKAx9U0uI2K0OMhVzbZvUQAZ2nPXp1w52kl I+Gw== Received: by 10.50.178.106 with SMTP id cx10mr18171917igc.24.1355426535898; Thu, 13 Dec 2012 11:22:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 11:21:55 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> From: James M Snell Date: Thu, 13 Dec 2012 11:21:55 -0800 Message-ID: To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f5036c830fda404d0c0d523 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" , Goix Laurent Walter , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:22:20 -0000 --e89a8f5036c830fda404d0c0d523 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 10:54 AM, James M Snell wrote: > >> What I'm saying is that there should be an option of adding a signature >> to the JRD document as a whole, generated using a key trusted by both the >> client and server. This can be provided either within the JRD document >> itself (perhaps leveraging JSON Web Signatures [1]) or using an external >> mechanism such as the proposed Integrity header [2]. Providing this >> information would be entirely optional on the part of the server. If it is >> provided, however, the client SHOULD verify it prior to consuming the data. >> A client could choose not to process any JRD unless the integrity check it >> provided. >> >> [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 >> [2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 >> >> How the client and server determine which key to use to generate the >> signature is out of scope but >> > > Which means nobody will use this. You can't just say "Here's a big > optional mechanism, but key details are missing... figure it out, maybe." > > Also, what about this webfinger-specific? If you want to work on signing > HTTP responses (a noble goal), that's great, but there's no reason it needs > to be lumped into WebFinger. > > HTTPS, on the other hand, is well-understood and widely implemented. > > WebFinger isn't supposed to be about designing a new PKI or crypto system. > It's supposed to be a simple mechanism to read some key/value pairs. > > Last post on the topic because I've said basically everything I think needs to be said on it: I never said this is WebFinger specific. I'm not suggesting that anything be "lumped into WebFinger". Nor am I suggesting that WF be "about designing a new PKI or crypto system". If, however, WebFinger is going to be used in cases where verifying the integrity of the provided information is critical, then the specification needs to properly address how the integrity of the information can be verified. HTTPS does not provide for that. Neither does any notion of a "secure link relation". --e89a8f5036c830fda404d0c0d523 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Dec 13, 2012 at 11:05 AM, Brad F= itzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 10:54 AM, James M Snell <jasnell= @gmail.com> wrote:
What I'm saying is that there should be a= n option of adding a signature to the JRD document as a whole, generated us= ing a key trusted by both the client and server. This can be provided eithe= r within the JRD document itself (perhaps leveraging JSON Web Signatures [1= ]) or using an external mechanism such as the proposed Integrity header [2]= . Providing this information would be entirely optional on the part of the = server. If it is provided, however, the client SHOULD verify it prior to co= nsuming the data. A client could choose not to process any JRD unless the i= ntegrity check it provided.=C2=A0

How the client and s= erver determine which key to use to generate the signature is out of scope = but

Which means no= body will use this. =C2=A0You can't just say "Here's a big opt= ional mechanism, but key details are missing... figure it out, maybe."=

Also, what about this webfinger-specific? =C2=A0If you = want to work on signing HTTP responses (a noble goal), that's great, bu= t there's no reason it needs to be lumped into WebFinger.
=C2=A0

--e89a8f5036c830fda404d0c0d523-- From paulej@packetizer.com Thu Dec 13 11:29:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5572221F897D for ; Thu, 13 Dec 2012 11:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+4tIsTwYXyx for ; Thu, 13 Dec 2012 11:29:34 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2421F894F for ; Thu, 13 Dec 2012 11:29:34 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDJTVPR008071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 14:29:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355426972; bh=76lVOlGfG1zphF5a0yyWkZAbbcxJ/pPNJdN3FHv8LQY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=B0vTyONE082K4DfDilv1Cs5IEARQ9db617tL7NFhgpdIqH2L6ImqK3oKa1Owgy9/V RlPp4XYHeFfIXhz66tHHScAw325hvEgZatDDKxdZdW/k3xZdu0j0iK+dzHWvC8Dwnn 8bcU09bPiYQKJcwZg7ZIRGJWS4preFtqbf3/DkAw= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 14:29:43 -0500 Message-ID: <069f01cdd968$34447420$9ccd5c60$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06A0_01CDD93E.4B6F5680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvEBUcsFhwLGVRnMmIvD4FA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:29:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06A0_01CDD93E.4B6F5680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I understand the downgrade attack, but that is totally unrelated to = what we were talking about. =20 What we were discussing is that a query to an HTTPS URL might return a = different set of link relations than a query to an HTTP URL. More = specifically, a query to an HTTPS URL might return things the server = believes should only be returned over HTTPS, such as links to an OpenID = Provider. =20 Nowhere in the currently proposed =E2=80=9Ccompromise=E2=80=9D text is = there a proposal to fall back as you=E2=80=99re showing it. A client = either requests WF via HTTPS or HTTP, not both. In the case of the = latter, it=E2=80=99s not looking for secure content or security is a = non-issue. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 11:54 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones = wrote: Don=E2=80=99t put it on the wire. You want the server to filter before = sending a reply. =20 I'm concerned you're still confused about how a downgrade attack works. =20 Again: it DOES NOT MATTER what the server thinks it's filtering if the = client has been tricked into talking to a DIFFERENT SERVER which is then = returning malicious results. =20 Such as: -- client wants "all links" for foo@example.com. -- client requests secure = https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com= -- EVIL HIJACKER BLOCKS PORT 443 -- client then requests plain = http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "https://attacker.openid.server/" }, =20 See what happened there? We need the *client* to say "whoa whoa, wait a minute... I contacted = this webfinger server over HTTP---- what's it doing returning rels = starting with https:? I'm gonna skip over those (or just return an = error)." =20 The real webfinger server _was never even contacted_, so it doesn't = matter whether it was filtering or not. =20 ------=_NextPart_000_06A0_01CDD93E.4B6F5680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

No, I understand the downgrade attack, but that is totally unrelated = to what we were talking about.

 

What we were discussing is that a query to an HTTPS URL might return = a different set of link relations than a query to an HTTP URL.=C2=A0 = More specifically, a query to an HTTPS URL might return things the = server believes should only be returned over HTTPS, such as links to an = OpenID Provider.

 

Nowhere in the currently proposed =E2=80=9Ccompromise=E2=80=9D text = is there a proposal to fall back as you=E2=80=99re showing it.=C2=A0 A = client either requests WF via HTTPS or HTTP, not both.=C2=A0 In the case = of the latter, it=E2=80=99s not looking for secure content or security = is a non-issue.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 11:54 AM
To: Paul E. Jones
Cc: = webfinger@googlegroups.com; webfinger@ietf.org
Subject: Re: = [webfinger] secure links with https = rels

 

On Thu, Dec = 13, 2012 at 8:45 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Don=E2=80=99t put it on the wire.  You want the server to filter = before sending a = reply.

 

I'm = concerned you're still confused about how a downgrade attack = works.

 

Again: it = DOES NOT MATTER what the server thinks it's filtering if the client has = been tricked into talking to a DIFFERENT SERVER which is then returning = malicious results.

 

Such = as:

-- client = wants "all links" for foo@example.com.

-- EVIL = HIJACKER BLOCKS PORT 443

-- EVIL = HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY = WANT:

  =        {

  =          "rel" : "https://openid.net/connect/ser= ver",

  =          "type" : = "text/html",

  =          "href" : "https://attacker.openid.server/<= /a>"

------=_NextPart_000_06A0_01CDD93E.4B6F5680-- From bradfitz@google.com Thu Dec 13 11:35:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9C21F89F9 for ; Thu, 13 Dec 2012 11:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u69e988qVcpe for ; Thu, 13 Dec 2012 11:35:09 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7021F8972 for ; Thu, 13 Dec 2012 11:35:08 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1921505wib.13 for ; Thu, 13 Dec 2012 11:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7K0bkgeILZptPnRPVGWJITWXaA3Hyy8t70Zwep3d+dQ=; b=TQPIPBslrARgXRMb2AQFGkoL9ZcdJ1DvpV+d6cNbG1YT3ifTv10m70y1mgdlPJeOWi 71Pb0EEFFNfJenGEymvODCowEMvq4pf+DePmSQtFN4xSATPrgiQT5Gpxeqw7a5JtdY2u A9Dh6kwgWtlZ8jXr7cx+J5cNuq2MZUb3EHw5eYMTs7vIjO54GTW9xLEFVAnZfqKxPCah gRr5HO5ZvBj1svP34vYAdBJ+kCaDN7W/QF8wBOUVEUUZ3rCeUMv6ax55KLkAaNzhlBbv K++QJPSCfIhDrca+KEZb3sOsoiF38LhhYgm1bJgM5QJwFXCNk5PyJMs7AXr3FJ9e9isV s7VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=7K0bkgeILZptPnRPVGWJITWXaA3Hyy8t70Zwep3d+dQ=; b=PNYPRZABx6IMYtR/5/pB2AHsA2cYmHOXHXIwtY9palCSl2d/cpyPir+6khrjMLPt9h mXha0+muTTFPQT+a5WHjkFvHuo5r0oavw0qTRmMbytKdMGKBSa3DPxZq3yhfpViteJTI hZ5SPrl9D2wDG2yfmO6oiFWP3tS1Dt1uf8R6I1kQCAVhpYNCyzgrkzexcu+7tS5XzS7N l5226o9u94+3VY49sbdVJ8NwuFQS5vudPLd4WSJx2cLF9UYsKR79rksX+FjVL8h9N7QR NfL1d2zFGUSs2Dui3SPZl8xCZ+nbULrn4aI16SXDxKECnMD4nd2K8cp1/QC3MlV5CaNh uufw== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr109149wjb.10.1355427308216; Thu, 13 Dec 2012 11:35:08 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 11:35:08 -0800 (PST) Date: Thu, 13 Dec 2012 11:35:08 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@ietf.org Content-Type: multipart/alternative; boundary=047d7bf10b2c39a22504d0c103c0 X-Gm-Message-State: ALoCoQk7w3C0oF4dWaNCOH4RnbrgYncJPwtAeF3llRMPyPNIzNwkPGUe0dnvBCJdRaFYlhjDo5yLJySutVhi4OrrvLJ9NHQC0Zqg1sJsudlxmZNhRILShOzISqZjg97nuPi30+OTzjbs+s13NdDkhWMDYBnLanWZQRcc+EMVQeASh+R16lnVoQgFhPhV25dn012LZxLwM2fD Subject: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:35:10 -0000 --047d7bf10b2c39a22504d0c103c0 Content-Type: text/plain; charset=UTF-8 Here are the conflicting forces at work in the WebFinger spec, as I see it: 1) security (the HTTPS-only camp, and people who want to use WebFinger for the base of e.g. OpenID Connect). It should be possible to get a key/value pair ("link") only over HTTPS. 2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just want to use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system) 3) client simplicity. I believe that we can only have 2 of those 3. We've heard proposals for different sets of those two: 1+2: secure rel proposal (clients filtering out secure rels from HTTP responses). requires some complexity in clients to filter out insecure rels. 1+3: HTTPS-only. 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest proposal, which I feel will be error-prone. 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever you can connect to. No security. Originally I voted for HTTPS-only (which is 1+3), but enough people on this list want 2), so I think we need to give up 3) and go with 1+2. I remain fine with HTTPS-only, but I don't think it has enough support. --047d7bf10b2c39a22504d0c103c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
H= ere are the conflicting forces at work in the WebFinger spec, as I see it:<= br>
1) security (the HTTPS-only camp, and people who want to use We= bFinger for the base of e.g. OpenID Connect). =C2=A0It should be possible t= o get a key/value pair ("link") only over HTTPS.

2) HTTP-permitted (status= .net, Blaine, Paul, et al ... also those who just want to use WebFinger= for casual things... names & avatars, or doing their own crypto/signin= g out of band, and/or don't like the Root CA system)

3) client simplicity.

I believ= e that we can only have 2 of those 3. =C2=A0We've heard proposals for d= ifferent sets of those two:

1+2: secure rel propos= al (clients filtering out secure rels from HTTP responses). =C2=A0requires = some complexity in clients to filter out insecure rels.
1+3: HTTPS-only.
2: contact either HTTP or HTTPS.= =C2=A0servers SHOULD run on both? =C2=A0latest proposal, which I feel will= be error-prone.
2+~3: contact both HTTP & HTTPS in para= llel or with fallback, use whatever you can connect to. No security.

Originally I voted for HTTPS-only (whi= ch is 1+3), but enough people on this list want 2), so I think we need to g= ive up 3) and go with 1+2.

I remain fine with HTTP= S-only, but I don't think it has enough support.

--047d7bf10b2c39a22504d0c103c0-- From paulej@packetizer.com Thu Dec 13 11:35:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DF321F89F9 for ; Thu, 13 Dec 2012 11:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckaXdHQMMRui for ; Thu, 13 Dec 2012 11:35:43 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE9D21F8972 for ; Thu, 13 Dec 2012 11:35:43 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDJZe7C008342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 14:35:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355427341; bh=Uwc+C+a97pe6msJfi6VQV08SQOgf8LipurzmD3+188M=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=OWRL30cU4ClvpN/7zYlScXV9RN5pjEOscvPIMIwqF7Aybd3RmlKO8Gsm4rgw0Ch2X upnsJfDJ9PrCoJdtIInE889BpgHOxrrFMVtHnZZWQtnFfUKzQRouF0ryLAMTaKeeyd tus9jOjaqmO+AI6EvoHl8yW4cntHRCJr5QuHOoXY= From: "Paul E. Jones" To: "'John Panzer'" , References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 14:35:52 -0500 Message-ID: <06ac01cdd969$1025f950$3071ebf0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AD_01CDD93F.275129D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvEBUcsFhwLGVRnMAVVBqe+YgRtTsA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:35:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06AD_01CDD93F.275129D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But starts with "https" does not mean security is important. We can't use that as the measuring stick. And what about other URI schemes that will be used by WF? "What is secure" needs to be determined by the WF server internally. If adding an OpenID link relation, as an example, the server knows (or the server admin knows) to mark this as "deliver only via HTTPS". The best solution, though, is if you support HTTPS have all HTTP queries redirected to HTTPS. This makes life so much simpler. And if you only support HTTP, you know you there is no security. Clients (e.g., an client trying to perform an OpenID login) would never even try HTTP. Paul From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 13, 2012 12:18 PM To: webfinger@googlegroups.com Cc: Paul E. Jones; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels Right. This is also why you need this attribute as part of the official "name" of the link relation, so the client knows which ones are supposed to be secure with a simple .startsWith("https") type of check. Anything more complicated will create more security issues. (A registry of relations which tells you which link relations are secure-only might work but only if it could be kept up to date on all clients...) I still don't understand what the client will do with rel="canonical" though. Does WebFinger exclude registered rel-values? They don't have to be URIs. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick wrote: On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wrote: Don't put it on the wire. You want the server to filter before sending a reply. I'm concerned you're still confused about how a downgrade attack works. Again: it DOES NOT MATTER what the server thinks it's filtering if the client has been tricked into talking to a DIFFERENT SERVER which is then returning malicious results. Such as: -- client wants "all links" for foo@example.com. -- client requests secure https://example.com/.well-known/webfinger?resource=acct:foo@example.com -- EVIL HIJACKER BLOCKS PORT 443 -- client then requests plain http://example.com/.well-known/webfinger?resource=acct:foo@example.com -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "https://attacker.openid.server/" }, See what happened there? We need the *client* to say "whoa whoa, wait a minute... I contacted this webfinger server over HTTP---- what's it doing returning rels starting with https:? I'm gonna skip over those (or just return an error)." The real webfinger server _was never even contacted_, so it doesn't matter whether it was filtering or not. ------=_NextPart_000_06AD_01CDD93F.275129D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But starts with “https” does not mean security is = important.  We can’t use that as the measuring = stick.

 

And what about other URI schemes that will be used by = WF?

 

“What is secure” needs to be determined by the WF server = internally.  If adding an OpenID link relation, as an example, the = server knows (or the server admin knows) to mark this as “deliver = only via HTTPS”.

 

The best solution, though, is if you support HTTPS have all HTTP = queries redirected to HTTPS.  This makes life so much = simpler.  And if you only support HTTP, you know you there is no = security.  Clients (e.g., an client trying to perform an OpenID = login) would never even try HTTP.

 

Paul

 

From:= = John Panzer [mailto:jpanzer@google.com]
Sent: Thursday, = December 13, 2012 12:18 PM
To: = webfinger@googlegroups.com
Cc: Paul E. Jones; = webfinger@ietf.org
Subject: Re: [webfinger] secure links with = https rels

 

Right. =  This is also why you need this attribute as part of the official = "name" of the link relation, so the client knows which ones = are supposed to be secure with a simple .startsWith("https") = type of check.  Anything more complicated will create more security = issues.  (A registry of relations which tells you which link = relations are secure-only might work but only if it could be kept up to = date on all clients...)

 

I still = don't understand what the client will do with = rel=3D"canonical" though.  Does WebFinger exclude = registered rel-values?  They don't have to be URIs.

--
John = Panzer / Google
jpanzer@google.com / abstractioneer.org / = @jpanzer



=

On Thu, Dec = 13, 2012 at 8:54 AM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

On Thu, Dec = 13, 2012 at 8:45 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Don’t put it on the wire.  You want the server to filter = before sending a = reply.

 

I'm = concerned you're still confused about how a downgrade attack = works.

 

Again: it = DOES NOT MATTER what the server thinks it's filtering if the client has = been tricked into talking to a DIFFERENT SERVER which is then returning = malicious results.

 

Such = as:

-- client = wants "all links" for foo@example.com.

-- EVIL = HIJACKER BLOCKS PORT 443

-- EVIL = HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY = WANT:

  =        {

  =          "rel" : "https://openid.net/connect/server",=

  =          "type" : = "text/html",

  =          "href" : "https://attacker.openid.server/"

  =        },

 

See what = happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this = webfinger server over HTTP---- what's it doing returning rels starting = with https:? I'm gonna skip over those (or just return an = error)."

 

The real = webfinger server _was never even contacted_, so it doesn't matter = whether it was filtering or not.

 

 

------=_NextPart_000_06AD_01CDD93F.275129D0-- From evan@status.net Thu Dec 13 11:36:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC921F8A08 for ; Thu, 13 Dec 2012 11:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwJDCMTEBYM8 for ; Thu, 13 Dec 2012 11:36:38 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 453F921F89F9 for ; Thu, 13 Dec 2012 11:36:38 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id A397F8D44D1; Thu, 13 Dec 2012 19:49:07 +0000 (UTC) Message-ID: <50CA2E40.7020600@status.net> Date: Thu, 13 Dec 2012 14:36:32 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "webfinger@ietf.org" References: <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <31369E33-89A8-491F-A2D5-D59ED63813FE@telecomitalia.it> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090002020207020505070500" Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:36:39 -0000 This is a multi-part message in MIME format. --------------090002020207020505070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fetching "https://example.com/.well-known/webfinger?resource=user@example.com", and requiring a valid cert, I can be reasonably sure* that the entity in control of "example.com" asserts that the "avatar" for "user@example.com" is "http://example.com/avatar/user.jpg" (or whatever). I think this is good enough. I trust example.com to control accounts @example.com, more or less by definition. Is there a counter-example I'm missing here? -Evan On 12-12-13 02:21 PM, James M Snell wrote: > > > > On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick > > wrote: > > On Thu, Dec 13, 2012 at 10:54 AM, James M Snell > wrote: > > What I'm saying is that there should be an option of adding a > signature to the JRD document as a whole, generated using a > key trusted by both the client and server. This can be > provided either within the JRD document itself (perhaps > leveraging JSON Web Signatures [1]) or using an external > mechanism such as the proposed Integrity header [2]. Providing > this information would be entirely optional on the part of the > server. If it is provided, however, the client SHOULD verify > it prior to consuming the data. A client could choose not to > process any JRD unless the integrity check it provided. > > [1] > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 > [2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 > > How the client and server determine which key to use to > generate the signature is out of scope but > > > Which means nobody will use this. You can't just say "Here's a > big optional mechanism, but key details are missing... figure it > out, maybe." > > Also, what about this webfinger-specific? If you want to work on > signing HTTP responses (a noble goal), that's great, but there's > no reason it needs to be lumped into WebFinger. > > HTTPS, on the other hand, is well-understood and widely implemented. > > WebFinger isn't supposed to be about designing a new PKI or crypto > system. It's supposed to be a simple mechanism to read some > key/value pairs. > > > Last post on the topic because I've said basically everything I think > needs to be said on it: I never said this is WebFinger specific. I'm > not suggesting that anything be "lumped into WebFinger". Nor am I > suggesting that WF be "about designing a new PKI or crypto system". > If, however, WebFinger is going to be used in cases where verifying > the integrity of the provided information is critical, then the > specification needs to properly address how the integrity of the > information can be verified. HTTPS does not provide for that. Neither > does any notion of a "secure link relation". > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 --------------090002020207020505070500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Fetching "https://example.com/.well-known/webfinger?resource=user@example.com", and requiring a valid cert, I can be reasonably sure* that the entity in control of "example.com" asserts that the "avatar" for "user@example.com" is "http://example.com/avatar/user.jpg" (or whatever).

I think this is good enough. I trust example.com to control accounts @example.com, more or less by definition.

Is there a counter-example I'm missing here?

-Evan

On 12-12-13 02:21 PM, James M Snell wrote:


On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 10:54 AM, James M Snell <jasnell@gmail.com> wrote:
What I'm saying is that there should be an option of adding a signature to the JRD document as a whole, generated using a key trusted by both the client and server. This can be provided either within the JRD document itself (perhaps leveraging JSON Web Signatures [1]) or using an external mechanism such as the proposed Integrity header [2]. Providing this information would be entirely optional on the part of the server. If it is provided, however, the client SHOULD verify it prior to consuming the data. A client could choose not to process any JRD unless the integrity check it provided. 


How the client and server determine which key to use to generate the signature is out of scope but

Which means nobody will use this.  You can't just say "Here's a big optional mechanism, but key details are missing... figure it out, maybe."

Also, what about this webfinger-specific?  If you want to work on signing HTTP responses (a noble goal), that's great, but there's no reason it needs to be lumped into WebFinger.
 
HTTPS, on the other hand, is well-understood and widely implemented.

WebFinger isn't supposed to be about designing a new PKI or crypto system.  It's supposed to be a simple mechanism to read some key/value pairs.


Last post on the topic because I've said basically everything I think needs to be said on it: I never said this is WebFinger specific. I'm not suggesting that anything be "lumped into WebFinger". Nor am I suggesting that WF be "about designing a new PKI or crypto system". If, however, WebFinger is going to be used in cases where verifying the integrity of the provided information is critical, then the specification needs to properly address how the integrity of the information can be verified. HTTPS does not provide for that. Neither does any notion of a "secure link relation". 




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826
--------------090002020207020505070500-- From bradfitz@google.com Thu Dec 13 11:43:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2ED21F87FA for ; Thu, 13 Dec 2012 11:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb26fGs4Sq8q for ; Thu, 13 Dec 2012 11:43:04 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7E21F87C9 for ; Thu, 13 Dec 2012 11:43:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1159759wey.31 for ; Thu, 13 Dec 2012 11:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vCfvlYiOCj9jS1K5RNvufXfkRR4NRXLq7fZTEqfJwbY=; b=EUob+1MNXBUH4Hnlpdw+vV1MEU4niKxj82jjTc6L97ZXQaJF1oJwJZ42fLBtayj0Ph rhO8JZdq/32bumMiMrN8NKIhXjetb9jLuDB5CTmVZaa3QtJtgXfI+/aH96PZgvpCZ+C0 mCsGxvPl4LGm5C/Oy4De/093YChPKvtJc27PfsQKeH8cKbXACbjrlcvBKe/TB2KVQxk2 hxbzCWbafDnjOjP5tXr9vcjmfnkCqzKmdM+/jVHr3VkDMnN0wZieTXQY9w+k3adX4Ww/ lM9Zwx9bvfmLLMJlD6ckWy6g1Dz2xURFrsgbIkEwnJ9Kai9Q4lipewVwmPFOfwfnHWLB cCnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vCfvlYiOCj9jS1K5RNvufXfkRR4NRXLq7fZTEqfJwbY=; b=P6GlS8L4KqoOlnDRCAeoWIwuD8VQuXY0eFuXruuRTR8bt4IGBxyXY97ChqyawpwsFR gT2PLqJaUVomO1QlSmAiyY/h/CbDzIaZaWlxnp/olgr0HUIqULUvKNGigjoOvlFMbJ4W S/piD+Q4vlD90rnJ+oklzGRPm610JOfbPVq9AOksON/5bBpyLYPJdAr+vAMNjUKEGa/F vHODtkb2WRIjLNnYSg9O9/p6Q2RsX+1lKnGknVs8LC+tk4XALIjRbMLMsi+mbTOH0MLn B5buRdsn3S9ntENssFJC5YaVI4buTZ1R4dK9vdYAwmHm7E7qDOoHGhJv8YGVHVVdkOax TbZw== MIME-Version: 1.0 Received: by 10.180.74.108 with SMTP id s12mr5354621wiv.12.1355427758363; Thu, 13 Dec 2012 11:42:38 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 11:42:38 -0800 (PST) In-Reply-To: <06ac01cdd969$1025f950$3071ebf0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06ac01cdd969$1025f950$3071ebf0$@packetizer.com> Date: Thu, 13 Dec 2012 11:42:38 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d043c81e60e549904d0c11e3c X-Gm-Message-State: ALoCoQnIp2lnAK89cMOPAddDb1YcoldnR4lOFDmi6/XX9z/xF0HskBVkaHVV1IcT4DM037MhHj/EDsS1RxPvu1V5IlQVzmXligqdnBzxlifrbsDEXIPsyDGrxF8eCuoiM8d8szH55G2mkFQWxurSYt0erSVyCJijMk0O4SxQYDaQYSBFWYzXn7ed+2NmGvNF1o5swjlHf+Hl Cc: John Panzer , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:43:05 -0000 --f46d043c81e60e549904d0c11e3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 11:35 AM, Paul E. Jones wrot= e: > But starts with =E2=80=9Chttps=E2=80=9D does not mean security is importa= nt. We can=E2=80=99t use > that as the measuring stick. > No, I've been arguing that we can. Let me see how many ways I can say the exact same thing: Rather than say that all of WebFinger is HTTPS-only (an earlier proposal), we say that certain rel values are HTTPS-only, and certain rel values are either (HTTP or HTTPS). These "HTTPS-only rels" I've been calling "secure rels", and are denoted by the rel value (NOT the "href" value) beginning with "https:" (for those not registered with the IANA), or beginning with "secure-" (for those registered with the IANA). > And what about other URI schemes that will be used by WF? > hrefs don't matter. Only the rel part. "https:" or "secure-" prefix. Note that "secure-" isn't a scheme, because a rel is just a string, which may be a URL or may be some token. > ** =E2=80=9CWhat is secure=E2=80=9D needs to be determined by the WF serv= er internally. > No, false. It's determined by the use case. An application using WebFinger makes that call. OpenID is secure (rel "secure-openid-server" or something), but Evan's Status.net may want to not use secure rels, if they do their own security some other way, so they use "http://status.net/rel/fo= o", which then works over HTTPS or HTTP webfinger queries. The best solution, though, is if you support HTTPS have all HTTP queries > redirected to HTTPS. > That's a terrible solution, since anybody can MITM that and redirect the query to an attacker's HTTP or HTTPS server. This makes life so much simpler. And if you only support HTTP, you know > you there is no security. Clients (e.g., an client trying to perform an > OpenID login) would never even try HTTP. > > ** ** > > Paul**** > > ** ** > > *From:* John Panzer [mailto:jpanzer@google.com] > *Sent:* Thursday, December 13, 2012 12:18 PM > *To:* webfinger@googlegroups.com > *Cc:* Paul E. Jones; webfinger@ietf.org > > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > Right. This is also why you need this attribute as part of the official > "name" of the link relation, so the client knows which ones are supposed = to > be secure with a simple .startsWith("https") type of check. Anything mor= e > complicated will create more security issues. (A registry of relations > which tells you which link relations are secure-only might work but only = if > it could be kept up to date on all clients...)**** > > ** ** > > I still don't understand what the client will do with rel=3D"canonical" > though. Does WebFinger exclude registered rel-values? They don't have t= o > be URIs. > **** > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org /= @jpanzer > **** > > > > **** > > On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick > wrote:**** > > On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones > wrote:**** > > Don=E2=80=99t put it on the wire. You want the server to filter before s= ending a > reply.**** > > ** ** > > I'm concerned you're still confused about how a downgrade attack works.**= * > * > > ** ** > > Again: it DOES NOT MATTER what the server thinks it's filtering if the > client has been tricked into talking to a DIFFERENT SERVER which is then > returning malicious results.**** > > ** ** > > Such as:**** > > -- client wants "all links" for foo@example.com.**** > > -- client requests secure > https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com= *** > * > > -- EVIL HIJACKER BLOCKS PORT 443**** > > -- client then requests plain > http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com*= *** > > -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:*= * > ** > > {**** > > "rel" : "https://openid.net/connect/server",**** > > "type" : "text/html",**** > > "href" : "https://attacker.openid.server/"**** > > },**** > > ** ** > > See what happened there?**** > > We need the *client* to say "whoa whoa, wait a minute... I contacted this > webfinger server over HTTP---- what's it doing returning rels starting wi= th > https:? I'm gonna skip over those (or just return an error)."**** > > ** ** > > The real webfinger server _was never even contacted_, so it doesn't matte= r > whether it was filtering or not.**** > > ** ** > > ** ** > --f46d043c81e60e549904d0c11e3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0=


--f46d043c81e60e549904d0c11e3c-- From paulej@packetizer.com Thu Dec 13 11:51:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF3B21F88A3 for ; Thu, 13 Dec 2012 11:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDXu+kZcbVP2 for ; Thu, 13 Dec 2012 11:51:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 839A121F889C for ; Thu, 13 Dec 2012 11:51:40 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDJpbMG009057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 14:51:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355428298; bh=ime/wY7LrTxrJGCZXVmh67MmwbECTNj011eGo4mVZxk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=MUk4Vw+1hKcx/KHCrAOSibiuHob8fGqNvGrRLjobnjUgT4wd3zOOZys6E2cWdqvf+ VNHSqN5+qYDKAJSUaTFFpPJsRPs9BBVWXRf7xjETyqjIrfcxvpx7UK2vnjqKUZ0sRo WGIPEL9crktDW2meTwLmRMDoOQxFoDpC549/av7g= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , "'James M Snell'" References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 14:51:49 -0500 Message-ID: <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06CA_01CDD941.61CDC7B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsCYPcevIA== Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:51:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06CA_01CDD941.61CDC7B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 I agree the idea of marking a =E2=80=9Crel=E2=80=9D as secure using = https makes sense. That said, is my profile page to be marked secure or = not? Do we define to rel values for a profile page, one that=E2=80=99s = secure and one that=E2=80=99s not, then let the user specify the rel = type based on preference? =20 What I think makes more sense if for the WF server admin to select what = information to convey via HTTP or HTTPS. I would have no objection to = certain things (e.g., the URI used to identify the OpenID Provider) to = be specified using https, thereby aiding in helping the server (and = admin) in making that decision. =20 But, many rel values are just simple token strings. How do we deal with = those? =20 I still think this should be a server-side decision to filter. Better, = have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to = HTTP. And clients that need security NEVER use HTTP. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 1:40 PM To: James M Snell Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels =20 On Thu, Dec 13, 2012 at 10:36 AM, James M Snell = wrote: =20 =20 On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick = wrote: [snip] =20 =20 No... that's just nonsense. The real issue here is that the client has = absolutely no way of detecting that the evil hijacker intercepted the = request and provided false information in the first place. It should not = matter at all if the returned document contains link rels with "https:" = in them or not.=20 =20 You can never detect with HTTP that the connection was intercepted. = That doesn't matter, because the client does know one thing: that it = used HTTP (and not HTTPS). So the client can filter out links which = should not ever appear over plain HTTP. I'm proposing that rels which = begin with "https:" should never go over HTTP, and I've started calling = those "secure rels". Maybe that's a bad name, if enough people = (including you now, in your earlier email) assume that I'm talking about = the value (the href). =20 I'm open to alternative name suggestions. =20 =20 I'm -1 on the whole proposal. The notion of "insecure" and "secure" link = relations makes absolutely no sense at all. =20 I'd like to ask that you think about and understand it before being so = negative on it. =20 I promise it makes sense. =20 It may not be possible to detect if the HTTP connection was intercepted, = but it is possible to determine if the information provided is = trustworthy. That is what cryptographic signatures are for. =20 That is outside the scope of WebFinger, and may be used in subsequent = hops. We're trying to provide a secure basis for the first hop. If we = can't get any attribute securely for foo@example.com, where are we = getting the public key from to verify subsequent use of "cryptographic = signatures". =20 ------=_NextPart_000_06CA_01CDD941.61CDC7B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

I agree the idea of marking a =E2=80=9Crel=E2=80=9D as secure using = https makes sense.=C2=A0 That said, is my profile page to be marked = secure or not?=C2=A0 Do we define to rel values for a profile page, one = that=E2=80=99s secure and one that=E2=80=99s not, then let the user = specify the rel type based on preference?

 

What I think makes more sense if for the WF server admin to select = what information to convey via HTTP or HTTPS.=C2=A0 I would have no = objection to certain things (e.g., the URI used to identify the OpenID = Provider) to be specified using https, thereby aiding in helping the = server (and admin) in making that decision.

 

But, many rel values are just simple token strings.=C2=A0 How do we = deal with those?

 

I still think this should be a server-side decision to filter.=C2=A0 = Better, have the HTTP server redirect to HTTPS.=C2=A0 HTTPS servers = NEVER redirect to HTTP.=C2=A0 And clients that need security NEVER use = HTTP.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 1:40 PM
To: James M Snell
Cc: Paul = E. Jones; webfinger@ietf.org; = webfinger@googlegroups.com
Subject: Re: [webfinger] secure = links with https rels

 

On Thu, Dec = 13, 2012 at 10:36 AM, James M Snell <jasnell@gmail.com> = wrote:

 

 

On Thu, Dec = 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

[snip]

 

 

No... that's just = nonsense. The real issue here is that the client has absolutely no way = of detecting that the evil hijacker intercepted the request and provided = false information in the first place. It should not matter at all if the = returned document contains link rels with "https:" in them or = not. 

 

You can = never detect with HTTP that the connection was intercepted.  That = doesn't matter, because the client does know one thing:  that it = used HTTP (and not HTTPS).  So the client can filter out links = which should not ever appear over plain HTTP.  I'm proposing that = rels which begin with "https:" should never go over HTTP, and = I've started calling those "secure rels".  Maybe that's a = bad name, if enough people (including you now, in your earlier email) = assume that I'm talking about the value (the = href).

 

I'm open to = alternative name suggestions.

 

 

I'm -1 on = the whole proposal. The notion of "insecure" and = "secure" link relations makes absolutely no sense at = all.

 

I'd like to = ask that you think about and understand it before being so negative on = it.

 

I promise it = makes sense.

 

It may not = be possible to detect if the HTTP connection was intercepted, but it is = possible to determine if the information provided is trustworthy. That = is what cryptographic signatures are = for.

 

That is = outside the scope of WebFinger, and may be used in subsequent hops. =  We're trying to provide a secure basis for the first hop.  If = we can't get any attribute securely for foo@example.com, where are we = getting the public key from to verify subsequent use of = "cryptographic signatures".

 

------=_NextPart_000_06CA_01CDD941.61CDC7B0-- From bradfitz@google.com Thu Dec 13 12:00:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588121F88A7 for ; Thu, 13 Dec 2012 12:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alR4Ooa7EGih for ; Thu, 13 Dec 2012 12:00:03 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4403121F886B for ; Thu, 13 Dec 2012 12:00:02 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1168920wey.31 for ; Thu, 13 Dec 2012 12:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=anAJT/ovMkltGekRoyWNhcI07a4AnOcpeoT+O+jrJr4=; b=UdpbYbpX2R8XubklIOUpq51R52ak40g10Ur8E4LCjC0zqpc7hRLszI3AsniZOvwwdf Yhanx9OHLNGHDA3OdBki6cYVa3qnHMLO2OmrWdMeuCzNStt78j04AIee3AFMtrR7tj9/ CqR5ghvlK97Itr60pMfN9PPuGVEcpSer/LL4k/BWEhwqnS4omrKM1SkN7G6F5TBaOlJ+ bOoAChWilaHsCG1+RACUN2zQoUBYQV4NncqYNl3kJhnGPUUK2wb6W8mBHpjGKBiiaVUh VGN6WzzMQgkLMWa4vlC4alVt53YxM6AC8fpVkhSF/5OfsuI6EwWSI7o76Vte7pTqi/Gw eFyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=anAJT/ovMkltGekRoyWNhcI07a4AnOcpeoT+O+jrJr4=; b=AhxWXaSQoUtLzgj5+5IsXKCaDOX+BYAV465ABehSQIe3HF08TITMt/+BXFvbEBlY+3 fPBsEHgIZqLqxJShgZKQ3CEJCP9Zyl+lRA1yWPiCYHqoVcSPFYvRQPsn3zUbbC6ns748 UASNcLt4XPM/tv6iRdWNbXnUXAzPtAHrhb4p3o0Qojb0nDf/VC1sBTvYy0Oh3uT2EW9k SSYbnre7hp8zn+GMmHKreSKlErcQCgZUTPLYPcSafVKvjuyAuo3jpW9aPqbXg+aQ3o28 3Gjzy9hdp0ZxHLHpMIcxTZx5+SXmwdNFMeQohAMsD/+JDRVa9SKNREgXRAgCLFddWLOe aREg== MIME-Version: 1.0 Received: by 10.194.58.175 with SMTP id s15mr102450wjq.31.1355428801385; Thu, 13 Dec 2012 12:00:01 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 12:00:01 -0800 (PST) In-Reply-To: <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 12:00:01 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7ba979243995ec04d0c15cf5 X-Gm-Message-State: ALoCoQnLu3NlVBneZJgXU71SkryjbNw8uP5+FllG9d5WmclK4jffXBI/4hfzKmot8Hg1SGOfFLxLmGGGFsdzUSIClvMWik7SmkTpsg9Euaw4jAgwYcaYQI0mgTba9DlQaH6ojMna1DF/JwJCG9YRKdNLHle3rGfw5iXumHS4R1jPigiyFnAfz5cNCEow+oBFwGugUuHw4ogl Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:00:04 -0000 --047d7ba979243995ec04d0c15cf5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones wrot= e: > Brad,**** > > ** ** > > I agree the idea of marking a =E2=80=9Crel=E2=80=9D as secure using https= makes sense. > That said, is my profile page to be marked secure or not? Do we define t= o > rel values for a profile page, one that=E2=80=99s secure and one that=E2= =80=99s not, then > let the user specify the rel type based on preference? > rel values are selected per-application. "secure-openid-connect-server" is secure, and the OpenID Connect spec would say "look up the 'secure-openid-connect-server' rel". If you're using a "blog" rel, that is not secure (it does not begin with "secure-"), just v1 of this whole webfinger spec, where there was no security. > **** > > ** What I think makes more sense if for the WF server admin to select > what information to convey via HTTP or HTTPS. > Downgrade attack. See my and Zellyn's emails elsewhere. > I would have no objection to certain things (e.g., the URI used to > identify the OpenID Provider) to be specified using https, thereby aiding > in helping the server (and admin) in making that decision. > > ** ** > > But, many rel values are just simple token strings. How do we deal with > those? > If they start with "secure-", they're HTTPS-only. If they're like "blog" or "avatar", HTTP is acceptable, like earlier drafts of the spec. > **** > > ** I still think this should be a server-side decision to filter. > Better, have the HTTP server redirect to HTTPS. HTTPS servers NEVER > redirect to HTTP. And clients that need security NEVER use HTTP. > What if the client doesn't know what it wants yet? Imagine: the client wants to query all links for foo@example.com to see what it can do with foo@example.com. Maybe it can show a pretty picture. Maybe it can do OpenID connect. So what do you use? HTTP or HTTPS? The proposal is that you do both, either serially or in parallel, preferring a valid HTTPS response, but filtering out secure rels if you end up using the HTTP connection. Then the client gets back some list of rels (and href values, not shown): "blog", "avatar", "secure-openid-connect-server", " https://webfinger.net/rel/key-server" Or, if HTTP was used: "blog", "avatar", "http://status.net/rel/foo" --047d7ba979243995ec04d0c15cf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Brad,

=C2=A0

I agree the idea of= marking a =E2=80=9Crel=E2=80=9D as secure using https makes sense.=C2=A0 T= hat said, is my profile page to be marked secure or not?=C2=A0 Do we define= to rel values for a profile page, one that=E2=80=99s secure and one that= =E2=80=99s not, then let the user specify the rel type based on preference?=


rel values are selected per-ap= plication. =C2=A0"secure-openid-connect-server" is secure, and th= e OpenID Connect spec would say "look up the 'secure-openid-connec= t-server' rel".

If you're using a "blog" rel, that is not= secure (it does not begin with "secure-"), just v1 of this whole= webfinger spec, where there was no security.

=C2=A0

=C2=A0What I think makes more sense if for the WF server admin to select what = information to convey via HTTP or HTTPS.=C2=A0


Downgrade attack. =C2=A0See my and Z= ellyn's emails elsewhere.
=C2=A0

I would have no objection to certain things= (e.g., the URI used to identify the OpenID Provider) to be specified using= https, thereby aiding in helping the server (and admin) in making that dec= ision.

=C2=A0

But, many rel value= s are just simple token strings.=C2=A0 How do we deal with those?


If they start with "secure-&quo= t;, they're HTTPS-only. =C2=A0If they're like "blog" or &= quot;avatar", HTTP is acceptable, like earlier drafts of the spec.
=C2=A0

<= u>

=C2=A0I still think this should be a server-side decision to filter.=C2=A0 Bet= ter, have the HTTP server redirect to HTTPS.=C2=A0 HTTPS servers NEVER redi= rect to HTTP.=C2=A0 And clients that need security NEVER use HTTP.



So what do you use? =C2=A0HTTP or HTTPS?

=
The proposal is that you do both, either serially or in parallel= , preferring a valid HTTPS response, but filtering out secure rels if you e= nd up using the HTTP connection.

Then the client gets back some list of rels (and href v= alues, not shown):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"blog", "avatar", "secure-openid-connect-server= ", "https://webf= inger.net/rel/key-server"

Or, if HTTP was used:

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"blog", "avatar", "http://status.net/rel/foo"
=


--047d7ba979243995ec04d0c15cf5-- From tbray@textuality.com Thu Dec 13 12:00:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4384321F8AE2 for ; Thu, 13 Dec 2012 12:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aXdGwSYY2IV for ; Thu, 13 Dec 2012 12:00:43 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE60D21F8AC9 for ; Thu, 13 Dec 2012 12:00:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2647165oag.31 for ; Thu, 13 Dec 2012 12:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kLR9ick/t/Wq1qh/9SiIxqjbvdapwyP8R/Q1b+T6FXc=; b=Cuf9SlweRyF06iqqJj7R0xZL9nj233dit8rUsA4izpaxKu1OyNp4bufjo2Xf7JujIT bzfzlQXD1n5EYUqzdZvG1mkQu9mtHXD7B21FDS1cJEIcEZlkODsKkzZsrXQT7hPfq3vg 2P0bZL1jv0vKLf+x8YgIoyVycSSXXFNwkYTkcF+F1ldvvxGORHd2+enzyTnGwMf5CsBk d3v5IlXuhK5OM4g+yLucn1fVU3Bo1F6kerYRkOxmp6hBFSaKldtlNKyk2j2eDaObZbu3 wJKuZne5QBUSvjfDYUmKW0ykYjbMv4slZXICdPgmhy0LSnDdZaLxR042j5sUpyNYYQD/ baRg== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr2545731oeb.24.1355428841035; Thu, 13 Dec 2012 12:00:41 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 13 Dec 2012 12:00:40 -0800 (PST) X-Originating-IP: [96.49.76.76] In-Reply-To: <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 12:00:40 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f41896994a04d0c15ef7 X-Gm-Message-State: ALoCoQnmK35E1pqXXPwXzbCP7Nz24d27BAuFqKTGjZlCMu+uua1YiVvQPhFcVXbvQgV60C4H8s+o Cc: Brad Fitzpatrick , James M Snell , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:00:46 -0000 --e89a8fb1f41896994a04d0c15ef7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Watching these threads, it seems like people aren=92t hearing each other: Team A: We really need a way to use WF in a way that=92s guaranteed to be HTTPS-only. Team B: HTTPS is too hard for some people and unnecessary for some apps. On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones wrot= e: > Brad,**** > > ** ** > > I agree the idea of marking a =93rel=94 as secure using https makes sense= . > That said, is my profile page to be marked secure or not? Do we define t= o > rel values for a profile page, one that=92s secure and one that=92s not, = then > let the user specify the rel type based on preference? > Why not? > **** > > What I think makes more sense if for the WF server admin to select what > information to convey via HTTP or HTTPS. I would have no objection to > certain things (e.g., the URI used to identify the OpenID Provider) to be > specified using https, thereby aiding in helping the server (and admin) i= n > making that decision. > This doesn't meet the needs of Team A. They need a way to fetch a resource that doesn't leave it up to the server. > But, many rel values are just simple token strings. How do we deal with > those? > Well, the idea is that a group like OpenID Connect could specify a required rel value that is marked as secure. Existing rel values aren't. This seems OK to me. > **** > > I still think this should be a server-side decision to filter. Better, > have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to > HTTP. And clients that need security NEVER use HTTP. > Team A really think they need to impose HTTPS-only from the request side. You may not have such a need, or even agree that it exists, but there are people who really think they need it, and that won't go away. > ** ** > > Paul**** > > ** ** > > *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] > *Sent:* Thursday, December 13, 2012 1:40 PM > *To:* James M Snell > *Cc:* Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com > > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote= : > **** > > ** ** > > ** ** > > On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick > wrote:**** > > [snip]**** > > ** ** > > ** ** > > No... that's just nonsense. The real issue here is that the client has > absolutely no way of detecting that the evil hijacker intercepted the > request and provided false information in the first place. It should not > matter at all if the returned document contains link rels with "https:" i= n > them or not. **** > > ** ** > > You can never detect with HTTP that the connection was intercepted. That > doesn't matter, because the client does know one thing: that it used HTT= P > (and not HTTPS). So the client can filter out links which should not eve= r > appear over plain HTTP. I'm proposing that rels which begin with "https:= " > should never go over HTTP, and I've started calling those "secure rels". > Maybe that's a bad name, if enough people (including you now, in your > earlier email) assume that I'm talking about the value (the href).**** > > ** ** > > I'm open to alternative name suggestions.**** > > ** ** > > ** ** > > I'm -1 on the whole proposal. The notion of "insecure" and "secure" link > relations makes absolutely no sense at all.**** > > ** ** > > I'd like to ask that you think about and understand it before being so > negative on it.**** > > ** ** > > I promise it makes sense.**** > > **** > > It may not be possible to detect if the HTTP connection was intercepted, > but it is possible to determine if the information provided is trustworth= y. > That is what cryptographic signatures are for.**** > > ** ** > > That is outside the scope of WebFinger, and may be used in subsequent > hops. We're trying to provide a secure basis for the first hop. If we > can't get any attribute securely for foo@example.com, where are we > getting the public key from to verify subsequent use of "cryptographic > signatures".**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8fb1f41896994a04d0c15ef7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Watching these threads, it seems like people aren=92t hearing each other:
Team A: We really need a way to use WF in a way that=92s guaranteed t= o be HTTPS-only.
Team B: HTTPS is too hard for some people and unnecessa= ry for some apps.


On Thu, Dec 13, 2012 at 11:51 AM, Paul E= . Jones <paulej@packetizer.com> wrote:

Brad,

=A0

I agree the idea of marking a =93rel=94 as se= cure using https makes sense.=A0 That said, is my profile page to be marked= secure or not?=A0 Do we define to rel values for a profile page, one that= =92s secure and one that=92s not, then let the user specify the rel type ba= sed on preference?


Why not?
=A0

= =A0What I think makes more sense if for the WF s= erver admin to select what information to convey via HTTP or HTTPS.=A0 I wo= uld have no objection to certain things (e.g., the URI used to identify the= OpenID Provider) to be specified using https, thereby aiding in helping th= e server (and admin) in making that decision.


This doesn't meet the needs of Team A= . They need a way to fetch a resource that doesn't leave it up to the s= erver.
=A0

But, many rel values are just simple token s= trings.=A0 How do we deal with those?


Well, the idea is that a group like OpenI= D Connect could specify a required rel value that is marked as secure.=A0 E= xisting rel values aren't. This seems OK to me.
=A0

=A0I still think this should be a server-sid= e decision to filter.=A0 Better, have the HTTP server redirect to HTTPS.=A0= HTTPS servers NEVER redirect to HTTP.=A0 And clients that need security NE= VER use HTTP.


Team A really think they need to impose H= TTPS-only from the request side.=A0 You may not have such a need, or even a= gree that it exists, but there are people who really think they need it, an= d that won't go away.
=A0

<= /u>=A0

Paul=

=A0

From:= Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snel= l
Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links with htt= ps rels

=A0

On Thu, Dec 13, 2012 = at 10:36 AM, James M Snell <jasnell@gmail.com> wrote:

=A0

=A0

On Thu, Dec 1= 3, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

[snip]

=

=A0

=A0

No... that's just nonsense. The= real issue here is that the client has absolutely no way of detecting that= the evil hijacker intercepted the request and provided false information i= n the first place. It should not matter at all if the returned document con= tains link rels with "https:" in them or not.=A0

=A0

= You can never detect with HTTP that the connection was intercepted. =A0That= doesn't matter, because the client does know one thing: =A0that it use= d HTTP (and not HTTPS). =A0So the client can filter out links which should = not ever appear over plain HTTP. =A0I'm proposing that rels which begin= with "https:" should never go over HTTP, and I've started ca= lling those "secure rels". =A0Maybe that's a bad name, if eno= ugh people (including you now, in your earlier email) assume that I'm t= alking about the value (the href).

=A0

I'm open to alternative name= suggestions.

=A0

=A0=

I'm -1 on the whole propos= al. The notion of "insecure" and "secure" link relation= s makes absolutely no sense at all.

=A0=

I'd like t= o ask that you think about and understand it before being so negative on it= .

=A0=

I promise it makes sense.<= u>

=A0

It may not be possible to detect if = the HTTP connection was intercepted, but it is possible to determine if the= information provided is trustworthy. That is what cryptographic signatures= are for.

=A0=

That is outside the= scope of WebFinger, and may be used in subsequent hops. =A0We're tryin= g to provide a secure basis for the first hop. =A0If we can't get any a= ttribute securely for = foo@example.com, where are we getting the public key from to verify sub= sequent use of "cryptographic signatures".

=A0


_________________________= ______________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8fb1f41896994a04d0c15ef7-- From ve7jtb@ve7jtb.com Thu Dec 13 12:04:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52621F898B for ; Thu, 13 Dec 2012 12:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSGA76ErSeUy for ; Thu, 13 Dec 2012 12:04:26 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6DB221F897E for ; Thu, 13 Dec 2012 12:04:25 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1171286wey.31 for ; Thu, 13 Dec 2012 12:04:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=rkFtkreO5Gc5Xb1hntkyHXLvs9LLEPOGBRADTUof3a8=; b=kpgVA1S8mgrl+K1ZgoT2VY/+5CDD3ECQGkuSd8kQKPz4QXzwQkARCDONFcbjelt2gZ RZkey1tYhd8Q4P+42GELOd2RIvD5p4p9QD5cmou6R0xQmGvlTEem2qdkq1o19b/qtpR4 GDayDJPm6Df0rfd+U+zdBiEGQ1fB0lo9n2fythIC8sX8eKMUt/uFJtbmlZFWPvDr5PM7 xchIvF0VTi2LbSExAPIY5Kwf/VINFyCLmQsmmGGPVn1k3BpJyZKITsuk64oohzOMxoan hcGOcQPIdOEYMUMNrSiObo5ilVS2oqlX9frhFs7d+uEBjwUUOWMnMgyfSlUGww0NMxst mJ1Q== Received: by 10.194.86.40 with SMTP id m8mr150693wjz.24.1355429064521; Thu, 13 Dec 2012 12:04:24 -0800 (PST) Received: from [10.167.220.187] (92.40.254.64.threembb.co.uk. [92.40.254.64]) by mx.google.com with ESMTPS id dm3sm9277326wib.9.2012.12.13.12.04.21 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 12:04:22 -0800 (PST) References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9CA3A6B2-AFF1-4EA3-BD36-8106C7B7E218; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <411A4E80-8233-4406-8443-604FAC5DDBE3@ve7jtb.com> X-Mailer: iPhone Mail (10A523) From: John Bradley Date: Thu, 13 Dec 2012 20:04:19 +0000 To: "webfinger@googlegroups.com" X-Gm-Message-State: ALoCoQns7RALT9gglxhMYMx+fEDvj5euJGMT9SvxoML5uMMvcENGgDzItManvPvaOPrtzPsfIQ/5 Cc: Brad Fitzpatrick , James M Snell , "" , "" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:04:27 -0000 --Apple-Mail-9CA3A6B2-AFF1-4EA3-BD36-8106C7B7E218 Content-Type: multipart/alternative; boundary=Apple-Mail-04E0A33A-50A8-407F-A501-0F70DF417BC8 Content-Transfer-Encoding: 7bit --Apple-Mail-04E0A33A-50A8-407F-A501-0F70DF417BC8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul. The server side filter is a distraction. It provides no security.=20 The client needs to filter on the secure flag, whatever that is.=20 John B.=20 Sent from my iPhone On 2012-12-13, at 7:51 PM, "Paul E. Jones" wrote: > Brad, > =20 > I agree the idea of marking a =E2=80=9Crel=E2=80=9D as secure using https m= akes sense. That said, is my profile page to be marked secure or not? Do w= e define to rel values for a profile page, one that=E2=80=99s secure and one= that=E2=80=99s not, then let the user specify the rel type based on prefere= nce? > =20 > What I think makes more sense if for the WF server admin to select what in= formation to convey via HTTP or HTTPS. I would have no objection to certain= things (e.g., the URI used to identify the OpenID Provider) to be specified= using https, thereby aiding in helping the server (and admin) in making tha= t decision. > =20 > But, many rel values are just simple token strings. How do we deal with t= hose? > =20 > I still think this should be a server-side decision to filter. Better, ha= ve the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to HTTP.= And clients that need security NEVER use HTTP. > =20 > Paul > =20 > From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 > Sent: Thursday, December 13, 2012 1:40 PM > To: James M Snell > Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com > Subject: Re: [webfinger] secure links with https rels > =20 > On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote:= > =20 > =20 >=20 > On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick w= rote: > [snip] > =20 > =20 > No... that's just nonsense. The real issue here is that the client has abs= olutely no way of detecting that the evil hijacker intercepted the request a= nd provided false information in the first place. It should not matter at al= l if the returned document contains link rels with "https:" in them or not.=20= > =20 > You can never detect with HTTP that the connection was intercepted. That d= oesn't matter, because the client does know one thing: that it used HTTP (a= nd not HTTPS). So the client can filter out links which should not ever app= ear over plain HTTP. I'm proposing that rels which begin with "https:" shou= ld never go over HTTP, and I've started calling those "secure rels". Maybe t= hat's a bad name, if enough people (including you now, in your earlier email= ) assume that I'm talking about the value (the href). > =20 > I'm open to alternative name suggestions. > =20 > =20 > I'm -1 on the whole proposal. The notion of "insecure" and "secure" link r= elations makes absolutely no sense at all. > =20 > I'd like to ask that you think about and understand it before being so neg= ative on it. > =20 > I promise it makes sense. > =20 > It may not be possible to detect if the HTTP connection was intercepted, b= ut it is possible to determine if the information provided is trustworthy. T= hat is what cryptographic signatures are for. > =20 > That is outside the scope of WebFinger, and may be used in subsequent hops= . We're trying to provide a secure basis for the first hop. If we can't ge= t any attribute securely for foo@example.com, where are we getting the publi= c key from to verify subsequent use of "cryptographic signatures". > =20 --Apple-Mail-04E0A33A-50A8-407F-A501-0F70DF417BC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Paul. The server side filter is a dist= raction. It provides no security. 

The client n= eeds to filter on the secure flag, whatever that is. 

John B. 

Sent from my iPhone

On 2012-12-13= , at 7:51 PM, "Paul E. Jones" <p= aulej@packetizer.com> wrote:

<= div>

Brad,

 

I agree the idea of marking a =E2=80=9Cr= el=E2=80=9D as secure using https makes sense.  That said, is my profil= e page to be marked secure or not?  Do we define to rel values for a pr= ofile page, one that=E2=80=99s secure and one that=E2=80=99s not, then let t= he user specify the rel type based on preference?

 

What I think makes more sense i= f for the WF server admin to select what information to convey via HTTP or H= TTPS.  I would have no objection to certain things (e.g., the URI used t= o identify the OpenID Provider) to be specified using https, thereby aiding i= n helping the server (and admin) in making that decision.<= /p>

 =

But, many rel values ar= e just simple token strings.  How do we deal with those?

 

I still think this s= hould be a server-side decision to filter.  Better, have the HTTP serve= r redirect to HTTPS.  HTTPS servers NEVER redirect to HTTP.  And c= lients that need security NEVER use HTTP.

 

Paul

 

From: Brad = Fitzpatrick [mailto:bradfitz@google.c= om]
Sent: Thursday, December 13, 2012 1:40 PM
To: J= ames M Snell
Cc: Paul E. Jones; webfinger@ietf.org; we= bfinger@googlegroups.com
Subject: Re: [webfinger] secure links= with https rels

 

On Thu, Dec 13, 2012= at 10:36 AM, James M Snell <jasnell@gmail.com> wrote:

=  

 

On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> w= rote:

[snip]=

 

 

No... that's just nonsense. The real= issue here is that the client has absolutely no way of detecting that the e= vil hijacker intercepted the request and provided false information in the f= irst place. It should not matter at all if the returned document contains li= nk rels with "https:" in them or not. 

<= o:p> 

You can never detect with HTTP that the connection was intercepted.  T= hat doesn't matter, because the client does know one thing:  that it us= ed HTTP (and not HTTPS).  So the client can filter out links which shou= ld not ever appear over plain HTTP.  I'm proposing that rels which begi= n with "https:" should never go over HTTP, and I've started calling those "s= ecure rels".  Maybe that's a bad name, if enough people (including you n= ow, in your earlier email) assume that I'm talking about the value (the href= ).

&nb= sp;

I'm open to a= lternative name suggestions.

 

=

 

I'm -1 on the whole proposal. The notion of "in= secure" and "secure" link relations makes absolutely no sense at all.

 

I'd l= ike to ask that you think about and understand it before being so negative o= n it.

 

I pr= omise it makes sense.

 

It may not be poss= ible to detect if the HTTP connection was intercepted, but it is possible to= determine if the information provided is trustworthy. That is what cryptogr= aphic signatures are for.

 

That is outside the scope of WebFinger, and may be use= d in subsequent hops.  We're trying to provide a secure basis for the f= irst hop.  If we can't get any attribute securely for foo@example.com, where are we getting the public key f= rom to verify subsequent use of "cryptographic signatures".

 

= --Apple-Mail-04E0A33A-50A8-407F-A501-0F70DF417BC8-- --Apple-Mail-9CA3A6B2-AFF1-4EA3-BD36-8106C7B7E218 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTIxMzIwMDQyNFowIwYJKoZIhvcNAQkEMRYEFLnE EIDhkYGabvdjhv7/LFV4PXsyMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAGZp3r0NeT2PKczTaQyHdOkYf9VfrCT2/ooz d9rMy5RSIsVKiAd25KfxEyEL0qt5dqZ5l9mHApqGPTr10alQ07Nx2OWPBxXUeYVlwaqApMmdtkWL eT64x7Jt8Zc6KRj3MvNjuCZWUBUmviOxa12FnmaEFpELjkM++ibOt3Kk3QGI+hmuJe7R46XF0tSG R3TGeZCKi6ml12hOEsdmcqGR96alPHoyPJVontpDkWHbRGFt2QuANI9kNS5Wmtg6EcnY5KWXKzBP nd5FDTkF1cTcsjU+LstfVJNek0aSVrp8tucLJ3BhzVXikJV3OZbo1svo6l9VLXuCTZqZB3pnIT+D G7MAAAAAAAA= --Apple-Mail-9CA3A6B2-AFF1-4EA3-BD36-8106C7B7E218-- From ve7jtb@ve7jtb.com Thu Dec 13 12:05:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2DD21F8A96 for ; Thu, 13 Dec 2012 12:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRWTqP662q4t for ; Thu, 13 Dec 2012 12:05:05 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8421F89AE for ; Thu, 13 Dec 2012 12:05:05 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1014364wgb.13 for ; Thu, 13 Dec 2012 12:05:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=plJOSFqnkk/7yokXXkXf8VwLoWadGqzEg1BuM5zsTDw=; b=SsiBkLh61Ap0gpljv/DPoBY/jUfQUuy5GBY7dUK+AZ3j7IJkbiUtndGh7x7WsbkmKN T+nIQiqX3A1I2HaD1/IwJV6ZYjao+S3SnY9JuZH5ADzb7eW4ZLxjU0gvLdZ6EuvZ56us SoE/a0g9pWdqrlI3zEXP5Xyjr5bBGXEk1R8boco4/KT2x7WEH+upfvgt4+kYPnCag6jR WCuefVWNWQEr1jd9X/3I/QaDdU2eX56MLPAPg30NvG3td+iV2ewnEC8QHLza5m1K2lr6 APa9gWglh6xaMUwj9a8Ui9AeswyZy+GCKtY/vY2BaZteuG4noIKt8koM/aGSEPWMpPNq +wHA== Received: by 10.194.119.5 with SMTP id kq5mr60330wjb.48.1355429104434; Thu, 13 Dec 2012 12:05:04 -0800 (PST) Received: from [10.167.220.187] (92.40.254.64.threembb.co.uk. [92.40.254.64]) by mx.google.com with ESMTPS id dm3sm9277326wib.9.2012.12.13.12.04.58 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 12:05:03 -0800 (PST) References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7EB30CA4-89EB-46E5-9669-F0FE4F44509B; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A523) From: John Bradley Date: Thu, 13 Dec 2012 20:04:54 +0000 To: "webfinger@googlegroups.com" X-Gm-Message-State: ALoCoQkND6SsUn4OkdPJhDdZYcg1GywaYb9BC/hKjX1KXo2kYN3g4UvsYYaMTctoaQZB8LH3UyRi Cc: Brad Fitzpatrick , James M Snell , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:05:06 -0000 --Apple-Mail-7EB30CA4-89EB-46E5-9669-F0FE4F44509B Content-Type: multipart/alternative; boundary=Apple-Mail-D6620E8F-D6AA-45CB-83F5-09E9B620E85A Content-Transfer-Encoding: 7bit --Apple-Mail-D6620E8F-D6AA-45CB-83F5-09E9B620E85A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Sent from my iPhone On 2012-12-13, at 7:55 PM, Zellyn Hunter wrote: > Paul, >=20 > It has to happen on the client. >=20 > 1. Application code tries to look up "secure-openid-server"=20 > 2. Client tries to connect to https://www.zellyn.com/ > 3. Evil adversary blocks the request. > 4. Client falls back to HTTP. > 5. Evil adversary returns a response that includes a value for rel=3D"secu= re-openid-server" > 6. Profit. >=20 >=20 >=20 > On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones wr= ote: >> Brad, >>=20 >> =20 >>=20 >> I agree the idea of marking a =E2=80=9Crel=E2=80=9D as secure using https= makes sense. That said, is my profile page to be marked secure or not? Do= we define to rel values for a profile page, one that=E2=80=99s secure and o= ne that=E2=80=99s not, then let the user specify the rel type based on prefe= rence? >>=20 >> =20 >>=20 >> What I think makes more sense if for the WF server admin to select what i= nformation to convey via HTTP or HTTPS. I would have no objection to certai= n things (e.g., the URI used to identify the OpenID Provider) to be specifie= d using https, thereby aiding in helping the server (and admin) in making th= at decision. >>=20 >> =20 >>=20 >> But, many rel values are just simple token strings. How do we deal with t= hose? >>=20 >> =20 >>=20 >> I still think this should be a server-side decision to filter. Better, h= ave the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to HTTP= . And clients that need security NEVER use HTTP. >>=20 >> =20 >>=20 >> Paul >>=20 >> =20 >>=20 >> From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 >> Sent: Thursday, December 13, 2012 1:40 PM >> To: James M Snell >> Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com >>=20 >>=20 >> Subject: Re: [webfinger] secure links with https rels >> =20 >>=20 >> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote= : >>=20 >> =20 >>=20 >> =20 >>=20 >> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick w= rote: >>=20 >> [snip] >>=20 >> =20 >>=20 >> =20 >>=20 >> No... that's just nonsense. The real issue here is that the client has ab= solutely no way of detecting that the evil hijacker intercepted the request a= nd provided false information in the first place. It should not matter at al= l if the returned document contains link rels with "https:" in them or not.=20= >>=20 >> =20 >>=20 >> You can never detect with HTTP that the connection was intercepted. That= doesn't matter, because the client does know one thing: that it used HTTP (= and not HTTPS). So the client can filter out links which should not ever ap= pear over plain HTTP. I'm proposing that rels which begin with "https:" sho= uld never go over HTTP, and I've started calling those "secure rels". Maybe= that's a bad name, if enough people (including you now, in your earlier ema= il) assume that I'm talking about the value (the href). >>=20 >> =20 >>=20 >> I'm open to alternative name suggestions. >>=20 >> =20 >>=20 >> =20 >>=20 >> I'm -1 on the whole proposal. The notion of "insecure" and "secure" link r= elations makes absolutely no sense at all. >>=20 >> =20 >>=20 >> I'd like to ask that you think about and understand it before being so ne= gative on it. >>=20 >> =20 >>=20 >> I promise it makes sense. >>=20 >> =20 >>=20 >> It may not be possible to detect if the HTTP connection was intercepted, b= ut it is possible to determine if the information provided is trustworthy. T= hat is what cryptographic signatures are for. >>=20 >> =20 >>=20 >> That is outside the scope of WebFinger, and may be used in subsequent hop= s. We're trying to provide a secure basis for the first hop. If we can't g= et any attribute securely for foo@example.com, where are we getting the publ= ic key from to verify subsequent use of "cryptographic signatures". >>=20 >=20 --Apple-Mail-D6620E8F-D6AA-45CB-83F5-09E9B620E85A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Sent from my iPhone

On 2012-12-13, at 7:55 PM, Zellyn Hunter <zellyn@gmail.com> wrote:

Paul,

It has to happen on the client.

1. Application code tries to look up "secure-openid-server" 
2. Client tries to connect to https= ://www.zellyn.com/
3. Evil adversary blocks the request.
=
4. Client falls back to HTTP.
5. Evil adversary returns a res= ponse that includes a value for rel=3D"secure-openid-server"
6. Profit.



On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones <pa= ulej@packetizer.com> wrote:

Brad,

 =

I agree the idea of mar= king a =E2=80=9Crel=E2=80=9D as secure using https makes sense.  That s= aid, is my profile page to be marked secure or not?  Do we define to re= l values for a profile page, one that=E2=80=99s secure and one that=E2=80=99= s not, then let the user specify the rel type based on preference?=

 =

What I think makes more= sense if for the WF server admin to select what information to convey via H= TTP or HTTPS.  I would have no objection to certain things (e.g., the U= RI used to identify the OpenID Provider) to be specified using https, thereb= y aiding in helping the server (and admin) in making that decision.

 =

But, many rel values ar= e just simple token strings.  How do we deal with those?<= /span>

 =

I still think this shou= ld be a server-side decision to filter.  Better, have the HTTP server r= edirect to HTTPS.  HTTPS servers NEVER redirect to HTTP.  And clie= nts that need security NEVER use HTTP.

 =

Paul

 =

From:= Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snell=
Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links with http= s rels

&= nbsp;

On Thu, Dec 13, 2012 a= t 10:36 AM, James M Snell <jasnell@gmail.com> wrote:

 

=  

On Thu, Dec 13= , 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

[snip]

 

=

 

No... that's just nonsense. The real i= ssue here is that the client has absolutely no way of detecting that the evi= l hijacker intercepted the request and provided false information in the fir= st place. It should not matter at all if the returned document contains link= rels with "https:" in them or not. 

=  

You c= an never detect with HTTP that the connection was intercepted.  That do= esn't matter, because the client does know one thing:  that it used HTT= P (and not HTTPS).  So the client can filter out links which should not= ever appear over plain HTTP.  I'm proposing that rels which begin with= "https:" should never go over HTTP, and I've started calling those "secure r= els".  Maybe that's a bad name, if enough people (including you now, in= your earlier email) assume that I'm talking about the value (the href).<= /u>

 

<= /div>

I'm open to alternative name sugg= estions.

 

<= /div>

 <= u>

I'm -1 on the whole proposal. Th= e notion of "insecure" and "secure" link relations makes absolutely no sense= at all.

 

I'd like to ask= that you think about and understand it before being so negative on it.

 

I promise it makes sense.

 

<= /div>

It may not be possible to detect if th= e HTTP connection was intercepted, but it is possible to determine if the in= formation provided is trustworthy. That is what cryptographic signatures are= for.

 

That is outside the s= cope of WebFinger, and may be used in subsequent hops.  We're trying to= provide a secure basis for the first hop.  If we can't get any attribu= te securely for foo@exa= mple.com, where are we getting the public key from to verify subsequent u= se of "cryptographic signatures".

 

<= /div>

=
= --Apple-Mail-D6620E8F-D6AA-45CB-83F5-09E9B620E85A-- --Apple-Mail-7EB30CA4-89EB-46E5-9669-F0FE4F44509B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTIxMzIwMDQ1NlowIwYJKoZIhvcNAQkEMRYEFP2y 02ddBUiNMjf0M8pTKZ9bMhjHMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAHQIhcdSd6aJDLvTfwketq9ycxqrLyR2io3u UpipfmM7MXDE+urd8vGP4Be43uX4C0UZaKh+7bl6c6zq1XhOjeXIURoP/TNIMroJZD/2WQuQNHPj ii7AAYja+bOgSGqvVTR2IDbYL7B2pyhCjT8LbXZXEZXi68NbG8yotDAKJIAwVkhAbMulPGTtR9ug ppXTDCO1krujTT67771bprysPwOuhp1wL2CbD+APoOvDYTHXYC2cRu59Jc3grXZfNx4dPV9skBnS k/t3EB8M4OkL7QVEepQRUX3t2bzlJGtebeHA0vBBh+8ys2d1Mw/PnyRuuhAIvemOkZQX/dOUsn8P +LcAAAAAAAA= --Apple-Mail-7EB30CA4-89EB-46E5-9669-F0FE4F44509B-- From jasnell@gmail.com Thu Dec 13 12:08:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE61921F8614 for ; Thu, 13 Dec 2012 12:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=-1.498, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_AMP2B=2.555] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDwU+yFIj6su for ; Thu, 13 Dec 2012 12:08:34 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88921F842A for ; Thu, 13 Dec 2012 12:08:34 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4710790ieb.31 for ; Thu, 13 Dec 2012 12:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XCAJxA+mBDyx+NZ6qKNdOlV2MA/fAUp1HCOFcxaEwq4=; b=DzohPh0ony3MOZ9xrH+wdtQ0oSJJJgh6n3rSM+d5fU0u7AIbck1hPuDLtJMI9+b6pH 4FRM8BPjt8rROaU0rBAi9+dxdDM7mNWzQvg0txgiYdqmtLqb3S7x4j+P2+SeBngHxcK/ r0v8Ri+XQTat6Q3nZoK8m7lfpdci7IeGGb4UmNhjSbwCXEn77BAd+/oIPGGmTrhc5C77 JWoVBSdF69kQiEFuOJ9TBKDuO5W4eTjTAtcmsMP7C7KOfhAv8DW3eKhmZ964zgxIQeMt JaONeR3H7kq/zZ5FrEWkj8OxzifjUH3k0xpfpt365kVyPdxZXb6mgqmqncrEOVHyy+N9 Bg/A== Received: by 10.50.77.166 with SMTP id t6mr2912360igw.72.1355429314127; Thu, 13 Dec 2012 12:08:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 12:08:13 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 12:08:13 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=e89a8f3baff7c969c104d0c17a67 Cc: "webfinger@ietf.org" , "Paul E. Jones" , "webfinger@googlegroups.com" , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:08:36 -0000 --e89a8f3baff7c969c104d0c17a67 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 12:00 PM, Tim Bray wrote: > [snip] > This doesn't meet the needs of Team A. They need a way to fetch a resource > that doesn't leave it up to the server. > > A. Client fetches request using HTTPS... if it fails, oh well, don't fall back to HTTP. B. If the response contains a JRD, look for the specific link rels the client is interested in. If href is "https://..." great, if not, ignore. There's no reason the link relations themselves need to be specifically marked as "secure" or not. C. If the response redirects to non https resource... ignore the redirect. D. If the response redirects to https resource, go to step B > But, many rel values are just simple token strings. How do we deal with >> those? >> > > Well, the idea is that a group like OpenID Connect could specify a > required rel value that is marked as secure. Existing rel values aren't. > This seems OK to me. > > This can be done without introducing some generalized notion of a "secure link relation". Specifically, ANY registered link relation can be defined such that being served over https is a requirement (refer to the rules for registered link relations in rfc5988). If the client needs rel="foobar" to be secure only, then it would send the request over https, only pay attention to responses returned over https, and would only use those links if href="https://..."... it's that simple. > **** >> >> I still think this should be a server-side decision to filter. Better, >> have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to >> HTTP. And clients that need security NEVER use HTTP. >> > > Team A really think they need to impose HTTPS-only from the request side. > You may not have such a need, or even agree that it exists, but there are > people who really think they need it, and that won't go away. > Already possible. The client is already in charge of whether it sends http or https requests, regardless of what the server sends it. - James > > >> ** ** >> >> Paul**** >> >> ** ** >> >> *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] >> *Sent:* Thursday, December 13, 2012 1:40 PM >> *To:* James M Snell >> *Cc:* Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com >> >> *Subject:* Re: [webfinger] secure links with https rels**** >> >> ** ** >> >> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell >> wrote:**** >> >> ** ** >> >> ** ** >> >> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick >> wrote:**** >> >> [snip]**** >> >> ** ** >> >> ** ** >> >> No... that's just nonsense. The real issue here is that the client has >> absolutely no way of detecting that the evil hijacker intercepted the >> request and provided false information in the first place. It should not >> matter at all if the returned document contains link rels with "https:" in >> them or not. **** >> >> ** ** >> >> You can never detect with HTTP that the connection was intercepted. That >> doesn't matter, because the client does know one thing: that it used HTTP >> (and not HTTPS). So the client can filter out links which should not ever >> appear over plain HTTP. I'm proposing that rels which begin with "https:" >> should never go over HTTP, and I've started calling those "secure rels". >> Maybe that's a bad name, if enough people (including you now, in your >> earlier email) assume that I'm talking about the value (the href).**** >> >> ** ** >> >> I'm open to alternative name suggestions.**** >> >> ** ** >> >> ** ** >> >> I'm -1 on the whole proposal. The notion of "insecure" and "secure" link >> relations makes absolutely no sense at all.**** >> >> ** ** >> >> I'd like to ask that you think about and understand it before being so >> negative on it.**** >> >> ** ** >> >> I promise it makes sense.**** >> >> **** >> >> It may not be possible to detect if the HTTP connection was intercepted, >> but it is possible to determine if the information provided is trustworthy. >> That is what cryptographic signatures are for.**** >> >> ** ** >> >> That is outside the scope of WebFinger, and may be used in subsequent >> hops. We're trying to provide a secure basis for the first hop. If we >> can't get any attribute securely for foo@example.com, where are we >> getting the public key from to verify subsequent use of "cryptographic >> signatures".**** >> >> ** ** >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --e89a8f3baff7c969c104d0c17a67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Dec 13, 2012 at 12:00 PM, Tim Br= ay <tbray@textuality.com> wrote:
[snip]
Th= is doesn't meet the needs of Team A. They need a way to fetch a resourc= e that doesn't leave it up to the server.
=C2=A0

A. Client fetches reques= t using HTTPS... if it fails, oh well, don't fall back to HTTP.
B. If the response contains a JRD, look for the specific link rels the c= lient is interested in. If href is "https://..." great, if not, i= gnore. There's no reason the link relations themselves need to be speci= fically marked as "secure" or not.
C. If the response redirects to non https resource... ignore the redir= ect.
D. If the response redirects to https resource, go to step B=
=C2=A0

But, many rel values are just simple token s= trings.=C2=A0 How do we deal with those?


Well, the idea is that a group like= OpenID Connect could specify a required rel value that is marked as secure= .=C2=A0 Existing rel values aren't. This seems OK to me.
=C2=A0

This can be done without introducing some = generalized notion of a "secure link relation". Specifically, ANY= registered link relation can be defined such that being served over https = is a requirement (refer to the rules for registered link relations in rfc59= 88). If the client needs rel=3D"foobar" to be secure only, then i= t would send the request over https, only pay attention to responses return= ed over https, and would only use those links if href=3D"https://...&q= uot;... it's that simple.
=C2=A0
=

=C2=A0I still think this should be a server-= side decision to filter.=C2=A0 Better, have the HTTP server redirect to HTT= PS.=C2=A0 HTTPS servers NEVER redirect to HTTP.=C2=A0 And clients that need= security NEVER use HTTP.


Team A really think they need to im= pose HTTPS-only from the request side.=C2=A0 You may not have such a need, = or even agree that it exists, but there are people who really think they ne= ed it, and that won't go away.

Already possible. The client i= s already in charge of whether it sends http or https requests, regardless = of what the server sends it.

- James
=C2=A0
=C2=A0

=C2=A0

Paul=

=C2=A0<= /span>

From:= Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snel= l
Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links with https rels

=C2=A0

On Thu, Dec 13, 2012 at 10:36 A= M, James M Snell <jasnell@gmail.com> wrote:

=C2=A0

=C2=A0

On Thu, De= c 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:=

[snip]

=

=C2=A0

=C2=A0

No... that's just nonsense. The= real issue here is that the client has absolutely no way of detecting that= the evil hijacker intercepted the request and provided false information i= n the first place. It should not matter at all if the returned document con= tains link rels with "https:" in them or not.=C2=A0

=C2=A0

You can never detect with HTTP that the connection was intercepted. =C2= =A0That doesn't matter, because the client does know one thing: =C2=A0t= hat it used HTTP (and not HTTPS). =C2=A0So the client can filter out links = which should not ever appear over plain HTTP. =C2=A0I'm proposing that = rels which begin with "https:" should never go over HTTP, and I&#= 39;ve started calling those "secure rels". =C2=A0Maybe that's= a bad name, if enough people (including you now, in your earlier email) as= sume that I'm talking about the value (the href).<= /p>

=C2=A0

I'm open to alternative n= ame suggestions.

=C2=A0

=C2= =A0

I'm -1 on the whole propos= al. The notion of "insecure" and "secure" link relation= s makes absolutely no sense at all.

=C2=A0<= /u>

I'd lik= e to ask that you think about and understand it before being so negative on= it.

=C2=A0

I promise it makes sens= e.

=C2=A0

It may not be possible to detect if = the HTTP connection was intercepted, but it is possible to determine if the= information provided is trustworthy. That is what cryptographic signatures= are for.

=C2=A0<= /u>

That is outside = the scope of WebFinger, and may be used in subsequent hops. =C2=A0We're= trying to provide a secure basis for the first hop. =C2=A0If we can't = get any attribute securely for foo@example.com, where are we getting the public key from to v= erify subsequent use of "cryptographic signatures".=

=C2=A0


_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



--e89a8f3baff7c969c104d0c17a67-- From bradfitz@google.com Thu Dec 13 12:17:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D006C21F8A89 for ; Thu, 13 Dec 2012 12:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.663 X-Spam-Level: X-Spam-Status: No, score=-101.663 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_AMP2B=2.555, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq476P+HuEP9 for ; Thu, 13 Dec 2012 12:17:47 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84D21F8AA2 for ; Thu, 13 Dec 2012 12:17:47 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4408774wib.13 for ; Thu, 13 Dec 2012 12:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zaZbUzyQliX3zf6TkGj/XCiY5TYyouvD1CxBXPGCTQs=; b=U5aX2j4yfyGPxHKFHFtJgnYkV8EnA6GzwPKZYgHw+Ba5GZAX6aQcOabHgjmCY7yGjN WzKY8iADRh7r3iBQ8fRjVgu4t+L4dIvzNTBj0YdOAQ3DOPk1SLCr6Xr4Fj+m5BrIoC9O qvlAAdpcXZLcUs1o2jHBU4id+FazI2DY4bMo+89jrf320xvoinywnqKqOBOjCZllgzxX e7SMAumXyY02Jvev3WlJyv1+BpajDghl6tbNUWQI9LF8MXTr+228LfXvxP3EfcSly88o QhDpj/8kTof5sAAz0IkAztLrlBqvuhxHbW/ryyzLZm/SbXmFdcuciSEczBMPeLNhAwjW 9bOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zaZbUzyQliX3zf6TkGj/XCiY5TYyouvD1CxBXPGCTQs=; b=pIGOs5fS2P5Y1crDl5FeTuZtjimTanQ6W58KIrMnO3TYGCo7AzOqTRStktIpnfEery 7OgiY87lbVAp3B6m5F9ZTBsiqEPRWpJ7C2X4s2xUsY/yCeEjJZ9kw8ydRkBOxZWhihtT tJv6ZlxjlpuKgNNUm5++EpjFhKgPacDsWzNEbFZAXdC2KeJtGDTqHrNvfBATArxhlsOo OTpZone3S+Pjn9kLZY7HPd0nRe/f3SwvgvsDfUyflokw0UeTXhtWEEjPv3BSWkBCA4lg g1HeGauaSdaUW1VzeUs7mVOmZX0bBnKRkLFcIf4JAl4wIayK8/X/L0faQnnk6uCIbeH3 LphA== MIME-Version: 1.0 Received: by 10.180.93.3 with SMTP id cq3mr35686198wib.1.1355429866295; Thu, 13 Dec 2012 12:17:46 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 12:17:46 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 12:17:46 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=f46d043c8056b2d23304d0c19bf6 X-Gm-Message-State: ALoCoQly6yeLgGGFXPRw55H2NzvlCaXhEjEUUmD7Ie7UO97+YUDh0A9BJXTU/Y46IwlCk+oS7u0Yhj6hmbj9Yc+DHZqVG/Fr6us4ndFRukRivlDwitQOBRTxtNNVVVsBhXEW+Za85iNVGwQH3kbbVmLZZcHcS8RC2l3ZtY822UIe0DlodAVNbA5ObYYlK4ItZdF89qu3qHbZ Cc: "Paul E. Jones" , Tim Bray , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:17:48 -0000 --f46d043c8056b2d23304d0c19bf6 Content-Type: text/plain; charset=UTF-8 James, Your proposal seems to require clients to explicitly specify http or https requests, and/or maintain a client database of which rels should be https-only. Both seem incredibly error-prone. How do the rels stay in sync? Do you keep a whitelist of http-okay rels, or a blacklist of https-only rels? Is an unknown rel allowed over plain http? My secure rel proposal makes that much simpler: you can tell statically from the rel's prefix whether it's secure: does it start with "secure-" or "https:"? And then WebFinger client applications can still just say "give me all link relations for foo@example.com", without specifying the transport. On Thu, Dec 13, 2012 at 12:08 PM, James M Snell wrote: > > > > On Thu, Dec 13, 2012 at 12:00 PM, Tim Bray wrote: > >> [snip] >> >> This doesn't meet the needs of Team A. They need a way to fetch a >> resource that doesn't leave it up to the server. >> >> > > A. Client fetches request using HTTPS... if it fails, oh well, don't fall > back to HTTP. > B. If the response contains a JRD, look for the specific link rels the > client is interested in. If href is "https://..." great, if not, ignore. > There's no reason the link relations themselves need to be specifically > marked as "secure" or not. > C. If the response redirects to non https resource... ignore the redirect. > D. If the response redirects to https resource, go to step B > > >> But, many rel values are just simple token strings. How do we deal >>> with those? >>> >> >> Well, the idea is that a group like OpenID Connect could specify a >> required rel value that is marked as secure. Existing rel values aren't. >> This seems OK to me. >> >> > > This can be done without introducing some generalized notion of a "secure > link relation". Specifically, ANY registered link relation can be defined > such that being served over https is a requirement (refer to the rules for > registered link relations in rfc5988). If the client needs rel="foobar" to > be secure only, then it would send the request over https, only pay > attention to responses returned over https, and would only use those links > if href="https://..."... it's that simple. > > >> **** >>> >>> I still think this should be a server-side decision to filter. Better, >>> have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to >>> HTTP. And clients that need security NEVER use HTTP. >>> >> >> Team A really think they need to impose HTTPS-only from the request >> side. You may not have such a need, or even agree that it exists, but >> there are people who really think they need it, and that won't go away. >> > > Already possible. The client is already in charge of whether it sends http > or https requests, regardless of what the server sends it. > > - James > > >> >> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] >>> *Sent:* Thursday, December 13, 2012 1:40 PM >>> *To:* James M Snell >>> *Cc:* Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com >>> >>> *Subject:* Re: [webfinger] secure links with https rels**** >>> >>> ** ** >>> >>> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell >>> wrote:**** >>> >>> ** ** >>> >>> ** ** >>> >>> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick >>> wrote:**** >>> >>> [snip]**** >>> >>> ** ** >>> >>> ** ** >>> >>> No... that's just nonsense. The real issue here is that the client has >>> absolutely no way of detecting that the evil hijacker intercepted the >>> request and provided false information in the first place. It should not >>> matter at all if the returned document contains link rels with "https:" in >>> them or not. **** >>> >>> ** ** >>> >>> You can never detect with HTTP that the connection was intercepted. >>> That doesn't matter, because the client does know one thing: that it used >>> HTTP (and not HTTPS). So the client can filter out links which should not >>> ever appear over plain HTTP. I'm proposing that rels which begin with >>> "https:" should never go over HTTP, and I've started calling those "secure >>> rels". Maybe that's a bad name, if enough people (including you now, in >>> your earlier email) assume that I'm talking about the value (the href).* >>> *** >>> >>> ** ** >>> >>> I'm open to alternative name suggestions.**** >>> >>> ** ** >>> >>> ** ** >>> >>> I'm -1 on the whole proposal. The notion of "insecure" and "secure" link >>> relations makes absolutely no sense at all.**** >>> >>> ** ** >>> >>> I'd like to ask that you think about and understand it before being so >>> negative on it.**** >>> >>> ** ** >>> >>> I promise it makes sense.**** >>> >>> **** >>> >>> It may not be possible to detect if the HTTP connection was intercepted, >>> but it is possible to determine if the information provided is trustworthy. >>> That is what cryptographic signatures are for.**** >>> >>> ** ** >>> >>> That is outside the scope of WebFinger, and may be used in subsequent >>> hops. We're trying to provide a secure basis for the first hop. If we >>> can't get any attribute securely for foo@example.com, where are we >>> getting the public key from to verify subsequent use of "cryptographic >>> signatures".**** >>> >>> ** ** >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> > --f46d043c8056b2d23304d0c19bf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
J= ames,

Your proposal seems to require clients to explicit= ly specify http or https requests, and/or maintain a client database of whi= ch rels should be https-only. =C2=A0Both seem incredibly error-prone. =C2= =A0How do the rels stay in sync? =C2=A0Do you keep a whitelist of http-okay= rels, or a blacklist of https-only rels? =C2=A0Is an unknown rel allowed o= ver plain http?

My secure rel proposal makes that much simpler: =C2=A0y= ou can tell statically from the rel's prefix whether it's secure: = =C2=A0does it start with "secure-" or "https:"?

And then WebFinger client applications can still just say &q= uot;give me all link relations for foo@e= xample.com", without specifying the transport.


On Thu, Dec 13, 2012 at 12:08 PM, James M Snell = <jasnell@gmail.com> wrote:

=

On Thu, Dec 13, 2012 at 12:00 PM, Tim Br= ay <tbray@textuality.com> wrote:
[snip]

This doesn't meet the needs of Team A. They need a way = to fetch a resource that doesn't leave it up to the server.
=C2=A0

A. Client fetches = request using HTTPS... if it fails, oh well, don't fall back to HTTP.
B. If the response contains a JRD, look for the specific link rels= the client is interested in. If href is "https://..." great, if = not, ignore. There's no reason the link relations themselves need to be= specifically marked as "secure" or not.
C. If the response redirects to non https resource... ignore the redir= ect.
D. If the response redirects to https resource, go to step B=
=C2=A0

But, many rel values are just simple token s= trings.=C2=A0 How do we deal with those?


Well, the idea is that a group like= OpenID Connect could specify a required rel value that is marked as secure= .=C2=A0 Existing rel values aren't. This seems OK to me.
=C2=A0

This can be done without introducing= some generalized notion of a "secure link relation". Specificall= y, ANY registered link relation can be defined such that being served over = https is a requirement (refer to the rules for registered link relations in= rfc5988). If the client needs rel=3D"foobar" to be secure only, = then it would send the request over https, only pay attention to responses = returned over https, and would only use those links if href=3D"https:/= /..."... it's that simple.
=C2=A0
=

=C2=A0I still think this should be a server-= side decision to filter.=C2=A0 Better, have the HTTP server redirect to HTT= PS.=C2=A0 HTTPS servers NEVER redirect to HTTP.=C2=A0 And clients that need= security NEVER use HTTP.


Team A really think they need to im= pose HTTPS-only from the request side.=C2=A0 You may not have such a need, = or even agree that it exists, but there are people who really think they ne= ed it, and that won't go away.

Already possible. The cl= ient is already in charge of whether it sends http or https requests, regar= dless of what the server sends it.

- James
=C2=A0
=C2=A0

=C2=A0

Paul=

=C2=A0<= /span>

From:= Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snel= l
Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links with https rels

=C2=A0

On Thu, Dec 13, 2012 at 10:36 A= M, James M Snell <jasnell@gmail.com> wrote:

=C2=A0

=C2=A0

On Thu, De= c 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:=

[snip]

=

=C2=A0

=C2=A0

No... that's just nonsense. The= real issue here is that the client has absolutely no way of detecting that= the evil hijacker intercepted the request and provided false information i= n the first place. It should not matter at all if the returned document con= tains link rels with "https:" in them or not.=C2=A0

=C2=A0

You can never detect with HTTP that the connection was intercepted. =C2= =A0That doesn't matter, because the client does know one thing: =C2=A0t= hat it used HTTP (and not HTTPS). =C2=A0So the client can filter out links = which should not ever appear over plain HTTP. =C2=A0I'm proposing that = rels which begin with "https:" should never go over HTTP, and I&#= 39;ve started calling those "secure rels". =C2=A0Maybe that's= a bad name, if enough people (including you now, in your earlier email) as= sume that I'm talking about the value (the href).<= /p>

=C2=A0

I'm open to alternative n= ame suggestions.

=C2=A0

=C2= =A0

I'm -1 on the whole propos= al. The notion of "insecure" and "secure" link relation= s makes absolutely no sense at all.

=C2=A0<= /u>

I'd lik= e to ask that you think about and understand it before being so negative on= it.

=C2=A0

I promise it makes sens= e.

=C2=A0

It may not be possible to detect if = the HTTP connection was intercepted, but it is possible to determine if the= information provided is trustworthy. That is what cryptographic signatures= are for.

=C2=A0<= /u>

That is outside = the scope of WebFinger, and may be used in subsequent hops. =C2=A0We're= trying to provide a secure basis for the first hop. =C2=A0If we can't = get any attribute securely for foo@example.com, where are we getting the public key from to v= erify subsequent use of "cryptographic signatures".=

=C2=A0


___________= ____________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger




--f46d043c8056b2d23304d0c19bf6-- From paulej@packetizer.com Thu Dec 13 12:33:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24B21F885E for ; Thu, 13 Dec 2012 12:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf9Bm4GmyFC7 for ; Thu, 13 Dec 2012 12:33:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 258EC21F87EC for ; Thu, 13 Dec 2012 12:33:33 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDKXVeg010994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 15:33:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355430811; bh=8m3cu4MSeCvci8Atbz8PZ/3W3m7NAL7kSKHGsMpRwjQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=KoOs98rywbgKTJjFwuoA0MRPlXS6Y1uvNn9MZhCAI4yBwRnc0eybfQL7zrDNAffun pff3MPHsZzX51ij4t8Da2QBbDhH04GtGiO/qFi6Va9R9aaMkij+ejCe9I2DN4a+RWe ihe/eBMgVnBvKOPnFGfJ9DIpdeAe4AedxYJ4sRvI= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: In-Reply-To: Date: Thu, 13 Dec 2012 15:33:42 -0500 Message-ID: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0735_01CDD947.3BE2D800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrZcXdphg Content-Language: en-us Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:33:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0735_01CDD947.3BE2D800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 To be clear, I=E2=80=99m in neither camp (1) or (2). I=E2=80=99ve = abstained from taking sides on this. =20 What I would expect is that if a client feels that security is paramount = for its application (e.g., logging into a web site), then it would use = HTTPS. If not, use HTTP. =20 What I consider the simplest solution is: 1) Let the client use HTTP or HTTPS depending on its preference, = guided by its security requirements 2) Servers that serve content only on HTTPS would redirect HTTP = requests to HTTPS 3) Clients that issue HTTPS requests and where the server happens = to not be listening on HTTPS fail =20 I believe #3 is the pain point. With the exception of #3, clients are = simple and are were simple. But #3 introduces a breakage where users = ask, =E2=80=9CWhy can you find any information about me?=E2=80=9D =20 The choice then becomes one of replying with =E2=80=9Cbecause your WF = provider is insecure=E2=80=9D or you change the client code to do the = =E2=80=9Cfall back=E2=80=9D to HTTP. The latter is undesirable from a = security perspective, but the choice really is that of the client. If = they would have been OK with HTTP in the first place, then they could = re-query using HTTP. The spec does not have to mandate or even = recommend that behavior. If security is important, then the client just = does not query using HTTP and the firm answer is =E2=80=9Cthe remote = server is insecure=E2=80=9D. =20 In short, let this be a client decision as to whether it needs security = or not. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 2:35 PM To: webfinger@ietf.org Subject: [webfinger] the conflicting goals =20 Here are the conflicting forces at work in the WebFinger spec, as I see = it: 1) security (the HTTPS-only camp, and people who want to use WebFinger = for the base of e.g. OpenID Connect). It should be possible to get a = key/value pair ("link") only over HTTPS. =20 2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who = just want to use WebFinger for casual things... names & avatars, or = doing their own crypto/signing out of band, and/or don't like the Root = CA system) =20 3) client simplicity. =20 I believe that we can only have 2 of those 3. We've heard proposals for = different sets of those two: =20 1+2: secure rel proposal (clients filtering out secure rels from HTTP = responses). requires some complexity in clients to filter out insecure = rels. 1+3: HTTPS-only. 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest = proposal, which I feel will be error-prone. 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use = whatever you can connect to. No security. =20 Originally I voted for HTTPS-only (which is 1+3), but enough people on = this list want 2), so I think we need to give up 3) and go with 1+2. =20 I remain fine with HTTPS-only, but I don't think it has enough support. =20 ------=_NextPart_000_0735_01CDD947.3BE2D800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

To be clear, I=E2=80=99m in neither camp (1) or (2).=C2=A0 = I=E2=80=99ve abstained from taking sides on = this.

 

What I would expect is that if a client feels that security is = paramount for its application (e.g., logging into a web site), then it = would use HTTPS.=C2=A0 If not, use HTTP.

 

What I consider the simplest solution is:

1)      = Let the client use HTTP or HTTPS depending on its preference, guided = by its security requirements

2)      = Servers that serve content only on HTTPS would redirect HTTP requests = to HTTPS

3)      = Clients that issue HTTPS requests and where the server happens to not = be listening on HTTPS fail

 

I believe #3 is the pain point.=C2=A0 With the exception of #3, = clients are simple and are were simple.=C2=A0 But #3 introduces a = breakage where users ask, =E2=80=9CWhy can you find any information = about me?=E2=80=9D

 

The choice then becomes one of replying with =E2=80=9Cbecause your WF = provider is insecure=E2=80=9D or you change the client code to do the = =E2=80=9Cfall back=E2=80=9D to HTTP.=C2=A0 The latter is undesirable = from a security perspective, but the choice really is that of the = client.=C2=A0 If they would have been OK with HTTP in the first place, = then they could re-query using HTTP.=C2=A0 The spec does not have to = mandate or even recommend that behavior.=C2=A0 If security is important, = then the client just does not query using HTTP and the firm answer is = =E2=80=9Cthe remote server is insecure=E2=80=9D.

 

In short, let this be a client decision as to whether it needs = security or not.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, = 2012 2:35 PM
To: webfinger@ietf.org
Subject: = [webfinger] the conflicting goals

 

Here are the = conflicting forces at work in the WebFinger spec, as I see = it:

1) security = (the HTTPS-only camp, and people who want to use WebFinger for the base = of e.g. OpenID Connect).  It should be possible to get a key/value = pair ("link") only over = HTTPS.

 

2) = HTTP-permitted (status.net, Blaine, = Paul, et al ... also those who just want to use WebFinger for casual = things... names & avatars, or doing their own crypto/signing out of = band, and/or don't like the Root CA = system)

 

3) client = simplicity.

 

I believe = that we can only have 2 of those 3.  We've heard proposals for = different sets of those two:

 

1+2: secure = rel proposal (clients filtering out secure rels from HTTP responses). =  requires some complexity in clients to filter out insecure = rels.

1+3: = HTTPS-only.

2: contact = either HTTP or HTTPS.  servers SHOULD run on both?  latest = proposal, which I feel will be = error-prone.

2+~3: = contact both HTTP & HTTPS in parallel or with fallback, use whatever = you can connect to. No = security.

 

Originally I = voted for HTTPS-only (which is 1+3), but enough people on this list want = 2), so I think we need to give up 3) and go with = 1+2.

 

I remain = fine with HTTPS-only, but I don't think it has enough = support.

 

------=_NextPart_000_0735_01CDD947.3BE2D800-- From jasnell@gmail.com Thu Dec 13 12:47:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E546A21F8A11 for ; Thu, 13 Dec 2012 12:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-1.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_AMP2B=2.555] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGcGviYkD0+S for ; Thu, 13 Dec 2012 12:47:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4021F89F8 for ; Thu, 13 Dec 2012 12:47:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4777029ieb.31 for ; Thu, 13 Dec 2012 12:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y3GvksGm+v5HPQvlCSVAKH/bTKYYlB3zhl6EPg4z+OM=; b=ocPzbW0sSSYNnz9V6Re+BllMj0L8Q8WenOOQnTZ+bbZrdN0eGID47pCE2TX6vmVxCq qBCG2LF46LFgkulhGFX9kydU5RR3VaE/37O5EKHzrWg1WlghdL3EEHSiFKq42pnKzlXd 3YntCe9VsExrHpvA50OZD2AfVvsaYKcNkmNRsLUbHF1KjQlSdLpCC+FblDjas8SILRec vY5oNkSu0ZRqd8MdO/zsksJJe55DbSPIi1eJqRKzJ7GfuhVIjEJPgVGBiUQGsaXX9sPw Jn1BNeLKrKbYEi/9OCzfllh+XkhOawnWNb+z2Tp5FUbhvP4DYFP2N1uTi0hWV1FZwYcj y2cg== MIME-Version: 1.0 Received: by 10.50.0.193 with SMTP id 1mr3130658igg.0.1355431634190; Thu, 13 Dec 2012 12:47:14 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 12:47:13 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 12:47:13 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 12:47:13 -0800 Message-ID: From: James M Snell To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f502f8e12c2d404d0c20536 Cc: "Paul E. Jones" , Tim Bray , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:47:16 -0000 --e89a8f502f8e12c2d404d0c20536 Content-Type: text/plain; charset=UTF-8 On Dec 13, 2012 12:17 PM, "Brad Fitzpatrick" wrote: > > James, > > Your proposal seems to require clients to explicitly specify http or https requests, and/or maintain a client database of which rels should be https-only. Both seem incredibly error-prone. How do the rels stay in sync? Do you keep a whitelist of http-okay rels, or a blacklist of https-only rels? Is an unknown rel allowed over plain http? > Link relations have no notion of http-ok or not-ok. They are just labels. A client requesting webfinger data will know exactly which link relations it is looking for and will determine on its own if it needs to request the webfinger document securely or not. There is no requirement to maintain any client side database or blacklist. That makes absolutely zero sense to me. Specifically, for example, if I want to know the oauth provider for a given user, and I want to know that "securely", I would send the request over HTTPS and look for the specific rel="oauth-authenticator" once I'm sure I can trust the document the server returned. If the initial HTTPS connection cannot be established, I give up. If I cannot be sure the returned jrd is trustworthy, I give up. > My secure rel proposal makes that much simpler: you can tell statically from the rel's prefix whether it's secure: does it start with "secure-" or "https:"? > No you can't. Any registered link relation can be defined such that HTTPS is required, with or without any kind of prefix. - james > And then WebFinger client applications can still just say "give me all link relations for foo@example.com", without specifying the transport. > > > On Thu, Dec 13, 2012 at 12:08 PM, James M Snell wrote: >> >> >> >> >> On Thu, Dec 13, 2012 at 12:00 PM, Tim Bray wrote: >>> >>> [snip] >>> >>> This doesn't meet the needs of Team A. They need a way to fetch a resource that doesn't leave it up to the server. >>> >> >> >> A. Client fetches request using HTTPS... if it fails, oh well, don't fall back to HTTP. >> B. If the response contains a JRD, look for the specific link rels the client is interested in. If href is "https://..." great, if not, ignore. There's no reason the link relations themselves need to be specifically marked as "secure" or not. >> C. If the response redirects to non https resource... ignore the redirect. >> D. If the response redirects to https resource, go to step B >> >>>> >>>> But, many rel values are just simple token strings. How do we deal with those? >>> >>> >>> Well, the idea is that a group like OpenID Connect could specify a required rel value that is marked as secure. Existing rel values aren't. This seems OK to me. >>> >> >> >> This can be done without introducing some generalized notion of a "secure link relation". Specifically, ANY registered link relation can be defined such that being served over https is a requirement (refer to the rules for registered link relations in rfc5988). If the client needs rel="foobar" to be secure only, then it would send the request over https, only pay attention to responses returned over https, and would only use those links if href="https://..."... it's that simple. >> >>>> >>>> I still think this should be a server-side decision to filter. Better, have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to HTTP. And clients that need security NEVER use HTTP. >>> >>> >>> Team A really think they need to impose HTTPS-only from the request side. You may not have such a need, or even agree that it exists, but there are people who really think they need it, and that won't go away. >> >> >> Already possible. The client is already in charge of whether it sends http or https requests, regardless of what the server sends it. >> >> - James >> >>> >>> >>>> >>>> >>>> >>>> Paul >>>> >>>> >>>> >>>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >>>> Sent: Thursday, December 13, 2012 1:40 PM >>>> To: James M Snell >>>> Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com >>>> >>>> >>>> Subject: Re: [webfinger] secure links with https rels >>>> >>>> >>>> >>>> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick < bradfitz@google.com> wrote: >>>>> >>>>> [snip] >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> No... that's just nonsense. The real issue here is that the client has absolutely no way of detecting that the evil hijacker intercepted the request and provided false information in the first place. It should not matter at all if the returned document contains link rels with "https:" in them or not. >>>>> >>>>> >>>>> >>>>> You can never detect with HTTP that the connection was intercepted. That doesn't matter, because the client does know one thing: that it used HTTP (and not HTTPS). So the client can filter out links which should not ever appear over plain HTTP. I'm proposing that rels which begin with "https:" should never go over HTTP, and I've started calling those "secure rels". Maybe that's a bad name, if enough people (including you now, in your earlier email) assume that I'm talking about the value (the href). >>>>> >>>>> >>>>> >>>>> I'm open to alternative name suggestions. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I'm -1 on the whole proposal. The notion of "insecure" and "secure" link relations makes absolutely no sense at all. >>>> >>>> >>>> >>>> I'd like to ask that you think about and understand it before being so negative on it. >>>> >>>> >>>> >>>> I promise it makes sense. >>>> >>>> >>>>> >>>>> It may not be possible to detect if the HTTP connection was intercepted, but it is possible to determine if the information provided is trustworthy. That is what cryptographic signatures are for. >>>> >>>> >>>> >>>> That is outside the scope of WebFinger, and may be used in subsequent hops. We're trying to provide a secure basis for the first hop. If we can't get any attribute securely for foo@example.com, where are we getting the public key from to verify subsequent use of "cryptographic signatures". >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>> >> > --e89a8f502f8e12c2d404d0c20536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 13, 2012 12:17 PM, "Brad Fitzpatrick" <bradfitz@google.com> wrote:
>
> James,
>
> Your proposal seems to require clients to explicitly specify http or h= ttps requests, and/or maintain a client database of which rels should be ht= tps-only. =C2=A0Both seem incredibly error-prone. =C2=A0How do the rels sta= y in sync? =C2=A0Do you keep a whitelist of http-okay rels, or a blacklist = of https-only rels? =C2=A0Is an unknown rel allowed over plain http?
>

Link relations have no notion of http-ok or not-ok. They are= just labels. A client requesting webfinger data will know exactly which li= nk relations it is looking for and will determine on its own if it needs to= request the webfinger document securely or not. There is no requirement to= maintain any client side database or blacklist. That makes absolutely zero= sense to me.

Specifically, for example, if I want to know the oauth provi= der for a given user, and I want to know that "securely", I would= send the request over HTTPS and look for the specific rel=3D"oauth-au= thenticator" once I'm sure I can trust the document the server ret= urned. If the initial HTTPS connection cannot be established, I give up. If= I cannot be sure the returned jrd is trustworthy, I give up.

> My secure rel proposal makes that much simpler: =C2=A0y= ou can tell statically from the rel's prefix whether it's secure: = =C2=A0does it start with "secure-" or "https:"?
>

No you can't. Any registered link relation can be define= d such that HTTPS is required, with or without any kind of prefix.

- james

> And then WebFinger client applications can still just s= ay "give me all link relations for = foo@example.com", without specifying the transport.
>
>
> On Thu, Dec 13, 2012 at 12:08 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>>
>>
>>
>> On Thu, Dec 13, 2012 at 12:00 PM, Tim Bray <tbray@textuality.com> wrote:
>>>
>>> [snip]
>>>
>>> This doesn't meet the needs of Team A. They need a way to = fetch a resource that doesn't leave it up to the server.
>>> =C2=A0
>>
>>
>> A. Client fetches request using HTTPS... if it fails, oh well, don= 't fall back to HTTP.
>> B. If the response contains a JRD, look for the specific link rels= the client is interested in. If href is "https://..." great, if = not, ignore. There's no reason the link relations themselves need to be= specifically marked as "secure" or not.
>> C. If the response redirects to non https resource... ignore the r= edirect.
>> D. If the response redirects to https resource, go to step B
>> =C2=A0
>>>>
>>>> But, many rel values are just simple token strings.=C2=A0 = How do we deal with those?
>>>
>>>
>>> Well, the idea is that a group like OpenID Connect could speci= fy a required rel value that is marked as secure.=C2=A0 Existing rel values= aren't. This seems OK to me.
>>> =C2=A0
>>
>>
>> This can be done without introducing some generalized notion of a = "secure link relation". Specifically, ANY registered link relatio= n can be defined such that being served over https is a requirement (refer = to the rules for registered link relations in rfc5988). If the client needs= rel=3D"foobar" to be secure only, then it would send the request= over https, only pay attention to responses returned over https, and would= only use those links if href=3D"https://..."... it's that si= mple.
>> =C2=A0
>>>>
>>>> =C2=A0I still think this should be a server-side decision = to filter.=C2=A0 Better, have the HTTP server redirect to HTTPS.=C2=A0 HTTP= S servers NEVER redirect to HTTP.=C2=A0 And clients that need security NEVE= R use HTTP.
>>>
>>>
>>> Team A really think they need to impose HTTPS-only from the re= quest side.=C2=A0 You may not have such a need, or even agree that it exist= s, but there are people who really think they need it, and that won't g= o away.
>>
>>
>> Already possible. The client is already in charge of whether it se= nds http or https requests, regardless of what the server sends it.
>>
>> - James
>> =C2=A0
>>>
>>> =C2=A0
>>>>
>>>> =C2=A0
>>>>
>>>> Paul
>>>>
>>>> =C2=A0
>>>>
>>>> From: Brad Fitzpatrick [mailto:bradfitz@google.com]
>>>> Sent: Thursday, December 13, 2012 1:40 PM
>>>> To: James M Snell
>>>> Cc: Paul E. Jones; w= ebfinger@ietf.org; webfin= ger@googlegroups.com
>>>>
>>>>
>>>> Subject: Re: [webfinger] secure links with https rels
>>>>
>>>> =C2=A0
>>>>
>>>> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell <jasnell@gmail.com> wrote:
>>>>>
>>>>> =C2=A0
>>>>>
>>>>> =C2=A0
>>>>>
>>>>> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <= ;bradfitz@google.com> wrote:<= br> >>>>>
>>>>> [snip]
>>>>>
>>>>> =C2=A0
>>>>>>
>>>>>> =C2=A0
>>>>>>
>>>>>> No... that's just nonsense. The real issue her= e is that the client has absolutely no way of detecting that the evil hijac= ker intercepted the request and provided false information in the first pla= ce. It should not matter at all if the returned document contains link rels= with "https:" in them or not.=C2=A0
>>>>>
>>>>> =C2=A0
>>>>>
>>>>> You can never detect with HTTP that the connection was= intercepted. =C2=A0That doesn't matter, because the client does know o= ne thing: =C2=A0that it used HTTP (and not HTTPS). =C2=A0So the client can = filter out links which should not ever appear over plain HTTP. =C2=A0I'= m proposing that rels which begin with "https:" should never go o= ver HTTP, and I've started calling those "secure rels". =C2= =A0Maybe that's a bad name, if enough people (including you now, in you= r earlier email) assume that I'm talking about the value (the href). >>>>>
>>>>> =C2=A0
>>>>>
>>>>> I'm open to alternative name suggestions.
>>>>>
>>>>> =C2=A0
>>>>>
>>>>> =C2=A0
>>>>>
>>>>> I'm -1 on the whole proposal. The notion of "= insecure" and "secure" link relations makes absolutely no se= nse at all.
>>>>
>>>> =C2=A0
>>>>
>>>> I'd like to ask that you think about and understand it= before being so negative on it.
>>>>
>>>> =C2=A0
>>>>
>>>> I promise it makes sense.
>>>>
>>>> =C2=A0
>>>>>
>>>>> It may not be possible to detect if the HTTP connectio= n was intercepted, but it is possible to determine if the information provi= ded is trustworthy. That is what cryptographic signatures are for.
>>>>
>>>> =C2=A0
>>>>
>>>> That is outside the scope of WebFinger, and may be used in= subsequent hops. =C2=A0We're trying to provide a secure basis for the = first hop. =C2=A0If we can't get any attribute securely for foo@example.com, where are we getting the publi= c key from to verify subsequent use of "cryptographic signatures"= .
>>>>
>>>> =C2=A0
>>>>
>>>>
>>>> _______________________________________________
>>>> webfinger mailing list
>>>> webfinger@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/webfinger
>>>>
>>>
>>
>

--e89a8f502f8e12c2d404d0c20536-- From bradfitz@google.com Thu Dec 13 12:51:02 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF721F8B1A for ; Thu, 13 Dec 2012 12:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdaXVY5Ri12i for ; Thu, 13 Dec 2012 12:51:00 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6525921F8ACA for ; Thu, 13 Dec 2012 12:51:00 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so4429408wib.13 for ; Thu, 13 Dec 2012 12:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BOTp2ipWQHqwBhWgyiKe0sT7+Q3jSDjMN9nE97e+OcE=; b=XRg4FpEZo0WOvdFnVeO3k9bOxmQru3uAl7f2jgynrBHkRq5DrTEnSDHArFBS4JWz62 H3Figrztpk/CTPlbM+weknArHjNyOjJNLnJHykngcm1Ro40JsBCcZXaMghYpmUheWVtS JaPvzCUjGId/yaAElWSMCo41NcX0Ju2De9qe9brbQXhdMwx4b0zXTq4rFq2BIDlTYesU A5qcarGFcu2o12ClkQGb1Hp5eCYw6SYa/ys78MhOx+yDC+q9Lu8zLMwJhEUXOFYQiFxH m8+6EYyk3Dgvn2OLqbUpA7yH2sVwLOpU1VfDea07VTcbDIIwGVRcNDy4XyPeF0G5pkDB q1aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BOTp2ipWQHqwBhWgyiKe0sT7+Q3jSDjMN9nE97e+OcE=; b=eG41tvwTjiQ57bdMTwmMmewM+VGz1fZi7qwsZIDGmuch7bqQezI20Hkh3ghCbmLEM+ e5QWuldoPXLb1oZPCAThfCFsoPpnxHeEL8SdDARWbA9hangSQMfzhv/vtKrYqs4HAQfB fKztVcsieIj0wiJRLkKlC/Gn+aO2Mgq/P9Og4Ov1cdnL5gE/QW+XSBO5b32NGV/NHsXy kZQeEKkio42Z9aDYYQ/wkGbT+s493xQL0cSrp5O2/s5NRWRm3wPhc+3fqHOgd5nc9r81 j/f1cJCpgIsGBKQKT8/5n4ulIlfxR19Eq1xJ0iXvxEzQYDRpPsWXuvIaZv1DwgC5sioz 7HRQ== MIME-Version: 1.0 Received: by 10.180.74.108 with SMTP id s12mr5584119wiv.12.1355431854568; Thu, 13 Dec 2012 12:50:54 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 12:50:54 -0800 (PST) In-Reply-To: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> Date: Thu, 13 Dec 2012 12:50:54 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043c81e635741704d0c2122a X-Gm-Message-State: ALoCoQkAKtvSktFiIFuCglcwaiAEEmNLbIsU2HMNoIfug9tCW+n4+UmhSgjnlt+uIIZ9Zta+xhsvuXgMQPbrkJZ2Pb4XjbKt0EZT3O6u5UzFAA0/LvlyFiiBTngbESaxEFWX+KOU1aP428IMRqTKJ4kPehrcByspK9Ptxzks1BBiuf5NiSRsbh4rJ2tFMNxsKSAfkiUxM83I Cc: webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:51:02 -0000 --f46d043c81e635741704d0c2122a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones wrot= e: > Brad,**** > > ** ** > > To be clear, I=E2=80=99m in neither camp (1) or (2). I=E2=80=99ve abstai= ned from taking > sides on this.**** > > ** ** > > What I would expect is that if a client feels that security is paramount > for its application (e.g., logging into a web site), then it would use > HTTPS. If not, use HTTP.**** > > ** ** > > What I consider the simplest solution is:**** > > **1) **Let the client use HTTP or HTTPS depending on its preference, > guided by its security requirements**** > > **2) **Servers that serve content only on HTTPS would redirect HTTP > requests to HTTPS**** > > **3) **Clients that issue HTTPS requests and where the server > happens to not be listening on HTTPS fail**** > > ** ** > > I believe #3 is the pain point. With the exception of #3, clients are > simple and are were simple. But #3 introduces a breakage where users ask= , > =E2=80=9CWhy can you find any information about me?=E2=80=9D**** > > ** ** > > The choice then becomes one of replying with =E2=80=9Cbecause your WF pro= vider is > insecure=E2=80=9D or you change the client code to do the =E2=80=9Cfall b= ack=E2=80=9D to HTTP. The > latter is undesirable from a security perspective, but the choice really = is > that of the client. If they would have been OK with HTTP in the first > place, then they could re-query using HTTP. The spec does not have to > mandate or even recommend that behavior. If security is important, then > the client just does not query using HTTP and the firm answer is =E2=80= =9Cthe > remote server is insecure=E2=80=9D.**** > > ** ** > > In short, let this be a client decision as to whether it needs security o= r > not. > I don't like this. Concerns: * flakiness. sometimes it just fails, because everybody had choices and the spec doesn't mandate either party behaving any particular way. * if clients do HTTPS-to-HTTP fallback to combat flakiness, we're back at square one with the security camp being unhappy. This is where we started. * if I just want to query all link relations for foo@example.com, how do I do it? Do I as an application have to explicitly pick HTTPS-only when I do that query, and then pick HTTP-only if it fails? So now instead of trusting just webfinger client library authors, we're trusting each and every application. I want to make it simple and secure for a spec (like OpenID Connect) to specify their WebFinger rel and then have WebFinger clients say: - give me all links (one of which might be for the OpenID Connect rel) - give me a certain link (e.g. the OpenID Connect rel) ... and know that if they get the OpenID Connect one, it arrived over HTTPS, per the OpenID Connect spec's wishes. I don't want applications to have to keep track of which transport links arrived over. You may think this is all overly complicated and we can just say "Clients: do whatever! security is your job!", but that is fundamentally what the HTTPS-only camp is against. If you want to make the security group happy, you either need ~this or HTTPS-only. If you want to make the HTTP-okay group happy, you either need this or you need to lose the support of the security group. --f46d043c81e635741704d0c2122a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Brad,

=C2=A0

To be clear, I=E2= =80=99m in neither camp (1) or (2).=C2=A0 I=E2=80=99ve abstained from takin= g sides on this.

=C2=A0

What I would expect= is that if a client feels that security is paramount for its application (= e.g., logging into a web site), then it would use HTTPS.=C2=A0 If not, use = HTTP.

=C2=A0

What I consider the= simplest solution is:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let the client use HTTP or HTTPS depend= ing on its preference, guided by its security requirements

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers that serve content only on HTTP= S would redirect HTTP requests to HTTPS

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clients that issue HTTPS requests and w= here the server happens to not be listening on HTTPS fail

=C2=A0

I believe #3 is the= pain point.=C2=A0 With the exception of #3, clients are simple and are wer= e simple.=C2=A0 But #3 introduces a breakage where users ask, =E2=80=9CWhy = can you find any information about me?=E2=80=9D

=C2=A0

The choice then bec= omes one of replying with =E2=80=9Cbecause your WF provider is insecure=E2= =80=9D or you change the client code to do the =E2=80=9Cfall back=E2=80=9D = to HTTP.=C2=A0 The latter is undesirable from a security perspective, but t= he choice really is that of the client.=C2=A0 If they would have been OK wi= th HTTP in the first place, then they could re-query using HTTP.=C2=A0 The = spec does not have to mandate or even recommend that behavior.=C2=A0 If sec= urity is important, then the client just does not query using HTTP and the = firm answer is =E2=80=9Cthe remote server is insecure=E2=80=9D.

=C2=A0

In short, let this = be a client decision as to whether it needs security or not.


I don't like this. =C2=A0C= oncerns:

* flakiness. =C2=A0sometimes it just fail= s, because everybody had choices and the spec doesn't mandate either pa= rty behaving any particular way.

* if clients do HTTPS-to-HTTP fallback to combat flakin= ess, we're back at square one with the security camp being unhappy. =C2= =A0This is where we started.
=C2=A0
* if I just want to= query all link relations for foo@exampl= e.com, how do I do it? =C2=A0Do I as an application have to explicitly = pick HTTPS-only when I do that query, and then pick HTTP-only if it fails? = =C2=A0So now instead of trusting just webfinger client library authors, we&= #39;re trusting each and every application.

I want to make it simple and secure for a spec (l= ike OpenID Connect) to specify their WebFinger rel and then have WebFinger = clients say:

- give me all links (one of which= might be for the OpenID Connect rel)
- give me a certain link (e.g. the OpenID Connect rel)

<= /div>
... and know that if they get the OpenID Connect one, it arrived = over HTTPS, per the OpenID Connect spec's wishes.

I don't want applications to have to keep track of which transport= links arrived over.

You may think this is all ove= rly complicated and we can just say "Clients: do whatever! security is= your job!", but that is fundamentally what the HTTPS-only camp is aga= inst.

If you want to make the security group happy, you eithe= r need ~this or HTTPS-only.
If you want to make the HTTP-okay gro= up happy, you either need this or you need to lose the support of the secur= ity group.

--f46d043c81e635741704d0c2122a-- From bradfitz@google.com Thu Dec 13 12:56:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68421F8B59 for ; Thu, 13 Dec 2012 12:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLUjxoCXgv1C for ; Thu, 13 Dec 2012 12:56:04 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E26321F8B1A for ; Thu, 13 Dec 2012 12:56:01 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1197530wey.31 for ; Thu, 13 Dec 2012 12:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2hOfy6t+o+2mloArdwQgIzt87VrO4M/0EUgctpERo7o=; b=UELhVgjupXIQPoKyeR5EppIpHptDWiluLIXn09H75I5JLzapPsiI90kFrvFovPsD89 SzAnzWvqORHS7R7Cg6McFKfBRZsP9sNC1kSWQxcc9gcJkMNyf/OlZ7n5wdiFzN5AWCZd 48geOpEIkS8+yZAImYq4PFMfjczxWTLKSDIB9ERuiK7jbkQeZi8ljgBItfAkqet15JvR 6BkY5mLCfRh9EKOtHm+Ba1CJ1WjTiexpSB8+72MzhBSaJ+iz7N69NwSatQT8ewpxmU0l D5aaJs+UCfrRov8wI9Z+VBOC+mrdl3MPypjx6AyLNnpHI7MPxKeaQuupHITg4LSoenSe rfwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2hOfy6t+o+2mloArdwQgIzt87VrO4M/0EUgctpERo7o=; b=AYhNiS6BgIjJ2hl0EtxFWJG9ihskZIgw8uclCaf0ytdqgA3pOL5EeEBZmCxzti80gQ lTxy/bnXGtsCP0yXX4J/CsalUABIC45nYwcDhldMxqCgRJBE6Vol8FIBx5o0dfDHiTcb UA5hRB4AaKIHcsh9k7fSeQXufHkKideDipRzgN4a1o5o3KnIt7ShxSxBCoZpl0M9dIvo WwWZmNETtXpGXUQhA1GfVPtmDg0vAeh84nQEye8bv6+ya3EOT+IMQj1ZyU5y48TWvfi3 m2p33xvfAkY3vjgJ3zxvVvEKjdG7jxX94KbNdLNpn7kFCHPIJ9B+dvpH4zAfrIPi8Tqs hISA== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr389723wjb.10.1355432160503; Thu, 13 Dec 2012 12:56:00 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 12:56:00 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 12:56:00 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=047d7bf10b2c71a81a04d0c22450 X-Gm-Message-State: ALoCoQn75Md+IRj/j0MR7kiXx9dhl1Qfd0788eed+HYtbuFQRgDPtzRU1A4/ccNZZbVdqrrMJew28Ypqq7PZ/0zq11ho8RQI1ucPFbdgkcSkpET3Cd3InssyO7JaDK7uKV/U0kUXnnpjXbWEERgQ6/2UnLkVJGsqDl6XGdmOjmw4RwV9AZjvQd8WQ80N9+zQ6gUEv+HfYHNj Cc: "Paul E. Jones" , Tim Bray , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:56:05 -0000 --047d7bf10b2c71a81a04d0c22450 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 12:47 PM, James M Snell wrote: > > On Dec 13, 2012 12:17 PM, "Brad Fitzpatrick" wrote: > > > > James, > > > > Your proposal seems to require clients to explicitly specify http or > https requests, and/or maintain a client database of which rels should be > https-only. Both seem incredibly error-prone. How do the rels stay in > sync? Do you keep a whitelist of http-okay rels, or a blacklist of > https-only rels? Is an unknown rel allowed over plain http? > > > > Link relations have no notion of http-ok or not-ok. > I'm proposing that they should. Without relations having an implicit http-okayness, we can't do fallback (notably on * requests). And without fallback, we can't reliably do a lookup, if servers have a choice of HTTP or HTTPS. > They are just labels. A client requesting webfinger data will know exactly > which link relations it is looking for and will determine on its own if it > needs to request the webfinger document securely or not. There is no > requirement to maintain any client side database or blacklist. [ ... ] Any > registered link relation can be defined such that HTTPS is required, with > or without any kind of prefix. > Those two statements seem to contradict each other. You said that we don't need a client-side database, but then you said IANA labels can be defined to be HTTPS-only. That's a database. Maybe not a big one, but it's a set of data that clients would need to know. --047d7bf10b2c71a81a04d0c22450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 12:47 PM, James M Snell <jasnell@gmail.com><= /span> wrote:


On Dec 13, 2012 12:17 PM, "Brad Fitzpatrick" <bradfitz@google.com> wrote:=
>
> James,
>
> Your proposal seems to require clients to explicitly specify http or h= ttps requests, and/or maintain a client database of which rels should be ht= tps-only. =C2=A0Both seem incredibly error-prone. =C2=A0How do the rels sta= y in sync? =C2=A0Do you keep a whitelist of http-okay rels, or a blacklist = of https-only rels? =C2=A0Is an unknown rel allowed over plain http?
>

Link relations have no notion of http-ok or not-ok.

I'm proposing that they should. =C2=A0Without relati= ons having an implicit http-okayness, we can't do fallback (notably on = * requests). =C2=A0And without fallback, we can't reliably do a lookup,= if servers have a choice of HTTP or HTTPS.

They are just labels. A clie= nt requesting webfinger data will know exactly which link relations it is l= ooking for and will determine on its own if it needs to request the webfing= er document securely or not. There is no requirement to maintain any client= side database or blacklist. [ ... ] Any registered link relation can be de= fined such that HTTPS is required, with or without any kind of prefix.


Those two statements seem to contradict ea= ch other. =C2=A0You said that we don't need a client-side database, but= then you said IANA labels can be defined to be HTTPS-only. =C2=A0That'= s a database. =C2=A0Maybe not a big one, but it's a set of data that cl= ients would need to know.

--047d7bf10b2c71a81a04d0c22450-- From jasnell@gmail.com Thu Dec 13 13:43:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16221F8618 for ; Thu, 13 Dec 2012 13:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biSXeiHzbejj for ; Thu, 13 Dec 2012 13:43:02 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC2021F8B9E for ; Thu, 13 Dec 2012 13:43:01 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4871353ieb.31 for ; Thu, 13 Dec 2012 13:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xLNJ+GQTGNZF9ga1o9ezbjWHHhBt+wGM6XljNXGOUXw=; b=AR71/PdXTlrL07XxI3PzYHdoVJWwyAikyiHls6sBO8QGuV1c1T4GGsBhhBEM5vOsq6 6rwnVEvQq/mgVfKRQuyISqPrCLGQOeoL1BczFgY9kAa9TTBbDmyEJkOllDildc0u+l3S ovfGINdsv7paoOXTwGy0q2iFoBiRFEzEPVluVToW7d5iOoHRK1x9Edwrh+b72FyVpflI GeFuB4Uh59hsRbNx+W+qX7Gko5FIqPYpvKYBNAEcIPzemN4vZd+ZnhsAWZJWb8ShLSN/ GmNNnaIdiaMbquLsnJJSin3Nz3LEFeg7ynn5pZRD6Pe41F0XLPI0l8pjdwMioQ2Imp5u Tngg== Received: by 10.42.41.144 with SMTP id p16mr2780756ice.39.1355434978650; Thu, 13 Dec 2012 13:42:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 13:42:38 -0800 (PST) In-Reply-To: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 13:42:38 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf301d42326b293204d0c2ccfc Cc: Brad Fitzpatrick , "webfinger@ietf.org" Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:43:03 -0000 --20cf301d42326b293204d0c2ccfc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones wrot= e: > [snip] > > ** ** > > The choice then becomes one of replying with =E2=80=9Cbecause your WF pro= vider is > insecure=E2=80=9D or you change the client code to do the =E2=80=9Cfall b= ack=E2=80=9D to HTTP. The > latter is undesirable from a security perspective, but the choice really = is > that of the client. If they would have been OK with HTTP in the first > place, then they could re-query using HTTP. The spec does not have to > mandate or even recommend that behavior. If security is important, then > the client just does not query using HTTP and the firm answer is =E2=80= =9Cthe > remote server is insecure=E2=80=9D.**** > > ** ** > > In short, let this be a client decision as to whether it needs security o= r > not.**** > > ** > +1 ... this is the only sensible position. - James > ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Brad Fitzpatrick > *Sent:* Thursday, December 13, 2012 2:35 PM > *To:* webfinger@ietf.org > *Subject:* [webfinger] the conflicting goals**** > > ** ** > > Here are the conflicting forces at work in the WebFinger spec, as I see i= t: > **** > > 1) security (the HTTPS-only camp, and people who want to use WebFinger fo= r > the base of e.g. OpenID Connect). It should be possible to get a key/val= ue > pair ("link") only over HTTPS.**** > > ** ** > > 2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who > just want to use WebFinger for casual things... names & avatars, or doing > their own crypto/signing out of band, and/or don't like the Root CA syste= m) > **** > > ** ** > > 3) client simplicity.**** > > ** ** > > I believe that we can only have 2 of those 3. We've heard proposals for > different sets of those two:**** > > ** ** > > 1+2: secure rel proposal (clients filtering out secure rels from HTTP > responses). requires some complexity in clients to filter out insecure > rels.**** > > 1+3: HTTPS-only.**** > > 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest > proposal, which I feel will be error-prone.**** > > 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whateve= r > you can connect to. No security.**** > > ** ** > > Originally I voted for HTTPS-only (which is 1+3), but enough people on > this list want 2), so I think we need to give up 3) and go with 1+2.**** > > ** ** > > I remain fine with HTTPS-only, but I don't think it has enough support.**= * > * > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --20cf301d42326b293204d0c2ccfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jo= nes <paulej@packetizer.com> wrote:

[snip]=

=C2=A0

The choice then bec= omes one of replying with =E2=80=9Cbecause your WF provider is insecure=E2= =80=9D or you change the client code to do the =E2=80=9Cfall back=E2=80=9D = to HTTP.=C2=A0 The latter is undesirable from a security perspective, but t= he choice really is that of the client.=C2=A0 If they would have been OK wi= th HTTP in the first place, then they could re-query using HTTP.=C2=A0 The = spec does not have to mandate or even recommend that behavior.=C2=A0 If sec= urity is important, then the client just does not query using HTTP and the = firm answer is =E2=80=9Cthe remote server is insecure=E2=80=9D.

=C2=A0

In short, let this = be a client decision as to whether it needs security or not.<= /span>

=C2=A0

<= /div>

+1 ... this is the only sensible posi= tion.

- James
=C2=A0

Paul=

=C2=A0<= /span>

From:= webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf = Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 2:35 PM
To: webfinger@ietf.org
Su= bject: [webfinger] the conflicting goals

=C2=A0

Here= are the conflicting forces at work in the WebFinger spec, as I see it:<= /u>

1) security (the HTTPS-only camp, an= d people who want to use WebFinger for the base of e.g. OpenID Connect). = =C2=A0It should be possible to get a key/value pair ("link") only= over HTTPS.

=C2=A0

2) HTTP-permitted (status.net, Blaine, Paul, et al .= .. also those who just want to use WebFinger for casual things... names &am= p; avatars, or doing their own crypto/signing out of band, and/or don't= like the Root CA system)

=C2=A0

3) client simplicity.<= u>

=C2=A0

I believe that we can only ha= ve 2 of those 3. =C2=A0We've heard proposals for different sets of thos= e two:

=C2=A0

1+2: secure rel proposal (cli= ents filtering out secure rels from HTTP responses). =C2=A0requires some co= mplexity in clients to filter out insecure rels.

1+3: HTTPS-only.=

2: contact either H= TTP or HTTPS. =C2=A0servers SHOULD run on both? =C2=A0latest proposal, whic= h I feel will be error-prone.

2+~3: contact both HTTP &= amp; HTTPS in parallel or with fallback, use whatever you can connect to. N= o security.

=C2=A0

Originally I= voted for HTTPS-only (which is 1+3), but enough people on this list want 2= ), so I think we need to give up 3) and go with 1+2.

=C2=A0

I remain fine with HTTPS-only= , but I don't think it has enough support.

=C2=A0


____________________________= ___________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--20cf301d42326b293204d0c2ccfc-- From evan@status.net Thu Dec 13 13:49:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6D21F8BBD for ; Thu, 13 Dec 2012 13:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hdEFo6QpBAa for ; Thu, 13 Dec 2012 13:49:04 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id BA34D21F88F7 for ; Thu, 13 Dec 2012 13:49:04 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id CFAF38D448A; Thu, 13 Dec 2012 22:01:36 +0000 (UTC) Message-ID: <50CA4D4D.6020002@status.net> Date: Thu, 13 Dec 2012 16:49:01 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "webfinger@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070502090605090003040207" Cc: Mikael Nordfeldth Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:49:05 -0000 This is a multi-part message in MIME format. --------------070502090605090003040207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brad, Can I suggest another possibility? 1. The Webfinger spec mandates HTTPS-only. 2. Those of us who want to support HTTP fall back to RFC 6415 (going through HostMeta and LRDD). 3. If there's a pressing need for an HTTP-accessible /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on HTTP. QED.") It's going to take a while for /.well-known/webfinger endpoints to get deployed, and falling back to /.well-known/host-meta will probably be part of our world for a while, so it's not really that big a loss. I can definitely live with this; MMN? -Evan On 12-12-13 02:35 PM, Brad Fitzpatrick wrote: > Here are the conflicting forces at work in the WebFinger spec, as I > see it: > > 1) security (the HTTPS-only camp, and people who want to use WebFinger > for the base of e.g. OpenID Connect). It should be possible to get a > key/value pair ("link") only over HTTPS. > > 2) HTTP-permitted (status.net , Blaine, Paul, et al > ... also those who just want to use WebFinger for casual things... > names & avatars, or doing their own crypto/signing out of band, and/or > don't like the Root CA system) > > 3) client simplicity. > > I believe that we can only have 2 of those 3. We've heard proposals > for different sets of those two: > > 1+2: secure rel proposal (clients filtering out secure rels from HTTP > responses). requires some complexity in clients to filter out > insecure rels. > 1+3: HTTPS-only. > 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest > proposal, which I feel will be error-prone. > 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use > whatever you can connect to. No security. > > Originally I voted for HTTPS-only (which is 1+3), but enough people on > this list want 2), so I think we need to give up 3) and go with 1+2. > > I remain fine with HTTPS-only, but I don't think it has enough support. > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 --------------070502090605090003040207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brad,

Can I suggest another possibility?
  1. The Webfinger spec mandates HTTPS-only.
  2. Those of us who want to support HTTP fall back to RFC 6415 (going through HostMeta and LRDD).
  3. If there's a pressing need for an HTTP-accessible /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on HTTP. QED.")
It's going to take a while for /.well-known/webfinger endpoints to get deployed, and falling back to /.well-known/host-meta will probably be part of our world for a while, so it's not really that big a loss.

I can definitely live with this; MMN?

-Evan

On 12-12-13 02:35 PM, Brad Fitzpatrick wrote:
Here are the conflicting forces at work in the WebFinger spec, as I see it:

1) security (the HTTPS-only camp, and people who want to use WebFinger for the base of e.g. OpenID Connect).  It should be possible to get a key/value pair ("link") only over HTTPS.

2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just want to use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system)

3) client simplicity.

I believe that we can only have 2 of those 3.  We've heard proposals for different sets of those two:

1+2: secure rel proposal (clients filtering out secure rels from HTTP responses).  requires some complexity in clients to filter out insecure rels.
1+3: HTTPS-only.
2: contact either HTTP or HTTPS.  servers SHOULD run on both?  latest proposal, which I feel will be error-prone.
2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever you can connect to. No security.

Originally I voted for HTTPS-only (which is 1+3), but enough people on this list want 2), so I think we need to give up 3) and go with 1+2.

I remain fine with HTTPS-only, but I don't think it has enough support.



_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826
--------------070502090605090003040207-- From tbray@textuality.com Thu Dec 13 13:54:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0817A21F89DF for ; Thu, 13 Dec 2012 13:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9W5oeJWv38r for ; Thu, 13 Dec 2012 13:54:00 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8121F8991 for ; Thu, 13 Dec 2012 13:53:59 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2780696oag.31 for ; Thu, 13 Dec 2012 13:53:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6JLznt0sEVVGxfH2TsfWahJHkefTpI2AL8Gpk2C0uck=; b=a5J1iEkt81/+BdoALiS3+eIcUTVg4raHJm+u/t85CJS7eZYKke5dc2lHwoJCRbn8B0 Y84rnnhVdg03KKpZNCSk0n3E10rSA2J+NVyERDTrrYS6i55jutaUmRcrzUlStSCz1h4k ffnqV4Dot/eGiL7B2RqQ+1E2p8F+g50rbsD+yagErkNbWX2KNce9VyPWqQPACRq9moE5 0a1rr1Yz9ZX9lqQ0ti/W4/E8yq1TK2JGCJlITekWZOTVvhD670VFddNrjMiQaeR8ksSF +ppSRzmcghMo+xRJHQLEEBknAjzyJTqNQ11bu88GsJQmsZz98pV8BSPPVhBhPgIDEkNq 9PlQ== MIME-Version: 1.0 Received: by 10.60.32.200 with SMTP id l8mr2988783oei.43.1355435639507; Thu, 13 Dec 2012 13:53:59 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 13 Dec 2012 13:53:59 -0800 (PST) X-Originating-IP: [96.49.76.76] In-Reply-To: <50CA4D4D.6020002@status.net> References: <50CA4D4D.6020002@status.net> Date: Thu, 13 Dec 2012 13:53:59 -0800 Message-ID: From: Tim Bray To: Evan Prodromou Content-Type: multipart/alternative; boundary=e89a8fb1f5b0cf091f04d0c2f318 X-Gm-Message-State: ALoCoQnjK59cyA0kq/4I0x0sYOhROCjDCmmns4ujYoa/05JMzLBL0YOf88i8vIx50OWLbbHLupEO Cc: "webfinger@ietf.org" , Mikael Nordfeldth Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:54:01 -0000 --e89a8fb1f5b0cf091f04d0c2f318 Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Dec 13, 2012 at 1:49 PM, Evan Prodromou wrote: > Brad, > > Can I suggest another possibility? > > 1. The Webfinger spec mandates HTTPS-only. > 2. Those of us who want to support HTTP fall back to RFC 6415 (going > through HostMeta and LRDD). > 3. If there's a pressing need for an HTTP-accessible > /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. > ("Do Webfinger, but on HTTP. QED.") > > It's going to take a while for /.well-known/webfinger endpoints to get > deployed, and falling back to /.well-known/host-meta will probably be part > of our world for a while, so it's not really that big a loss. > > I can definitely live with this; MMN? > > -Evan > > On 12-12-13 02:35 PM, Brad Fitzpatrick wrote: > > Here are the conflicting forces at work in the WebFinger spec, as I see it: > > 1) security (the HTTPS-only camp, and people who want to use WebFinger for > the base of e.g. OpenID Connect). It should be possible to get a key/value > pair ("link") only over HTTPS. > > 2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who > just want to use WebFinger for casual things... names & avatars, or doing > their own crypto/signing out of band, and/or don't like the Root CA system) > > 3) client simplicity. > > I believe that we can only have 2 of those 3. We've heard proposals for > different sets of those two: > > 1+2: secure rel proposal (clients filtering out secure rels from HTTP > responses). requires some complexity in clients to filter out insecure > rels. > 1+3: HTTPS-only. > 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest > proposal, which I feel will be error-prone. > 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use > whatever you can connect to. No security. > > Originally I voted for HTTPS-only (which is 1+3), but enough people on > this list want 2), so I think we need to give up 3) and go with 1+2. > > I remain fine with HTTPS-only, but I don't think it has enough support. > > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > -- > Evan Prodromou, CEO and Founder, StatusNet Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@status.net P: +1-514-554-3826 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8fb1f5b0cf091f04d0c2f318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Thu, Dec 13, 2012 at 1:49 PM, Evan = Prodromou <evan@status.net> wrote:
=20 =20 =20
Brad,

Can I suggest another possibility?
  1. The Webfinger spec mandates HTTPS-only.
  2. Those of us who want to support HTTP fall back to RFC 6415 (going through HostMeta and LRDD).
  3. If there's a pressing need for an HTTP-accessible /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on HTTP. QED.")
It's going to take a while for /.well-known/webfinger endpoints t= o get deployed, and falling back to /.well-known/host-meta will probably be part of our world for a while, so it's not really tha= t big a loss.

I can definitely live with this; MMN?

-Evan

On 12-12-13 02:35 PM, Brad Fitzpatrick wrote:
= Here are the conflicting forces at work in the WebFinger spec, as I see it:

1) security (the HTTPS-only camp, and people who want to use WebFinger for the base of e.g. OpenID Connect). =A0It should be possible to get a key/value pair ("link") only over = HTTPS.

2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just want to use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system)

3) client simplicity.

I believe that we can only have 2 of those 3. =A0We've hea= rd proposals for different sets of those two:

1+2: secure rel proposal (clients filtering out secure rels from HTTP responses). =A0requires some complexity in clients to filter out insecure rels.
1+3: HTTPS-only.
2: contact either HTTP or HTTPS. =A0servers SHOULD run on both? =A0latest proposal, which I feel will be error-prone.
2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever you can connect to. No security.

Originally I voted for HTTPS-only (which is 1+3), but enough people on this list want 2), so I think we need to give up 3) and go with 1+2.

I remain fine with HTTPS-only, but I don't think it has enough support.



_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger



--=20
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net=
 P: +1-514-554-3826

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8fb1f5b0cf091f04d0c2f318-- From paulej@packetizer.com Thu Dec 13 14:12:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928121F8AD8 for ; Thu, 13 Dec 2012 14:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnsVZVjI4ydV for ; Thu, 13 Dec 2012 14:12:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B06F621F8924 for ; Thu, 13 Dec 2012 14:12:03 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDMC1XN015122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 17:12:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355436722; bh=+IfmQd3ZyDQJPrlr+mn1c47K5GfCI7YOZci5tSvudWE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=frBDygG+vk97+Amu64btA44AAJttaev3yjedlfNWoQsD1ASSCqn9nTyIcZKE8pKHj z8TaWSu9qgCicTkWzNvf+LpS1T1He5U4BNJqxzAF8zNZPJ3sJutIwct1cWugXncDwT qepnFllVGND4F5AwgxeNmZuu1Sq5YtCTYK7HXUYA= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 17:12:13 -0500 Message-ID: <077401cdd97e$e78210e0$b68632a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0775_01CDD954.FEAD4160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrQJNGg2YATtEkl2W+0y+sA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:12:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0775_01CDD954.FEAD4160 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 I agree there is a little flakiness. Specifically, if a WF server = decides to provide WF services only on HTTP, then there will be some = clients that fail. =20 Don=E2=80=99t conflate that issue with getting particular link = relations, though. Any OpenID-related WF client could ALWAYS issue = requests via HTTPS (even though I assert that still is not a = bullet-proof solution since a rogue web site can still do dirty things = by directing a user to a phishing site). =20 The way I see it, we either have to accept that some clients might fail = to get a reply (since the user=E2=80=99s WF server only supports HTTP) = or we have to mandate use of HTTPS. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 3:51 PM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals =20 On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones = wrote: Brad, =20 To be clear, I=E2=80=99m in neither camp (1) or (2). I=E2=80=99ve = abstained from taking sides on this. =20 What I would expect is that if a client feels that security is paramount = for its application (e.g., logging into a web site), then it would use = HTTPS. If not, use HTTP. =20 What I consider the simplest solution is: 1) Let the client use HTTP or HTTPS depending on its preference, = guided by its security requirements 2) Servers that serve content only on HTTPS would redirect HTTP = requests to HTTPS 3) Clients that issue HTTPS requests and where the server happens = to not be listening on HTTPS fail =20 I believe #3 is the pain point. With the exception of #3, clients are = simple and are were simple. But #3 introduces a breakage where users = ask, =E2=80=9CWhy can you find any information about me?=E2=80=9D =20 The choice then becomes one of replying with =E2=80=9Cbecause your WF = provider is insecure=E2=80=9D or you change the client code to do the = =E2=80=9Cfall back=E2=80=9D to HTTP. The latter is undesirable from a = security perspective, but the choice really is that of the client. If = they would have been OK with HTTP in the first place, then they could = re-query using HTTP. The spec does not have to mandate or even = recommend that behavior. If security is important, then the client just = does not query using HTTP and the firm answer is =E2=80=9Cthe remote = server is insecure=E2=80=9D. =20 In short, let this be a client decision as to whether it needs security = or not. =20 I don't like this. Concerns: =20 * flakiness. sometimes it just fails, because everybody had choices and = the spec doesn't mandate either party behaving any particular way. =20 * if clients do HTTPS-to-HTTP fallback to combat flakiness, we're back = at square one with the security camp being unhappy. This is where we = started. =20 * if I just want to query all link relations for foo@example.com, how do = I do it? Do I as an application have to explicitly pick HTTPS-only when = I do that query, and then pick HTTP-only if it fails? So now instead of = trusting just webfinger client library authors, we're trusting each and = every application. =20 I want to make it simple and secure for a spec (like OpenID Connect) to = specify their WebFinger rel and then have WebFinger clients say: =20 - give me all links (one of which might be for the OpenID Connect rel) - give me a certain link (e.g. the OpenID Connect rel) =20 ... and know that if they get the OpenID Connect one, it arrived over = HTTPS, per the OpenID Connect spec's wishes. =20 I don't want applications to have to keep track of which transport links = arrived over. =20 You may think this is all overly complicated and we can just say = "Clients: do whatever! security is your job!", but that is fundamentally = what the HTTPS-only camp is against. =20 If you want to make the security group happy, you either need ~this or = HTTPS-only. If you want to make the HTTP-okay group happy, you either need this or = you need to lose the support of the security group. =20 ------=_NextPart_000_0775_01CDD954.FEAD4160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

I agree there is a little flakiness.=C2=A0 Specifically, if a WF = server decides to provide WF services only on HTTP, then there will be = some clients that fail.

 

Don=E2=80=99t conflate that issue with getting particular link = relations, though.=C2=A0 Any OpenID-related WF client could ALWAYS issue = requests via HTTPS (even though I assert that still is not a = bullet-proof solution since a rogue web site can still do dirty things = by directing a user to a phishing site).

 

The way I see it, we either have to accept that some clients might = fail to get a reply (since the user=E2=80=99s WF server only supports = HTTP) or we have to mandate use of HTTPS.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 3:51 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] the conflicting = goals

 

On Thu, Dec = 13, 2012 at 12:33 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Brad,

 

To be clear, I=E2=80=99m in neither camp (1) or (2).  = I=E2=80=99ve abstained from taking sides on = this.

 

What I would expect is that if a client feels that security is = paramount for its application (e.g., logging into a web site), then it = would use HTTPS.  If not, use HTTP.

 

What I consider the simplest solution = is:

1)      = Let the client use HTTP or HTTPS depending on its preference, guided = by its security requirements

2)      = Servers that serve content only on HTTPS would redirect HTTP requests = to HTTPS

3)      = Clients that issue HTTPS requests and where the server happens to not = be listening on HTTPS fail

 

I believe #3 is the pain point.  With the exception of #3, = clients are simple and are were simple.  But #3 introduces a = breakage where users ask, =E2=80=9CWhy can you find any information = about me?=E2=80=9D

 

The choice then becomes one of replying with =E2=80=9Cbecause your WF = provider is insecure=E2=80=9D or you change the client code to do the = =E2=80=9Cfall back=E2=80=9D to HTTP.  The latter is undesirable = from a security perspective, but the choice really is that of the = client.  If they would have been OK with HTTP in the first place, = then they could re-query using HTTP.  The spec does not have to = mandate or even recommend that behavior.  If security is important, = then the client just does not query using HTTP and the firm answer is = =E2=80=9Cthe remote server is insecure=E2=80=9D.

 

In short, let this be a client decision as to whether it needs = security or not.

 

I don't like = this.  Concerns:

 

* flakiness. =  sometimes it just fails, because everybody had choices and the = spec doesn't mandate either party behaving any particular = way.

 

* if clients = do HTTPS-to-HTTP fallback to combat flakiness, we're back at square one = with the security camp being unhappy.  This is where we = started.

 

* if I just = want to query all link relations for foo@example.com, how do I do it? =  Do I as an application have to explicitly pick HTTPS-only when I = do that query, and then pick HTTP-only if it fails?  So now instead = of trusting just webfinger client library authors, we're trusting each = and every application.

 

I want to = make it simple and secure for a spec (like OpenID Connect) to specify = their WebFinger rel and then have WebFinger clients = say:

 

- give me = all links (one of which might be for the OpenID Connect = rel)

- give me a = certain link (e.g. the OpenID Connect = rel)

 

... and know = that if they get the OpenID Connect one, it arrived over HTTPS, per the = OpenID Connect spec's wishes.

 

I don't want = applications to have to keep track of which transport links arrived = over.

 

You may = think this is all overly complicated and we can just say "Clients: = do whatever! security is your job!", but that is fundamentally what = the HTTPS-only camp is against.

 

If you want = to make the security group happy, you either need ~this or = HTTPS-only.

If you want = to make the HTTP-okay group happy, you either need this or you need to = lose the support of the security = group.

 

------=_NextPart_000_0775_01CDD954.FEAD4160-- From paulej@packetizer.com Thu Dec 13 14:18:24 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E621F8641 for ; Thu, 13 Dec 2012 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD7mgBiEUOhB for ; Thu, 13 Dec 2012 14:18:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BA67C21F8623 for ; Thu, 13 Dec 2012 14:18:21 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDMIJZ6015408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 17:18:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355437099; bh=/8lw0hMnq4Nz81nt4rzKAFyq8/OknJhK9cJQml0WYgs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LNscC3j3gnZ7tpQE/61HICfMuL8b0waQnH6Xx4YPs4/ti30o1q7zqwl7oZs0gfv+c yi5f6ijKLEgmgfTPxkOjlp7qcFJ35JZn+GeKZur71eeePUuUV8HnCzNv1i0O2f52Ng fS6L5EkERrqeZHgPS9HkSp2PwvymUYzjG7sDIeEo= From: "Paul E. Jones" To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 17:18:30 -0500 Message-ID: <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0782_01CDD955.DFE4BE10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXmBjzTmA= Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'James M Snell' , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:18:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0782_01CDD955.DFE4BE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, the client should not fall back to HTTP. That's not written in the current proposal. From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Zellyn Hunter Sent: Thursday, December 13, 2012 2:56 PM To: webfinger@googlegroups.com Cc: Brad Fitzpatrick; James M Snell; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels Paul, It has to happen on the client. 1. Application code tries to look up "secure-openid-server" 2. Client tries to connect to https://www.zellyn.com/ 3. Evil adversary blocks the request. 4. Client falls back to HTTP. 5. Evil adversary returns a response that includes a value for rel="secure-openid-server" 6. Profit. On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones wrote: Brad, I agree the idea of marking a "rel" as secure using https makes sense. That said, is my profile page to be marked secure or not? Do we define to rel values for a profile page, one that's secure and one that's not, then let the user specify the rel type based on preference? What I think makes more sense if for the WF server admin to select what information to convey via HTTP or HTTPS. I would have no objection to certain things (e.g., the URI used to identify the OpenID Provider) to be specified using https, thereby aiding in helping the server (and admin) in making that decision. But, many rel values are just simple token strings. How do we deal with those? I still think this should be a server-side decision to filter. Better, have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to HTTP. And clients that need security NEVER use HTTP. Paul From: Brad Fitzpatrick [mailto:bradfitz@google.com] Sent: Thursday, December 13, 2012 1:40 PM To: James M Snell Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote: On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick wrote: [snip] No... that's just nonsense. The real issue here is that the client has absolutely no way of detecting that the evil hijacker intercepted the request and provided false information in the first place. It should not matter at all if the returned document contains link rels with "https:" in them or not. You can never detect with HTTP that the connection was intercepted. That doesn't matter, because the client does know one thing: that it used HTTP (and not HTTPS). So the client can filter out links which should not ever appear over plain HTTP. I'm proposing that rels which begin with "https:" should never go over HTTP, and I've started calling those "secure rels". Maybe that's a bad name, if enough people (including you now, in your earlier email) assume that I'm talking about the value (the href). I'm open to alternative name suggestions. I'm -1 on the whole proposal. The notion of "insecure" and "secure" link relations makes absolutely no sense at all. I'd like to ask that you think about and understand it before being so negative on it. I promise it makes sense. It may not be possible to detect if the HTTP connection was intercepted, but it is possible to determine if the information provided is trustworthy. That is what cryptographic signatures are for. That is outside the scope of WebFinger, and may be used in subsequent hops. We're trying to provide a secure basis for the first hop. If we can't get any attribute securely for foo@example.com, where are we getting the public key from to verify subsequent use of "cryptographic signatures". ------=_NextPart_000_0782_01CDD955.DFE4BE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, the client should not fall back to HTTP.  That’s not = written in the current proposal.

 

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Zellyn Hunter
Sent: Thursday, December 13, 2012 = 2:56 PM
To: webfinger@googlegroups.com
Cc: Brad = Fitzpatrick; James M Snell; webfinger@ietf.org
Subject: Re: = [webfinger] secure links with https = rels

 

Paul,

 

It has to happen on the = client.

 

1. Application code tries to look up "secure-openid= -server" 

2. Client tries to connect to https://www.zellyn.com/

3. Evil adversary blocks the = request.

4. Client falls = back to HTTP.

5. Evil = adversary returns a response that includes a value for = rel=3D"secure-openid-server"

6. Profit.

 

 

On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Brad,

 

I agree the idea of marking a “rel” as secure using https = makes sense.  That said, is my profile page to be marked secure or = not?  Do we define to rel values for a profile page, one = that’s secure and one that’s not, then let the user specify = the rel type based on preference?

 

What I think makes more sense if for the WF server admin to select = what information to convey via HTTP or HTTPS.  I would have no = objection to certain things (e.g., the URI used to identify the OpenID = Provider) to be specified using https, thereby aiding in helping the = server (and admin) in making that decision.

 

But, many rel values are just simple token strings.  How do we = deal with those?

 

I still think this should be a server-side decision to filter.  = Better, have the HTTP server redirect to HTTPS.  HTTPS servers = NEVER redirect to HTTP.  And clients that need security NEVER use = HTTP.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 1:40 PM
To: James M Snell
Cc: Paul = E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links = with https rels

 <= /o:p>

On Thu, Dec = 13, 2012 at 10:36 AM, James M Snell <jasnell@gmail.com> = wrote:

 =

 =

On Thu, Dec = 13, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

[snip]=

 =

 =

No... that's just = nonsense. The real issue here is that the client has absolutely no way = of detecting that the evil hijacker intercepted the request and provided = false information in the first place. It should not matter at all if the = returned document contains link rels with "https:" in them or = not. 

 =

You can = never detect with HTTP that the connection was intercepted.  That = doesn't matter, because the client does know one thing:  that it = used HTTP (and not HTTPS).  So the client can filter out links = which should not ever appear over plain HTTP.  I'm proposing that = rels which begin with "https:" should never go over HTTP, and = I've started calling those "secure rels".  Maybe that's a = bad name, if enough people (including you now, in your earlier email) = assume that I'm talking about the value (the = href).

 =

I'm open to = alternative name suggestions.

 =

 =

I'm -1 on = the whole proposal. The notion of "insecure" and = "secure" link relations makes absolutely no sense at = all.

 =

I'd like to = ask that you think about and understand it before being so negative on = it.

 =

I promise it = makes sense.

 =

It may not = be possible to detect if the HTTP connection was intercepted, but it is = possible to determine if the information provided is trustworthy. That = is what cryptographic signatures are = for.

 =

That is = outside the scope of WebFinger, and may be used in subsequent hops. =  We're trying to provide a secure basis for the first hop.  If = we can't get any attribute securely for foo@example.com, = where are we getting the public key from to verify subsequent use of = "cryptographic signatures".

 =

 

------=_NextPart_000_0782_01CDD955.DFE4BE10-- From bradfitz@google.com Thu Dec 13 14:19:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005C021F88DC for ; Thu, 13 Dec 2012 14:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh+bbjBngX+I for ; Thu, 13 Dec 2012 14:19:37 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06A6021F88D1 for ; Thu, 13 Dec 2012 14:19:36 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1236706wey.31 for ; Thu, 13 Dec 2012 14:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0S3oRuR5m4xVhiBCsHWhw0b7YRNPYxZzPoFjFg/Xajg=; b=BDtow1ksd3A40gM7HU0OWOUDeuF4YXPjX35mMxQ6q9Cn0Dp/o4wDcKS4eiADjqm9Y3 CToOsQc+AR4Erc5R/pW8vklzcDSy4+T7Rr6xtkT0MOOrWZ/HmPLG+VT0d8txmZ1rxGWk PmxAO39a7BQslivXeQhaizv10nxdcK+zvfFNsfTs3rRPViHzuAjQPQBxrD0z8nT6l7xY Uh0D+Dfp4SsIxHtTNYSn6jC4IXaU2T9xhCEaWorhxy7Cjt/Hlhzn1oc8samIPE3sBZjD gaOLn0t1vCrCcuViQ7LjKYQubAge7fUzyow0CzIHomHxp3UJIljwPnRB6McmOjbK3YJO Mjzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0S3oRuR5m4xVhiBCsHWhw0b7YRNPYxZzPoFjFg/Xajg=; b=pmkFcdbTc0FLPpbPMlBY6kZXSU8FfPMGOiq656TsZZvN4ssaWHTpDg3g5PxW8T26eZ Qmi/654cYSmgkIcx1Ln7AlE4cKA+Xq3NfYwQfuyv+KcfxqtqzjPpk0Wlyw9YB1CyziFJ M67g6NNRwWIN+VlUHfkcVlg68oc7ig5qTUZjdqhRERAc59+ZN71R29cHbrr2RuLhDHuW +BRGb9eNIKN3EVDuCtrrIBTvhYSuH6aIdHjM4ju/sWa62x0ZGHghDpqwIpoS5+uibK3f UbSrKTry7g3+1/Xkj+hrZD4XWaw9MQeGxIMovzC+Pm+2QTMltXFuQNWfSdG7IplPs76Q CB/Q== MIME-Version: 1.0 Received: by 10.180.87.39 with SMTP id u7mr31533054wiz.6.1355437176170; Thu, 13 Dec 2012 14:19:36 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:19:36 -0800 (PST) In-Reply-To: <077401cdd97e$e78210e0$b68632a0$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> Date: Thu, 13 Dec 2012 14:19:36 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d044280f866aa8604d0c34faf X-Gm-Message-State: ALoCoQmadL3ys+/SKUarE6MV/xZ3JsbL0Ken+9x8nCTYb2RD7U4G3bS3p1miYx2scwQssuQIQ+CGKcYGgH5V1C4g+Ya+rQCf5KBK7JemzNcs/fHlgFzn768WRlKZFy7PFQt7npPItsBDkZi8hTVaZU62+eEPHO2NxoUhGL5B6HPbVkKL5YRQ6wBSD2eBf+82FxAca1qBA1qT Cc: webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:19:38 -0000 --f46d044280f866aa8604d0c34faf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 2:12 PM, Paul E. Jones wrote= : > Brad,**** > > ** ** > > I agree there is a little flakiness. Specifically, if a WF server decide= s > to provide WF services only on HTTP, then there will be some clients that > fail.**** > > ** ** > > Don=E2=80=99t conflate that issue with getting particular link relations,= though. > Any OpenID-related WF client could ALWAYS issue requests via HTTPS (even > though I assert that still is not a bullet-proof solution since a rogue w= eb > site can still do dirty things by directing a user to a phishing site).**= * > * > > ** ** > > The way I see it, we either have to accept that some clients might fail t= o > get a reply > unacceptable, IMO. > (since the user=E2=80=99s WF server only supports HTTP) or we have to man= date use > of HTTPS. > Yes, I support either HTTPS-only, in either of two forms: a) HTTPS-only for everything b) HTTPS-only-for-"secure-rels" --f46d044280f866aa8604d0c34faf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 2:12 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Brad,

=C2=A0

I agree there is a = little flakiness.=C2=A0 Specifically, if a WF server decides to provide WF = services only on HTTP, then there will be some clients that fail.=

=C2=A0

Don=E2=80=99t confl= ate that issue with getting particular link relations, though.=C2=A0 Any Op= enID-related WF client could ALWAYS issue requests via HTTPS (even though I= assert that still is not a bullet-proof solution since a rogue web site ca= n still do dirty things by directing a user to a phishing site).<= /u>

=C2=A0

The way I see it, w= e either have to accept that some clients might fail to get a reply<= /p>


unacceptable, IMO.
= =C2=A0

(since the user=E2= =80=99s WF server only supports HTTP) or we have to mandate use of HTTPS.


Yes, I support either HTTPS-on= ly, in either of two forms:

a) HTTPS-only for everything<= /div>
b) HTTPS-only-for-"secure-rels"

--f46d044280f866aa8604d0c34faf-- From bradfitz@google.com Thu Dec 13 14:23:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CE221F86D9 for ; Thu, 13 Dec 2012 14:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgK04QJZFgqf for ; Thu, 13 Dec 2012 14:23:18 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6721F86AB for ; Thu, 13 Dec 2012 14:23:17 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1238270wey.31 for ; Thu, 13 Dec 2012 14:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sbJfrknfpr59n5vJP6meUh52MUXh1qHwmznvkA7f47k=; b=MZ2ll0cWesTUgwYDAbL89mmTZBS2PwiAhUL2HBFeZnR1Z9LvBtmoAVRbO+ALKxPpzL LUfEXfpnkeAU/2OjFdfeUcrUkiSCnMNXblsA+cmAAEJj3s80v4zz+4dbJ3fSYI2v87c0 JDgtiLsPHg3QhBLThQmlSNJ1WkOW3JRPYmEbmdMwwitwANfoYaRoMkFmeVc/6WZzUvQf /6vswsS6xTgwZkO13EwblkNG3bDnbvaREkoB83zYa+aHgX2CspjNUjCE0m7XONfMhfse vP/KIBBcKDB2rnRqvz4k3B7inaSGFt2gbyq+3LqkM7tRiUHsaqQii9KUZF5d3d0E0eYC jvAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=sbJfrknfpr59n5vJP6meUh52MUXh1qHwmznvkA7f47k=; b=YbyTVt1EhcRlwe6PYFq6caEch4+4gspsXUnWd2asA/sBj1M5NpS29Wtf9LXpjAFFbg F3BxE+hgkJFtJ8AJrQyxVzsS/W6hLeog5NKvb+PxotIdpBlV7RuKp0Vw55l+aJ6GF7XE +2C3ZrE+vaWky+BC0fVbXOtnBK/yoZbeJBsQwBmh3cruRQgg21v8lHUfjESOz7e6n/WM xUQBtHvn1qoevubAkocL5BCbCvPB5cuFyJTFZKV2EtWpZeP88sbHNlc6br6j264zQ7/2 xyqE+qOATTbP0K/a3gK4hMgtl+nisZYWGCMji7D59m4068dmFxqpY90d74RJGIDxtD24 QRvQ== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr620386wjz.19.1355437396784; Thu, 13 Dec 2012 14:23:16 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:23:16 -0800 (PST) In-Reply-To: <50CA4D4D.6020002@status.net> References: <50CA4D4D.6020002@status.net> Date: Thu, 13 Dec 2012 14:23:16 -0800 Message-ID: From: Brad Fitzpatrick To: Evan Prodromou Content-Type: multipart/alternative; boundary=089e0102e1028cf5e604d0c35c26 X-Gm-Message-State: ALoCoQkQv9A6nv8Ru7q0idqf4FrRxjJo68yIEpuJEt1zjMe2R+xHOfbaM+HONrYb1jTP6nzHPnE7wQ2a+sYIIVTK4UrH59wHd7RYyJxHy+8bTZkvcAdXpsOX6WZRjPnfNnz7uHlSgXALIInkgxlGtHxp3gxf0k7aXia4Wy98x6jFSI2dKYoUB1q+Mxrm4kd0z3X2oX9elp1g Cc: "webfinger@ietf.org" , Mikael Nordfeldth Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:23:18 -0000 --089e0102e1028cf5e604d0c35c26 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 1:49 PM, Evan Prodromou wrote: > Brad, > > Can I suggest another possibility? > > 1. The Webfinger spec mandates HTTPS-only. > 2. Those of us who want to support HTTP fall back to RFC 6415 (going > through HostMeta and LRDD). > 3. If there's a pressing need for an HTTP-accessible > /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. > ("Do Webfinger, but on HTTP. QED.") > > It's going to take a while for /.well-known/webfinger endpoints to get > deployed, and falling back to /.well-known/host-meta will probably be part > of our world for a while, so it's not really that big a loss. > > I can definitely live with this; MMN? > How much of that would you want to put in the WebFinger spec? If just (1), great: that's just HTTPS-only-for-everything, which already has a lot of support, but I thought you were one of the main opponents. If also (2), that's starting to get pretty ugly, adding that dependency and reference. As I told Paul, I'm down for either HTTPS-only for everything or HTTPS-only-for-"secure-rels". --089e0102e1028cf5e604d0c35c26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 1:49 PM, Evan Prodromou <evan@status.net> wrote:
=20 =20 =20
Brad,

Can I suggest another possibility?
  1. The Webfinger spec mandates HTTPS-only.
  2. Those of us who want to support HTTP fall back to RFC 6415 (going through HostMeta and LRDD).
  3. If there's a pressing need for an HTTP-accessible /.well-known/webfinger endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on HTTP. QED.")
It's going to take a while for /.well-known/webfinger endpoints t= o get deployed, and falling back to /.well-known/host-meta will probably be part of our world for a while, so it's not really tha= t big a loss.

I can definitely live with this; MMN?

How much of that would you want to put in the WebFinger sp= ec?

If just (1), great: that's just HTTPS-only= -for-everything, which already has a lot of support, but I thought you were= one of the main opponents.

If also (2), that's starting to get pretty ugly, ad= ding that dependency and reference.

As I told= Paul, I'm down for either HTTPS-only for everything or HTTPS-only-for-= "secure-rels".

--089e0102e1028cf5e604d0c35c26-- From nick@silverbucket.net Thu Dec 13 14:24:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4E21F8B55 for ; Thu, 13 Dec 2012 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwzRMe+u34AF for ; Thu, 13 Dec 2012 14:24:23 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70D4521F8689 for ; Thu, 13 Dec 2012 14:24:22 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2211891lah.31 for ; Thu, 13 Dec 2012 14:24:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DAu/fxXkqL9Qmpv26GwyR+dpNI6ipvnor5A+l7k5Gt8=; b=H7ps2xxnrY0FZQthAxwYfirYxIuSWNOFwtpnUj0riBr5t6d3J3GYuZQAYR0jUtxcI/ 1tsmQhuZLAH4lYbusJ5nMjoE8tXRreiqLluzjHxpnrnlkdZLTTJXKt8OuH9kPjQ/GhPZ XXLNjYc5TbCAzlgMbj1PU7KXDXHHLOID4N0bj6TOmOp0rBFYFGrbvLxq8+rGVp7UprO3 QFKQqmkoqXI3BUj94A+f99ivnEZgEQrPAUvzYWlwUteY0QIn6oismxaA85OFMnrfS+5w K8MppOYDXoytUqKwp5/mFi2kCOct/E0WsJujgB+KiFXge5pIMRb6KiylzqzdDmyg2W4d o2vA== Received: by 10.152.131.168 with SMTP id on8mr701622lab.38.1355437461362; Thu, 13 Dec 2012 14:24:21 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id ps11sm1130995lab.12.2012.12.13.14.24.20 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:24:20 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2211876lah.31 for ; Thu, 13 Dec 2012 14:24:20 -0800 (PST) Received: by 10.112.24.161 with SMTP id v1mr1536371lbf.28.1355437460140; Thu, 13 Dec 2012 14:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 14:23:49 -0800 (PST) In-Reply-To: <077401cdd97e$e78210e0$b68632a0$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 23:23:49 +0100 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkgAPGckeOqVEV69Z4eXF48/GXDvv7xjPA2aqGTrG1o+Fp6HFbR0GUNNLKKEJEJSUU18I91 Cc: Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:24:23 -0000 For what it's worth. I'll chime in here and say what I think makes the most sense to me. 1. Servers MUST answer over both HTTPS and HTTP (no upgrading or downgradin= g). 2. Servers MUST filter 'secure' links from any HTTP request. 3. Client libraries SHOULD default to using HTTPS and MAY offer configuration options to use HTTP. 4. Client libraries MUST filter any 'secure' links from any HTTP request (just in case) On Thu, Dec 13, 2012 at 11:12 PM, Paul E. Jones wro= te: > Brad, > > > > I agree there is a little flakiness. Specifically, if a WF server decide= s > to provide WF services only on HTTP, then there will be some clients that > fail. > > > > Don=E2=80=99t conflate that issue with getting particular link relations,= though. > Any OpenID-related WF client could ALWAYS issue requests via HTTPS (even > though I assert that still is not a bullet-proof solution since a rogue w= eb > site can still do dirty things by directing a user to a phishing site). > > > > The way I see it, we either have to accept that some clients might fail t= o > get a reply (since the user=E2=80=99s WF server only supports HTTP) or we= have to > mandate use of HTTPS. > > > > Paul > > > > From: Brad Fitzpatrick [mailto:bradfitz@google.com] > Sent: Thursday, December 13, 2012 3:51 PM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] the conflicting goals > > > > On Thu, Dec 13, 2012 at 12:33 PM, Paul E. Jones > wrote: > > Brad, > > > > To be clear, I=E2=80=99m in neither camp (1) or (2). I=E2=80=99ve abstai= ned from taking > sides on this. > > > > What I would expect is that if a client feels that security is paramount = for > its application (e.g., logging into a web site), then it would use HTTPS. > If not, use HTTP. > > > > What I consider the simplest solution is: > > 1) Let the client use HTTP or HTTPS depending on its preference, gui= ded > by its security requirements > > 2) Servers that serve content only on HTTPS would redirect HTTP > requests to HTTPS > > 3) Clients that issue HTTPS requests and where the server happens to > not be listening on HTTPS fail > > > > I believe #3 is the pain point. With the exception of #3, clients are > simple and are were simple. But #3 introduces a breakage where users ask= , > =E2=80=9CWhy can you find any information about me?=E2=80=9D > > > > The choice then becomes one of replying with =E2=80=9Cbecause your WF pro= vider is > insecure=E2=80=9D or you change the client code to do the =E2=80=9Cfall b= ack=E2=80=9D to HTTP. The > latter is undesirable from a security perspective, but the choice really = is > that of the client. If they would have been OK with HTTP in the first > place, then they could re-query using HTTP. The spec does not have to > mandate or even recommend that behavior. If security is important, then = the > client just does not query using HTTP and the firm answer is =E2=80=9Cthe= remote > server is insecure=E2=80=9D. > > > > In short, let this be a client decision as to whether it needs security o= r > not. > > > > I don't like this. Concerns: > > > > * flakiness. sometimes it just fails, because everybody had choices and = the > spec doesn't mandate either party behaving any particular way. > > > > * if clients do HTTPS-to-HTTP fallback to combat flakiness, we're back at > square one with the security camp being unhappy. This is where we starte= d. > > > > * if I just want to query all link relations for foo@example.com, how do = I > do it? Do I as an application have to explicitly pick HTTPS-only when I = do > that query, and then pick HTTP-only if it fails? So now instead of trust= ing > just webfinger client library authors, we're trusting each and every > application. > > > > I want to make it simple and secure for a spec (like OpenID Connect) to > specify their WebFinger rel and then have WebFinger clients say: > > > > - give me all links (one of which might be for the OpenID Connect rel) > > - give me a certain link (e.g. the OpenID Connect rel) > > > > ... and know that if they get the OpenID Connect one, it arrived over HTT= PS, > per the OpenID Connect spec's wishes. > > > > I don't want applications to have to keep track of which transport links > arrived over. > > > > You may think this is all overly complicated and we can just say "Clients= : > do whatever! security is your job!", but that is fundamentally what the > HTTPS-only camp is against. > > > > If you want to make the security group happy, you either need ~this or > HTTPS-only. > > If you want to make the HTTP-okay group happy, you either need this or yo= u > need to lose the support of the security group. > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From bradfitz@google.com Thu Dec 13 14:27:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E421F8B9F for ; Thu, 13 Dec 2012 14:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+7dUIHayaQN for ; Thu, 13 Dec 2012 14:27:40 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9721F8B55 for ; Thu, 13 Dec 2012 14:27:39 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1082003wgb.13 for ; Thu, 13 Dec 2012 14:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qrDqdTd3JC/hYy5UU0nO1bXMNVimmXEwOOsfC9l4CRo=; b=Rpt6KM32iXCHBYDpfool2T7E6Tp1O0aSIpK34QvWLdMRkSPKGkg4K11Zu2Rxy/XzGZ IIqr46KspbKnkR68kMe+hYWfnom5YcGcla2V1flhlJQyZtdBA3BQHxuSb7gegNl5ERy0 DHNkZKflEH+VgHLnj205EmZMkrdX+aa/Nj3LCCF9MH6cR5dtmGczHcnMsAhrVutNFXcL CMVZ3ZP/DXiqBXY5FY6YZtFcYV/qTUVHZ8YpX9YmRvmkrXqhkfcnXYCS2m93+BedNYWm CCFCvtHuBoEj37rR3WMCbo5giqtcr1WBrdhxcZ2IFyR1cCxQOTLUPJaQj8M4mEqaXx1x pE1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qrDqdTd3JC/hYy5UU0nO1bXMNVimmXEwOOsfC9l4CRo=; b=YggejZWrmURu39lqlsgECncGjeHPxIEOm4Mxxp5EVuHACgSf6wbR0X2oVOFHYUrLIk +EDeEC1ZzR04FHtVdaq/dhc379NlIqGfJzbu3T8Ov8Ad3c4fwkFU+lAN+pZ/Gyfh5lU0 3tq7X5aw2adDLhIBKDC3RI98rL8rAj8+UJqCrJtsQfypmtw3QRKz71BG6WgcokMTC7DX IqD7tpqHAA0xYigxZN+9oD6aijHIauu0iOEtaSxDGH1yzvh82axQdp3ONEJ6GONxM04D BpHzUxr+QVnFXL/dK3UcjRcKR/sdi5ZY4yJqUTL9gB4SQF5dtH8SpYEKgkHbOLIgjFeg Hmgg== MIME-Version: 1.0 Received: by 10.180.74.108 with SMTP id s12mr5875779wiv.12.1355437657627; Thu, 13 Dec 2012 14:27:37 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:27:37 -0800 (PST) In-Reply-To: <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> Date: Thu, 13 Dec 2012 14:27:37 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043c81e6191bad04d0c36ca9 X-Gm-Message-State: ALoCoQmoj4eq8MqC9Wc9h5IcJiOw8LnBMKb0ZqNVVEKPu0ctfL34YW1Jxwgsrl4Bu1x9S6QRzP8J2EfEhuIzrNj1czU5F2ARHnknBK2Epr3Ln4E+XtlgRHV3RMGY0pbHAGeWGXcb2rGSTDbpuuVq2tbxin7kiUJ6DPsPWkyC/VsxPS3eypqzTvvF/qM/oOFcDZizpoSuVNAz Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:27:40 -0000 --f46d043c81e6191bad04d0c36ca9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 2:18 PM, Paul E. Jones wrote= : > No, the client should not fall back to HTTP. That=E2=80=99s not written = in the > current proposal. > If the server is allowed to serve on either HTTPS or HTTP, I think the client needs to do fallback. HTTPS-only makes this all easier. If we want to allow HTTP, we need more complexity in the client. --f46d043c81e6191bad04d0c36ca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f46d043c81e6191bad04d0c36ca9-- From bradfitz@google.com Thu Dec 13 14:32:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D021F8B59 for ; Thu, 13 Dec 2012 14:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgHM1f-jXFU for ; Thu, 13 Dec 2012 14:32:25 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id CA8DD21F89E2 for ; Thu, 13 Dec 2012 14:32:24 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1084012wgb.13 for ; Thu, 13 Dec 2012 14:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VmEjkB0W3ARtZKDdLm1tCIpJl7j8uW4sgWGm9NFtgp8=; b=DNfyQDYU9KfYhN0heyzLqtpZBJ3F7ki3Vm13SvjQvJuMhTIJAaGfVCLFXtndXykVQX bLt2+CZ9zwkJ8W0f2MbhA1rg4X7lMo6HZnqQ3GN6/21z5Elmelk1x7X/6XsRq261Q1e6 Axy+7r2xSfNhpcEJ1lEJjytETMIPyGSMXwwwIGYPQcawuJ5GItgP93A79eWNY0hzUTtu f+ZNxzE+YKxcDsGEc+fWBefgDbqzUdMhdHVCrNo2t5ybz33rZ9buhLgDMAaszBDd/ykq tVbsyNL+8hcar/xaiSFcjvyEFX6f82boFm4A1SN8PbtQcqHO9iuzgfkmCoUYkoO9c5a9 SBMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VmEjkB0W3ARtZKDdLm1tCIpJl7j8uW4sgWGm9NFtgp8=; b=n5nlAn3XSRmfwZOvyKlqaYHHmklZIpNYNo0hUygzGBzYd+uFlCNSUt2qZuMO+F9LxJ A64kbfzv5F8uXHI7uhmm1BfRMInuVlLdgTqXozcmOUFSLj4xnnYKHS0ptfBCHeTIu5mo wZvx/UFGbPtf/lBQXmuLnxvjrQJvLOwWFC1AU40AnWAQN0Ec12sVTI5uXlrrNIbMCd3T kEPEFhbVTECOWW024UJ+02pDj3P7KOLBHIkq6wdftA5akrJwoTVmwYbrrgqDHjfTwpOT bEMZumDenRkzQU7WTIiJyvFd0Xd/HaRtZqpdaxhrtr+htc6ZF1PSHug6oWtuG8cxi/Ec Z/Cw== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr645234wjz.19.1355437944028; Thu, 13 Dec 2012 14:32:24 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:32:23 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> Date: Thu, 13 Dec 2012 14:32:23 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=089e0102e1022b3c2104d0c37d2a X-Gm-Message-State: ALoCoQkXTklIs+lfQPa/UUJVvPUoDUjceJ200odJ6y8CFavpSmhncd+FPu4cTwg4qNrryMpbtSN5KssNBsBfjoMe1TpfHX+HK+HAOH09PS0NwgzY0sXEq4hECA3VVLs8wGgmbyYIT9vxe9X0lC2wusPZEXsVyuub+fV1qzVqWXzjcS1gtUb/0dRKjOlOoFM3NRbiSwInSUaM Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:32:25 -0000 --089e0102e1022b3c2104d0c37d2a Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 2:23 PM, Nick Jennings wrote: > For what it's worth. I'll chime in here and say what I think makes the > most sense to me. > > 1. Servers MUST answer over both HTTPS and HTTP (no upgrading or > downgrading). > > 2. Servers MUST filter 'secure' links from any HTTP request. > > 3. Client libraries SHOULD default to using HTTPS and MAY offer > configuration options to use HTTP. > > 4. Client libraries MUST filter any 'secure' links from any HTTP > request (just in case) Of the 3 goals I mentioned earlier (secure, HTTP, and simple client), this seems to be just secure. Any proposal should be able to get 2 of the 3, not just 1. In particular, your item (1) alienates the camp who doesn't want to buy SSL certs. And your item (3) introduces an configuration option, which also worries the security camp (giving less security-aware applications options to mess up) and also makes the client-simplicity story worse. And then (4) makes the client-simplicity story worse yet. --089e0102e1022b3c2104d0c37d2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 2:23 PM, Nick Jennings <nick@silverbucket.net> wrote:
For what it's= worth. I'll chime in here and say what I think makes the
most sense to me.

1. Servers MUST answer over both HTTPS and HTTP (no upgrading or downgradin= g).

2. Servers MUST filter 'secure' links from any HTTP request.

3. Client libraries SHOULD default to using HTTPS and MAY offer
configuration options to use HTTP.

4. Client libraries MUST filter any 'secure' links from any HTTP request (just in case)

Of the 3 goals I men= tioned earlier (secure, HTTP, and simple client), this seems to be just sec= ure. =C2=A0Any proposal should be able to get 2 of the 3, not just 1.

In particular, your item (1) alienates the camp who doe= sn't want to buy SSL certs.

And your item (3) = introduces an configuration option, which also worries the security camp (g= iving less security-aware applications options to mess up) and also makes t= he client-simplicity story worse. =C2=A0And then (4) makes the client-simpl= icity story worse yet.

--089e0102e1022b3c2104d0c37d2a-- From nick@silverbucket.net Thu Dec 13 14:33:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68921F8613 for ; Thu, 13 Dec 2012 14:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGf+qlCU-SpO for ; Thu, 13 Dec 2012 14:33:17 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3521F8617 for ; Thu, 13 Dec 2012 14:33:16 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2231675lbk.31 for ; Thu, 13 Dec 2012 14:33:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=K1Reqrfku3UYhzqbb1J8djcy8bZpgGZtCuwr61KwmLc=; b=NdeOX0kd52dOnRCA4WSmibKusaanqyQ7e6HzU3OMRflw7W7mM8MrqD5sx/Ith1PsVm KRR3S/CN9P2yHvDmf9BRtnFJxKlntUppZHjhDHEyDTE+PEdBu81MgXaGWUt4FRVON6vt XpO82+mudSQrB/kp+EpRnemqunRLqYwcASJPeBUpannuQv0qbzZoUgWFqxsJLfuX2hOd ZWyLFJzJNzhaCTtrkBDETvXefOjuDdewmWf5pvHbr31PlBGN7uinUnLKllJves81D7Hm CidpgWoqVR4MS4o67L/o1Pc1w/ly+E3/ixy78XIMWK+WM+Jml6nofuEs1CY3jF3eS6zx idlA== Received: by 10.112.88.7 with SMTP id bc7mr1545652lbb.108.1355437991009; Thu, 13 Dec 2012 14:33:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id fb1sm1206826lbb.15.2012.12.13.14.33.09 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:33:09 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2216933lah.31 for ; Thu, 13 Dec 2012 14:33:09 -0800 (PST) Received: by 10.152.106.4 with SMTP id gq4mr638605lab.44.1355437988976; Thu, 13 Dec 2012 14:33:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 14:32:38 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 23:32:38 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyihM4ZJMG7l8vPKRhKq31wQltwKEcYTBo6Zh+/YjlWvaJMB/1EKbH3ugXx4AdBVgiVt7U Cc: "Paul E. Jones" , James M Snell , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:33:17 -0000 On Thu, Dec 13, 2012 at 11:27 PM, Brad Fitzpatrick wr= ote: > On Thu, Dec 13, 2012 at 2:18 PM, Paul E. Jones > wrote: >> >> No, the client should not fall back to HTTP. That=E2=80=99s not written= in the >> current proposal. > > > If the server is allowed to serve on either HTTPS or HTTP, I think the > client needs to do fallback. > > HTTPS-only makes this all easier. > > If we want to allow HTTP, we need more complexity in the client. > Why not HTTPS and HTTP for the server? (not either-or) From paulej@packetizer.com Thu Dec 13 14:34:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02721F88CE for ; Thu, 13 Dec 2012 14:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bY-s5wHaBMM for ; Thu, 13 Dec 2012 14:34:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C18FB21F8983 for ; Thu, 13 Dec 2012 14:34:15 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDMYD9T016190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 17:34:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355438054; bh=vzR+kPCxXV6B/iT5nJfLIX6Chh543Lja5H+1viKt93U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=hFAku57Ef7BEdLBe1XKOPWUXZwHKrj/UNXl5X65Y3sKNoj21RJ4H6hQDmKWEgKRUT W8EvAmZkxa2AJoFvY9o861ceLbIEQSJyvAkVzM2R3SqEqFr1X5bqsZISE5WyLXGaqe sWF5SOW68/SQfca41Rbm5pzi6qkW1r64Vq31MQjU= From: "Paul E. Jones" To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <069f01cdd968$34447420$9ccd5c60$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 17:34:25 -0500 Message-ID: <07a601cdd982$01b075d0$05116170$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07A7_01CDD958.18DBF470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAKzhuCLAmVCwkkCepxYsgJaZ1yWAm+kfvEBUcsFhwLGVRnMAiufZtoCInJ6zJhphRzA Content-Language: en-us Cc: 'Brad Fitzpatrick' , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:34:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07A7_01CDD958.18DBF470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What I am suggesting is that *if*we want to do any kind of URL filtering that we do it based on server configuration, not "rel" type. I don't like the "secure-cat-picture" idea. If you are an HTTP-only client and the only cat picture I have I want served only via HTTPS, then I tell my WF server "serve this only via HTTPS". So, a query to the HTTP server will never see that. However, I don't even like that. If the HTTP server has this rule that it follows, it means it can do HTTPS. So, rather than filtering, just redirect the client to the HTTPS server. The concern, of course, is that some client writer might write a client that SHOULD have requested WF content securely in the first place and is looking for secure content. That insecure request ends up getting redirected to the wrong place. So clients that need security should never use HTTP. Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Zellyn Hunter Sent: Thursday, December 13, 2012 2:37 PM To: webfinger@googlegroups.com Cc: Brad Fitzpatrick; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels Only if by "query to an HTTPs URL" and "query to an HTTP URL", you mean a "webfinger client query" rather than a plain old "http(s) query". The onus is on the *client* to reject "secure" items retrieved over HTTP. The server can return the same content in both cases. In other words, if you ask the webfinger client for my "secure-cat-picture", you will never get an answer unless the answer was retrieved over HTTPS, regardless of whether it's in the HTTP response or not. Zellyn On Thu, Dec 13, 2012 at 11:29 AM, Paul E. Jones wrote: No, I understand the downgrade attack, but that is totally unrelated to what we were talking about. What we were discussing is that a query to an HTTPS URL might return a different set of link relations than a query to an HTTP URL. More specifically, a query to an HTTPS URL might return things the server believes should only be returned over HTTPS, such as links to an OpenID Provider. Nowhere in the currently proposed "compromise" text is there a proposal to fall back as you're showing it. A client either requests WF via HTTPS or HTTP, not both. In the case of the latter, it's not looking for secure content or security is a non-issue. Paul From: Brad Fitzpatrick [mailto:bradfitz@google.com] Sent: Thursday, December 13, 2012 11:54 AM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones wrote: Don't put it on the wire. You want the server to filter before sending a reply. I'm concerned you're still confused about how a downgrade attack works. Again: it DOES NOT MATTER what the server thinks it's filtering if the client has been tricked into talking to a DIFFERENT SERVER which is then returning malicious results. Such as: -- client wants "all links" for foo@example.com. -- client requests secure https://example.com/.well-known/webfinger?resource=acct:foo@example.com -- EVIL HIJACKER BLOCKS PORT 443 -- client then requests plain http://example.com/.well-known/webfinger?resource=acct:foo@example.com -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT: { "rel" : "https://openid.net/connect/server", "type" : "text/html", "href" : "https://attacker.openid.server/" }, See what happened there? We need the *client* to say "whoa whoa, wait a minute... I contacted this webfinger server over HTTP---- what's it doing returning rels starting with https:? I'm gonna skip over those (or just return an error)." The real webfinger server _was never even contacted_, so it doesn't matter whether it was filtering or not. ------=_NextPart_000_07A7_01CDD958.18DBF470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What I am suggesting is that *if*we want to do any kind of URL = filtering that we do it based on server configuration, not = “rel” type.  I don’t like the = “secure-cat-picture” idea.

 

If you are an HTTP-only client and the only cat picture I have I want = served only via HTTPS, then I tell my WF server “serve this only = via HTTPS”.  So, a query to the HTTP server will never see = that.

 

However, I don’t even like that.  If the HTTP server has = this rule that it follows, it means it can do HTTPS.  So, rather = than filtering, just redirect the client to the HTTPS = server.

 

The concern, of course, is that some client writer might write a = client that SHOULD have requested WF content securely in the first place = and is looking for secure content.  That insecure request ends up = getting redirected to the wrong place.   So clients that need = security should never use HTTP.

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Zellyn Hunter
Sent: Thursday, December 13, 2012 = 2:37 PM
To: webfinger@googlegroups.com
Cc: Brad = Fitzpatrick; webfinger@ietf.org
Subject: Re: [webfinger] = secure links with https rels

 

Only if = by "query to an HTTPs URL" and "query to an HTTP = URL", you mean a "webfinger client query" rather than a = plain old "http(s) query". The onus is on the *client* to = reject "secure" items retrieved over HTTP. The server can = return the same content in both cases.

 

In other words, if you ask the webfinger client for my = "secure-cat-picture", you will never get an answer unless the = answer was retrieved over HTTPS, regardless of whether it's in the HTTP = response or not.


Zellyn

 

On Thu, Dec 13, 2012 at 11:29 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

No, I understand the downgrade attack, but that is totally unrelated = to what we were talking about.

 

What we were discussing is that a query to an HTTPS URL might return = a different set of link relations than a query to an HTTP URL.  = More specifically, a query to an HTTPS URL might return things the = server believes should only be returned over HTTPS, such as links to an = OpenID Provider.

 

Nowhere in the currently proposed “compromise” text is = there a proposal to fall back as you’re showing it.  A client = either requests WF via HTTPS or HTTP, not both.  In the case of the = latter, it’s not looking for secure content or security is a = non-issue.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 11:54 AM


To: Paul E. Jones
Cc: webfinger@googlegroups.com; webfinger@ietf.org
Subject: Re: = [webfinger] secure links with https = rels

 <= /o:p>

On Thu, Dec = 13, 2012 at 8:45 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Don’t put it on the wire.  You want the server to filter = before sending a = reply.

 =

I'm = concerned you're still confused about how a downgrade attack = works.

 =

Again: it = DOES NOT MATTER what the server thinks it's filtering if the client has = been tricked into talking to a DIFFERENT SERVER which is then returning = malicious results.

 =

Such = as:

-- client = wants "all links" for foo@example.com.

-- EVIL = HIJACKER BLOCKS PORT 443

-- EVIL = HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY = WANT:

  =        {

  =          "rel" : "https://openid.net/connect/server",

  =          "type" : = "text/html",

  =          "href" : "https://attacker.openid.server/"

  =        },

 =

See what = happened there?

We need the = *client* to say "whoa whoa, wait a minute... I contacted this = webfinger server over HTTP---- what's it doing returning rels starting = with https:? I'm gonna skip over those (or just return an = error)."

 =

The real = webfinger server _was never even contacted_, so it doesn't matter = whether it was filtering or not.

 =

 

------=_NextPart_000_07A7_01CDD958.18DBF470-- From bradfitz@google.com Thu Dec 13 14:35:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0200B21F88D1 for ; Thu, 13 Dec 2012 14:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyyFYLMvCkez for ; Thu, 13 Dec 2012 14:35:02 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4517021F88CE for ; Thu, 13 Dec 2012 14:35:02 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1085111wgb.13 for ; Thu, 13 Dec 2012 14:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EF6a3GHIIT+/RwyoV7Hbf2HuPGVmiTWJLG/HEAyb2Zc=; b=fNALUWJN7XYd61OZWI6ccI2rMTxjIZlPi7MziGlswpinDlNMv0axSLRyyfNWUgdaUL 3xDhT/QU5lHFLEDmv60+n6QUrCcbMEVb8tYhN64JX9hql6Xffc+9bw5tleUAuuksCteg c3pe10vHkJRCvphwwvN+mwux/IoRA2JqqPqasBlgJjSN27mh39Kdqnmcfyv7CBQL1twj M6p6MGxqBNwDa9BottFPaJYuWrdZON48Yap/qpiRmFi2OJTMBXVWXZCdvByitPKo8Amj mOkQvXqYD7A9KNMqHYFN86IehMETOalVloaVf1wHwfmcQ6WZkd2iwoepSmV69iCWHgtE FTuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EF6a3GHIIT+/RwyoV7Hbf2HuPGVmiTWJLG/HEAyb2Zc=; b=Gv38KZs95YbUSpRTH3eu6msVVbY7EzIg/CpHD4PPVmhoMl3eSB06Jpk7jr/cnsSfkm BE24Pr8tbjzh8shje+8zoE1cD2DDprgIwyGGoSW8bEYE0zVRrDeNF59TW9JqsPuhA2dR WvLE5tyJDzQP9ppp/RtXNHmt446CvtAkqj3/sh4f8MFm+GlkbA2ZcZLfA626vADaaP67 5F1iz2rVOM54L/mtpyGZ2E2mRuBdGhDyudjfZQ/8ExWZR+tagbjvJOh2Fu5motdU0OQC nL+nkHrN72LhlQLnGIRaIIlmK8zSmz5SVUhKDK4xZY1ayPsw1BpjZocGusKFhTwZfHbO iJpg== MIME-Version: 1.0 Received: by 10.180.86.39 with SMTP id m7mr31621461wiz.1.1355438101472; Thu, 13 Dec 2012 14:35:01 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:35:01 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> Date: Thu, 13 Dec 2012 14:35:01 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04428e108da4fe04d0c38621 X-Gm-Message-State: ALoCoQm+6o3KuT+aa6mZ/85sFbrQVEm3jjvwaqR+9mFg07AEXMPo0LaIRzQa1ai/unq0MC57J/Y6kBBZIOcIeLB4BtgeU07a1RrmQN5D25QHUIC1H0uc5uyGYrz0qBnqAJQJ26W79FcGEMAHUJbBcm8CmD6+H9TSK6HAnf5GsM/E2yAdLT0Bl59sEkz/eZgpX84b8cRuWLLv Cc: "Paul E. Jones" , James M Snell , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:35:03 -0000 --f46d04428e108da4fe04d0c38621 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 2:32 PM, Nick Jennings wrote: > > > > HTTPS-only makes this all easier. > > > > If we want to allow HTTP, we need more complexity in the client. > > > > Why not HTTPS and HTTP for the server? (not either-or) > There are a number of people on this list who want to run WebFinger servers over HTTP without the pain and expense of setting up HTTPS. HTTP fallback was a compromise for them. --f46d04428e108da4fe04d0c38621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f46d04428e108da4fe04d0c38621-- From bradfitz@google.com Thu Dec 13 14:43:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758A21F8B11 for ; Thu, 13 Dec 2012 14:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqjdzRQrLwS1 for ; Thu, 13 Dec 2012 14:43:47 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1121F863B for ; Thu, 13 Dec 2012 14:43:23 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1246663wey.31 for ; Thu, 13 Dec 2012 14:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2cuAwYLNcMiQda58qGDYWhCLJtLDOh4Y8p9I8gKv64=; b=jUOxKCbzgLVaic1YRuNzKMY/t/iAkncaS/bUiNXbMqttvTiC+oNh1OaKT8T3bTr9b8 qUtopq3d9pcVV3YXzM7GunZHFEuw7de/JGtvTlogi90+aGvFwZnJp7Xj/EJb3mC1G6rP FoTfDGq9x3KZ9XDy65eBOglKaX8zkwPnbdceP3XTocgD3mI4IrsGTtzjDl2zKwqCcuGy 7/IRN8ZDk4sdTn/AUd6IfccmXMuWGIbg0g4ifI1JiDiuJryhOMvhfH4uY7k4NnE71OA7 TmpknV8T+xhNiwyoeKp+BqcvPwLO841ZErVn82ZjYL/u1tGzte5wahi/tztuIJIpWozm IYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=O2cuAwYLNcMiQda58qGDYWhCLJtLDOh4Y8p9I8gKv64=; b=eedxMyD5nc0VqGZ771yj6RiLecGBE/ZUAH/MCjVZNu7vuXFoOS5sb8LOH1bQqiKR5M MJOBVKBug875AJNQ3Y9dvoB6ttlOOLRoV2m6mx3Jtrz/Jpsbx4aBlA4yISlzayfueqxn nbWiVNSFBxdm2QoG1ADM4O+1XthU0cna55mG5XD3vCYKCTuxBL7ztVh222HZ4wqG70B4 fmNaXh6AKjusNOgzL478mcv+tP5OX5zEj5V1I75FK9WT3H6tfTv/vjSf+0uLyqg4csxf R5eALkKXWYYwMMbf87c+9rLz/TG5Loosr3t9bDznju0HgGly29pnvdzc9NOV31+VpjG2 HXiQ== MIME-Version: 1.0 Received: by 10.180.109.132 with SMTP id hs4mr5950953wib.1.1355438603063; Thu, 13 Dec 2012 14:43:23 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:43:22 -0800 (PST) In-Reply-To: <07a601cdd982$01b075d0$05116170$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <069f01cdd968$34447420$9ccd5c60$@packetizer.com> <07a601cdd982$01b075d0$05116170$@packetizer.com> Date: Thu, 13 Dec 2012 14:43:22 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f2355c773501204d0c3a415 X-Gm-Message-State: ALoCoQnC4v8qg7GaT0cTUSO9kAndCcYgO8TumNqZtFG3TS3Y9AKwtAZxG7Hs588WBg1myQMDRX98eF05J5+p9xAMK03V7+ffckvUWL6VzEzP5xrXYC4aXg64wIEnEpqByPvbF7Uy5r3vywqDxzpLDnKEvXg4Q+UZ8pRi4+mKWIr1W4uuCPMH+gQzH3vjEaIXom4uD/677ElY Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:43:48 -0000 --e89a8f2355c773501204d0c3a415 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 2:34 PM, Paul E. Jones wrote= : > What I am suggesting is that *if*we want to do any kind of URL filtering > that we do it based on server configuration, not =E2=80=9Crel=E2=80=9D ty= pe. I don=E2=80=99t like > the =E2=80=9Csecure-cat-picture=E2=80=9D idea.**** > > ** ** > > If you are an HTTP-only client and the only cat picture I have I want > served only via HTTPS, then I tell my WF server =E2=80=9Cserve this only = via > HTTPS=E2=80=9D. So, a query to the HTTP server will never see that. > MITM. The client gets rerouted by the attacker that serves "cat-picture" =3D> href: "evil-cat.jpg". The real server was never contacted, so all you= r server filtering is useless. Security needs to be in the client too. > **** > > ** However, I don=E2=80=99t even like that. If the HTTP server has this = rule > that it follows, it means it can do HTTPS. So, rather than filtering, ju= st > redirect the client to the HTTPS server. > > ** ** > > The concern, of course, is that some client writer might write a client > that SHOULD have requested WF content securely in the first place and is > looking for secure content. That insecure request ends up getting > redirected to the wrong place. So clients that need security should nev= er > use HTTP. > I don't want to make applications choose between security and not. That significantly increases the amount of code to audit, most of it not visible. The security camp won't like it. You need to make the client library always results that are trustworthy. Again, I'm not mandating the client interface (any API is acceptable), only the behavior. In fact, I want zero configuration on the client side. If an application queries "all links for foo@example.com" and gets back a set of 10 links, one of which is: rel "https://openid.net/rel/connect/server", href: " https://myopenid.example.com/" ... I want that to be trustworthy, without the webfinger client being configured "correctly". --e89a8f2355c773501204d0c3a415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 2:34 PM, Paul E. Jones <paulej@packetizer.com> wrote:

What I am suggesting is that *if*we want to do any kind of URL fil= tering that we do it based on server configuration, not =E2=80=9Crel=E2=80= =9D type.=C2=A0 I don=E2=80=99t like the =E2=80=9Csecure-cat-picture=E2=80= =9D idea.

=C2=A0

If you are an HTTP-= only client and the only cat picture I have I want served only via HTTPS, t= hen I tell my WF server =E2=80=9Cserve this only via HTTPS=E2=80=9D.=C2=A0 = So, a query to the HTTP server will never see that.


MITM. =C2=A0The client gets rerouted= by the attacker that serves "cat-picture" =3D> href: "ev= il-cat.jpg". =C2=A0The real server was never contacted, so all your se= rver filtering is useless.=C2=A0

Security needs to be in the client too.
=C2= =A0

=

=C2=A0However, I don=E2=80=99t even like that.=C2=A0 If the HTTP server has th= is rule that it follows, it means it can do HTTPS.=C2=A0 So, rather than fi= ltering, just redirect the client to the HTTPS server.

=C2=A0

The concern, of cou= rse, is that some client writer might write a client that SHOULD have reque= sted WF content securely in the first place and is looking for secure conte= nt.=C2=A0 That insecure request ends up getting redirected to the wrong pla= ce. =C2=A0=C2=A0So clients that need security should never use HTTP.=


I don't want to make application= s choose between security and not. =C2=A0That=C2=A0significantly=C2=A0incre= ases the amount of code to audit, most of it not visible. =C2=A0The securit= y camp won't like it.

You need to make the client library always results that= are trustworthy. =C2=A0Again, I'm not mandating the client interface (= any API is acceptable), only the behavior. =C2=A0In fact, I want zero confi= guration on the client side.

If an application queries "all links for foo@example.com" and gets back a set o= f 10 links, one of which is:


... I want that to be trustworthy, without the webfinge= r client being configured "correctly".
--e89a8f2355c773501204d0c3a415-- From nick@silverbucket.net Thu Dec 13 14:46:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1466421F89A0 for ; Thu, 13 Dec 2012 14:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga4OplGNsQ9n for ; Thu, 13 Dec 2012 14:46:39 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5AE21F8644 for ; Thu, 13 Dec 2012 14:46:38 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2224437lah.31 for ; Thu, 13 Dec 2012 14:46:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=bWoeeNAUNLqf950TL88YWarAYF2uknNm1k4GGcL0gtE=; b=V0RKUnAkg/cT/36h5Jddz5cMu7i1FXh11uL1NBF3mgrzNPH+7B+5ufiSrqRXbUV6QU tLVeiz8bcDqg+VaD3Fb7Rv6i2EPxBGy1Oz2ma6QCsFsvZlvvRTY6drB1NkT5XdTFx4db sUuu1mqQ8hZZygT6W4G+ikEIcXqPLq7R9nWL5NnPtTbo6lpBe1cJNED2DZ2ap7zVMp8W LMfm5WpIoNkPoKmuZQioupE/DTpC/ZG+/iU3ODRDYC6MRwlxPPPSCiVRaUMOHpANe4rM skuOmJBCnpwkkP5pwx4bpaZukmagLOYCzpskEMZL9Z/dXwpM8nDZQ/UWxGjJlm5T4kci ypag== Received: by 10.112.25.198 with SMTP id e6mr1587403lbg.63.1355438797895; Thu, 13 Dec 2012 14:46:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id pw17sm1147599lab.5.2012.12.13.14.46.36 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:46:37 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2224421lah.31 for ; Thu, 13 Dec 2012 14:46:36 -0800 (PST) Received: by 10.152.125.136 with SMTP id mq8mr832691lab.41.1355438796735; Thu, 13 Dec 2012 14:46:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 14:46:06 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 23:46:06 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmhe3zQXd+0fjQdg0O36MxQmWh5NbZSB52mde7PRkhH+DBs9BKr4+12ADrrX3p9eg7YOm61 Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:46:40 -0000 On Thu, Dec 13, 2012 at 11:32 PM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 2:23 PM, Nick Jennings > wrote: >> >> For what it's worth. I'll chime in here and say what I think makes the >> most sense to me. >> >> 1. Servers MUST answer over both HTTPS and HTTP (no upgrading or >> downgrading). >> >> 2. Servers MUST filter 'secure' links from any HTTP request. >> >> 3. Client libraries SHOULD default to using HTTPS and MAY offer >> configuration options to use HTTP. >> >> 4. Client libraries MUST filter any 'secure' links from any HTTP >> request (just in case) > > > Of the 3 goals I mentioned earlier (secure, HTTP, and simple client), this > seems to be just secure. Any proposal should be able to get 2 of the 3, not > just 1. > > In particular, your item (1) alienates the camp who doesn't want to buy SSL > certs. (maybe I should have given my points letters so I could reference your points and mine without confusion). It addresses all of the concerns related to (your point #2) EXCEPT for the SSL cert issue (which would not be solved for HTTPS-only anyway). > And your item (3) introduces an configuration option, which also worries the > security camp (giving less security-aware applications options to mess up) > and also makes the client-simplicity story worse. The whole point of (your point #2) (from my perspective) is so that a web developer can make the decision to keep things as simple and use-able for anyone using their site/app (ie. mobile devices). They should be able to say "give me names and avatars using HTTP"... that's a pretty basic configuration option, and any security-focused link, like OpenID, wouldn't come back because of my points (2) and (4) No matter what, there will be configuration options and client complexity unless we go with HTTPS only. > And then (4) makes the > client-simplicity story worse yet. > I suggested the server-filtering only, but you brought up the point that an HTTP request could be intercepted and 'secure' links could be sent back. The client should ignore 'secure' links no matter what, if HTTPS was not used. So, the complexity would be there unless we used HTTPS only. From nick@silverbucket.net Thu Dec 13 14:48:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098F121F86CA for ; Thu, 13 Dec 2012 14:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWrwDJAgybIN for ; Thu, 13 Dec 2012 14:48:17 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1CEC21F852B for ; Thu, 13 Dec 2012 14:48:05 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2225181lah.31 for ; Thu, 13 Dec 2012 14:48:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=BxfoMQiFKulcjqDddbwOUngGbO8UbhIIQyYLNWKVpXw=; b=dtFKaIOYEnVc63I7JLLeHmaZnLvFKrlY2QGRfHT8+qSUmKaBjsbLKWKxmH8lgOlKjV GGk1a6faNR1bslrGJu0EN7Uj5ogtnIilN58bPFxavKsM3nly56KaYQa7Q105dIX9OKsm 25KY63KlDkJKvsv1ZnHgVQW098V6Gev6Kz45zLf5ePeDb9avu11/z8WLNcUoHwOTak+Z DNoMJddr3d3uk0aJYxmRMun17ZzeEoTsTujQu8Okp7oFKL7OuTeJKNxj9wKpr13XBui1 jIICzkSMujqQQ57I0tjCc3aYxA3Pvtp0K/rR/5WjS7RqJLzcaDJm7eaqr6JkKgnyIkXP dhuQ== Received: by 10.112.16.110 with SMTP id f14mr1513207lbd.126.1355438884564; Thu, 13 Dec 2012 14:48:04 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id lr20sm1142846lab.17.2012.12.13.14.48.03 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:48:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2225169lah.31 for ; Thu, 13 Dec 2012 14:48:03 -0800 (PST) Received: by 10.152.113.66 with SMTP id iw2mr729829lab.37.1355438883446; Thu, 13 Dec 2012 14:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 14:47:33 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 23:47:33 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlUD1UaVIlKgw99tNEMG9As800YXV1XTxhMTURU38NfebTG02za9p2Nz0KwAn4h3LZ+bhaQ Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:48:18 -0000 In short, I think my suggestion addresses points (1) and (3) - the client simplicity is cut down because there's not 'fallback' which was the main sore-spot. And half or more of (2) On Thu, Dec 13, 2012 at 11:46 PM, Nick Jennings wrote: > On Thu, Dec 13, 2012 at 11:32 PM, Brad Fitzpatrick wrote: >> On Thu, Dec 13, 2012 at 2:23 PM, Nick Jennings >> wrote: >>> >>> For what it's worth. I'll chime in here and say what I think makes the >>> most sense to me. >>> >>> 1. Servers MUST answer over both HTTPS and HTTP (no upgrading or >>> downgrading). >>> >>> 2. Servers MUST filter 'secure' links from any HTTP request. >>> >>> 3. Client libraries SHOULD default to using HTTPS and MAY offer >>> configuration options to use HTTP. >>> >>> 4. Client libraries MUST filter any 'secure' links from any HTTP >>> request (just in case) >> >> >> Of the 3 goals I mentioned earlier (secure, HTTP, and simple client), this >> seems to be just secure. Any proposal should be able to get 2 of the 3, not >> just 1. >> >> In particular, your item (1) alienates the camp who doesn't want to buy SSL >> certs. > > (maybe I should have given my points letters so I could reference your > points and mine without confusion). > > It addresses all of the concerns related to (your point #2) EXCEPT for > the SSL cert issue (which would not be solved for HTTPS-only anyway). > > >> And your item (3) introduces an configuration option, which also worries the >> security camp (giving less security-aware applications options to mess up) >> and also makes the client-simplicity story worse. > > The whole point of (your point #2) (from my perspective) is so that a > web developer can make the decision to keep things as simple and > use-able for anyone using their site/app (ie. mobile devices). They > should be able to say "give me names and avatars using HTTP"... that's > a pretty basic configuration option, and any security-focused link, > like OpenID, wouldn't come back because of my points (2) and (4) > > No matter what, there will be configuration options and client > complexity unless we go with HTTPS only. > >> And then (4) makes the >> client-simplicity story worse yet. >> > > I suggested the server-filtering only, but you brought up the point > that an HTTP request could be intercepted and 'secure' links could be > sent back. > The client should ignore 'secure' links no matter what, if HTTPS was > not used. So, the complexity would be there unless we used HTTPS only. From bradfitz@google.com Thu Dec 13 14:51:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284E21F894C for ; Thu, 13 Dec 2012 14:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UiqstaLcDnr for ; Thu, 13 Dec 2012 14:51:45 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74121F8855 for ; Thu, 13 Dec 2012 14:51:44 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so126402wib.1 for ; Thu, 13 Dec 2012 14:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kknWU6Tvqv/EzCijm0KZo71tRPCvAwDRYVXv6748kDE=; b=cMTo1fTXFibyJG1NQfFdqpxnKToKCXc1psJlwf8JSkWFYa6rev6zuMgei1NRexn/oQ jwRwY4rparvSzPc6OAlD8c48aigH2fqAZjfVquOPzp9jZXC1Ej0PJw+3Fe2DVzySAwQ5 qmECYa0/LOgvoDfd24CeAt3KzE4Ah/UI6JHshbJMGBdNz7leUXLwTY+9WgZJ6/Zc/Rs2 0SWo+Ap6WD60Wa0gm12Ye7Q4mboBZlsSvxxLKY6L65/q/rGFCtyhjZ1J9eoTw3y8DLeN PQsj0c9ze5tWLZVMG5abnpGFcvHwkthd2d98CsbuKA7X72kA4HTqZHKY6BE7NF7eSrJi xJtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=kknWU6Tvqv/EzCijm0KZo71tRPCvAwDRYVXv6748kDE=; b=H4Hta2kSRuMjph7sLeGr9U7slFthAx6IhxrtQZUIgK1CrcSWTsHp0CaLQ8cREmlcS7 Sthy3Vs/BZMW0N610WSoSYaQiJ9owUWMyzEvI847KqDz4rUvM+vsJdJ9KWGCyY+Kzp2e LixL/PknQuUDQJLx7QagyxvyKgU1/lYbC5aWwbMW/bhqcCKsQOEnoqsLj9Au7opkZdAy Nwy0V/pjiLBPwNGBsQUzsFwL2tpcT48JokEYSW8JHTTJFN/5zxFm8UwqYHhiIsRSGZ3n tcR1TW5llaz5S8TTqkO87Z71JfiyfvqBLXCXVpMIrGtUFJ1g6FeKlNb0hLHn+OwSulTL Sv7w== MIME-Version: 1.0 Received: by 10.194.108.106 with SMTP id hj10mr735203wjb.10.1355439104348; Thu, 13 Dec 2012 14:51:44 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 14:51:44 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> Date: Thu, 13 Dec 2012 14:51:44 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=047d7bf10b2c5450bb04d0c3c2db X-Gm-Message-State: ALoCoQkOycWj5nrXYqr81GosFq2xWg+U4bMFGTHgi3oIIieYXOV+OlALN7CXm/4k5a06MjPDJuBsntB1OqbutULUog4eAZU/OZEUJmxVs+yG4aAFZ6pFN7ZphNQGd/8WFWRWECjYV8aJx4z/h3UUUeo9ztjizrxDNLDOjC+u4vHSu+G9NlLUpcejPvQG+OjPKRSo0HhsAzAA Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:51:46 -0000 --047d7bf10b2c5450bb04d0c3c2db Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings wrote: > In short, I think my suggestion addresses points (1) and (3) - the > client simplicity is cut down because there's not 'fallback' which was > the main sore-spot. And half or more of (2) > But your proposal says servers MUST do both HTTP and HTTPS. Once you're saying that HTTPS is required, what's the advantage of allowing clients to do HTTP? Why not just say HTTPS-only on both sides? The opponents to HTTPS aren't concerned about client-HTTPS, just server-HTTPS. (I still think HTTPS-only is the simplest proposal.) --047d7bf10b2c5450bb04d0c3c2db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings <nick@silverbucket.net> wrote:
In short, I think= my suggestion addresses points (1) and (3) - the
client simplicity is cut down because there's not 'fallback' wh= ich was
the main sore-spot. And half or more of (2)

=
But your proposal says servers MUST do both HTTP and HTTPS. =C2=A0Once= you're saying that HTTPS is required, what's the advantage of allo= wing clients to do HTTP? =C2=A0Why not just say HTTPS-only on both sides?

The opponents to HTTPS aren't concerned about clien= t-HTTPS, just server-HTTPS.

(I still think HTTPS-o= nly is the simplest proposal.)

--047d7bf10b2c5450bb04d0c3c2db-- From nick@silverbucket.net Thu Dec 13 14:59:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4707321F8B0C for ; Thu, 13 Dec 2012 14:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1bVCrYl03bN for ; Thu, 13 Dec 2012 14:59:05 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02A4121F8BCE for ; Thu, 13 Dec 2012 14:59:04 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2230979lah.31 for ; Thu, 13 Dec 2012 14:59:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=QRL+4ysmG6anPCt2CUeqQh6Kydm63tHGfEJMaLEQ4Zo=; b=WW5aTBnYJZpJZrZopj+f/AbJPVtDmPj8Uhn7LwKPcRifBYMj4uAjLndyObNJRCY6Wk oEzY/3kAkZX3xlpPwMcdVPXgxC+Rz0nHeosLyrQIL8/tu0y7EA8kdoarKsFODyhErzQS yZ8mYUgEVHlOcAZGnacAXMjPP1e1CoXn5u1D4gCOZZQ0ryenYza6Zy+6JgZtK4+iQ5CU +TaXYpMaB+70MZ2qphWTPlj9MAu3LI6Cu0rd1IIBESlyy2OZtyE1t94LRjvpNvJufjeU cLr5r5q/eCT9Xb3CGJIhUB+QwsPM7q+zt4MYrycj1t6hLWZ7DxGv2I1gQvIYQzXzP850 dabw== Received: by 10.152.132.137 with SMTP id ou9mr816582lab.7.1355439543948; Thu, 13 Dec 2012 14:59:03 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id sj3sm1155578lab.2.2012.12.13.14.59.02 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 14:59:03 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2245822lbk.31 for ; Thu, 13 Dec 2012 14:59:02 -0800 (PST) Received: by 10.152.105.103 with SMTP id gl7mr749556lab.10.1355439542713; Thu, 13 Dec 2012 14:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 14:58:31 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> From: Nick Jennings Date: Thu, 13 Dec 2012 23:58:31 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkFuMXKLllvYMDON9yXggXp0akM+CGsAt6PtSvUcY42hJyBRYG2evJbLshN9ptDjyECwtF2 Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:59:06 -0000 On Thu, Dec 13, 2012 at 11:51 PM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings > wrote: >> >> In short, I think my suggestion addresses points (1) and (3) - the >> client simplicity is cut down because there's not 'fallback' which was >> the main sore-spot. And half or more of (2) > > > But your proposal says servers MUST do both HTTP and HTTPS. Once you're > saying that HTTPS is required, what's the advantage of allowing clients to > do HTTP? Why not just say HTTPS-only on both sides? > > The opponents to HTTPS aren't concerned about client-HTTPS, just > server-HTTPS. > > (I still think HTTPS-only is the simplest proposal.) > So, instead of HTTPS and HTTP... We REQUIRE HTTP and require HTTPS for sending any secure information? No fallback, no downgrading/upgrading. If you want to serve any secure-data, that data will be queried against HTTPS, so if you don't want to play with certs, then you don't get to provide secure-data for your users. From laurentwalter.goix@telecomitalia.it Thu Dec 13 15:05:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA621F8B82 for ; Thu, 13 Dec 2012 15:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIpRzx4S9dlu for ; Thu, 13 Dec 2012 15:05:00 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9004621F8B0C for ; Thu, 13 Dec 2012 15:04:59 -0800 (PST) Content-Type: multipart/mixed; boundary="_200877e3-8f8d-4f24-b30c-f98d37c42141_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 14 Dec 2012 00:04:51 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 14 Dec 2012 00:04:50 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Fri, 14 Dec 2012 00:04:44 +0100 Thread-Topic: [webfinger] secure links with https rels Thread-Index: Ac3ZhkE0xurC01wRRVWU4glnupWShg== Message-ID: <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <50CA5960.2030807@openlinksw.com> In-Reply-To: <50CA5960.2030807@openlinksw.com> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Brad Fitzpatrick , James M Snell , "webfinger@googlegroups.com" , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:05:05 -0000 --_200877e3-8f8d-4f24-b30c-f98d37c42141_ Content-Type: multipart/alternative; boundary="_000_695443B7917E4E4C9231F32FB160D2ADtelecomitaliait_" --_000_695443B7917E4E4C9231F32FB160D2ADtelecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZSdyZSBhbGwgbG9vc2luZyBmb2N1cyB3aXRoIHRoaXMgdGhyZWFkLi4uLg0KV2h5 IG5vdCBzaW1wbHkgc3RhdGUgdGhhdDoNCi0gc2VydmVycyBtdXN0IHN1cHBvcnQgaHR0cCBhbmQg c2hvdWxkIHN1cHBvcnQgaHR0cHMNCi0gY2xpZW50cyBzaG91bGQgdHJ5IGh0dHBzIGZpcnN0IChi dXQgbWF5IGhhdmUgb3B0aW9ucyBub3QgdG8gZG8gaXQgZm9yIHNwZWNpZmljIHB1cnBvc2VzKQ0K LSBzZXJ2ZXJzIG11c3Qgbm90IGluY2x1ZGUgJ3NlY3VyZScgKmhyZWYqIG92ZXIgcGxhaW4gaHR0 cCArIGNsaWVudHMgbXVzdCBpZ25vcmUgdGhvc2UgaHJlZnMgaWYgcHJlc2VudCBhbnl3YXkgKHRv IGF2b2lkIHRoZSBhdHRhY2sgc3VnZ2VzdGVkIGVhcmxpZXIpDQoNClRoaXMgSSBiZWxpZXZlIGFj Y29tbW9kYXRlcyBhbGw6DQotIHdlIGRvbid0IG1lbnRpb24gZmFsbGJhY2sgZXhwbGljaXRseS4g Q2xpZW50cyBtYXkgZmFsbGJhY2sgc2luY2Ugc2VydmVycyBtYXkgbm90IHN1cHBvcnQgaHR0cHMg YnV0IGtub3cgdGhhdCBpbiB0aGF0IGNhc2Ugd29uJ3QgZ2V0IGFueSBzZWN1cmUgaHJlZiAoaW1w bGllZDogd29uJ3QgcHJvYmFibHkgZ2V0IHRob3NlIHJlbHMgdGhhdCBhcmUgc2Vuc2l0aXZlIGxp a2Ugb2F1dGggb3Igb3BlbmlkIGNvbm5lY3QgZW5kcG9pbnRzIGV0YykuDQotIHdlIGRvbid0IG1l bnRpb24gdGhlIGNvbmNlcHQgb2Ygc2VjdXJlIGxpbmsgcmVscyBidXQgc2VjdXJlIGhyZWYNCi0g cGxhaW4gaHR0cCBzb2x1dGlvbiBzdGlsbCB3b3JrcyBhbmQgaXQgaXMgY2xlYXIgdGhhdCBpdCBk b2VzIG5vdCByZXR1cm4gc2VjdXJlIGVuZHBvaW50cyAoSSBkb24ndCB0aGluayBhbnlvbmUgd2Fu dHMgdGhpcykNCi0gaHR0cHMgaXMgc3RpbGwgcmVjb21tZW5kZWQgYXQgZmlyc3QgaGl0IHRvIGdl dCBhIG1heGltdW0gbnVtYmVyIG9mIHJlbHMNCi0gaHR0cHMgcXVlcmllcyBhcmUgbm90IGxpbWl0 ZWQgdG8gcmV0dXJuIHNlY3VyZSBsaW5rcyBvbmx5IGJ1dCBhbnkuLi4NCi0gc2VjdXJlIGxpbmsg ZmlsdGVyaW5nIG92ZXIgcGxhaW4gaHR0cCBpcyBlbnN1cmVkIGJvdGggYXQgc2VydmVyIGFuZCBj bGllbnQgc2lkZQ0KDQpXYWx0ZXINCg0KTGUgMTMgZMOpYy4gMjAxMiDDoCAyMzo0MCwgIktpbmdz bGV5IElkZWhlbiIgPGtpZGVoZW5Ab3Blbmxpbmtzdy5jb208bWFpbHRvOmtpZGVoZW5Ab3Blbmxp bmtzdy5jb20+PiBhIMOpY3JpdCA6DQoNCk9uIDEyLzEzLzEyIDU6MzUgUE0sIEJyYWQgRml0enBh dHJpY2sgd3JvdGU6DQpPbiBUaHUsIERlYyAxMywgMjAxMiBhdCAyOjMyIFBNLCBOaWNrIEplbm5p bmdzIDxuaWNrQHNpbHZlcmJ1Y2tldC5uZXQ8bWFpbHRvOm5pY2tAc2lsdmVyYnVja2V0Lm5ldD4+ IHdyb3RlOg0KPg0KPiBIVFRQUy1vbmx5IG1ha2VzIHRoaXMgYWxsIGVhc2llci4NCj4NCj4gSWYg d2Ugd2FudCB0byBhbGxvdyBIVFRQLCB3ZSBuZWVkIG1vcmUgY29tcGxleGl0eSBpbiB0aGUgY2xp ZW50Lg0KPg0KDQpXaHkgbm90IEhUVFBTIGFuZCBIVFRQIGZvciB0aGUgc2VydmVyPyAobm90IGVp dGhlci1vcikNCg0KVGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBlb3BsZSBvbiB0aGlzIGxpc3Qgd2hv IHdhbnQgdG8gcnVuIFdlYkZpbmdlciBzZXJ2ZXJzIG92ZXIgSFRUUCB3aXRob3V0IHRoZSBwYWlu IGFuZCBleHBlbnNlIG9mIHNldHRpbmcgdXAgSFRUUFMuICBIVFRQIGZhbGxiYWNrIHdhcyBhIGNv bXByb21pc2UgZm9yIHRoZW0uDQorMQ0KDQpWZXJ5IGltcG9ydGFudC4gVGhlIFdlYiBpcyBpbmhl cmVudGx5IGxvb3NlbHkgY291cGxlZCwgd2UgaGF2ZSB0byBrZWVwIGl0IHRoYXQgd2F5Lg0KDQoN Ci0tDQoNClJlZ2FyZHMsDQoNCktpbmdzbGV5IElkZWhlbg0KRm91bmRlciAmIENFTw0KT3Blbkxp bmsgU29mdHdhcmUNCkNvbXBhbnkgV2ViOiBodHRwOi8vd3d3Lm9wZW5saW5rc3cuY29tDQpQZXJz b25hbCBXZWJsb2c6IGh0dHA6Ly93d3cub3Blbmxpbmtzdy5jb20vYmxvZy9+a2lkZWhlbg0KVHdp dHRlci9JZGVudGkuY2E8aHR0cDovL0lkZW50aS5jYT4gaGFuZGxlOiBAa2lkZWhlbg0KR29vZ2xl KyBQcm9maWxlOiBodHRwczovL3BsdXMuZ29vZ2xlLmNvbS8xMTIzOTk3Njc3NDA1MDg2MTgzNTAv YWJvdXQNCkxpbmtlZEluIFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL2tpZGVo ZW4NCg0KDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBp bmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1 c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29u b3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRl LiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNp ZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25l IGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll Lg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lk OjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEg bCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3Nhcmlv Lg0KDQo= --_000_695443B7917E4E4C9231F32FB160D2ADtelecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkkgdGhpbmsgd2UncmUgYWxsIGxvb3NpbmcgZm9jdXMgd2l0aCB0aGlzIHRocmVhZC4uLi48 L2Rpdj4NCjxkaXY+V2h5IG5vdCBzaW1wbHkgc3RhdGUgdGhhdDo8L2Rpdj4NCjxkaXY+LSBzZXJ2 ZXJzIG11c3Qgc3VwcG9ydCBodHRwIGFuZCBzaG91bGQgc3VwcG9ydCBodHRwczwvZGl2Pg0KPGRp dj4tIGNsaWVudHMgc2hvdWxkIHRyeSBodHRwcyBmaXJzdCAoYnV0IG1heSBoYXZlIG9wdGlvbnMg bm90IHRvIGRvIGl0IGZvciBzcGVjaWZpYyBwdXJwb3Nlcyk8L2Rpdj4NCjxkaXY+LSBzZXJ2ZXJz IG11c3Qgbm90IGluY2x1ZGUgJ3NlY3VyZScgKmhyZWYqIG92ZXIgcGxhaW4gaHR0cCAmIzQzOyBj bGllbnRzIG11c3QgaWdub3JlIHRob3NlIGhyZWZzIGlmIHByZXNlbnQgYW55d2F5ICh0byBhdm9p ZCB0aGUgYXR0YWNrIHN1Z2dlc3RlZCBlYXJsaWVyKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhpcyBJIGJlbGlldmUgYWNjb21tb2RhdGVzIGFsbDo8L2Rpdj4NCjxkaXY+LSB3ZSBk b24ndCBtZW50aW9uIGZhbGxiYWNrIGV4cGxpY2l0bHkuIENsaWVudHMgbWF5IGZhbGxiYWNrIHNp bmNlIHNlcnZlcnMgbWF5IG5vdCBzdXBwb3J0IGh0dHBzIGJ1dCBrbm93IHRoYXQgaW4gdGhhdCBj YXNlIHdvbid0IGdldCBhbnkgc2VjdXJlIGhyZWYgKGltcGxpZWQ6IHdvbid0IHByb2JhYmx5IGdl dCB0aG9zZSByZWxzIHRoYXQgYXJlIHNlbnNpdGl2ZSBsaWtlIG9hdXRoIG9yIG9wZW5pZCBjb25u ZWN0IGVuZHBvaW50cyBldGMpLjwvZGl2Pg0KPGRpdj4tIHdlIGRvbid0IG1lbnRpb24gdGhlIGNv bmNlcHQgb2Ygc2VjdXJlIGxpbmsgcmVscyBidXQgc2VjdXJlIGhyZWY8L2Rpdj4NCjxkaXY+LSBw bGFpbiBodHRwIHNvbHV0aW9uIHN0aWxsIHdvcmtzIGFuZCBpdCBpcyBjbGVhciB0aGF0IGl0IGRv ZXMgbm90IHJldHVybiBzZWN1cmUgZW5kcG9pbnRzIChJIGRvbid0IHRoaW5rIGFueW9uZSB3YW50 cyB0aGlzKTwvZGl2Pg0KPGRpdj4tIGh0dHBzIGlzIHN0aWxsIHJlY29tbWVuZGVkIGF0IGZpcnN0 IGhpdCB0byBnZXQgYSBtYXhpbXVtIG51bWJlciBvZiByZWxzPC9kaXY+DQo8ZGl2Pi0gaHR0cHMg cXVlcmllcyBhcmUgbm90IGxpbWl0ZWQgdG8gcmV0dXJuIHNlY3VyZSBsaW5rcyBvbmx5IGJ1dCBh bnkuLi48L2Rpdj4NCjxkaXY+LSBzZWN1cmUgbGluayBmaWx0ZXJpbmcgb3ZlciBwbGFpbiBodHRw IGlzIGVuc3VyZWQgYm90aCBhdCBzZXJ2ZXIgYW5kIGNsaWVudCBzaWRlPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5XYWx0ZXI8YnI+DQo8YnI+DQpMZSAxMyBkw6ljLiAyMDEyIMOgIDIz OjQwLCAmcXVvdDtLaW5nc2xleSBJZGVoZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpraWRl aGVuQG9wZW5saW5rc3cuY29tIj5raWRlaGVuQG9wZW5saW5rc3cuY29tPC9hPiZndDsgYSDDqWNy aXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXY+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDEyLzEzLzEyIDU6MzUgUE0sIEJy YWQgRml0enBhdHJpY2sgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6 Q0FBa1RwQ3EwX3FtWkJwSHRqdW0zV2VNSm1SRlo0QlBpWTF3OVI4YVp1T1JaQUdwREx3QG1haWwu Z21haWwuY29tIiB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6DQogICAgICAgIDEwcHQiPg0KT24gVGh1 LCBEZWMgMTMsIDIwMTIgYXQgMjozMiBQTSwgTmljayBKZW5uaW5ncyA8c3BhbiBkaXI9Imx0ciI+ Jmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOm5pY2tAc2lsdmVyYnVj a2V0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm5pY2tAc2lsdmVyYnVja2V0Lm5ldDwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGNsYXNz PSJIT0VuWmIiPg0KPGRpdiBjbGFzcz0iaDUiPiZndDs8YnI+DQomZ3Q7IEhUVFBTLW9ubHkgbWFr ZXMgdGhpcyBhbGwgZWFzaWVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHdlIHdhbnQgdG8gYWxs b3cgSFRUUCwgd2UgbmVlZCBtb3JlIGNvbXBsZXhpdHkgaW4gdGhlIGNsaWVudC48YnI+DQomZ3Q7 PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCldoeSBub3QgSFRUUFMgYW5kIEhUVFAgZm9yIHRo ZSBzZXJ2ZXI/IChub3QgZWl0aGVyLW9yKTxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy Pg0KPGRpdj5UaGVyZSBhcmUgYSBudW1iZXIgb2YgcGVvcGxlIG9uIHRoaXMgbGlzdCB3aG8gd2Fu dCB0byBydW4gV2ViRmluZ2VyIHNlcnZlcnMgb3ZlciBIVFRQIHdpdGhvdXQgdGhlIHBhaW4gYW5k IGV4cGVuc2Ugb2Ygc2V0dGluZyB1cCBIVFRQUy4gJm5ic3A7SFRUUCBmYWxsYmFjayB3YXMgYSBj b21wcm9taXNlIGZvciB0aGVtLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQomIzQzOzE8 YnI+DQo8YnI+DQpWZXJ5IGltcG9ydGFudC4gVGhlIFdlYiBpcyBpbmhlcmVudGx5IGxvb3NlbHkg Y291cGxlZCwgd2UgaGF2ZSB0byBrZWVwIGl0IHRoYXQgd2F5Lg0KPGJyPg0KPGJyPg0KPHByZSBj bGFzcz0ibW96LXNpZ25hdHVyZSIgY29scz0iNzIiPi0tIA0KDQpSZWdhcmRzLA0KDQpLaW5nc2xl eSBJZGVoZW4JICAgICAgDQpGb3VuZGVyICZhbXA7IENFTyANCk9wZW5MaW5rIFNvZnR3YXJlICAg ICANCkNvbXBhbnkgV2ViOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwOi8vd3d3Lm9wZW5saW5rc3cuY29tIj5odHRwOi8vd3d3Lm9wZW5saW5rc3cuY29tPC9hPg0K UGVyc29uYWwgV2VibG9nOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwOi8vd3d3Lm9wZW5saW5rc3cuY29tL2Jsb2cvfmtpZGVoZW4iPmh0dHA6Ly93d3cub3Blbmxp bmtzdy5jb20vYmxvZy9+a2lkZWhlbjwvYT4NClR3aXR0ZXIvPGEgaHJlZj0iaHR0cDovL0lkZW50 aS5jYSI+SWRlbnRpLmNhPC9hPiBoYW5kbGU6IEBraWRlaGVuDQpHb29nbGUmIzQzOyBQcm9maWxl OiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3BsdXMuZ29v Z2xlLmNvbS8xMTIzOTk3Njc3NDA1MDg2MTgzNTAvYWJvdXQiPmh0dHBzOi8vcGx1cy5nb29nbGUu Y29tLzExMjM5OTc2Nzc0MDUwODYxODM1MC9hYm91dDwvYT4NCkxpbmtlZEluIFByb2ZpbGU6IDxh IGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cubGlua2VkaW4u Y29tL2luL2tpZGVoZW4iPmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL2tpZGVoZW48L2E+DQoN Cg0KDQoNCjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiPg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5 ZXM7fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5 Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFy aWFsOyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lk dGg9IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBl IGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVy c29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBh emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGln bj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdC Ij5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8 c3BhbiBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHku IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2Ug aXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2Ug dGhlIHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bh bj48L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpW ZXJkYW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJ LkRpc2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9 IjQwIj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9u IMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_695443B7917E4E4C9231F32FB160D2ADtelecomitaliait_-- --_200877e3-8f8d-4f24-b30c-f98d37c42141_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_200877e3-8f8d-4f24-b30c-f98d37c42141_-- From nick@silverbucket.net Thu Dec 13 15:09:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2121F8A97 for ; Thu, 13 Dec 2012 15:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.008 X-Spam-Level: X-Spam-Status: No, score=-3.008 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbqv6gssslSP for ; Thu, 13 Dec 2012 15:09:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65C21F8BD1 for ; Thu, 13 Dec 2012 15:09:10 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2236413lah.31 for ; Thu, 13 Dec 2012 15:09:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=hRWioDalgB7tepmW+yAXLhFfjeHW1+SEGYL7Op2uFZU=; b=YDJ4Wh+dW8g0MtjyKgwYbMYHmk9S8eUxlkMWARG/Z3RbTKOkst9lkMh+ZAbMvEpV7j mHHEaeqAJ1xOUzAavL4cLdonuaiS4hQz5bH4aGDH/hwFlVBJ+jIEua902NRQ/LmHt5Qb FIuDIstPvuQvLXBfiXEQGSJLwicPOAIj2eZvFz3XlLOcEkLVz00KC5ixmBuqDvDUuPUw IgCC9V1um9WW8lGprbalUsDVJ5W15mllipQUSMZSgfcYekU4YBumqgRACjtLJ4Iu0iks OpyOCPBhYfxPhdAP8Qoe7gLRs1Up6JLV1oqRAJndhd3XT31s4m+sAFtOU6eWn2XWJqAy zfiA== Received: by 10.112.42.197 with SMTP id q5mr1588544lbl.9.1355440148010; Thu, 13 Dec 2012 15:09:08 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id n7sm1234023lbg.3.2012.12.13.15.09.07 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 15:09:07 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2251209lbk.31 for ; Thu, 13 Dec 2012 15:09:06 -0800 (PST) Received: by 10.152.106.4 with SMTP id gq4mr700981lab.44.1355440146741; Thu, 13 Dec 2012 15:09:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 15:08:36 -0800 (PST) In-Reply-To: <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <50CA5960.2030807@openlinksw.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> From: Nick Jennings Date: Fri, 14 Dec 2012 00:08:36 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04083e0f75fa1404d0c400c8 X-Gm-Message-State: ALoCoQltVAZc4w3rPRL3QBfZdBFTXr21h8R9sKDeOYO1CSP97y2Om6C3wFQ0+UTp/tpu05OQrvOA Cc: "webfinger@ietf.org" , Brad Fitzpatrick , James M Snell , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:09:15 -0000 --f46d04083e0f75fa1404d0c400c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 that's what I just suggested in a different thread. I think it makes the most sense, keeps things flexible AND secure, and makes servers /want/ to setup HTTPS in order to participate in providing secure data On Fri, Dec 14, 2012 at 12:04 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > I think we're all loosing focus with this thread.... > Why not simply state that: > - servers must support http and should support https > - clients should try https first (but may have options not to do it for > specific purposes) > - servers must not include 'secure' *href* over plain http + clients must > ignore those hrefs if present anyway (to avoid the attack suggested earli= er) > > This I believe accommodates all: > - we don't mention fallback explicitly. Clients may fallback since server= s > may not support https but know that in that case won't get any secure hre= f > (implied: won't probably get those rels that are sensitive like oauth or > openid connect endpoints etc). > - we don't mention the concept of secure link rels but secure href > - plain http solution still works and it is clear that it does not return > secure endpoints (I don't think anyone wants this) > - https is still recommended at first hit to get a maximum number of rels > - https queries are not limited to return secure links only but any... > - secure link filtering over plain http is ensured both at server and > client side > > Walter > > Le 13 d=C3=A9c. 2012 =C3=A0 23:40, "Kingsley Idehen" a > =C3=A9crit : > > On 12/13/12 5:35 PM, Brad Fitzpatrick wrote: > > On Thu, Dec 13, 2012 at 2:32 PM, Nick Jennings wr= ote: > >> > >> > HTTPS-only makes this all easier. >> > >> > If we want to allow HTTP, we need more complexity in the client. >> > >> >> Why not HTTPS and HTTP for the server? (not either-or) >> > > There are a number of people on this list who want to run WebFinger > servers over HTTP without the pain and expense of setting up HTTPS. HTTP > fallback was a compromise for them. > > +1 > > Very important. The Web is inherently loosely coupled, we have to keep it > that way. > > -- > > Regards, > > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > --f46d04083e0f75fa1404d0c400c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 that's what I just suggested in a different thread. I think it makes= the most sense, keeps things flexible AND secure, and makes servers /want/= to setup HTTPS in order to participate in providing secure data


On Fri, Dec 14, 2012 at 12:04 AM, Goix Laure= nt Walter <laurentwalter.goix@telecomitalia.it> wrote:
I think we're all loosing focus with this thread....
Why not simply state that:
- servers must support http and should support https
- clients should try https first (but may have options not to do it fo= r specific purposes)
- servers must not include 'secure' *href* over plain http + c= lients must ignore those hrefs if present anyway (to avoid the attack sugge= sted earlier)

This I believe accommodates all:
- we don't mention fallback explicitly. Clients may fallback since= servers may not support https but know that in that case won't get any= secure href (implied: won't probably get those rels that are sensitive= like oauth or openid connect endpoints etc).
- we don't mention the concept of secure link rels but secure href=
- plain http solution still works and it is clear that it does not ret= urn secure endpoints (I don't think anyone wants this)
- https is still recommended at first hit to get a maximum number of r= els
- https queries are not limited to return secure links only but any...=
- secure link filtering over plain http is ensured both at server and = client side

Walter

Le 13 d=C3=A9c. 2012 =C3=A0 23:40, "Kingsley Idehen" <kidehen@openlinksw.com= > a =C3=A9crit=C2=A0:

On 12/13/12 5:35 PM, Brad Fitzpatrick wrote:
+1

Very important. The Web is inherently loosely coupled, we have to keep it t= hat way. 

--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle=
: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen
Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=C2=A0is= =C2=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =C3=A8 necessario.


--f46d04083e0f75fa1404d0c400c8-- From bradfitz@google.com Thu Dec 13 15:11:00 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1721F8BEF for ; Thu, 13 Dec 2012 15:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnrLIfWOsqvL for ; Thu, 13 Dec 2012 15:10:59 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2078021F8BEB for ; Thu, 13 Dec 2012 15:10:58 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1257424wey.31 for ; Thu, 13 Dec 2012 15:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hKwv5Ypx8tk6VbCfJhsxIlhxIG8kGtTbgV6oQ8FDJN0=; b=nvAAMvhhEQXyN1Y3nejOBX1nSSnbrs87tInOkxIoT6jdcrgTwoxikgmOAWOCs30yhF cdKLrjGHmI/yDq9qYKgHgrLxteGccdvH+rswuuCC3D4RhKF7XnnRI4xkqvXmkrV89dOD 3iN2iviXi3GRB3Lfrc/W2Lzry36PBE1P+oae6hmOmBvXZCsgb3coNhl6vWfYiRIMNMiT fObsmQVAFbVEMUCR/bWhwswIjKRQQaMmsKmgH/oi7iMUfJuzkB+xqMrREycTXxX6uA3O Fv7PQoEklaMXICjsXL1MQ3p43M+pbRE4/4fLagmqLdWYM7Q38aDL95m+WPJJ61tBW13X xoWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hKwv5Ypx8tk6VbCfJhsxIlhxIG8kGtTbgV6oQ8FDJN0=; b=OGZLwERgbwViR+Jz8nHLOYcgu7Rj5ErS4B//wz9zD/p8j7ZqXxGeGEcZba/6NL0SPH 20i99zGfZOozKfZVznljzbSzIxtWxOQoG5L943/enX1WlEk6qcyQzYKdQyiss7puqU/f cQcxOl59pzx9YkNrfwdtW+NjRtFJoOVHqyGWaEB5PTvlIi4NXlnP+6ofD3mkBkCZhsEl fYff7VrmwqSvd+56Dqzcwr80b9yBsY6qzRn7xpzXFFURCtG5M6KF8Ums9GITtviuORNk jVNJiZHFBmg4ovOZ1s76rdz5H41lMkHLaZw49X2PPkKYqp/NxUh0rfs/l5Bu/1FD8ApV 046Q== MIME-Version: 1.0 Received: by 10.180.109.132 with SMTP id hs4mr6019164wib.1.1355440258273; Thu, 13 Dec 2012 15:10:58 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 15:10:58 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> Date: Thu, 13 Dec 2012 15:10:58 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=e89a8f2355c71bd30004d0c407c9 X-Gm-Message-State: ALoCoQmWlox+vOnooKNROW85Smbywx+827pQRZnZgVwNKDgOcIclZNB8dEG8l+14xN9lCTmfiCujFCqwCXSOjZEGrmGwpJdjHhIneAjjMPJUv5bnDgiHImxlRSVzPrV329417tm9lUkEvI3wU1kxNX6mGriv09FwhVn+fWHWuLlEzNzMc7DnRelIUcA8MSjo4SDQzahcY9T/ Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:11:00 -0000 --e89a8f2355c71bd30004d0c407c9 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 2:58 PM, Nick Jennings wrote: > On Thu, Dec 13, 2012 at 11:51 PM, Brad Fitzpatrick > wrote: > > On Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings > > wrote: > >> > >> In short, I think my suggestion addresses points (1) and (3) - the > >> client simplicity is cut down because there's not 'fallback' which was > >> the main sore-spot. And half or more of (2) > > > > > > But your proposal says servers MUST do both HTTP and HTTPS. Once you're > > saying that HTTPS is required, what's the advantage of allowing clients > to > > do HTTP? Why not just say HTTPS-only on both sides? > > > > The opponents to HTTPS aren't concerned about client-HTTPS, just > > server-HTTPS. > > > > (I still think HTTPS-only is the simplest proposal.) > > > > > So, instead of HTTPS and HTTP... We REQUIRE HTTP and require HTTPS for > sending any secure information? > requiring HTTP seems fine. HTTPS was already de-facto required for secure info, so no objections on this. > No fallback, no downgrading/upgrading. If you want to serve any > secure-data, that data will be queried against HTTPS, so if you don't > want to play with certs, then you don't get to provide secure-data for > your users. > With no fallback, clients now need to be configured, right? I believe the concern is that this is pushing security too far out. Also, what do you propose clients filter? --e89a8f2355c71bd30004d0c407c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Thu, Dec 13, 2012 at 2:58 PM, Nick Jen= nings <nick@silverbucket.net> wrote:
On T= hu, Dec 13, 2012 at 11:51 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
> On Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings <nick@silverbucket.net>
> wrote:
>>
>> In short, I think my suggestion addresses points (1) and (3) - the=
>> client simplicity is cut down because there's not 'fallbac= k' which was
>> the main sore-spot. And half or more of (2)
>
>
> But your proposal says servers MUST do both HTTP and HTTPS. =C2=A0Once= you're
> saying that HTTPS is required, what's the advantage of allowing cl= ients to
> do HTTP? =C2=A0Why not just say HTTPS-only on both sides?
>
> The opponents to HTTPS aren't concerned about client-HTTPS, just > server-HTTPS.
>
> (I still think HTTPS-only is the simplest proposal.)
>


So, instead of HTTPS and HTTP... We REQUIRE HTTP and require HT= TPS for
sending any secure information?

requiri= ng HTTP seems fine. =C2=A0HTTPS was already de-facto required for secure in= fo, so no objections on this.
=C2=A0
No fallback, no downgrading/upgrading. If you want to serve any
secure-data, that data will be queried against HTTPS, so if you don't want to play with certs, then you don't get to provide secure-data for<= br> your users.

With no fallback, clients n= ow need to be configured, right? =C2=A0I believe the concern is that this i= s pushing security too far out.

Also, what do = you propose clients filter?
--e89a8f2355c71bd30004d0c407c9-- From paulej@packetizer.com Thu Dec 13 15:11:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548B821F8BE8 for ; Thu, 13 Dec 2012 15:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aICXhGuXTP5u for ; Thu, 13 Dec 2012 15:11:38 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA421F8A97 for ; Thu, 13 Dec 2012 15:11:37 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDNBWUv017930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 18:11:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355440293; bh=FJG75KC3+EnGmwS6xGimJTwwAEpIB6qDaZ0evQh1sk8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=R/IMYU11tUb50ApKKw+GxKOfPea4Tcf22xyNh9GaledXOoY6MRygML6kFKHMvArsp uKG1bhZMTlJDWKiBW1Ay0B1dXvQ8QgrnYJfVtRMYQcp79iTfGTC1Ezf4IjKbt2zaCl QNkk/CqTUaHJOBpMJkBFKM9nLCM187ztsNdrYyLM= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <5! 0CA5960.2030807@openlin ksw.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> In-Reply-To: <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> Date: Thu, 13 Dec 2012 18:11:44 -0500 Message-ID: <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_07EF_01CDD95D.4F537D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCuu+2jAMEKZEhl9pFmWA= Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'James M Snell' , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:11:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07EF_01CDD95D.4F537D70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_07F0_01CDD95D.4F537D70" ------=_NextPart_001_07F0_01CDD95D.4F537D70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Walter, =20 No, this will not work. People want to have secure content and what is = secure might be determined by the server admin or user. One might = consider his avatar should be served over HTTPS only. =20 And people do not want to have to write clients that do fallback. =20 We either have to do HTTPS only or we have to live with the fact that = some client requests are going to fail if a WF provider does not provide = WF services over HTTPS. =20 So, 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS 2) Servers and clients MAY implement HTTP 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as secure since it allows for a MITM attack) 4) Servers MUST NOT redirect from HTTPS to HTTP =20 All works well, except for the case where you have an HTTPS-only client. = But, I bet that will be the majority of clients, which will then drive = the majority of the servers to support HTTPS. =20 Still, it leaves the option on the table for some clients and servers to = use HTTP if they wish. =20 Paul =20 From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it]=20 Sent: Thursday, December 13, 2012 6:05 PM To: webfinger@googlegroups.com Cc: webfinger@googlegroups.com; Brad Fitzpatrick; Paul E. Jones; James M = Snell; webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 I think we're all loosing focus with this thread.... Why not simply state that: - servers must support http and should support https - clients should try https first (but may have options not to do it for = specific purposes) - servers must not include 'secure' *href* over plain http + clients = must ignore those hrefs if present anyway (to avoid the attack suggested = earlier) =20 This I believe accommodates all: - we don't mention fallback explicitly. Clients may fallback since = servers may not support https but know that in that case won't get any = secure href (implied: won't probably get those rels that are sensitive = like oauth or openid connect endpoints etc). - we don't mention the concept of secure link rels but secure href - plain http solution still works and it is clear that it does not = return secure endpoints (I don't think anyone wants this) - https is still recommended at first hit to get a maximum number of = rels - https queries are not limited to return secure links only but any... - secure link filtering over plain http is ensured both at server and = client side =20 Walter Le 13 d=C3=A9c. 2012 =C3=A0 23:40, "Kingsley Idehen" = a =C3=A9crit : On 12/13/12 5:35 PM, Brad Fitzpatrick wrote: On Thu, Dec 13, 2012 at 2:32 PM, Nick Jennings = wrote: > > HTTPS-only makes this all easier. > > If we want to allow HTTP, we need more complexity in the client. > Why not HTTPS and HTTP for the server? (not either-or) =20 There are a number of people on this list who want to run WebFinger = servers over HTTP without the pain and expense of setting up HTTPS. = HTTP fallback was a compromise for them. +1 Very important. The Web is inherently loosely coupled, we have to keep = it that way.=20 --=20 =20 Regards, =20 Kingsley Idehen =20 Founder & CEO=20 OpenLink Software =20 Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen =20 =20 =20 =20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non = =C3=A8 necessario.=20 =20 ------=_NextPart_001_07F0_01CDD95D.4F537D70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Walter,

 

No, this will not work.=C2=A0 People want to have secure content and = what is secure might be determined by the server admin or user.=C2=A0 = One might consider his avatar should be served over HTTPS = only.

 

And people do not want to have to write clients that do = fallback.

 

We either have to do HTTPS only or we have to live with the = fact that some client requests are going to fail if a WF provider does = not provide WF services over HTTPS.

 

So,

1)      = Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS

2)      = Servers and clients MAY implement HTTP

3)      = Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as = secure since it allows for a MITM attack)

4)      = Servers MUST NOT redirect from HTTPS to HTTP

 

All works well, except for the case where you have an HTTPS-only = client.=C2=A0 But, I bet that will be the majority of clients, which = will then drive the majority of the servers to support = HTTPS.

 

Still, it leaves the option on the table for some clients and servers = to use HTTP if they wish.

 

Paul

 

From:= = Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] =
Sent: Thursday, December 13, 2012 6:05 PM
To: = webfinger@googlegroups.com
Cc: webfinger@googlegroups.com; = Brad Fitzpatrick; Paul E. Jones; James M Snell; = webfinger@ietf.org
Subject: Re: [webfinger] secure links with = https rels

 

I think = we're all loosing focus with this thread....

Why not simply state that:

- servers must support http and should support = https

- clients should try = https first (but may have options not to do it for specific = purposes)

- servers must = not include 'secure' *href* over plain http + clients must ignore those = hrefs if present anyway (to avoid the attack suggested = earlier)

 

This I believe accommodates = all:

- we don't mention = fallback explicitly. Clients may fallback since servers may not support = https but know that in that case won't get any secure href (implied: = won't probably get those rels that are sensitive like oauth or openid = connect endpoints etc).

- = we don't mention the concept of secure link rels but secure = href

- plain http solution = still works and it is clear that it does not return secure endpoints (I = don't think anyone wants this)

- https is still recommended at first hit to get a = maximum number of rels

- = https queries are not limited to return secure links only but = any...

- secure link = filtering over plain http is ensured both at server and client = side

 

Walter

Le 13 d=C3=A9c. 2012 =C3=A0 = 23:40, "Kingsley Idehen" <kidehen@openlinksw.com> a = =C3=A9crit :

On 12/13/12 5:35 PM, Brad Fitzpatrick = wrote:

On Thu, Dec = 13, 2012 at 2:32 PM, Nick Jennings <nick@silverbucket.net> = wrote:

>
> = HTTPS-only makes this all easier.
>
> If we want to allow = HTTP, we need more complexity in the = client.
>

Why not = HTTPS and HTTP for the server? (not = either-or)

 

There are a = number of people on this list who want to run WebFinger servers over = HTTP without the pain and expense of setting up HTTPS.  HTTP = fallback was a compromise for = them.

+1

Very important. The Web is inherently = loosely coupled, we have to keep it that way. = 


-- =

 
Regards,
 
Kingsley Idehen =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
Founder & CEO =

OpenLink Software=C2=A0=C2=A0=C2=A0=C2=A0 =

Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.co=
m/blog/~kidehen
Twitter/Identi.ca handle: =
@kidehen
Google+ Profile: https://plus=
.google.com/112399767740508618350/about
LinkedIn=
 Profile: http://www.linkedin.com/in/ki=
dehen
 
 
 
 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. =

= This e-mail and any attachments=  is = confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, Thanks.= =

= 3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =C3=A8 = necessario.=

 

------=_NextPart_001_07F0_01CDD95D.4F537D70-- ------=_NextPart_000_07EF_01CDD95D.4F537D70 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------=_NextPart_000_07EF_01CDD95D.4F537D70-- From bradfitz@google.com Thu Dec 13 15:15:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED6E21F8BED for ; Thu, 13 Dec 2012 15:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNJO79XRwlh3 for ; Thu, 13 Dec 2012 15:15:28 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE53521F8B7D for ; Thu, 13 Dec 2012 15:15:27 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1259091wey.31 for ; Thu, 13 Dec 2012 15:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dZwrSmeVnEwowWuK1lW47VJXZX2olMKxrUSgWN52FI=; b=UR54AYXz9DIozX+Zp7k5rJ+Lf8aEJaCTxST4ty+M7DNr7f6u/Sgtp5A7FbH92uZWuT CFfN0EyO1Xn3Mb7NA9aCqgxXKk+Gtz8F50Fifs17c1fsSFyMANVQoFboCFd/F3MCQQo4 gb2ag6eALOg8r3i74Zx7baEtiIj9jS+AGZDxlF++adknyXss+cdsu1cz2u0hrhrZ7J20 no8lhf1jys1nmkKe374rFrVAtJKJfJWE38NCo+KeGO52COwfsUiQ8JQniYOO+aPuzY6r uWBUKkKk+GZAYsJ09ACIMRuSUh1UvBezAnVzk4K3d1QO9ZTqM1UkGvEf1mYGcg9oxv6B z6eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+dZwrSmeVnEwowWuK1lW47VJXZX2olMKxrUSgWN52FI=; b=KCxYtlAzFpZK1T/o3v1DjjpJvhdLmC/LebkeOI5IDEjXrp+TBzLrjS2irjBzbUZ7oI 8k6moFe4JUvgI9khM3dj9tr84srOuyWzjh6c7YnqR65EoXqzaddpgZQWpOTQavZ4y4GL DHExFBaSlaQV9AEblzWY2HggNigzT/aeJgJwK7FqxUAH7L9ChyewvqH3dPWoEG3af3Qp j4Xn2kXeqgK0qbrqlPbA8bHYPta6Qt6MrCrVDH8UI9Tz6Ue1Kra/2wy6pKgc3jXv18fw 8AzhyhJuZoC3K9R1WkT3kJo35QJTbZ+PqNkdq++oEFTB6AUY57Las1dQpPsNhr7u/Gq7 RUVA== MIME-Version: 1.0 Received: by 10.180.86.39 with SMTP id m7mr31721765wiz.1.1355440526788; Thu, 13 Dec 2012 15:15:26 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 15:15:26 -0800 (PST) In-Reply-To: <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Thu, 13 Dec 2012 15:15:26 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04428e101d065004d0c417d0 X-Gm-Message-State: ALoCoQkPAx8jvKlewkErfIsA8ro2ROPyDC5bh/7Xt7Fox9l6si67Ctqk08IT2wuhSrzTUxO4ZLyui34ZZITB5P2j/uxSU+E5pcopQi9OO2U4Jv0g8uvN1CUuMDsFyoR4Reah2kpDVDUCrFbhwkU6eUMLD/BNbg4RFuw0Uk2CUXpKblUMTBAVuwiy4C71emWeGCe0hMJ2mkxd Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com, Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:15:29 -0000 --f46d04428e101d065004d0c417d0 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wrote: > Walter,**** > > ** ** > > No, this will not work. People want to have secure content and what is > secure might be determined by the server admin or user. One might consider > his avatar should be served over HTTPS only.**** > > ** ** > > And people do not want to have to write clients that do fallback. > I never saw any strong opposition against fallback. People disliked the extra complexity, but for quite awhile everybody assumed that fallback would be involved, and I think it was considered acceptable. Who was strongly anti-fallback? **** > > We either have to do HTTPS only *or* we have to live with the fact that > some client requests are going to fail if a WF provider does not provide WF > services over HTTPS. > I strongly disagree that those are the only two options. But if you really believe that, I hope you realize that flakiness is unacceptable, which leaves you with HTTPS-only. If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with HTTPS-only. > ** So, > > **1) **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS*** > * > > **2) **Servers and clients MAY implement HTTP**** > > **3) **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as secure since it allows for a MITM attack)**** > > **4) **Servers MUST NOT redirect from HTTPS to HTTP**** > > ** ** > > All works well, except for the case where you have an HTTPS-only client. > But, I bet that will be the majority of clients, which will then drive the > majority of the servers to support HTTPS. > This is a terrible cop-out. Flakiness in the spec is unacceptable. > **** > > ** Still, it leaves the option on the table for some clients and servers > to use HTTP if they wish. > --f46d04428e101d065004d0c417d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Walter,

=C2=A0

No, this will not w= ork.=C2=A0 People want to have secure content and what is secure might be d= etermined by the server admin or user.=C2=A0 One might consider his avatar = should be served over HTTPS only.

=C2=A0

And people do not w= ant to have to write clients that do fallback.


I never saw any strong opposit= ion against fallback. =C2=A0People disliked the extra complexity, but for q= uite awhile everybody assumed that fallback would be involved, and I think = it was considered acceptable.

Who was strongly anti-fallback?


=

We either have to do HTTPS only = or we have to live with the fact that some client requests are = going to fail if a WF provider does not provide WF services over HTTPS.


I strongly disagree that those are t= he only two options.

But if you really believe tha= t, I hope you realize that flakiness is unacceptable, which leaves you with= HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't cle= ar, I'd be happy with HTTPS-only.
=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0So,

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers SHOULD implement HTTPS and clie= nts SHOULD use HTTPS

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers and clients MAY implement HTTP<= u>

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MAY redirect from HTTP to HTTPS= (this MUST NOT be treated as secure since it allows for a MITM attack)<= /u>

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MUST NOT redirect from HTTPS to= HTTP

=C2=A0

All works well, exc= ept for the case where you have an HTTPS-only client.=C2=A0 But, I bet that= will be the majority of clients, which will then drive the majority of the= servers to support HTTPS.


This is a terrible cop-out. =C2=A0Fl= akiness in the spec is unacceptable.
=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0Still, it leaves the = option on the table for some clients and servers to use HTTP if they wish.<= /span>



--f46d04428e101d065004d0c417d0-- From nick@silverbucket.net Thu Dec 13 15:16:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941C521F8BED for ; Thu, 13 Dec 2012 15:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZFQSu6OgLFW for ; Thu, 13 Dec 2012 15:16:13 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF5321F8BEB for ; Thu, 13 Dec 2012 15:16:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2254849lbk.31 for ; Thu, 13 Dec 2012 15:16:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=f3uMYtUGrj5LqbfDGdlV9YL46MLKLMo8uygpKGmuL6Y=; b=MAol4XHIhxDidUxSNRzk/GkPAbmQlgaNrJ31VMxrtGH/pHbQaNuVwIaSszBtTgsESY iIaXgVsKl7fjAc9qMMQ3+l0MGjquIcxpVb1jQJaiLYGtU1mNpHHKRn9+o+HZJD3WusQ7 LWp1MhHIVZZBh/i/BDVZ9qPD35wjajRjep9GQwZUJvUBvtx4SWXfv/Ct8qAWL67UlmS5 Mc2PxfNB7m7FTJuw6MG5qqQUSzPWDoRalGGNAZh3rea3h6mbUha1hSPz0LTbs7dH6U9H mVncelauaIXTLhw8UkkclduDePusg1MZIbuDKNDMEXJDBrTrleZ9U1B0gNVwLCux1/jq 02Hw== Received: by 10.112.25.106 with SMTP id b10mr1520203lbg.68.1355440571419; Thu, 13 Dec 2012 15:16:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id n7sm1236290lbz.5.2012.12.13.15.16.10 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 15:16:10 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2240040lah.31 for ; Thu, 13 Dec 2012 15:16:10 -0800 (PST) Received: by 10.152.113.66 with SMTP id iw2mr778672lab.37.1355440570313; Thu, 13 Dec 2012 15:16:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Thu, 13 Dec 2012 15:15:39 -0800 (PST) In-Reply-To: References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> From: Nick Jennings Date: Fri, 14 Dec 2012 00:15:39 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmaN59+l+Zyxath5LQtbTvd/kXdLzoEaVkom5ibYhf6yrLYX/fwtBf9aAjtpgHb4t/QnOTX Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:16:13 -0000 On Fri, Dec 14, 2012 at 12:10 AM, Brad Fitzpatrick wrote: > > > On Thu, Dec 13, 2012 at 2:58 PM, Nick Jennings > wrote: >> >> On Thu, Dec 13, 2012 at 11:51 PM, Brad Fitzpatrick >> wrote: >> > On Thu, Dec 13, 2012 at 2:47 PM, Nick Jennings >> > wrote: >> >> >> >> In short, I think my suggestion addresses points (1) and (3) - the >> >> client simplicity is cut down because there's not 'fallback' which was >> >> the main sore-spot. And half or more of (2) >> > >> > >> > But your proposal says servers MUST do both HTTP and HTTPS. Once you're >> > saying that HTTPS is required, what's the advantage of allowing clients >> > to >> > do HTTP? Why not just say HTTPS-only on both sides? >> > >> > The opponents to HTTPS aren't concerned about client-HTTPS, just >> > server-HTTPS. >> > >> > (I still think HTTPS-only is the simplest proposal.) >> > >> >> >> So, instead of HTTPS and HTTP... We REQUIRE HTTP and require HTTPS for >> sending any secure information? > > > requiring HTTP seems fine. HTTPS was already de-facto required for secure > info, so no objections on this. > >> >> No fallback, no downgrading/upgrading. If you want to serve any >> secure-data, that data will be queried against HTTPS, so if you don't >> want to play with certs, then you don't get to provide secure-data for >> your users. > > > With no fallback, clients now need to be configured, right? I believe the > concern is that this is pushing security too far out. var links = webFinger.getAllLinks('user@example.com', {secure:true}); Something like that would be a real easy way to say "give me all links, including secure stuff". That would obviously default to HTTPS. var avatar = webFinger.getAvatar('user@example.com'); That would default to HTTP. > > Also, what do you propose clients filter? I don't know off-hand, the same way they'd have to do the filtering in your initial proposal? From jasnell@gmail.com Thu Dec 13 15:17:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEEF21F8B7D for ; Thu, 13 Dec 2012 15:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5xPqqM7sR0y for ; Thu, 13 Dec 2012 15:16:59 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD74221F8BD0 for ; Thu, 13 Dec 2012 15:16:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4996187ieb.31 for ; Thu, 13 Dec 2012 15:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i7sk0OZwfBzzQ/xubye0YA1hk+cvjtgBVL2Np2tiWQg=; b=L8P+EhwiUur9x5pmXKeP1ukcP2CZ09HYMVsDN+mQwsJK+u91D4a1KdzdL85ZCFK29v EOZJ3bJLCIBqn1gNa+znn1dZir5n7lHPUEzDDb+m39RmgJwMC2/VYwrWLAR4p3Hbo7CN qlVyu74rMeWyFu5YQO3s8BNaLsf4OASqApj1kXWrq6vuwlUbi9GrvSxZ6CvZoRm+bJgX NbAwgyDTgUh9JeDtlpylO/uZxS5LK/LHE9DfW1xDaKtX3mXO9nr+4KJo/sRn39B8zUsP ch9g9SBHS413OatAOxAeKIch0u+LB4IYUz7XF3TfP/xDfGLSD1phrEOI//doFfPA9Ai2 R+1w== Received: by 10.50.45.166 with SMTP id o6mr3513507igm.0.1355440618515; Thu, 13 Dec 2012 15:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 15:16:37 -0800 (PST) In-Reply-To: <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 15:16:37 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/related; boundary=14dae934035794ad9b04d0c41c31 Cc: Brad Fitzpatrick , "webfinger@googlegroups.com" , Goix Laurent Walter , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:17:03 -0000 --14dae934035794ad9b04d0c41c31 Content-Type: multipart/alternative; boundary=14dae934035794ad9a04d0c41c30 --14dae934035794ad9a04d0c41c30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... This also leaves the door open to the kind of integrity checking mechanism I suggested earlier to deal with the vulnerabilities in your #3. It's ok if some requests fail. HTTPS-to-HTTP fallback should NEVER be done. - James On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wrote= : > Walter,**** > > ** ** > > No, this will not work. People want to have secure content and what is > secure might be determined by the server admin or user. One might consid= er > his avatar should be served over HTTPS only.**** > > ** ** > > And people do not want to have to write clients that do fallback.**** > > ** ** > > We either have to do HTTPS only *or* we have to live with the fact that > some client requests are going to fail if a WF provider does not provide = WF > services over HTTPS.**** > > ** ** > > So,**** > > **1) **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS**= * > * > > **2) **Servers and clients MAY implement HTTP**** > > **3) **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as secure since it allows for a MITM attack)**** > > **4) **Servers MUST NOT redirect from HTTPS to HTTP**** > > ** ** > > All works well, except for the case where you have an HTTPS-only client. > But, I bet that will be the majority of clients, which will then drive th= e > majority of the servers to support HTTPS.**** > > ** ** > > Still, it leaves the option on the table for some clients and servers to > use HTTP if they wish.**** > > ** ** > > Paul**** > > ** ** > > *From:* Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] > *Sent:* Thursday, December 13, 2012 6:05 PM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@googlegroups.com; Brad Fitzpatrick; Paul E. Jones; James > M Snell; webfinger@ietf.org > > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > I think we're all loosing focus with this thread....**** > > Why not simply state that:**** > > - servers must support http and should support https**** > > - clients should try https first (but may have options not to do it for > specific purposes)**** > > - servers must not include 'secure' *href* over plain http + clients must > ignore those hrefs if present anyway (to avoid the attack suggested earli= er) > **** > > ** ** > > This I believe accommodates all:**** > > - we don't mention fallback explicitly. Clients may fallback since server= s > may not support https but know that in that case won't get any secure hre= f > (implied: won't probably get those rels that are sensitive like oauth or > openid connect endpoints etc).**** > > - we don't mention the concept of secure link rels but secure href**** > > - plain http solution still works and it is clear that it does not return > secure endpoints (I don't think anyone wants this)**** > > - https is still recommended at first hit to get a maximum number of rels= * > *** > > - https queries are not limited to return secure links only but any...***= * > > - secure link filtering over plain http is ensured both at server and > client side**** > > ** ** > > Walter > > Le 13 d=C3=A9c. 2012 =C3=A0 23:40, "Kingsley Idehen" a > =C3=A9crit :**** > > On 12/13/12 5:35 PM, Brad Fitzpatrick wrote:**** > > On Thu, Dec 13, 2012 at 2:32 PM, Nick Jennings > wrote:**** > > > > > HTTPS-only makes this all easier. > > > > If we want to allow HTTP, we need more complexity in the client. > >**** > > Why not HTTPS and HTTP for the server? (not either-or)**** > > ** ** > > There are a number of people on this list who want to run WebFinger > servers over HTTP without the pain and expense of setting up HTTPS. HTTP > fallback was a compromise for them.**** > > +1 > > Very important. The Web is inherently loosely coupled, we have to keep it > that way. > > > **** > > -- **** > > ** ** > > Regards,**** > > ** ** > > Kingsley Idehen **** > > Founder & CEO **** > > OpenLink Software **** > > Company Web: http://www.openlinksw.com**** > > Personal Weblog: http://www.openlinksw.com/blog/~kidehen**** > > Twitter/Identi.ca handle: @kidehen**** > > Google+ Profile: https://plus.google.com/112399767740508618350/about**** > > LinkedIn Profile: http://www.linkedin.com/in/kidehen**** > > ** ** > > ** ** > > ** ** > > ** ** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. **** > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* **** > > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* **** > > ** ** > --14dae934035794ad9a04d0c41c30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1... This also leaves the door open t= o the kind of integrity checking mechanism I suggested earlier to deal with= the vulnerabilities in your #3. It's ok if some requests fail. HTTPS-t= o-HTTP fallback should NEVER be done.


--14dae934035794ad9a04d0c41c30-- --14dae934035794ad9b04d0c41c31 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b4e314a4c0c5e9bf_0.1 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --14dae934035794ad9b04d0c41c31-- From tbray@textuality.com Thu Dec 13 15:17:50 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D911621F8BEB for ; Thu, 13 Dec 2012 15:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jUrVtZzv8J1 for ; Thu, 13 Dec 2012 15:17:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B35D821F8BD0 for ; Thu, 13 Dec 2012 15:17:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2681883obc.31 for ; Thu, 13 Dec 2012 15:17:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9oJ5wClaflGEFAmDXSHiZUtnOKRrHrxbKEkk76uEBn0=; b=Xvo0Ashqo2rC405rW3fa3A0jDoNtUJozEA+G/BxhCV0Zt3mZvAX35zgCDFPuS+dmtn weVMe9U3JztTbNwqqMCykFRSwY3ekZP8StTC8FPM4GWGH6w1Vf3d8Vh2MTb+Xj1lerfk UKiZ6+7ganil1yOkYGPWdpIGI9KTyYckaaGXmtlcDTbVcN+8RdC86rC4U25eJkZFT60w iCIRmU8H6BHBcbwJSQDfClq3Uxzi8L/MU1NvHAoZiDFB96ucZrmAOdbmCeBEDUpIeMZZ tmzGngw99s+aDfPG+FpHxLMePG3w83OWcJ3X+AnTRo+V3RuT9FbQjMnJePfOPsovRbv0 xdWw== MIME-Version: 1.0 Received: by 10.182.52.105 with SMTP id s9mr3097643obo.25.1355440666238; Thu, 13 Dec 2012 15:17:46 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 13 Dec 2012 15:17:46 -0800 (PST) X-Originating-IP: [96.49.76.76] In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Thu, 13 Dec 2012 15:17:46 -0800 Message-ID: From: Tim Bray To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=14dae93994296ce01204d0c41fc3 X-Gm-Message-State: ALoCoQnBFVpGofFET7II57AAdn25ZUJHRQZfxwf9MiMatKI7DbRJYd5kQpjbWCOvaUBoISn+1tRy Cc: "Paul E. Jones" , James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:17:51 -0000 --14dae93994296ce01204d0c41fc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick wrot= e: > On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wro= te: > > I never saw any strong opposition against fallback. People disliked the > extra complexity, but for quite awhile everybody assumed that fallback > would be involved, and I think it was considered acceptable. > > Who was strongly anti-fallback?'''' > Um, maybe me. What is unacceptable for some applications is if I tell the client =93Fetch https://example.com/.well-known/whatever=94 and for some re= ason it silently falls back to HTTP. -T > > > **** >> >> We either have to do HTTPS only *or* we have to live with the fact that >> some client requests are going to fail if a WF provider does not provide= WF >> services over HTTPS. >> > > I strongly disagree that those are the only two options. > > But if you really believe that, I hope you realize that flakiness is > unacceptable, which leaves you with HTTPS-only. > > If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with > HTTPS-only. > > >> ** So, >> >> **1) **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS*= * >> ** >> >> **2) **Servers and clients MAY implement HTTP**** >> >> **3) **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be >> treated as secure since it allows for a MITM attack)**** >> >> **4) **Servers MUST NOT redirect from HTTPS to HTTP**** >> >> ** ** >> >> All works well, except for the case where you have an HTTPS-only client. >> But, I bet that will be the majority of clients, which will then drive t= he >> majority of the servers to support HTTPS. >> > > This is a terrible cop-out. Flakiness in the spec is unacceptable. > > >> **** >> >> ** Still, it leaves the option on the table for some clients and servers >> to use HTTP if they wish. >> > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93994296ce01204d0c41fc3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Thu= , Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>= ; wrote:

I never saw any strong opposition again= st fallback. =A0People disliked the extra complexity, but for quite awhile = everybody assumed that fallback would be involved, and I think it was consi= dered acceptable.

Who was strongly anti-fallback?''''

Um, maybe me.=A0 What is unacceptable f= or some applications is if I tell the client =93Fetch https://example.com/.well-known/whatever=94 and for some reason it silently falls back to HTTP.=A0=A0 -T

=A0

<= /div>

=

We either have to do HTTPS only = or we have to live with the fact that some client requests are = going to fail if a WF provider does not provide WF services over HTTPS.


I strongly disagree that those are t= he only two options.

But if you really believe tha= t, I hope you realize that flakiness is unacceptable, which leaves you with= HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't cle= ar, I'd be happy with HTTPS-only.
=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0So,

1)=A0=A0=A0=A0=A0 Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS

2)=A0=A0=A0=A0=A0 Servers and clients MAY implement HTTP

3)=A0=A0=A0=A0=A0 Servers MAY redirect from HTTP to HTTPS (this MUST NOT= be treated as secure since it allows for a MITM attack)

4)=A0=A0=A0=A0=A0 Servers MUST NOT redirect from HTTPS to HTTP=

=A0<= /p>

All works well, except= for the case where you have an HTTPS-only client.=A0 But, I bet that will = be the majority of clients, which will then drive the majority of the serve= rs to support HTTPS.


This is a terrible cop-out. =A0Flaki= ness in the spec is unacceptable.
=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0Still, it leaves the opt= ion on the table for some clients and servers to use HTTP if they wish.




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--14dae93994296ce01204d0c41fc3-- From jasnell@gmail.com Thu Dec 13 15:19:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3621F8BD0 for ; Thu, 13 Dec 2012 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DEtwYrSSDKP for ; Thu, 13 Dec 2012 15:19:32 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 777C921F8BD4 for ; Thu, 13 Dec 2012 15:19:32 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2586048iaz.31 for ; Thu, 13 Dec 2012 15:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LFVKmhgM1tyJvOP/wcvb/V+UzhnKGABoUoKejxT/7Pc=; b=ORNnpsq7IXfdT8qYHN/FdPE+wuTmxuZIECaj298VSWfhUT/JzZKGcV4IbTZ+S/sqMo rkuJQhC5c7xMYAA/S7YHoIE8qNgTTJkrpoMugQrWMViiDzRdU0t0Rmlpl2dr6+HX17LV KHMQJZzTIJKlAni4nvRJoU3P+mDX62ET+xVTKHiElOxas55l9+y+hzMUJKDk1Wm4JO4H SOIB4hx/8Qc+ZvHQ15/NVl1/ska/wkSutrF04/xUqrym3YNW+ydh3MazpX4rYozIdOWR tO7AaG9d5nvG8SPc8L/rZFZnZtWvdZboVPJppmlxX8g0xzbeWnm7LT4f7cOeU3ZVah04 KRLQ== Received: by 10.50.0.193 with SMTP id 1mr3514222igg.0.1355440771895; Thu, 13 Dec 2012 15:19:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 15:19:10 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 15:19:10 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=e89a8f502f8eb910d204d0c425a5 Cc: "webfinger@ietf.org" , Brad Fitzpatrick , "webfinger@googlegroups.com" , Goix Laurent Walter , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:19:37 -0000 --e89a8f502f8eb910d204d0c425a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:17 PM, Tim Bray wrote: > On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick wr= ote: > >> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wr= ote: >> >> I never saw any strong opposition against fallback. People disliked the >> extra complexity, but for quite awhile everybody assumed that fallback >> would be involved, and I think it was considered acceptable. >> >> Who was strongly anti-fallback?'''' >> > > Um, maybe me. What is unacceptable for some applications is if I tell th= e > client =E2=80=9CFetch https://example.com/.well-known/whatever=E2=80=9D a= nd for some > reason it silently falls back to HTTP. -T > Raising my hand as well. If it hasn't been clear up to this point, I'm hugely -1 on https-to-http fallback. - James > > > >> >> >> **** >>> >>> We either have to do HTTPS only *or* we have to live with the fact that >>> some client requests are going to fail if a WF provider does not provid= e WF >>> services over HTTPS. >>> >> >> I strongly disagree that those are the only two options. >> >> But if you really believe that, I hope you realize that flakiness is >> unacceptable, which leaves you with HTTPS-only. >> >> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with >> HTTPS-only. >> >> >>> ** So, >>> >>> **1) **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS= * >>> *** >>> >>> **2) **Servers and clients MAY implement HTTP**** >>> >>> **3) **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be >>> treated as secure since it allows for a MITM attack)**** >>> >>> **4) **Servers MUST NOT redirect from HTTPS to HTTP**** >>> >>> ** ** >>> >>> All works well, except for the case where you have an HTTPS-only >>> client. But, I bet that will be the majority of clients, which will th= en >>> drive the majority of the servers to support HTTPS. >>> >> >> This is a terrible cop-out. Flakiness in the spec is unacceptable. >> >> >>> **** >>> >>> ** Still, it leaves the option on the table for some clients and >>> servers to use HTTP if they wish. >>> >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --e89a8f502f8eb910d204d0c425a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Thu, Dec 13, 2012 at 3:17 PM, Tim Bra= y <tbray@textuality.com> wrote:
On Thu, Dec 13, 2012 at 3:= 15 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@pac= ketizer.com> wrote:

I never saw any= strong opposition against fallback. =C2=A0People disliked the extra comple= xity, but for quite awhile everybody assumed that fallback would be involve= d, and I think it was considered acceptable.

Who was strongly anti-fallback?'''= 9;

Um, maybe me.=C2=A0 What is unacc= eptable for some applications is if I tell the client =E2=80=9CFetch https://ex= ample.com/.well-known/whatever=E2=80=9D and for some reason it silently= falls back to HTTP.=C2=A0=C2=A0 -T

Raising my hand as well. If it= hasn't been clear up to this point, I'm hugely -1 on https-to-http= fallback.

- James
=C2=A0

=C2=A0


=

We either have to do HTTPS only = or we have to live with the fact that some client requests are = going to fail if a WF provider does not provide WF services over HTTPS.


I strongly disagree that those are t= he only two options.

But if you really believe tha= t, I hope you realize that flakiness is unacceptable, which leaves you with= HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't cle= ar, I'd be happy with HTTPS-only.
=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0So,

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers SHOULD implement HTTPS and clie= nts SHOULD use HTTPS

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers and clients MAY implement HTTP<= u>

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MAY redirect from HTTP to HTTPS= (this MUST NOT be treated as secure since it allows for a MITM attack)<= /u>

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MUST NOT redirect from HTTPS to= HTTP

=C2=A0

All works well, exc= ept for the case where you have an HTTPS-only client.=C2=A0 But, I bet that= will be the majority of clients, which will then drive the majority of the= servers to support HTTPS.


This is a terrible cop-out. =C2=A0Fl= akiness in the spec is unacceptable.
=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0Still, it leaves the = option on the table for some clients and servers to use HTTP if they wish.<= /span>




_______________________________________________=
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



--e89a8f502f8eb910d204d0c425a5-- From bradfitz@google.com Thu Dec 13 15:20:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264CD21F8BD4 for ; Thu, 13 Dec 2012 15:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCGZ5JHLhksg for ; Thu, 13 Dec 2012 15:20:21 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id EC37421F8BD0 for ; Thu, 13 Dec 2012 15:20:19 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1102056wgb.13 for ; Thu, 13 Dec 2012 15:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pt+N5fLvePqwvMEH3X8hGUugG/OCQJk6m/yGhN/mHMo=; b=Axo2w1KJhTtqv9SrulePmqsO7zD2jxSYfPiekqXw0ruQ2kM22RBk3vCSyANhXcMJRn KtN/K3mDGmnfZPCgucbiw62BrV6J1x4fVuJxyPkZlf7DlHxzd3qwgvYYY1yPFWqtVeut cuB07v3lreM0TfBBP4M4THsMzD/5vVt6HEcDjaa31rvX0HkjRNFjHdEOfrmoTjuPPmqw 7D7WY/poxwahW2GnHWGiSx7ouL4vaWgfoASSMMwXBHxq5TaLjOPgbeWInW7ZcJPc8fL1 yVZ4p+p2H/uyVdpjONVlaO7hvTVGrEJCMoUD0+5oBj7sHGINrtFucLlDZpnjDzm1d5pD Af1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Pt+N5fLvePqwvMEH3X8hGUugG/OCQJk6m/yGhN/mHMo=; b=DyBmoAHLMKmx+CfQWl8dUeFoas+c8gZyArwkjdJqHvgIl28jut/RVG/XgNFtfY6NsQ sErO/yR3NsnawduXBzPKakLTS2xX3FwKK0Wq9NRTzKdG4xjTu8NLnc0m6ziWKIbJcvA8 puEtWY1zJjVH7hxLYCHUitSUiBcBtfrsOKY0AnfG9BYQrBDkF9VGCZCmL4Zqm3a+lLmw sDnALnoa20i7dr1W9NhFLNtDwQdW1BDlNNmtSMEBKoIO5DbIlh0nh2NEHvevWbBPAYoP IJJhAVJzLJIi5u28quIxb+6pxycV3Ccb9uwt764u7NqMhCPN7+U/p3d0D/5Tj94FQEDa Z2zA== MIME-Version: 1.0 Received: by 10.194.86.72 with SMTP id n8mr768668wjz.19.1355440818896; Thu, 13 Dec 2012 15:20:18 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 15:20:18 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Thu, 13 Dec 2012 15:20:18 -0800 Message-ID: From: Brad Fitzpatrick To: Tim Bray Content-Type: multipart/alternative; boundary=089e0102e1028640bf04d0c42877 X-Gm-Message-State: ALoCoQlIlshGBS2C90UNrQs6TFc5d430SWyuznH3cQHoPOI39couddarEiPy+39pYSRNcpkzQ1DS9Z8sKDGu92KgDXk56NWYQyPH5Zea8wTXqFpGu1tohXdYLYNis/YnZ+CXDYvKAcvkvn5HH5Wh0we37YuOD2tuUB7mBKAflCVnYld6kffy4a1smoVUKtM4Sdnh5tLtIycE Cc: "Paul E. Jones" , James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:20:22 -0000 --089e0102e1028640bf04d0c42877 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:17 PM, Tim Bray wrote: > On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick wr= ote: > >> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wr= ote: >> >> I never saw any strong opposition against fallback. People disliked the >> extra complexity, but for quite awhile everybody assumed that fallback >> would be involved, and I think it was considered acceptable. >> >> Who was strongly anti-fallback?'''' >> > > Um, maybe me. What is unacceptable for some applications is if I tell th= e > client =E2=80=9CFetch https://example.com/.well-known/whatever=E2=80=9D a= nd for some > reason it silently falls back to HTTP. -T > What if you knew ahead of time that your client wouldn't give you results for important rels fetched over HTTP, and would only return them if they came over HTTPS? Would fallback be acceptable for "unimportant" rels? (still trying to feel out everybody's varying concerns) --089e0102e1028640bf04d0c42877 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 3:17 PM, Tim Bray <tbray@textuality.com><= /span> wrote:
On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick <bradfitz@google.com<= /a>> wrote:
On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@pac= ketizer.com> wrote:

I never saw any= strong opposition against fallback. =C2=A0People disliked the extra comple= xity, but for quite awhile everybody assumed that fallback would be involve= d, and I think it was considered acceptable.

Who was strongly anti-fallback?'''= 9;

Um, maybe me.=C2=A0 What is unacc= eptable for some applications is if I tell the client =E2=80=9CFetch https://ex= ample.com/.well-known/whatever=E2=80=9D and for some reason it silently= falls back to HTTP.=C2=A0=C2=A0 -T

What if you knew ahead of time that = your client wouldn't give you results for important rels fetched over H= TTP, and would only return them if they came over HTTPS? =C2=A0Would fallba= ck be acceptable for "unimportant" rels?

(still trying to feel out everybody's varying conce= rns)

--089e0102e1028640bf04d0c42877-- From bradfitz@google.com Thu Dec 13 15:21:57 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34E21F8BED for ; Thu, 13 Dec 2012 15:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eznmiv8Lwil6 for ; Thu, 13 Dec 2012 15:21:55 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0421F8BF0 for ; Thu, 13 Dec 2012 15:21:47 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1102594wgb.13 for ; Thu, 13 Dec 2012 15:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lz7pLVo5Be1u7aCSTlyVqP+XW2kDEpuGlK7aXgqtnJA=; b=PZctL3NomlIC1ClH2E+fZIIjKvVwFwGCCuhUkH58oFZkCqqA/MB+9mQlp8eQlCqV8a 2D8AKzabJE4ViHI4JAulTQrLFfu6SgGDI04mlaEFt8PzR2Ty0nAcW72JIFf6cLG45D7q x2/d0M6SOtwsTNcAjIyBruUKni5evUSfVXa9yUG8Dou+PjUYDouQmnCdiMx2v7Xen8cm dqRYVqGDFILnIvxUyMrt+HXca5edam8OC6oLShGd6uFW1FGWpdgPR6WFQS0OV26Xqz7J j8MaIPfzDOfJB1iR05+2+uzoryywmtyxieu/mlFMxRq5WiQbQR8wKBXOEmzcKKijbeKG Y8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lz7pLVo5Be1u7aCSTlyVqP+XW2kDEpuGlK7aXgqtnJA=; b=mDVFpvwBfQJGliYujWWoqTrqNh1kIrisrZfPHUNVMztWQpvs1JkHmRzFoIthnH9opE nCmh04AG9p7gUbuGFJ6SurhWOP8Bbc2PxteYyMOoqWvsRFwI6F9b6FvpIppZPW+L1oxP sSfcZm3Ei/uEVD3BqzwvEpKWOq6d7PRGEl1k0aK+DZa6MP1SMbf2u7DmnBKeM+8A6q6V LelG6pajVF+dR+QeneQro2/AdL1tdBODpexftIA+4bDJcTOkNqaLUlSSd3VRLqmQ6WEb vuYlXRXSWBcxf0mZXe60WWkFKR9rL9JEihxfvvhLmq/XAjU/E44UGttqGhzazNB8haVy pBRw== MIME-Version: 1.0 Received: by 10.180.90.106 with SMTP id bv10mr6011420wib.12.1355440906925; Thu, 13 Dec 2012 15:21:46 -0800 (PST) Received: by 10.194.166.100 with HTTP; Thu, 13 Dec 2012 15:21:46 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Thu, 13 Dec 2012 15:21:46 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=f46d043c81e8c5773004d0c42dae X-Gm-Message-State: ALoCoQl7rJV8ePaUk6R7SgnoCQ3Yi+AivKckg+5Ii0pPnGMajtwRtAIjR8vg6vcn1WBiNbJ0NHb2eeNEwfgp4FOGHAlWMATvU4LFmUTLse8omGo4i+57LjfnMLcuyYRRNWJa/qATCVfCa+t8xSkJrGT7ToVWiD39z93N3/xs1bVVS8kUkJtM1J0zHr3VvfI94AjEmR2UGLhG Cc: "Paul E. Jones" , Tim Bray , "webfinger@googlegroups.com" , Goix Laurent Walter , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:21:58 -0000 --f46d043c81e8c5773004d0c42dae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:19 PM, James M Snell wrote: > > > > On Thu, Dec 13, 2012 at 3:17 PM, Tim Bray wrote: > >> On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick w= rote: >> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones w= rote: >>> >>> I never saw any strong opposition against fallback. People disliked th= e >>> extra complexity, but for quite awhile everybody assumed that fallback >>> would be involved, and I think it was considered acceptable. >>> >>> Who was strongly anti-fallback?'''' >>> >> >> Um, maybe me. What is unacceptable for some applications is if I tell >> the client =E2=80=9CFetch https://example.com/.well-known/whatever=E2=80= =9D and for some >> reason it silently falls back to HTTP. -T >> > > Raising my hand as well. If it hasn't been clear up to this point, I'm > hugely -1 on https-to-http fallback. > Please explain why. Saying "-1" and calling things insane without justification doesn't lend as much credibility as presenting constructive feedback. --f46d043c81e8c5773004d0c42dae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 3:19 PM, James M Snell <jasnell@gmail.com> wrote:



On Thu, Dec 13, 2012 at 3:17 PM, Tim Bray <tbray@text= uality.com> wrote:
On Thu, Dec 13, 2012 at 3:15 PM, Brad F= itzpatrick <bradfitz@google.com> wrote:

Raising my hand as well.= If it hasn't been clear up to this point, I'm hugely -1 on https-t= o-http fallback.

Please e= xplain why. =C2=A0Saying "-1" and calling things insane without j= ustification doesn't lend as much credibility as presenting constructiv= e feedback.
--f46d043c81e8c5773004d0c42dae-- From paulej@packetizer.com Thu Dec 13 15:27:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48721F8BE7 for ; Thu, 13 Dec 2012 15:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2jATA4klOAz for ; Thu, 13 Dec 2012 15:27:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D396921F8BE6 for ; Thu, 13 Dec 2012 15:27:15 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDNR80e018823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 18:27:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355441229; bh=xPvY3fZ9brMNQdjUsFYzJo/ZZMGOQV+O+VZ+qkuhi2A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HPPsYRecZ6m1UnzAX//dgWAQ9O2ROy2+H8wKnD5Xg2CjehvcpdmnPJvWoNOMkx8Cf kgnWqbMb5kHphXCdsA8DeLUTRdK70KuUS7xVUtUiTnMWzniIBsPhotE+FQJ8mAThms 5HGdCbXkHysz/WURKXW1OJ2v2RHBRyth/nQXxeXo= From: "Paul E. Jones" To: "'Nick Jennings'" , "'Brad Fitzpatrick'" References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 18:27:20 -0500 Message-ID: <081e01cdd989$66344160$329cc420$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrQJNGg2YATtEkl0CW7tvJgKUQTeYAjoH2foCAZndYgMOveMEAbE3eq4BspAHhQJ/JwHvAqZSqGWWVUv1oA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:27:20 -0000 Nick, > var links =3D webFinger.getAllLinks('user@example.com', = {secure:true}); This is equal to using HTTPS and stopping there. =20 > var avatar =3D webFinger.getAvatar('user@example.com'); That's equal to either: 1) Doing HTTPS and falling back to HTTP 2) Doing HTTP only This is possible with the proposal on the table. Just to remind folks, = here is the current proposal (as modified during discussions): Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS and the server has an invalid certificate, the client MUST accept that the WebFinger query has failed. WebFinger servers operating on HTTP MAY redirect a client using an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. (I'd like to replace "appropriate" above with "3xx".) Paul From tbray@textuality.com Thu Dec 13 15:35:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0F21F87C5 for ; Thu, 13 Dec 2012 15:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVnXRM-mLGQl for ; Thu, 13 Dec 2012 15:35:06 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0610021F87C9 for ; Thu, 13 Dec 2012 15:35:05 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2694177obc.31 for ; Thu, 13 Dec 2012 15:35:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9bmttPkTx/4FW55Y5E877GczodqIMktay+o07L93u54=; b=G6etfufMVp3jqkNZWovD+7FmgTAHUvrKFktM5C9Rnh26mCsaak6aB3zH/k0hwnDZYf NU/BkC5kSsbM0MtdZTf/fYX804egzeezcYQoxI4S/8/hS1h4/j1YhQOW/2fpbwt96YBN gVnVuYsSROYFpUJtZoa8KSlzh6431yGc6SF5FvNWnDQA6zUeHOGqNOV2i6XE3saJgcYb zGeLQbPSANK1cRTCQw6DEIC4MqAQJaEiJ1rR9xh0ZLphW5y3MZkEFcUyiMbybV6i6Mdm nZgsGmqWVd9/6ovCj4PLHI8Jtb1e4eJQr8FwA2DV/sjJlVVOZnZB2sCUFnUn8HXNnj1y JpOA== MIME-Version: 1.0 Received: by 10.182.212.35 with SMTP id nh3mr3151620obc.10.1355441705552; Thu, 13 Dec 2012 15:35:05 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 13 Dec 2012 15:35:05 -0800 (PST) X-Originating-IP: [96.49.76.76] In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Thu, 13 Dec 2012 15:35:05 -0800 Message-ID: From: Tim Bray To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=e89a8f5039dc5f897c04d0c45d3b X-Gm-Message-State: ALoCoQnfkx8AWfpTDWnXm7ju9PyHXuRDz8y+SAX1EJTUh4fOUJJGFavypQZDDaErD5B9Q+KaFNeI Cc: "Paul E. Jones" , James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:35:06 -0000 --e89a8f5039dc5f897c04d0c45d3b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:20 PM, Brad Fitzpatrick wrot= e: > > >> Um, maybe me. What is unacceptable for some applications is if I tell >> the client =93Fetch https://example.com/.well-known/whatever=94 and for = some >> reason it silently falls back to HTTP. -T >> > > What if you knew ahead of time that your client wouldn't give you results > for important rels fetched over HTTP, and would only return them if they > came over HTTPS? Would fallback be acceptable for "unimportant" rels? > Yeah, that would be fine. It=92s exactly why I proposed writing a =93fallba= ck=94 parameter into the spec, allowing clients to assert HTTPS-or-nothing. -T > > (still trying to feel out everybody's varying concerns) > > --e89a8f5039dc5f897c04d0c45d3b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:20 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

What if you knew ahead of time= that your client wouldn't give you results for important rels fetched = over HTTP, and would only return them if they came over HTTPS? =A0Would fal= lback be acceptable for "unimportant" rels?

Yeah, that would be fine. It=92s exactly = why I proposed writing a =93fallback=94 parameter into the spec, allowing c= lients to assert HTTPS-or-nothing.=A0=A0 -T

=A0

(still trying to feel out everybody's varying conce= rns)


--e89a8f5039dc5f897c04d0c45d3b-- From jasnell@gmail.com Thu Dec 13 15:38:16 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC721F87EA for ; Thu, 13 Dec 2012 15:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S+UpXH3bFK2 for ; Thu, 13 Dec 2012 15:38:12 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D921F8798 for ; Thu, 13 Dec 2012 15:38:12 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so4851427ieb.25 for ; Thu, 13 Dec 2012 15:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hSVRx36s+dpmAKK/VGVgNzxtflbzoLJjLlpmHOTspUA=; b=mY6lmJsPEd2bHfaa7x/8KGpVKQJXBCUcQVCrWP1Vv0SJSOjuUEVUE/6SmTPDdrmL3F EtFFy+PeGe7B+BHZrSRvLMogjyQchEc5y3Ml4zvP4bzDN7Pl0wEHW+29pA5DjyYSsrkV gjJ2Aza1ZjlTk6qBCvu3CQI29Ei4V1TWPj9dKEVuRUTWmcRNCroSTUpsdXDsgAI7CHcV 2+4bhsxBDuUR8L7yVCrXCG8IW0sb+p12Oy1dRS0hLWi2JpML8JY58r9Z2sJWAav+daFL TgVNC9JbUFgifS9NdNCKG6DmHQla9vcSxnfThlqPkVMSLYuUnND+uPLUIojYMVxlA2dc tesA== Received: by 10.50.151.238 with SMTP id ut14mr18874298igb.72.1355441892276; Thu, 13 Dec 2012 15:38:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 15:37:52 -0800 (PST) In-Reply-To: <081e01cdd989$66344160$329cc420$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 15:37:52 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f3b9f7d80babe04d0c468b2 Cc: Brad Fitzpatrick , Nick Jennings , "webfinger@ietf.org" Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:38:17 -0000 --e89a8f3b9f7d80babe04d0c468b2 Content-Type: text/plain; charset=UTF-8 +1 to this... with one exception.. see below... On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones wrote: > [snip] > > This is possible with the proposal on the table. Just to remind folks, > here is the current proposal (as modified during discussions): > > Clients MAY issue a query to the WebFinger server using either > HTTPS or HTTP, but MUST NOT attempt to use both, either serially > or in parallel. The choice of transport protocols depends on the > client's security requirements, though use of HTTPS is > RECOMMENDED in most situations. > > If a query is issued using HTTPS and the server has an invalid > certificate, the client MUST accept that the WebFinger query has > failed. > Change to: If a query is issued using HTTPS and either: a) the server returns an invalid certificate, b) the server returns a 4xx or 5xx status or c) the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. > > WebFinger servers operating on HTTP MAY redirect a client using > an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. > Likewise, WebFinger servers operating on HTTPS MAY redirect a > client to another HTTPS URI, but MUST NOT redirect a client to an > HTTP URI. Further, clients MUST NOT follow a redirection from an > HTTPS URI to an HTTP URI, but SHOULD automatically follow all > other server redirects. > > (I'd like to replace "appropriate" above with "3xx".) > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --e89a8f3b9f7d80babe04d0c468b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to this... with one exception.. see= below...


On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones <paulej@packetizer.c= om> wrote:
[snip]

This is possible with the proposal on the table. =C2=A0Just to remind folks= , here is the current proposal (as modified during discussions):

=C2=A0 =C2=A0 Clients MAY issue a query to the WebFinger server using eithe= r
=C2=A0 =C2=A0 HTTPS or HTTP, but MUST NOT attempt to use both, either seria= lly
=C2=A0 =C2=A0 or in parallel. =C2=A0The choice of transport protocols depen= ds on the
=C2=A0 =C2=A0 client's security requirements, though use of HTTPS is =C2=A0 =C2=A0 RECOMMENDED in most situations.

=C2=A0 =C2=A0 If a query is issued using HTTPS and the server has an invali= d
=C2=A0 =C2=A0 certificate, the client MUST accept that the WebFinger query = has
=C2=A0 =C2=A0 failed.

Change to: If a query is issued using HTTPS and either= : a) the server returns an invalid certificate, b) the server returns a 4xx= or 5xx status or c) the HTTPS connection cannot be established for any rea= son, the client MUST accept that the WebFinger query has failed and MUST NO= T attempt to reissue the WebFinger request using HTTP.=C2=A0
=C2=A0

=C2=A0 =C2=A0 WebFinger servers operating on HTTP MAY redirect a client usi= ng
=C2=A0 =C2=A0 an _appropriate_ HTTP status code to another HTTP or an HTTPS= URI.
=C2=A0 =C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect a=
=C2=A0 =C2=A0 client to another HTTPS URI, but MUST NOT redirect a client t= o an
=C2=A0 =C2=A0 HTTP URI. =C2=A0Further, clients MUST NOT follow a redirectio= n from an
=C2=A0 =C2=A0 HTTPS URI to an HTTP URI, but SHOULD automatically follow all=
=C2=A0 =C2=A0 other server redirects.

(I'd like to replace "appropriate" above with "3xx"= .)

Paul


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--e89a8f3b9f7d80babe04d0c468b2-- From paulej@packetizer.com Thu Dec 13 15:39:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB921F897F for ; Thu, 13 Dec 2012 15:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECcZ2M+CIlfY for ; Thu, 13 Dec 2012 15:39:01 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2F21F88F6 for ; Thu, 13 Dec 2012 15:39:01 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDNcxFm019319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 18:38:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355441939; bh=1kTXonCq+sjFw7JZcSkSnub6LkmyLNVykj8atg3vFLk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=pqzX+/mcM3hxdd77ugoM/0hhCi+LHM7rZMTz/r03LYpzXCLCiKyJfURxqeJ77ceZc JB4YoVWGUkksiDjpEUkNgRi+ACx0byyFkTEH2FNcgsnym0ztbCLEVB1uAjCbrL2j+U hP34JiLFtRFbtOAI5EHvBwTSYeJb10Pdm4R05JTI= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <6! 95443B7-917E-4E4C-9231- F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 18:39:10 -0500 Message-ID: <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0821_01CDD961.24B72590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYDBCmRIQLKTrWIAmblzoGXxpm2sA== Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , webfinger@googlegroups.com, 'Goix Laurent Walter' Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:39:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0821_01CDD961.24B72590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 I really don=E2=80=99t like the secure-rels idea. If a rel is secure or = should be treated as secure, I can mark it as such on the server without = creating more names and cluttering up the link relation name space with = multiple variants of the same thing. =20 There were several people opposed to the client fall back text due to = both security concerns and client-side complexity. That was one of the = main items we addressed with this latest proposal re-write. =20 I do realize the flakiness of the proposed solution. Sometimes, the = client just does not work. You type in paulej@packetizer.com and it = says =E2=80=9Ccould not find a thing=E2=80=9D, because the client only = issued the query over HTTPS. If one needs security, I see on other way. = However, if we=E2=80=99re willing to go back to the -07 text that has = an allowance for fall back, the issue is addressed. In the -07 text, a = client MAY re-issue a request using HTTP. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Thursday, December 13, 2012 6:15 PM To: Paul E. Jones Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; = webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels =20 On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones = wrote: Walter, =20 No, this will not work. People want to have secure content and what is = secure might be determined by the server admin or user. One might = consider his avatar should be served over HTTPS only. =20 And people do not want to have to write clients that do fallback. =20 I never saw any strong opposition against fallback. People disliked the = extra complexity, but for quite awhile everybody assumed that fallback = would be involved, and I think it was considered acceptable. =20 Who was strongly anti-fallback? =20 =20 We either have to do HTTPS only or we have to live with the fact that = some client requests are going to fail if a WF provider does not provide = WF services over HTTPS. =20 I strongly disagree that those are the only two options. =20 But if you really believe that, I hope you realize that flakiness is = unacceptable, which leaves you with HTTPS-only. =20 If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with = HTTPS-only. =20 So, 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS 2) Servers and clients MAY implement HTTP 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as secure since it allows for a MITM attack) 4) Servers MUST NOT redirect from HTTPS to HTTP =20 All works well, except for the case where you have an HTTPS-only client. = But, I bet that will be the majority of clients, which will then drive = the majority of the servers to support HTTPS. =20 This is a terrible cop-out. Flakiness in the spec is unacceptable. =20 Still, it leaves the option on the table for some clients and servers = to use HTTP if they wish. =20 =20 ------=_NextPart_000_0821_01CDD961.24B72590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

I really don=E2=80=99t like the secure-rels idea.=C2=A0 If a rel is = secure or should be treated as secure, I can mark it as such on the = server without creating more names and cluttering up the link relation = name space with multiple variants of the same = thing.

 

There were several people opposed to the client fall back text due to = both security concerns and client-side complexity.=C2=A0 That was one of = the main items we addressed with this latest proposal = re-write.

 

I do realize the flakiness of the proposed solution.=C2=A0 Sometimes, = the client just does not work.=C2=A0 You type in paulej@packetizer.com = and it says =E2=80=9Ccould not find a thing=E2=80=9D, because the client = only issued the query over HTTPS.=C2=A0 If one needs security, I see on = other way.=C2=A0 However, if we=E2=80=99re willing to go back to the -07 = text that has an allowance for fall back, the issue is addressed.=C2=A0 = In the -07 text, a client MAY re-issue a request using = HTTP.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, = December 13, 2012 6:15 PM
To: Paul E. Jones
Cc: Goix = Laurent Walter; webfinger@googlegroups.com; James M Snell; = webfinger@ietf.org
Subject: Re: [webfinger] secure links with = https rels

 

On Thu, Dec = 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Walter,

 

No, this will not work.  People want to have secure content and = what is secure might be determined by the server admin or user.  = One might consider his avatar should be served over HTTPS = only.

 

And people do not want to have to write clients that do = fallback.

 

I never saw = any strong opposition against fallback.  People disliked the extra = complexity, but for quite awhile everybody assumed that fallback would = be involved, and I think it was considered = acceptable.

 

Who was = strongly anti-fallback?

 

 

We either have to do HTTPS only or we have to live with the = fact that some client requests are going to fail if a WF provider does = not provide WF services over = HTTPS.

 

I strongly = disagree that those are the only two = options.

 

But if you = really believe that, I hope you realize that flakiness is unacceptable, = which leaves you with HTTPS-only.

 

If the = HTTPS-for-some-rels proposal still isn't clear, I'd be happy with = HTTPS-only.

 

 So,

1)      = Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS

2)      = Servers and clients MAY implement HTTP

3)      = Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as = secure since it allows for a MITM attack)

4)      = Servers MUST NOT redirect from HTTPS to HTTP

 

All works well, except for the case where you have an HTTPS-only = client.  But, I bet that will be the majority of clients, which = will then drive the majority of the servers to support = HTTPS.

 

This is a = terrible cop-out.  Flakiness in the spec is = unacceptable.

 

 Still, it leaves the option on the table for some clients and = servers to use HTTP if they = wish.

 

 

------=_NextPart_000_0821_01CDD961.24B72590-- From paulej@packetizer.com Thu Dec 13 15:48:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCD221F84E0 for ; Thu, 13 Dec 2012 15:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cauVCwyffHaX for ; Thu, 13 Dec 2012 15:48:17 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6BB21F84DD for ; Thu, 13 Dec 2012 15:48:17 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBDNmFSl019715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 18:48:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355442496; bh=FsAGjIvcMf6o3Ykl8tzC/nBmbd1bAViHw0r8SaVBC+c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=od9KnadERCn0EYYNS3qBS89WHJqvpQkZ8LgKwl9khVRo0gIoORv1bA7ZlkLoDT4+p 5Ht6rPrSI1qriPsOuTsiowxbUmlgimfpBNT/aDlV1j1PmyE19C6y/LO19Tk9rWr9gG wsV9/j5e0MSyFIRoxVnLbZnHjChnBwYuL14IHVV8= From: "Paul E. Jones" To: "'James M Snell'" References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 18:48:27 -0500 Message-ID: <083301cdd98c$593d97b0$0bb8c710$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0834_01CDD962.70685300" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrQJNGg2YATtEkl0CW7tvJgKUQTeYAjoH2foCAZndYgMOveMEAbE3eq4BspAHhQJ/JwHvAqZSqGUBIydM3QFm9GiclkEB7hA= Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'Nick Jennings' , webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:48:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0834_01CDD962.70685300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That=E2=80=99s closer to what was in the -6 or -07 drafts. Removing the = (a), (b), =E2=80=A6 stuff. How is this: =20 If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and MUST NOT attempt to reissue the = WebFinger request using HTTP. =20 If we want to allow for fall back in the case that the client really = does not care whether the response is secure or not, then we=E2=80=99d = need to soften that language. Right now, it=E2=80=99s either all or = nothing. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Thursday, December 13, 2012 6:38 PM To: Paul E. Jones Cc: Nick Jennings; Brad Fitzpatrick; webfinger@ietf.org Subject: Re: [webfinger] the conflicting goals =20 +1 to this... with one exception.. see below... =20 On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones = wrote: [snip] This is possible with the proposal on the table. Just to remind folks, = here is the current proposal (as modified during discussions): Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS and the server has an invalid certificate, the client MUST accept that the WebFinger query has failed. =20 Change to: If a query is issued using HTTPS and either: a) the server = returns an invalid certificate, b) the server returns a 4xx or 5xx = status or c) the HTTPS connection cannot be established for any reason, = the client MUST accept that the WebFinger query has failed and MUST NOT = attempt to reissue the WebFinger request using HTTP.=20 =20 WebFinger servers operating on HTTP MAY redirect a client using an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. (I'd like to replace "appropriate" above with "3xx".) Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 ------=_NextPart_000_0834_01CDD962.70685300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That=E2=80=99s closer to what was in the -6 or -07 drafts. = =C2=A0Removing the (a), (b), =E2=80=A6 stuff.=C2=A0 How is = this:

 

If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and MUST NOT attempt to reissue the = WebFinger request using HTTP.

 

If we want to allow for fall back in the case that the client really = does not care whether the response is secure or not, then we=E2=80=99d = need to soften that language.=C2=A0 Right now, it=E2=80=99s either all = or nothing.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Thursday, = December 13, 2012 6:38 PM
To: Paul E. Jones
Cc: Nick = Jennings; Brad Fitzpatrick; webfinger@ietf.org
Subject: Re: = [webfinger] the conflicting goals

 

+1 to this... with one exception.. = see below...

 

On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones <paulej@packetizer.com> wrote:

[snip]

This is possible with the proposal on = the table.  Just to remind folks, here is the current proposal (as = modified during discussions):

    Clients MAY issue a = query to the WebFinger server using either
    HTTPS or = HTTP, but MUST NOT attempt to use both, either serially
    = or in parallel.  The choice of transport protocols depends on = the
    client's security requirements, though use of HTTPS = is
    RECOMMENDED in most situations.

    = If a query is issued using HTTPS and the server has an invalid
  =   certificate, the client MUST accept that the WebFinger query = has
    failed.

 

Change to: = If a query is issued using HTTPS and either: a) the server returns an = invalid certificate, b) the server returns a 4xx or 5xx status or c) the = HTTPS connection cannot be established for any reason, the client MUST = accept that the WebFinger query has failed and MUST NOT attempt to = reissue the WebFinger request using = HTTP. 

 


    WebFinger servers operating on HTTP = MAY redirect a client using
    an _appropriate_ HTTP = status code to another HTTP or an HTTPS URI.
    Likewise, = WebFinger servers operating on HTTPS MAY redirect a
    = client to another HTTPS URI, but MUST NOT redirect a client to = an
    HTTP URI.  Further, clients MUST NOT follow a = redirection from an
    HTTPS URI to an HTTP URI, but = SHOULD automatically follow all
    other server = redirects.

(I'd like to replace "appropriate" above = with "3xx".)

Paul



_______________________________________________=
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0834_01CDD962.70685300-- From jasnell@gmail.com Thu Dec 13 15:52:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5D21F8BD2 for ; Thu, 13 Dec 2012 15:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynMyBnDkCbRG for ; Thu, 13 Dec 2012 15:52:16 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 536D421F84E3 for ; Thu, 13 Dec 2012 15:52:16 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2607805iaz.31 for ; Thu, 13 Dec 2012 15:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F9xxfTztCrrIYKImy4wanZXhQ8YhOrAKWtKUIJcdUoI=; b=0FXZSEfX8U5vHJ1N68AekQGZHVZjm5YC4nXKp7gpeCI5cytlmGGUY6vHb2+Uy/3pCW PiIqYuKnyTScDx0wW6pWHvfpRFkgisoF4vDNN5ofsnqJQ7M7yNLM6u4b1jR9GFUK9NIn agWWi+jxxbZCQjaa1Te7tDoo44GIl01+zOcl22DZ5NoW2XHFn2HjlbiL8+C1t8OIPiqx 471iLQlXDM3bn/yH3E/ph+rr6gbu6Vn/J9UCdo2Xri0dunkhBICwpIUKcXqDo23TB/V4 wRy817L6m+kyjUV5G6RnpK4PbMEZYPm/ymEXO4RPgC5QzqPs56zrHD59YtYuFRI+qbx8 6YCQ== Received: by 10.42.32.71 with SMTP id c7mr3134312icd.35.1355442733841; Thu, 13 Dec 2012 15:52:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 15:51:53 -0800 (PST) In-Reply-To: <083301cdd98c$593d97b0$0bb8c710$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> <083301cdd98c$593d97b0$0bb8c710$@packetizer.com> From: James M Snell Date: Thu, 13 Dec 2012 15:51:53 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec517cda8a9fe6604d0c49ad3 Cc: Brad Fitzpatrick , Nick Jennings , "webfinger@ietf.org" Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:52:21 -0000 --bcaec517cda8a9fe6604d0c49ad3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's fine. If the client really does not care whether the response is secure or not, the client can issue the initial request over HTTP. If the request is sent over HTTPS the assumption should be that's what the client intended. On Thu, Dec 13, 2012 at 3:48 PM, Paul E. Jones wrote= : > That=E2=80=99s closer to what was in the -6 or -07 drafts. Removing the = (a), (b), > =E2=80=A6 stuff. How is this:**** > > ** ** > > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > > ** ** > > If we want to allow for fall back in the case that the client really does > not care whether the response is secure or not, then we=E2=80=99d need to= soften > that language. Right now, it=E2=80=99s either all or nothing.**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Thursday, December 13, 2012 6:38 PM > *To:* Paul E. Jones > *Cc:* Nick Jennings; Brad Fitzpatrick; webfinger@ietf.org > > *Subject:* Re: [webfinger] the conflicting goals**** > > ** ** > > +1 to this... with one exception.. see below...**** > > ** ** > > On Thu, Dec 13, 2012 at 3:27 PM, Paul E. Jones > wrote:**** > > [snip] > > This is possible with the proposal on the table. Just to remind folks, > here is the current proposal (as modified during discussions): > > Clients MAY issue a query to the WebFinger server using either > HTTPS or HTTP, but MUST NOT attempt to use both, either serially > or in parallel. The choice of transport protocols depends on the > client's security requirements, though use of HTTPS is > RECOMMENDED in most situations. > > If a query is issued using HTTPS and the server has an invalid > certificate, the client MUST accept that the WebFinger query has > failed.**** > > ** ** > > Change to: If a query is issued using HTTPS and either: a) the server > returns an invalid certificate, b) the server returns a 4xx or 5xx status > or c) the HTTPS connection cannot be established for any reason, the clie= nt > MUST accept that the WebFinger query has failed and MUST NOT attempt to > reissue the WebFinger request using HTTP. **** > > **** > > > WebFinger servers operating on HTTP MAY redirect a client using > an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. > Likewise, WebFinger servers operating on HTTPS MAY redirect a > client to another HTTPS URI, but MUST NOT redirect a client to an > HTTP URI. Further, clients MUST NOT follow a redirection from an > HTTPS URI to an HTTP URI, but SHOULD automatically follow all > other server redirects. > > (I'd like to replace "appropriate" above with "3xx".) > > Paul**** > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --bcaec517cda8a9fe6604d0c49ad3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's fine. If the client really = does not care whether the response is secure or not, the client can issue t= he initial request over HTTP. If the request is sent over HTTPS the assumpt= ion should be that's what the client intended.


On Thu= , Dec 13, 2012 at 3:48 PM, Paul E. Jones <paulej@packetizer.com>= ; wrote:

That=E2=80=99= s closer to what was in the -6 or -07 drafts. =C2=A0Removing the (a), (b), = =E2=80=A6 stuff.=C2=A0 How is this:

=C2=A0

If a query is issued using HTTPS and the server has an invalid cert= ificate, the server returns a 4xx or 5xx status code, or the HTTPS connecti= on cannot be established for any reason, the client MUST accept that the We= bFinger query has failed and MUST NOT attempt to reissue the WebFinger requ= est using HTTP.

=C2=A0

If we want to allow= for fall back in the case that the client really does not care whether the= response is secure or not, then we=E2=80=99d need to soften that language.= =C2=A0 Right now, it=E2=80=99s either all or nothing.<= /p>

=C2=A0

Paul<= /span>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Thursday, December 13, 2012 6:38 PM
To: Paul E. Jone= s
Cc: Nick Jennings; Brad Fitzpatrick; webfinger@ietf.org


Subject: Re: [webfinger] the conflicting goals

=C2=A0

+1 to t= his... with one exception.. see below...

=C2=A0

On Thu, Dec 13, = 2012 at 3:27 PM, Paul E. Jones <paulej@packetizer.com> wrote:

[snip]

This is possible with the proposal on = the table. =C2=A0Just to remind folks, here is the current proposal (as mod= ified during discussions):

=C2=A0 =C2=A0 Clients MAY issue a query t= o the WebFinger server using either
=C2=A0 =C2=A0 HTTPS or HTTP, but MUST NOT attempt to use both, either seria= lly
=C2=A0 =C2=A0 or in parallel. =C2=A0The choice of transport protocol= s depends on the
=C2=A0 =C2=A0 client's security requirements, thoug= h use of HTTPS is
=C2=A0 =C2=A0 RECOMMENDED in most situations.

=C2=A0 =C2=A0 If a query is issued using HTTPS and the server has an in= valid
=C2=A0 =C2=A0 certificate, the client MUST accept that the WebFing= er query has
=C2=A0 =C2=A0 failed.

=C2=A0

Change to: If a query is issued using HTTPS and either: a) the server = returns an invalid certificate, b) the server returns a 4xx or 5xx status o= r c) the HTTPS connection cannot be established for any reason, the client = MUST accept that the WebFinger query has failed and MUST NOT attempt to rei= ssue the WebFinger request using HTTP.=C2=A0

=C2=A0


=C2=A0 = =C2=A0 WebFinger servers operating on HTTP MAY redirect a client using
=C2=A0 =C2=A0 an _appropriate_ HTTP status code to another HTTP or an HTTPS= URI.
=C2=A0 =C2=A0 Likewise, WebFinger servers operating on HTTPS MAY r= edirect a
=C2=A0 =C2=A0 client to another HTTPS URI, but MUST NOT redire= ct a client to an
=C2=A0 =C2=A0 HTTP URI. =C2=A0Further, clients MUST NO= T follow a redirection from an
=C2=A0 =C2=A0 HTTPS URI to an HTTP URI, but SHOULD automatically follow all=
=C2=A0 =C2=A0 other server redirects.

(I'd like to replace &= quot;appropriate" above with "3xx".)

Paul



__________________________________= _____________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/m= ailman/listinfo/webfinger

=C2=A0<= /p>


--bcaec517cda8a9fe6604d0c49ad3-- From paulej@packetizer.com Thu Dec 13 18:54:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB83421F8929 for ; Thu, 13 Dec 2012 18:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7m5TS8JaGcb for ; Thu, 13 Dec 2012 18:54:31 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95621F87DF for ; Thu, 13 Dec 2012 18:54:30 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE2sTcS027453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Dec 2012 21:54:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355453669; bh=PXUsufjs1VNcs8cXC80oT0ohsZhhgqWkMOvwnTFCnw8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=kzl9FpoqCs/l748alWDsJ2dp25lDZrmVKNEVoClTtX+TdnVNpIA3rGvk108AVRDhB c/KPq1XxqUp1YGuzfUVLulwX8jCX2eHyxJ879ql0aXt0wJNbQ5rGVBoKLID4rCfzgd 7yE5C8eAlVIHF1aB8qR1LHQEvclYIllYJ99rPCso= From: "Paul E. Jones" To: Date: Thu, 13 Dec 2012 21:54:41 -0500 Message-ID: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0897_01CDD97C.74AD9F00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ZpfGNDpIFHX0IRVGRmh0kFFpohA== Content-Language: en-us Subject: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 02:54:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0897_01CDD97C.74AD9F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I'm not sure we're any closer to agreement, but I don't think so. What if we require servers to support both HTTP (directly or redirected to HTTPS) and HTTPS, then letting the client select the transport it wants to use given its own security requirements? Paul ------=_NextPart_000_0897_01CDD97C.74AD9F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I’m = not sure we’re any closer to agreement, but I don’t think = so.

 

What if we require servers to support both HTTP = (directly or redirected to HTTPS) and HTTPS, then letting the client = select the transport it wants to use given its own security = requirements?

 

Paul

 

------=_NextPart_000_0897_01CDD97C.74AD9F00-- From paulej@packetizer.com Thu Dec 13 18:58:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA921F879F for ; Thu, 13 Dec 2012 18:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVcF5gB6JYKV for ; Thu, 13 Dec 2012 18:58:21 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E06C021F876C for ; Thu, 13 Dec 2012 18:58:20 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE2wKJ1027625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Dec 2012 21:58:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355453900; bh=d6mRoITRJbILA40ntiegNUk4fLjgwWkAP/KbydgDwpo=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=izovGAkNV8/BaNQeANtsO/PFux0bMDO9tS2pMM8PjAEQWil2F/FABJBjmCrg0Y7hu T54tKzgxn0usaoEemTchgJLKg/e+ccTnPhumyN/OD3GTKu2Nsb3wu2dVjInTWevzD5 /5KG8A/GYUTCEjxvw5cRO01uLy8zeuWfVVdEisM0= From: "Paul E. Jones" To: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> In-Reply-To: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> Date: Thu, 13 Dec 2012 21:58:32 -0500 Message-ID: <08c101cdd9a6$e6ff9340$b4feb9c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C2_01CDD97C.FE2A0070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNf5qO/8qTltp+U2sQELwebce9195TzgFNA Content-Language: en-us Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 02:58:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08C2_01CDD97C.FE2A0070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Never mind that question. If we go that path, we might as well just mandate HTTPS. So, who still is NOT in favor of just mandating use of HTTPS? Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Thursday, December 13, 2012 9:55 PM To: webfinger@ietf.org Subject: [webfinger] The HTTP/HTTPS Issue Folks, I'm not sure we're any closer to agreement, but I don't think so. What if we require servers to support both HTTP (directly or redirected to HTTPS) and HTTPS, then letting the client select the transport it wants to use given its own security requirements? Paul ------=_NextPart_000_08C2_01CDD97C.FE2A0070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Never mind that question.  If we go that = path, we might as well just mandate HTTPS.

 

So, who still is NOT in = favor of just mandating use of HTTPS?

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Paul E. Jones
Sent: Thursday, December 13, 2012 = 9:55 PM
To: webfinger@ietf.org
Subject: [webfinger] = The HTTP/HTTPS Issue

 

Folks,

 

I’m = not sure we’re any closer to agreement, but I don’t think = so.

 

What if we require servers to support both HTTP = (directly or redirected to HTTPS) and HTTPS, then letting the client = select the transport it wants to use given its own security = requirements?

 

Paul

 

------=_NextPart_000_08C2_01CDD97C.FE2A0070-- From bradfitz@google.com Thu Dec 13 19:00:08 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B2D21F89E6 for ; Thu, 13 Dec 2012 19:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RVFpQVfkyQo for ; Thu, 13 Dec 2012 19:00:07 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4528521F896E for ; Thu, 13 Dec 2012 19:00:07 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so2198403qca.31 for ; Thu, 13 Dec 2012 19:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nhfzcnBPDyQmd2XARVOt0VJ8Vflsxkcc2qwMRChJRzU=; b=ec59EIXVozMj+HsLPNMj1Ry3SNPqrt8iFJiUGHELLJza5DhHwE63ENqoWnKmkFwQir dJpiA38m+0Emghft3xjOf9jf7O9c+Vz8XqWKQr/U5KavIpFCt0eOOG8VzUVrhQLkXZoK R4tAuIhQX4zDRmgA6erOgdiiIc71Rca21awyDxch1qHRzqTi3kelTs2E/0Ay48H60nX1 jCeDWnt4ang/AnwPu4EFF3To+L6YOWkBfRHyuQsaUBqqemXfm1ZPY7QA1FNmKBICSry1 Eb/NZyctSS4oxqJL4HOzqwdxIgn/PIOG3wlvUFnNiGtH8igABLurT8HTarNL3WS8LDBx vUXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nhfzcnBPDyQmd2XARVOt0VJ8Vflsxkcc2qwMRChJRzU=; b=KM0ZIy76vvl/BrUiP56vkCQO0eE/GFtltf5sUQyHK8TFhvRarjVQqI1VuLl2d8Ty+i pxyPoB7eLg5ICz0N5SzML/zF1WRvTtQh1xLcm8j1VER8csItXTAQU/biRnYzCHz3wntc MXryzG07vU2EbP9PExRNxFPbD6N6/4UAfyNzY6k3T9Iuc8inKBSt54upyuL1POlC19Of gHRZ4Y/vo+EMfUlUsuRiICuGu6kGpM+RITV53ErljHTH/MN7ih5TbJ12v/dIcfKIku3B ZrEBv/nOtCOQyT4oM7WkgQ6JfS4ETpnoYyKIosZRNrzmhXHQKgWPB0Oh2oQWf30C9Ooi SnnA== MIME-Version: 1.0 Received: by 10.224.191.131 with SMTP id dm3mr1975029qab.27.1355454006644; Thu, 13 Dec 2012 19:00:06 -0800 (PST) Received: by 10.224.96.19 with HTTP; Thu, 13 Dec 2012 19:00:06 -0800 (PST) In-Reply-To: <08c101cdd9a6$e6ff9340$b4feb9c0$@packetizer.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08c101cdd9a6$e6ff9340$b4feb9c0$@packetizer.com> Date: Thu, 13 Dec 2012 19:00:06 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf300fb0cb93508c04d0c73a98 X-Gm-Message-State: ALoCoQnpigO+eG3LXS6c0Xfg1ohPhuM657c//C4Tt5cNwKgZECRLcE0F57Q1aibZiPa4FZHJ/g5RK95sOossQUFa7OC/0J5oecWl6+tEBsq2/BGDWpkwmxT8no6PZ8uKapi92q3nUBt0K70Af3v3zo+B3PeteciCusEYWDd6WyVS6beXhRo95xT9gN4lnOZpdKktuWTW3WrG Cc: webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:00:08 -0000 --20cf300fb0cb93508c04d0c73a98 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones wrote: > Never mind that question. If we go that path, we might as well just > mandate HTTPS. > Phew, that saved me a very confused email. Yes. > **** > > ** So, who still is NOT in favor of just mandating use of HTTPS? > Also curious on this. --20cf300fb0cb93508c04d0c73a98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --20cf300fb0cb93508c04d0c73a98-- From jasnell@gmail.com Thu Dec 13 19:15:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755E121F8C3E for ; Thu, 13 Dec 2012 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08yfdYQ5R9nd for ; Thu, 13 Dec 2012 19:15:54 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF821F8C50 for ; Thu, 13 Dec 2012 19:15:53 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2739122iaz.31 for ; Thu, 13 Dec 2012 19:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tewOPN0QHWnwyEFO5AD4PBPvvMCN+clAFLw4ujxLGB8=; b=eKuKS6ZxYEKAXWy3cwL+FeEaFQFgNAyTDxDL0HK6y4Ax4Bw29BPPw0dkgL3qxaKrST egccix/dSLePhXhZSVs1+JjBOuUwYnmCLrMg2CgPZmP1yX0uqE4FA5IEGM1Tc5n5JDeC JtgW4CXhDcIvzl9QbKWiOV/+0tFqO2e7l3dPNE315m//uW8NV4jvbh+CY/rQMsQ4T9Te RDzTT01gevW07MF6zqqu2SeX4OAIwfozeLB5ryjIl1bi+mZFLgtK/7R19hOQLcRtWDrG vjQlXLmjM4lfBdHsmstjeCg3UTX+JVQd+SED2HZ4QbZuspm5Bi3/NYGYGgo4IYZmiE2i RZ3Q== MIME-Version: 1.0 Received: by 10.50.6.169 with SMTP id c9mr400306iga.24.1355454953513; Thu, 13 Dec 2012 19:15:53 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 19:15:53 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 19:15:53 -0800 (PST) In-Reply-To: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> Date: Thu, 13 Dec 2012 19:15:53 -0800 Message-ID: From: James M Snell To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f6467170361c704d0c77359 Cc: webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:15:54 -0000 --e89a8f6467170361c704d0c77359 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Dec 13, 2012 6:54 PM, "Paul E. Jones" wrote: > > Folks, > > > > I=E2=80=99m not sure we=E2=80=99re any closer to agreement, but I don=E2= =80=99t think so. > > > > What if we require servers to support both HTTP (directly or redirected to HTTPS) and HTTPS, then letting the client select the transport it wants to use given its own security requirements? > The spec language you posted earlier, with the changes you and I discussed, is spot on. -1 to mandating HTTPS. - James > > > Paul > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --e89a8f6467170361c704d0c77359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 13, 2012 6:54 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Folks,
>
> =C2=A0
>
> I=E2=80=99m not sure we=E2=80=99re any closer to agreement, but I don= =E2=80=99t think so.
>
> =C2=A0
>
> What if we require servers to support both HTTP (directly or redirecte= d to HTTPS) and HTTPS, then letting the client select the transport it want= s to use given its own security requirements?
>

The spec language you posted earlier, with the changes you a= nd I discussed, is spot on.

-1 to mandating HTTPS.

- James

> =C2=A0
>
> Paul
>
> =C2=A0
>
>
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/webfinger
>

--e89a8f6467170361c704d0c77359-- From dick.hardt@gmail.com Thu Dec 13 19:20:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1098621F8C51 for ; Thu, 13 Dec 2012 19:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc2WwqN0hwHX for ; Thu, 13 Dec 2012 19:20:53 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB221F8C13 for ; Thu, 13 Dec 2012 19:20:53 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1922044pad.31 for ; Thu, 13 Dec 2012 19:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=M68QDmqBr3iYoYRh+FmdjuFTiFFee5+BIaRjQfYTMkw=; b=UPAfdApH2ajVsOGWW6IZU04yNDSjkLK+VtFXdcRUkbgnvnXJrpbYmhldy0wZneAsCn n7ToMNRfdBaTO3VFYYDTlUo+muwvrpffprz9VaGpI4ViHj68u3Hn0PljMA0mXDwu6o1Z L4ALoYxQ1DQI38inPHi2GpeJdPeJs9ymRWLLDvN2BzamrdWxrMhYDnIj5WjvJDTVsg4A 28wU3yFb2A9QS/zNXkP1AAtEStTlcD8DhBmqkIrcqAHfI7E1cpKZ2+ryh2ZnL4klmtQ8 HQS72Yo9gQpKPsgfbWyXW9+gPGH5CO2Ex80QAm02L8q7zGTjrwbKZCrGA+XsoKIK9JTg W9Iw== Received: by 10.66.52.102 with SMTP id s6mr12288383pao.6.1355455252975; Thu, 13 Dec 2012 19:20:52 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id d2sm2345622paw.19.2012.12.13.19.20.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 19:20:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B011E0EF-6896-451B-A52A-24D4A5614269" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Thu, 13 Dec 2012 19:20:45 -0800 Message-Id: <8EA3B579-817B-4A3B-807D-F280C2BC7501@gmail.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08c101cdd9a6$e6ff9340$b4feb9c0$@packetizer.com> To: Brad Fitzpatrick X-Mailer: Apple Mail (2.1499) Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:20:54 -0000 --Apple-Mail=_B011E0EF-6896-451B-A52A-24D4A5614269 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 on mandating HTTPS The internet is not static. I can imagine providers innovating on = providing HTTPS if WF becomes popular. On Dec 13, 2012, at 7:00 PM, Brad Fitzpatrick = wrote: > On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones = wrote: > Never mind that question. If we go that path, we might as well just = mandate HTTPS. >=20 >=20 > Phew, that saved me a very confused email. Yes. --Apple-Mail=_B011E0EF-6896-451B-A52A-24D4A5614269 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1 on mandating HTTPS

The internet is not static. I can imagine providers innovating on providing HTTPS if WF becomes popular.

On Dec 13, 2012, at 7:00 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Never mind that question.  If we go that path, we might as well just mandate HTTPS.


Phew, that saved me a very confused email.  Yes.

--Apple-Mail=_B011E0EF-6896-451B-A52A-24D4A5614269-- From paulej@packetizer.com Thu Dec 13 19:36:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2621F8C64 for ; Thu, 13 Dec 2012 19:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quiadlY3a0V2 for ; Thu, 13 Dec 2012 19:36:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9951A21F8C61 for ; Thu, 13 Dec 2012 19:36:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE3a7qa029196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 22:36:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355456168; bh=9YzBUpsdozXYxpfw/PRZVqrL9wJycfROiqrAe+nQ23c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ieHR9u/xd8An5sJmaBDYZR+8I3TIyNoMFvtmzkzT7kaJdjQ9liilys/siivv5f2HV obTlyF4kEIhIpBI/djLpP8gPb3QNhThkQbkbaQB4Z5uuU6fHinbr11jRP31e/pf/e0 aVcQqeI2HAsKvMjjKcQCWRqpiWA4mgT5jmRNM9Ew= From: "Paul E. Jones" To: "'James M Snell'" References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 22:36:19 -0500 Message-ID: <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08F1_01CDD982.45EFC610" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNf5qO/8qTltp+U2sQELwebce919wHRumEilOT6soA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:36:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08F1_01CDD982.45EFC610 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, et al, =20 I that text still seemed to be controversial, since it would mean there = is a possibility that clients requiring secure connections would fail = when a domain did not implement WF on HTTPS. =20 Let me present it again: =20 Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client=E2=80=99s security requirements, though use of HTTPS is RECOMMENDED in most situations. =20 If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. =20 WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. =20 Do we go with this or do we mandate HTTPS only? (I=E2=80=99ve tried to = not take a position on this, but it does seem like the more we go back = and forth and discuss pros and cons, HTTPS is looking much simpler. It = does mean domain owners will have to get a certificate and it will not = work on hosting providers that do not support SNI. However, I would = assume that the number of such providers is dwindling now that SNI has = been in OpenSSL for a few years.) =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Thursday, December 13, 2012 10:16 PM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue =20 On Dec 13, 2012 6:54 PM, "Paul E. Jones" wrote: > > Folks, > > =20 > > I=E2=80=99m not sure we=E2=80=99re any closer to agreement, but I = don=E2=80=99t think so. > > =20 > > What if we require servers to support both HTTP (directly or = redirected to HTTPS) and HTTPS, then letting the client select the = transport it wants to use given its own security requirements? > The spec language you posted earlier, with the changes you and I = discussed, is spot on. -1 to mandating HTTPS. - James > =20 > > Paul > > =20 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > ------=_NextPart_000_08F1_01CDD982.45EFC610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James, et=C2=A0 al,

 

I that text still seemed to be controversial, since it would mean = there is a possibility that clients requiring secure connections would = fail when a domain did not implement WF on = HTTPS.

 

Let me present it again:

 

=C2=A0=C2=A0=C2=A0 Clients MAY issue a query to the = WebFinger server using either

=C2=A0=C2=A0=C2=A0 HTTPS or HTTP, but MUST NOT = attempt to use both, either serially

=C2=A0=C2=A0=C2=A0 or in parallel.=C2=A0 The choice = of transport protocols depends on the

=C2=A0=C2=A0=C2=A0 client=E2=80=99s security = requirements, though use of HTTPS is

=C2=A0=C2=A0=C2=A0 RECOMMENDED in most = situations.

 

=C2=A0=C2=A0=C2=A0 If a query is issued using HTTPS = and the server has an invalid

=C2=A0=C2=A0=C2=A0 certificate, the server returns a = 4xx or 5xx status code, or the

=C2=A0=C2=A0=C2=A0 HTTPS connection cannot be = established for any reason, the client

=C2=A0=C2=A0=C2=A0 MUST accept that the WebFinger = query has failed and MUST NOT

=C2=A0=C2=A0=C2=A0 attempt to reissue the WebFinger = request using HTTP.

 

=C2=A0=C2=A0=C2=A0 WebFinger servers operating on = HTTP MAY redirect a client using

=C2=A0=C2=A0=C2=A0 an appropriate HTTP status code = to another HTTP or an HTTPS URI.

=C2=A0=C2=A0=C2=A0 Likewise, WebFinger servers = operating on HTTPS MAY redirect a

=C2=A0=C2=A0=C2=A0 client to another HTTPS URI, but = MUST NOT redirect a client to an

=C2=A0=C2=A0=C2=A0 HTTP URI.=C2=A0 Further, clients = MUST NOT follow a redirection from an

=C2=A0=C2=A0=C2=A0 HTTPS URI to an HTTP URI, but = SHOULD automatically follow all

=C2=A0=C2=A0=C2=A0 other server = redirects.

 

Do we go with this or do we mandate HTTPS only?=C2=A0 (I=E2=80=99ve = tried to not take a position on this, but it does seem like the more we = go back and forth and discuss pros and cons, HTTPS is looking much = simpler. It does mean domain owners will have to get a certificate and = it will not work on hosting providers that do not support SNI.=C2=A0 = However, I would assume that the number of such providers is dwindling = now that SNI has been in OpenSSL for a few = years.)

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Thursday, = December 13, 2012 10:16 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] The HTTP/HTTPS = Issue

 


On Dec 13, 2012 6:54 PM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:
>
> Folks,
>
>  
>
> = I=E2=80=99m not sure we=E2=80=99re any closer to agreement, but I = don=E2=80=99t think so.
>
>  
>
> What if = we require servers to support both HTTP (directly or redirected to = HTTPS) and HTTPS, then letting the client select the transport it wants = to use given its own security requirements?
>

The = spec language you posted earlier, with the changes you and I discussed, = is spot on.

-1 to mandating HTTPS.

- = James

>  
>
> Paul
>
> =  
>
>
> = _______________________________________________
> webfinger = mailing list
> webfinger@ietf.org
> https://www.ietf= .org/mailman/listinfo/webfinger
>

- James

On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones = <paulej@packetizer.com> wrote:

Walter,

=C2=A0

No, this will not w= ork.=C2=A0 People want to have secure content and what is secure might be d= etermined by the server admin or user.=C2=A0 One might consider his avatar = should be served over HTTPS only.

=C2=A0

And people do not w= ant to have to write clients that do fallback.

=C2=A0

We either have to d= o HTTPS only or we have to live with the fact that some client reque= sts are going to fail if a WF provider does not provide WF services over HT= TPS.

=C2=A0

So,

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers SHOULD implement HTTPS and clie= nts SHOULD use HTTPS

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers and clients MAY implement HTTP<= u>

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MAY redirect from HTTP to HTTPS= (this MUST NOT be treated as secure since it allows for a MITM attack)<= /u>

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Servers MUST NOT redirect from HTTPS to= HTTP

=C2=A0

All works well, exc= ept for the case where you have an HTTPS-only client.=C2=A0 But, I bet that= will be the majority of clients, which will then drive the majority of the= servers to support HTTPS.

=C2=A0

Still, it leaves th= e option on the table for some clients and servers to use HTTP if they wish= .

=C2=A0

Paul<= /span>

=C2=A0

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] Sent: Thursday, December 13, 2012 6:05 PM
To: webfinger@googlegroups.= com
Cc: webfinger@googlegroups.com; Brad Fitzpatrick; Paul E. Jones= ; James M Snell; we= bfinger@ietf.org


Subject: Re: [webfinger] secure links with htt= ps rels

=C2=A0

I think we're all loosing= focus with this thread....

Why not simply sta= te that:

- servers must = support http and should support https

- clients should try https first (but may have options not to do it for spe= cific purposes)

- server= s must not include 'secure' *href* over plain http + clients must i= gnore those hrefs if present anyway (to avoid the attack suggested earlier)=

=C2=A0

This I believe accommodates all:

- we don't mention fallback explicitly. Clien= ts may fallback since servers may not support https but know that in that c= ase won't get any secure href (implied: won't probably get those re= ls that are sensitive like oauth or openid connect endpoints etc).

- we don't mention the concept of sec= ure link rels but secure href

- plain http solution still works and it is clear that it does not re= turn secure endpoints (I don't think anyone wants this)

- https is still recommended at first hit= to get a maximum number of rels

- https queries are not limited to return secure links only but an= y...

- secure link filtering over plain http i= s ensured both at server and client side

=C2=A0

Walter

Le 13 d=C3=A9c. 2012 =C3=A0 23:40, "Kingsley Idehen"= ; <kidehen@o= penlinksw.com> a =C3=A9crit=C2=A0:

On 12/13/12 5:35 PM, Brad Fitzpatrick wrot= e:

On Thu, Dec 13, 2012 at 2:= 32 PM, Nick Jennings <nick@silverbucket.net> wrote:

>
> HTTPS-only makes this all easier.
>
> If we want to allow = HTTP, we need more complexity in the client.
>

Why not HTTPS and HTTP for = the server? (not either-or)

=C2=A0

There are a number of peopl= e on this list who want to run WebFinger servers over HTTP without the pain= and expense of setting up HTTPS. =C2=A0HTTP fallback was a compromise for = them.

+1

Very important. T= he Web is inherently loosely coupled, we have to keep it that way.

= 

-- 
=C2=A0=

Regards,
=C2=A0
Kingsl=
ey Idehen =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
Founder &=
amp; CEO 
OpenLink Software=C2=A0=C2=A0=C2=A0=C2=A0=
 
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen<=
/pre>
Twitter/Identi.ca<=
/a> handle: @kidehen



Google+ Profile: https://plus.google.com/112399767740508618350/=
about
LinkedIn Profile: http://www.linkedin.com/in/kidehe=
n



=C2=A0
=C2=A0
=
=C2=A0
=C2=A0

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pe= rsone indicate. La diffusione, copia o qualsiasi altra azione derivante dal= la conoscenza di queste informazioni sono rigorosamente vietate. Qualora ab= biate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzion= e, Grazie.

This e-mail and any attachments=C2=A0is=C2=A0confidential and may contain privileged information intended for the ad= dressee(s) only. Dissemination, copying, printing or use by anybody else is= unauthorised. If you are not the intended recipient, please delete this me= ssage and any attachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l'ambiente. Non stampare = questa mail se non =C3=A8 necessario. =

=C2=A0

O= n Thu, Dec 13, 2012 at 11:35 AM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

But starts with =E2=80=9Chttps=E2=80=9D does not mean secur= ity is important.=C2=A0 We can=E2=80=99t use that as the measuring stick.


No, I've been arguing that= we can.

Let me see how many ways I can say the exact same th= ing:

Rather than say that all of WebFinger is HTTP= S-only (an earlier proposal), we say that certain rel values are HTTPS-only= , and certain rel values are either (HTTP or HTTPS).

These "HTTPS-only rels" I've been calling= "secure rels", and are denoted by the rel value (NOT the "h= ref" value) beginning with "https:" (for those not registere= d with the IANA), or beginning with "secure-" (for those register= ed with the IANA).

=C2=A0

=C2=A0And what about other URI schemes that will be used by WF?


hrefs don't matter. =C2=A0= Only the rel part. =C2=A0"https:" or "secure-" prefix. = =C2=A0Note that "secure-" isn't a scheme, because a rel is ju= st a string, which may be a URL or may be some token.
=C2=A0

<= u>=C2=A0=E2=80=9CWhat is secure=E2=80=9D needs to be det= ermined by the WF server internally.=C2=A0
=C2=A0

The= best solution, though, is if you support HTTPS have all HTTP queries redir= ected to HTTPS.=C2=A0


That's a terrible solution, sinc= e anybody can MITM that and redirect the query to an attacker's HTTP or= HTTPS server.
=C2=A0

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt"> This makes life so much simpler.=C2=A0 And if you only support HTTP= , you know you there is no security.=C2=A0 Clients (e.g., an client trying = to perform an OpenID login) would never even try HTTP.

=C2=A0

Paul<= /span>

=C2=A0

From: John Panzer [mailto:jpanzer@google.com]
Sent: Thursday, December 13, 2012 12:18 PM
To: webfinger@googlegroups= .com
Cc: Paul E. Jones; webfinger@ietf.org


Subject: Re: [webfinger] secure links with htt= ps rels

=C2=A0

Right. =C2=A0This = is also why you need this attribute as part of the official "name"= ; of the link relation, so the client knows which ones are supposed to be s= ecure with a simple .startsWith("https") type of check. =C2=A0Any= thing more complicated will create more security issues. =C2=A0(A registry = of relations which tells you which link relations are secure-only might wor= k but only if it could be kept up to date on all clients...)<= /span>

=C2=A0=

I still don&= #39;t understand what the client will do with rel=3D"canonical" t= hough. =C2=A0Does WebFinger exclude registered rel-values? =C2=A0They don&#= 39;t have to be URIs.

--
= John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



= On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

On Thu, Dec 13, 2012 at 8:45 AM= , Paul E. Jones <paulej@packetizer.com> wrote:

Don=E2=80=99t put it o= n the wire.=C2=A0 You want the server to filter before sending a reply.

=C2= =A0

I&#= 39;m concerned you're still confused about how a downgrade attack works= .

=C2=A0

Again: it DOES NOT MATTER wha= t the server thinks it's filtering if the client has been tricked into = talking to a DIFFERENT SERVER which is then returning malicious results.=

=C2=A0

Such as:

-- client wants "all link= s" for foo@exampl= e.com.

-- EVIL HIJACKER BLOCKS PORT 4= 43

-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:

=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0{

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if"">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"rel" : "= https://ope= nid.net/connect/server",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"type" : "text/html",=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"href" : &quo= t;https://att= acker.openid.server/"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0},

=C2=A0

See what happened there?

We need the *client* to say "whoa whoa, wait a minute... I = contacted this webfinger server over HTTP---- what's it doing returning= rels starting with https:? I'm gonna skip over those (or just return a= n error)."

=C2=A0

The real webfinger server _wa= s never even contacted_, so it doesn't matter whether it was filtering = or not.

=C2=A0

 ------=_NextPart_000_08F1_01CDD982.45EFC610-- From jasnell@gmail.com Thu Dec 13 19:38:41 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EDF21F88CC for ; Thu, 13 Dec 2012 19:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsOxJlbmRIfH for ; Thu, 13 Dec 2012 19:38:40 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74721F8861 for ; Thu, 13 Dec 2012 19:38:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so5243488ieb.31 for ; Thu, 13 Dec 2012 19:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ngQjLdec5cww8qXr+6OgbvGHCGw+DX8hFdUcUqejHdc=; b=pHWjxOy1BQpFURl44sbeK+dszeENiwluecHUIdSTvnuxMZ5J5KXP8Mx1UXXFne7iM2 kbslI3Ueddtz6E4hzk5MDMkeInaTIrSuecnWH3j7aiHGcUZsNvyuJeWbI3zrroV0BJKv AUBb4h9acqWRmAG1SDsg3qnfPynkOXm8tyAVsPq2v/XtmXjoabFfkNEb14DeJZpwu/ku //AQ1CpjO5hqyLmzG/Do+LsNZUY9YR8+fd8cQikDS/J5H4UQUVQaYB4QHEAx/1w56qnQ XSD10BNt6l9YSEmbtsAlLLAKuv+ZyBhEdKONf2ylsPglxHb3hXXDnMSu3W7zjvHfbw95 ABSQ== MIME-Version: 1.0 Received: by 10.50.151.165 with SMTP id ur5mr426357igb.24.1355456319574; Thu, 13 Dec 2012 19:38:39 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 19:38:39 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 13 Dec 2012 19:38:39 -0800 (PST) In-Reply-To: <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> Date: Thu, 13 Dec 2012 19:38:39 -0800 Message-ID: From: James M Snell To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f23541d6fd2b704d0c7c4d0 Cc: webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:38:41 -0000 --e89a8f23541d6fd2b704d0c7c4d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Failure of a request is perfectly acceptable. If the client needs a secured connection and the server simply does not provide for it, the client simply won't use that server. Simple as that. On Dec 13, 2012 7:36 PM, "Paul E. Jones" wrote: > James, et al,**** > > ** ** > > I that text still seemed to be controversial, since it would mean there i= s > a possibility that clients requiring secure connections would fail when a > domain did not implement WF on HTTPS.**** > > ** ** > > Let me present it again:**** > > ** ** > > Clients MAY issue a query to the WebFinger server using either**** > > HTTPS or HTTP, but MUST NOT attempt to use both, either serially**** > > or in parallel. The choice of transport protocols depends on the**** > > client=E2=80=99s security requirements, though use of HTTPS is**** > > RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS and the server has an invalid**** > > certificate, the server returns a 4xx or 5xx status code, or the**** > > HTTPS connection cannot be established for any reason, the client**** > > MUST accept that the WebFinger query has failed and MUST NOT**** > > attempt to reissue the WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using**** > > an appropriate HTTP status code to another HTTP or an HTTPS URI.**** > > Likewise, WebFinger servers operating on HTTPS MAY redirect a**** > > client to another HTTPS URI, but MUST NOT redirect a client to an**** > > HTTP URI. Further, clients MUST NOT follow a redirection from an**** > > HTTPS URI to an HTTP URI, but SHOULD automatically follow all**** > > other server redirects.**** > > ** ** > > Do we go with this or do we mandate HTTPS only? (I=E2=80=99ve tried to n= ot take a > position on this, but it does seem like the more we go back and forth and > discuss pros and cons, HTTPS is looking much simpler. It does mean domain > owners will have to get a certificate and it will not work on hosting > providers that do not support SNI. However, I would assume that the numb= er > of such providers is dwindling now that SNI has been in OpenSSL for a few > years.)**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Thursday, December 13, 2012 10:16 PM > *To:* Paul E. Jones > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] The HTTP/HTTPS Issue**** > > ** ** > > > On Dec 13, 2012 6:54 PM, "Paul E. Jones" wrote: > > > > Folks, > > > > > > > > I=E2=80=99m not sure we=E2=80=99re any closer to agreement, but I don= =E2=80=99t think so. > > > > > > > > What if we require servers to support both HTTP (directly or redirected > to HTTPS) and HTTPS, then letting the client select the transport it want= s > to use given its own security requirements? > >**** > > The spec language you posted earlier, with the changes you and I > discussed, is spot on.**** > > -1 to mandating HTTPS.**** > > - James**** > > > > > > > Paul > > > > > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > >**** > --e89a8f23541d6fd2b704d0c7c4d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Failure of a request is perfectly acceptable. If the client = needs a secured connection and the server simply does not provide for it, t= he client simply won't use that server. Simple as that.

On Dec 13, 2012 7:36 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:

James, et=C2=A0 al,

=

=C2=A0

I that text still seemed to be controversi= al, since it would mean there is a possibility that clients requiring secur= e connections would fail when a domain did not implement WF on HTTPS.

=C2=A0

Let me present it a= gain:

=C2=A0

=C2=A0=C2=A0=C2=A0 Clients MAY issue a = query to the WebFinger server using either

=C2=A0=C2=A0=C2=A0 HTTPS or HTTP, but MUST NO= T attempt to use both, either serially

=C2=A0=C2=A0=C2=A0 or in parallel.=C2=A0 The choice of tr= ansport protocols depends on the

=C2=A0=C2=A0=C2=A0 client=E2=80=99s security = requirements, though use of HTTPS is

=C2=A0=C2=A0=C2=A0 RECOMMENDED in most situations.

=C2=A0

=C2=A0=C2=A0=C2=A0 If a query is issued using HTTPS and the= server has an invalid

=C2=A0=C2=A0=C2=A0 certificate, the server re= turns a 4xx or 5xx status code, or the

=C2=A0=C2=A0=C2=A0 HTTPS connection cannot be established= for any reason, the client

=C2=A0=C2=A0=C2=A0 MUST accept that the WebFi= nger query has failed and MUST NOT

=C2=A0=C2=A0=C2=A0 attempt to reissue the WebFinger request u= sing HTTP.

=C2=A0

=C2=A0=C2=A0=C2=A0 WebFinger servers operating on HTTP MAY = redirect a client using

=C2=A0=C2=A0=C2=A0 an appropriate HTTP status= code to another HTTP or an HTTPS URI.

=C2=A0=C2=A0=C2=A0 Likewise, WebFinger servers operating = on HTTPS MAY redirect a

=C2=A0=C2=A0=C2=A0 client to another HTTPS UR= I, but MUST NOT redirect a client to an

=C2=A0=C2=A0=C2=A0 HTTP URI.=C2=A0 Further, clients MUST= NOT follow a redirection from an

=C2=A0=C2=A0=C2=A0 HTTPS URI to an HTTP URI, = but SHOULD automatically follow all

=C2=A0=C2=A0=C2=A0 other server redirects.

=C2=A0

Do we go with this = or do we mandate HTTPS only?=C2=A0 (I=E2=80=99ve tried to not take a positi= on on this, but it does seem like the more we go back and forth and discuss= pros and cons, HTTPS is looking much simpler. It does mean domain owners w= ill have to get a certificate and it will not work on hosting providers tha= t do not support SNI.=C2=A0 However, I would assume that the number of such= providers is dwindling now that SNI has been in OpenSSL for a few years.)<= u>

=C2=A0

Paul<= /span>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Thursday, December 13, 2012 10:16 PM
To: Paul E. Jon= es
Cc: we= bfinger@ietf.org
Subject: Re: [webfinger] The HTTP/HTTPS Issu= e

=C2=A0


On Dec 13= , 2012 6:54 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
><= br>> Folks,
>
> =C2=A0
>
> I=E2=80=99m not sure we=E2=80=99re any = closer to agreement, but I don=E2=80=99t think so.
>
> =C2=A0>
> What if we require servers to support both HTTP (directly or= redirected to HTTPS) and HTTPS, then letting the client select the transpo= rt it wants to use given its own security requirements?
>

The spec language you posted earlier, with the cha= nges you and I discussed, is spot on.

-1 to mandating H= TTPS.

- James

> =C2=A0
> > Paul
>
> =C2=A0
>
>
> __________________= _____________________________
> webfinger mailing list
> webfinger@ietf.org> https://www.ietf.org/mailman/listinfo/webfinger
>

--e89a8f23541d6fd2b704d0c7c4d0-- From breno.demedeiros@gmail.com Thu Dec 13 20:00:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0921F8A53 for ; Thu, 13 Dec 2012 20:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZYH7Ze8Pnvx for ; Thu, 13 Dec 2012 20:00:22 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6516221F88BE for ; Thu, 13 Dec 2012 20:00:22 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1940980pad.31 for ; Thu, 13 Dec 2012 20:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cUsUdUuEnSmNvow7aZxqfS0kB4WpAKc57VFQg2nrz74=; b=D7v1KVlFLFCiBrgFBjmrLOK+MkvejYQRokNSnhhnELLwwK62c7JlQlIlFLSzOU8Oym IDy7yAksX3bZvY0vhOZi8fE7lUpeCcveQcivU+faBSliutS6VKeedObaCXx0JZTnXyuQ jNILfk7whV5tr6oKJIaLV0aQh2pCJDMueFZ3F/4/tEaWGSuARpqCfxlAeGjSK38cwuDq HaHLJ/waRXYlc6rdpxOno1W2JtLzrfCC6VEQ2SKoqjVVXxsGKfYiqs02COljWnl37DG6 7fetHn99OmI5n6PQUe85ShNX9rUAnWdegCcKmf8NFlLgL3l4dxChJmLO7dwi/kicAYMa QN3w== MIME-Version: 1.0 Received: by 10.66.77.99 with SMTP id r3mr12546557paw.10.1355457622161; Thu, 13 Dec 2012 20:00:22 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:00:21 -0800 (PST) In-Reply-To: <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> Date: Thu, 13 Dec 2012 20:00:21 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Brad Fitzpatrick , James M Snell , Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:00:23 -0000 On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones wrot= e: > Brad, > > > > I really don=92t like the secure-rels idea. If a rel is secure or should= be > treated as secure, I can mark it as such on the server without creating m= ore > names and cluttering up the link relation name space with multiple varian= ts > of the same thing. As explained above, this does not address HTTP-fallback degrade attacks. > > > > There were several people opposed to the client fall back text due to bot= h > security concerns and client-side complexity. That was one of the main > items we addressed with this latest proposal re-write. The proposal re-write does not seem to address any complexity. It simply removes guidance that would ensure implementations that can be 'plugged in' both in insecure and secure contexts. The likely result are simpler implementations that can't be used in secure contexts, even if they may make a claim to the contrary. > > > > I do realize the flakiness of the proposed solution. Yes. It's too flaky for the purposes of secure discovery. > Sometimes, the client > just does not work. You type in paulej@packetizer.com and it says =93cou= ld > not find a thing=94, because the client only issued the query over HTTPS.= If > one needs security, I see on other way. However, if we=92re willing to g= o > back to the -07 text that has an allowance for fall back, the issue is > addressed. In the -07 text, a client MAY re-issue a request using HTTP. > > > > Paul > > > > From: Brad Fitzpatrick [mailto:bradfitz@google.com] > Sent: Thursday, December 13, 2012 6:15 PM > To: Paul E. Jones > Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; > webfinger@ietf.org > > > Subject: Re: [webfinger] secure links with https rels > > > > On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones > wrote: > > Walter, > > > > No, this will not work. People want to have secure content and what is > secure might be determined by the server admin or user. One might consid= er > his avatar should be served over HTTPS only. > > > > And people do not want to have to write clients that do fallback. > > > > I never saw any strong opposition against fallback. People disliked the > extra complexity, but for quite awhile everybody assumed that fallback wo= uld > be involved, and I think it was considered acceptable. > > > > Who was strongly anti-fallback? > > > > > > We either have to do HTTPS only or we have to live with the fact that som= e > client requests are going to fail if a WF provider does not provide WF > services over HTTPS. > > > > I strongly disagree that those are the only two options. > > > > But if you really believe that, I hope you realize that flakiness is > unacceptable, which leaves you with HTTPS-only. > > > > If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with > HTTPS-only. > > > > So, > > 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS > > 2) Servers and clients MAY implement HTTP > > 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated= as > secure since it allows for a MITM attack) > > 4) Servers MUST NOT redirect from HTTPS to HTTP > > > > All works well, except for the case where you have an HTTPS-only client. > But, I bet that will be the majority of clients, which will then drive th= e > majority of the servers to support HTTPS. > > > > This is a terrible cop-out. Flakiness in the spec is unacceptable. > > > > Still, it leaves the option on the table for some clients and servers to > use HTTP if they wish. > > > > --=20 Breno de Medeiros From breno.demedeiros@gmail.com Thu Dec 13 20:08:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A2321F8BBA for ; Thu, 13 Dec 2012 20:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMVQC+liwGnO for ; Thu, 13 Dec 2012 20:08:58 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4803021F8B95 for ; Thu, 13 Dec 2012 20:08:58 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1945409pad.31 for ; Thu, 13 Dec 2012 20:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PQTTGDs5gBJhTkcHB2h7NAhajGwZx9WyZM0mFUxhSA4=; b=uXXvXK8mkUFn10h5mv/QDhycdINxLrInnriS7oeey9Ws99xS7Tb5IVyeck90WgusQk kstm1wucQAwTFnC2kfLa/MiUJ38rePc6HwhhpG7zJ8+tGhI/Ijsnf4uXwJFJEr9g+rNm bJRDXh/s5zCoqez9GMRsEBZKufVuSREptNg2PAiPaXkBxeJ9QJQF2H1R1bWll4pyU8rZ RpEub76NZJ04KsPRyytjruxR2sBNK5+Q0LHoMLE5GhH8J3KGNFNScisqrn+Fj6Szv+b5 k2xNDRb9Np7rBQHw0GJlIYq+83yaI2KEZj4/nzXt8/lcB9ZJwRkCFtMVtDCwJY3xDk/H JfzQ== MIME-Version: 1.0 Received: by 10.68.189.233 with SMTP id gl9mr11785130pbc.166.1355458138016; Thu, 13 Dec 2012 20:08:58 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:08:57 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> Date: Thu, 13 Dec 2012 20:08:57 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Brad Fitzpatrick , James M Snell , Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:08:59 -0000 Also, I reject the notion that WF standard should be simple for clients. If we want WF to be widely deployed, we make it easier for servers so that the information is ubiquitously deployed even by users and companies that are unsophisticated. In contrast, standard-compliant WF clients are probably going to be less common. Even if WF is not too complex, why wouldn't you use a library if you want to have some guarantee like security? If you want to simply write a few curl commands and mesh the data after applying your homebrew parser, you neither care for standard compliance or security, and you still can get things done because the underlying data schema is simple. On Thu, Dec 13, 2012 at 8:00 PM, Breno wrote: > On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones wr= ote: >> Brad, >> >> >> >> I really don=92t like the secure-rels idea. If a rel is secure or shoul= d be >> treated as secure, I can mark it as such on the server without creating = more >> names and cluttering up the link relation name space with multiple varia= nts >> of the same thing. > > As explained above, this does not address HTTP-fallback degrade attacks. > >> >> >> >> There were several people opposed to the client fall back text due to bo= th >> security concerns and client-side complexity. That was one of the main >> items we addressed with this latest proposal re-write. > > The proposal re-write does not seem to address any complexity. It > simply removes guidance that would ensure implementations that can be > 'plugged in' both in insecure and secure contexts. The likely result > are simpler implementations that can't be used in secure contexts, > even if they may make a claim to the contrary. > >> >> >> >> I do realize the flakiness of the proposed solution. > > Yes. It's too flaky for the purposes of secure discovery. > >> Sometimes, the client >> just does not work. You type in paulej@packetizer.com and it says =93co= uld >> not find a thing=94, because the client only issued the query over HTTPS= . If >> one needs security, I see on other way. However, if we=92re willing to = go >> back to the -07 text that has an allowance for fall back, the issue is >> addressed. In the -07 text, a client MAY re-issue a request using HTTP. >> >> >> >> Paul >> >> >> >> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >> Sent: Thursday, December 13, 2012 6:15 PM >> To: Paul E. Jones >> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >> webfinger@ietf.org >> >> >> Subject: Re: [webfinger] secure links with https rels >> >> >> >> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones >> wrote: >> >> Walter, >> >> >> >> No, this will not work. People want to have secure content and what is >> secure might be determined by the server admin or user. One might consi= der >> his avatar should be served over HTTPS only. >> >> >> >> And people do not want to have to write clients that do fallback. >> >> >> >> I never saw any strong opposition against fallback. People disliked the >> extra complexity, but for quite awhile everybody assumed that fallback w= ould >> be involved, and I think it was considered acceptable. >> >> >> >> Who was strongly anti-fallback? >> >> >> >> >> >> We either have to do HTTPS only or we have to live with the fact that so= me >> client requests are going to fail if a WF provider does not provide WF >> services over HTTPS. >> >> >> >> I strongly disagree that those are the only two options. >> >> >> >> But if you really believe that, I hope you realize that flakiness is >> unacceptable, which leaves you with HTTPS-only. >> >> >> >> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with >> HTTPS-only. >> >> >> >> So, >> >> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >> >> 2) Servers and clients MAY implement HTTP >> >> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treate= d as >> secure since it allows for a MITM attack) >> >> 4) Servers MUST NOT redirect from HTTPS to HTTP >> >> >> >> All works well, except for the case where you have an HTTPS-only client. >> But, I bet that will be the majority of clients, which will then drive t= he >> majority of the servers to support HTTPS. >> >> >> >> This is a terrible cop-out. Flakiness in the spec is unacceptable. >> >> >> >> Still, it leaves the option on the table for some clients and servers t= o >> use HTTP if they wish. >> >> >> >> > > > > -- > Breno de Medeiros --=20 Breno de Medeiros From breno.demedeiros@gmail.com Thu Dec 13 20:19:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905B221F8899 for ; Thu, 13 Dec 2012 20:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74CQYsysIaro for ; Thu, 13 Dec 2012 20:19:33 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDDEF21F8883 for ; Thu, 13 Dec 2012 20:19:33 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1139220dae.31 for ; Thu, 13 Dec 2012 20:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LKszRKS9QWUqzQDSOCYC40YYDKp7ZKm2o5cer2PJAI4=; b=QIqh7EvX11Sj7E9MNsYaaVimKGdkYkfVtZztQ+dgPkn5UEsxfyIO3SRiwUOD4JCVD8 bbL3zbaEUzV7IqmQOzCUd3Y7LA8KVjcQ54EpE+vpe3sJlPV99xTDPaln18eh4WKDw5xI m8w1/axyMYndhTmEchKuiU2SHraZW6iEgXSvzFRmZ7Ym2tF8lbk5uCW0tXHFfrAOX9Sz zOBHhClhLkxKC05k9Xcb8AaWClYpvpYhI6Y16DZmo6E9GFSmjYDTbrwDKEFQ1V92i8Vr vyoChLklD5pBu7MSStPMv5/JbSqCy0W1hNq73pQXFwPhnhxnY/GTwtwGEE1pIoS2/xwr 7NOQ== MIME-Version: 1.0 Received: by 10.68.143.129 with SMTP id se1mr12357647pbb.67.1355458773579; Thu, 13 Dec 2012 20:19:33 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:19:33 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> Date: Thu, 13 Dec 2012 20:19:33 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Brad Fitzpatrick , James M Snell , Goix Laurent Walter , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:19:34 -0000 I will go further: Security is best served by simplicity: If HTTPS was only allowable protocol, that'd be the best approach security-wise. If simplicity is not available (and the decision to allow HTTPS and HTTP means it isn't), then a fully specified behavior, in all it's glorious complexity, is required for security. If that discourages the proliferation of low-quality I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client implementations, so much better for security. Put all eggs in one basket and watch that basket. The current compromise where we pretend that we can have simple client specification that allows for both complex behavior and secure operation is a smokescreen. Just add a disclaimer that WF is not intended to use in secure contexts, at least it'd be honest. On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote: > Also, I reject the notion that WF standard should be simple for > clients. If we want WF to be widely deployed, we make it easier for > servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated. > > In contrast, standard-compliant WF clients are probably going to be > less common. Even if WF is not too complex, why wouldn't you use a > library if you want to have some guarantee like security? If you want > to simply write a few curl commands and mesh the data after applying > your homebrew parser, you neither care for standard compliance or > security, and you still can get things done because the underlying > data schema is simple. > > On Thu, Dec 13, 2012 at 8:00 PM, Breno wrote= : >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones w= rote: >>> Brad, >>> >>> >>> >>> I really don=92t like the secure-rels idea. If a rel is secure or shou= ld be >>> treated as secure, I can mark it as such on the server without creating= more >>> names and cluttering up the link relation name space with multiple vari= ants >>> of the same thing. >> >> As explained above, this does not address HTTP-fallback degrade attacks. >> >>> >>> >>> >>> There were several people opposed to the client fall back text due to b= oth >>> security concerns and client-side complexity. That was one of the main >>> items we addressed with this latest proposal re-write. >> >> The proposal re-write does not seem to address any complexity. It >> simply removes guidance that would ensure implementations that can be >> 'plugged in' both in insecure and secure contexts. The likely result >> are simpler implementations that can't be used in secure contexts, >> even if they may make a claim to the contrary. >> >>> >>> >>> >>> I do realize the flakiness of the proposed solution. >> >> Yes. It's too flaky for the purposes of secure discovery. >> >>> Sometimes, the client >>> just does not work. You type in paulej@packetizer.com and it says =93c= ould >>> not find a thing=94, because the client only issued the query over HTTP= S. If >>> one needs security, I see on other way. However, if we=92re willing to= go >>> back to the -07 text that has an allowance for fall back, the issue is >>> addressed. In the -07 text, a client MAY re-issue a request using HTTP= . >>> >>> >>> >>> Paul >>> >>> >>> >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >>> Sent: Thursday, December 13, 2012 6:15 PM >>> To: Paul E. Jones >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >>> webfinger@ietf.org >>> >>> >>> Subject: Re: [webfinger] secure links with https rels >>> >>> >>> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones >>> wrote: >>> >>> Walter, >>> >>> >>> >>> No, this will not work. People want to have secure content and what is >>> secure might be determined by the server admin or user. One might cons= ider >>> his avatar should be served over HTTPS only. >>> >>> >>> >>> And people do not want to have to write clients that do fallback. >>> >>> >>> >>> I never saw any strong opposition against fallback. People disliked th= e >>> extra complexity, but for quite awhile everybody assumed that fallback = would >>> be involved, and I think it was considered acceptable. >>> >>> >>> >>> Who was strongly anti-fallback? >>> >>> >>> >>> >>> >>> We either have to do HTTPS only or we have to live with the fact that s= ome >>> client requests are going to fail if a WF provider does not provide WF >>> services over HTTPS. >>> >>> >>> >>> I strongly disagree that those are the only two options. >>> >>> >>> >>> But if you really believe that, I hope you realize that flakiness is >>> unacceptable, which leaves you with HTTPS-only. >>> >>> >>> >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy wit= h >>> HTTPS-only. >>> >>> >>> >>> So, >>> >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >>> >>> 2) Servers and clients MAY implement HTTP >>> >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treat= ed as >>> secure since it allows for a MITM attack) >>> >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >>> >>> >>> >>> All works well, except for the case where you have an HTTPS-only client= . >>> But, I bet that will be the majority of clients, which will then drive = the >>> majority of the servers to support HTTPS. >>> >>> >>> >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. >>> >>> >>> >>> Still, it leaves the option on the table for some clients and servers = to >>> use HTTP if they wish. >>> >>> >>> >>> >> >> >> >> -- >> Breno de Medeiros > > > > -- > Breno de Medeiros --=20 Breno de Medeiros From paulej@packetizer.com Thu Dec 13 20:36:19 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6421F8C04 for ; Thu, 13 Dec 2012 20:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvGkSFPccBuI for ; Thu, 13 Dec 2012 20:36:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A162A21F8C01 for ; Thu, 13 Dec 2012 20:36:18 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE4aFmM031611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 23:36:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355459775; bh=Ru+xkkhknQaaCNMRMKZCeHHQnMppJy019Vn/TFPVxsM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OoC7ixEOUEiZ9m6jDdcCg8PWT/ReEFuP7Wf3ObsEbjAnca7xflzh7LuUvxiqnDu+8 dtDm0j2rAvjdTSXyPFN6OtU0wRfewAR5HmgSmybHF6JXiezCmlAFdz/iis9rzTSscW mFWbmC5kMxOWaT1LSQqQe2J+O89oANvKgKUfpapk= From: "Paul E. Jones" To: "'Breno'" , References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <0! 7ee01cdd987$3827d7c0$a8 778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 23:36:27 -0500 Message-ID: <091201cdd9b4$95122f30$bf368d90$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCyk61iAJm5c6BAgdFug0CAx/yoQFnDvE4l7OEL+A= Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'James M Snell' , 'Goix Laurent Walter' , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:36:19 -0000 > Also, I reject the notion that WF standard should be simple for clients. > If we want WF to be widely deployed, we make it easier for servers so > that the information is ubiquitously deployed even by users and > companies that are unsophisticated. > > In contrast, standard-compliant WF clients are probably going to be less > common. Even if WF is not too complex, why wouldn't you use a library if > you want to have some guarantee like security? If you want to simply > write a few curl commands and mesh the data after applying your homebrew > parser, you neither care for standard compliance or security, and you > still can get things done because the underlying data schema is simple. Your opinion conflicts with nearly every other statement on where complexity should be. I tend to agree with others on this one: we should strive for simplicity in the client, though my own server is pretty darn simple. There just isn't much complexity to WF. The *only* thing I think is complex is having to query using HTTPS and then HTTP if the server does not reply. It's not just complexity, but also a matter of delay. We should strive to reduce the time it takes to return a WF reply. Paul From bradfitz@google.com Thu Dec 13 20:37:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1A021F8C06 for ; Thu, 13 Dec 2012 20:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4F6vGMQuB6A for ; Thu, 13 Dec 2012 20:37:10 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03AA321F8C04 for ; Thu, 13 Dec 2012 20:37:09 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so334031qan.10 for ; Thu, 13 Dec 2012 20:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LMkMO663E8936qzsWc6UPc+HAkAyyqw4QrCt3yQLQfA=; b=fZcgrl7W9+FkjKirKk3TG4oGYedWrP6GncEWJrRX0GJk7R2/UWhIqrwY0HdnLvmYQA UXmuJnPiKteSWTee05q1QjYKufdkCQoz9OvbQlng5d/vyWjz+Df4BovAqFpZBTwbnBsU 983GfHBe0WAEESJ7Fv78aM6MnpYnhUFu5wSfPGBPs3W73B3XbORN57stOEpP9x1afA7d M8xclOIr4IEple/OBD0klzinxyaeI00WtkRAWstLImqf0Xehx5/wdy83mAhj72Tk9Fbk vRyIYrjWoWn4uesGOLCJdGt7FdJCOoKsEahbyTfmjAaWv/tWTDNj67zSQJEm5xMV2Z1v 585g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LMkMO663E8936qzsWc6UPc+HAkAyyqw4QrCt3yQLQfA=; b=kmnb1QoIKqmrlmQlEvwtaoBWBS3yrGJI8UFqUjLhBCD4OvQvVUqlZ8iNgteTDauBIC d6nDE63EbNPbqlxhpsTW6N4Y/AGhxsPGps57U1TQX0Z9jWcMfAFkW+rxDgjvm8eDoUzu VOGOU4/6giMF6x4rf0A8I9MkW+PPlZhtHoveAUejnSCn2apL7xVx513AVGdoNCEC3G5x cKBfbXgFZ87A5f0OzB3KDLxw9Y5drAzyKsp46phpduwZ/La3CtA6BxENIErowSLssYVZ VDlSJiefAitCl6avl1DAQsr40GSetLye2BbnIQ2fZpo89nFC59+4X01m52R8/dKlJXes HrSA== MIME-Version: 1.0 Received: by 10.224.222.14 with SMTP id ie14mr1975316qab.61.1355459829336; Thu, 13 Dec 2012 20:37:09 -0800 (PST) Received: by 10.224.96.19 with HTTP; Thu, 13 Dec 2012 20:37:09 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> Date: Thu, 13 Dec 2012 20:37:09 -0800 Message-ID: From: Brad Fitzpatrick To: Breno , webfinger@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b45ca28c0704d0c89596 X-Gm-Message-State: ALoCoQkSbML2ScKsjbI143SaSja2hmWc+eoP6foBAPBICcMyNOwyQDRkK6IH45ABI6dNkAXsd7Bo/c7mgbyFrBo4WVSOrmXMIuilI57dc6YPm9XqJ12RuWm9K6VchCINFJrz4ALTVLi4XNkh95Rev7zjZnU/CZDZXEoi6QftgSr/PwjRhIFHje3nHEfHJMzVVPcU75bKceqk Cc: James M Snell , webfinger@googlegroups.com, Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:37:11 -0000 --20cf3074b45ca28c0704d0c89596 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Breno, in all his points and previous emails. Again, I will repeat myself: we can have at most two of these three: 1) security 2) support HTTP servers 3) simple clients We don't get all 3. We get at most 2. I think everybody wants 1), so that leave us deciding between 2) and 3) as our other feature. Which is it? HTTP servers or simple clients? On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote: > I will go further: > > Security is best served by simplicity: If HTTPS was only allowable > protocol, that'd be the best approach security-wise. > > If simplicity is not available (and the decision to allow HTTPS and > HTTP means it isn't), then a fully specified behavior, in all it's > glorious complexity, is required for security. If that discourages the > proliferation of low-quality > I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client > implementations, so much better for security. Put all eggs in one > basket and watch that basket. > > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure > operation is a smokescreen. Just add a disclaimer that WF is not > intended to use in secure contexts, at least it'd be honest. > > On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote= : > > Also, I reject the notion that WF standard should be simple for > > clients. If we want WF to be widely deployed, we make it easier for > > servers so that the information is ubiquitously deployed even by users > > and companies that are unsophisticated. > > > > In contrast, standard-compliant WF clients are probably going to be > > less common. Even if WF is not too complex, why wouldn't you use a > > library if you want to have some guarantee like security? If you want > > to simply write a few curl commands and mesh the data after applying > > your homebrew parser, you neither care for standard compliance or > > security, and you still can get things done because the underlying > > data schema is simple. > > > > On Thu, Dec 13, 2012 at 8:00 PM, Breno > wrote: > >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones > wrote: > >>> Brad, > >>> > >>> > >>> > >>> I really don=E2=80=99t like the secure-rels idea. If a rel is secure= or > should be > >>> treated as secure, I can mark it as such on the server without > creating more > >>> names and cluttering up the link relation name space with multiple > variants > >>> of the same thing. > >> > >> As explained above, this does not address HTTP-fallback degrade attack= s. > >> > >>> > >>> > >>> > >>> There were several people opposed to the client fall back text due to > both > >>> security concerns and client-side complexity. That was one of the ma= in > >>> items we addressed with this latest proposal re-write. > >> > >> The proposal re-write does not seem to address any complexity. It > >> simply removes guidance that would ensure implementations that can be > >> 'plugged in' both in insecure and secure contexts. The likely result > >> are simpler implementations that can't be used in secure contexts, > >> even if they may make a claim to the contrary. > >> > >>> > >>> > >>> > >>> I do realize the flakiness of the proposed solution. > >> > >> Yes. It's too flaky for the purposes of secure discovery. > >> > >>> Sometimes, the client > >>> just does not work. You type in paulej@packetizer.com and it says > =E2=80=9Ccould > >>> not find a thing=E2=80=9D, because the client only issued the query o= ver > HTTPS. If > >>> one needs security, I see on other way. However, if we=E2=80=99re wi= lling to > go > >>> back to the -07 text that has an allowance for fall back, the issue i= s > >>> addressed. In the -07 text, a client MAY re-issue a request using > HTTP. > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] > >>> Sent: Thursday, December 13, 2012 6:15 PM > >>> To: Paul E. Jones > >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; > >>> webfinger@ietf.org > >>> > >>> > >>> Subject: Re: [webfinger] secure links with https rels > >>> > >>> > >>> > >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones > >>> wrote: > >>> > >>> Walter, > >>> > >>> > >>> > >>> No, this will not work. People want to have secure content and what = is > >>> secure might be determined by the server admin or user. One might > consider > >>> his avatar should be served over HTTPS only. > >>> > >>> > >>> > >>> And people do not want to have to write clients that do fallback. > >>> > >>> > >>> > >>> I never saw any strong opposition against fallback. People disliked > the > >>> extra complexity, but for quite awhile everybody assumed that fallbac= k > would > >>> be involved, and I think it was considered acceptable. > >>> > >>> > >>> > >>> Who was strongly anti-fallback? > >>> > >>> > >>> > >>> > >>> > >>> We either have to do HTTPS only or we have to live with the fact that > some > >>> client requests are going to fail if a WF provider does not provide W= F > >>> services over HTTPS. > >>> > >>> > >>> > >>> I strongly disagree that those are the only two options. > >>> > >>> > >>> > >>> But if you really believe that, I hope you realize that flakiness is > >>> unacceptable, which leaves you with HTTPS-only. > >>> > >>> > >>> > >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy > with > >>> HTTPS-only. > >>> > >>> > >>> > >>> So, > >>> > >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS > >>> > >>> 2) Servers and clients MAY implement HTTP > >>> > >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as > >>> secure since it allows for a MITM attack) > >>> > >>> 4) Servers MUST NOT redirect from HTTPS to HTTP > >>> > >>> > >>> > >>> All works well, except for the case where you have an HTTPS-only > client. > >>> But, I bet that will be the majority of clients, which will then driv= e > the > >>> majority of the servers to support HTTPS. > >>> > >>> > >>> > >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. > >>> > >>> > >>> > >>> Still, it leaves the option on the table for some clients and server= s > to > >>> use HTTP if they wish. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Breno de Medeiros > > > > > > > > -- > > Breno de Medeiros > > > > -- > Breno de Medeiros > --20cf3074b45ca28c0704d0c89596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= agree with Breno, in all his points and previous emails.

Again, I will repeat myself: =C2=A0we can have at most two of these three= :

1) security
2) support HTTP servers
3) simple clients

We don't get all 3. =C2=A0W= e get at most 2.

I think everybody wants 1), so th= at leave us deciding between 2) and 3) as our other feature.

Which is it? =C2=A0HTTP servers or simple clients?


On Thu, Dec 13, 2012 at 8:19 = PM, Breno <breno.demedeiros@gmail.com> wrote:
I will go further:

Security is best served by simplicity: If HTTPS was only allowable
protocol, that'd be the best approach security-wise.

If simplicity is not available (and the decision to allow HTTPS and
HTTP means it isn't), then a fully specified behavior, in all it's<= br> glorious complexity, is required for security. If that discourages the
proliferation of low-quality
I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client
implementations, so much better for security. Put all eggs in one
basket and watch that basket.

The current compromise where we pretend that we can have simple client
specification that allows for both complex behavior and secure
operation is a smokescreen. Just add a disclaimer that WF is not
intended to use in secure contexts, at least it'd be honest.

On Thu, Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrote:
> Also, I reject the notion that WF standard should be simple for
> clients. If we want WF to be widely deployed, we make it easier for > servers so that the information is ubiquitously deployed even by users=
> and companies that are unsophisticated.
>
> In contrast, standard-compliant WF clients are probably going to be > less common. Even if WF is not too complex, why wouldn't you use a=
> library if you want to have some guarantee like security? If you want<= br> > to simply write a few curl commands and mesh the data after applying > your homebrew parser, you neither care for standard compliance or
> security, and you still can get things done because the underlying
> data schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM, Breno <breno.demedeiros@gmail.com> wrote:
>> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> Brad,
>>>
>>>
>>>
>>> I really don=E2=80=99t like the secure-rels idea. =C2=A0If a r= el is secure or should be
>>> treated as secure, I can mark it as such on the server without= creating more
>>> names and cluttering up the link relation name space with mult= iple variants
>>> of the same thing.
>>
>> As explained above, this does not address HTTP-fallback degrade at= tacks.
>>
>>>
>>>
>>>
>>> There were several people opposed to the client fall back text= due to both
>>> security concerns and client-side complexity. =C2=A0That was o= ne of the main
>>> items we addressed with this latest proposal re-write.
>>
>> The proposal re-write does not seem to address any complexity. It<= br> >> simply removes guidance that would ensure implementations that can= be
>> 'plugged in' both in insecure and secure contexts. The lik= ely result
>> are simpler implementations that can't be used in secure conte= xts,
>> even if they may make a claim to the contrary.
>>
>>>
>>>
>>>
>>> I do realize the flakiness of the proposed solution.
>>
>> Yes. It's too flaky for the purposes of secure discovery.
>>
>>> Sometimes, the client
>>> just does not work. =C2=A0You type in paulej@packetizer.com and it says =E2=80=9Ccould
>>> not find a thing=E2=80=9D, because the client only issued the = query over HTTPS. =C2=A0If
>>> one needs security, I see on other way. =C2=A0However, if we= =E2=80=99re willing to go
>>> back to the -07 text that has an allowance for fall back, the = issue is
>>> addressed. =C2=A0In the -07 text, a client MAY re-issue a requ= est using HTTP.
>>>
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>> From: Brad Fitzpatrick [mailto:bradfitz@google.com]
>>> Sent: Thursday, December 13, 2012 6:15 PM
>>> To: Paul E. Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell;
>>> webfinger@ietf.org >>>
>>>
>>> Subject: Re: [webfinger] secure links with https rels
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>
>>> wrote:
>>>
>>> Walter,
>>>
>>>
>>>
>>> No, this will not work. =C2=A0People want to have secure conte= nt and what is
>>> secure might be determined by the server admin or user. =C2=A0= One might consider
>>> his avatar should be served over HTTPS only.
>>>
>>>
>>>
>>> And people do not want to have to write clients that do fallba= ck.
>>>
>>>
>>>
>>> I never saw any strong opposition against fallback. =C2=A0Peop= le disliked the
>>> extra complexity, but for quite awhile everybody assumed that = fallback would
>>> be involved, and I think it was considered acceptable.
>>>
>>>
>>>
>>> Who was strongly anti-fallback?
>>>
>>>
>>>
>>>
>>>
>>> We either have to do HTTPS only or we have to live with the fa= ct that some
>>> client requests are going to fail if a WF provider does not pr= ovide WF
>>> services over HTTPS.
>>>
>>>
>>>
>>> I strongly disagree that those are the only two options.
>>>
>>>
>>>
>>> But if you really believe that, I hope you realize that flakin= ess is
>>> unacceptable, which leaves you with HTTPS-only.
>>>
>>>
>>>
>>> If the HTTPS-for-some-rels proposal still isn't clear, I&#= 39;d be happy with
>>> HTTPS-only.
>>>
>>>
>>>
>>> =C2=A0So,
>>>
>>> 1) =C2=A0 =C2=A0 =C2=A0Servers SHOULD implement HTTPS and clie= nts SHOULD use HTTPS
>>>
>>> 2) =C2=A0 =C2=A0 =C2=A0Servers and clients MAY implement HTTP<= br> >>>
>>> 3) =C2=A0 =C2=A0 =C2=A0Servers MAY redirect from HTTP to HTTPS= (this MUST NOT be treated as
>>> secure since it allows for a MITM attack)
>>>
>>> 4) =C2=A0 =C2=A0 =C2=A0Servers MUST NOT redirect from HTTPS to= HTTP
>>>
>>>
>>>
>>> All works well, except for the case where you have an HTTPS-on= ly client.
>>> But, I bet that will be the majority of clients, which will th= en drive the
>>> majority of the servers to support HTTPS.
>>>
>>>
>>>
>>> This is a terrible cop-out. =C2=A0Flakiness in the spec is una= cceptable.
>>>
>>>
>>>
>>> =C2=A0Still, it leaves the option on the table for some client= s and servers to
>>> use HTTP if they wish.
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Breno de Medeiros
>
>
>
> --
> Breno de Medeiros



--
Breno de Medeiros

--20cf3074b45ca28c0704d0c89596-- From bradfitz@google.com Thu Dec 13 20:40:44 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4259921F8C1B for ; Thu, 13 Dec 2012 20:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcvpu+meG4Qp for ; Thu, 13 Dec 2012 20:40:43 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B233A21F8C1A for ; Thu, 13 Dec 2012 20:40:43 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so345915qad.10 for ; Thu, 13 Dec 2012 20:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AVos2o12637jf6387Da4Ffb+BwGcsqHTJrHPF5pgJ2I=; b=O27uGomqPawT83vc6WGaQgj3sjzGrFh6ik8XvrkdoL3teDjuBOyfCp0Nv+6Fl7X+6X nYWzqPycbQDe45khsYd1AYzi8ug9eTr3FiQH4OzsdxzJsDZu4adUar5OXHhPDJn0rvXE 8ZLJcptpmSbXsvEydJi/Cy+jOza7js3CWE4CkTojR8MNYMu0Fhs7dLO3ddIiMLFBj+SI qPTlQtuBkF4ClMOYGPX2p7/jjoaw3HI/PoT+9a8DsMkfTyThCTwhYhUv4rCm1POnQOeM +BUuseNZLqXucAXluvkAdIYnhJtXrn6hL+QrC8NRBId5cF5p2gDJX8nzIAZO7iwKCGlv lySQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AVos2o12637jf6387Da4Ffb+BwGcsqHTJrHPF5pgJ2I=; b=mSNUNxrSN+1sptbWdIgAI+dfnNJ2+p40QWyrJverWTrPIJwXdD+geza/KysI37GDKZ pN6Q1VcHOI4F9ZKRAi01VDJhX7gxhErhIT2MkwmnnEsBSbcEFnmyHxNptz3FYA2sUxyR mdYQWONMGnL7YMRLx36foVzEDV76+sgQ3RBhEWdntV2A8ZOlHEDA6yUK7Ax8n8yIIF4A Xc0RgdAs+0WsdDyrjeVVaNygVvyF/zXUx3+OK/fDFLevkP44XTdlhqCoE6Bz+8yCGEBY LkYV2wtu5mGpq+BF3pU2UZxGehVF/Y7+godMGWwnV/1oV43x07hajF18B/w0ce2Uo6nQ W5Lg== MIME-Version: 1.0 Received: by 10.224.42.139 with SMTP id s11mr1970426qae.52.1355460043216; Thu, 13 Dec 2012 20:40:43 -0800 (PST) Received: by 10.224.96.19 with HTTP; Thu, 13 Dec 2012 20:40:43 -0800 (PST) In-Reply-To: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> Date: Thu, 13 Dec 2012 20:40:43 -0800 Message-ID: From: Brad Fitzpatrick To: James M Snell Content-Type: multipart/alternative; boundary=20cf3074d86262159204d0c8a22b X-Gm-Message-State: ALoCoQnUwBc77T+bs/ntg1ow2tcN8LVXaaGweDthJvaZDQitZQxV2RxA/lpFj2uuAPJxtP7URiBX515exj6rA7gSTILI8KCo7uic5g7AoA1bQxY464UdYsDZvsR0BRYc2JzTeSEXOFfby4KBxcs0e4AykYrPhWrwQNc+6FcTArh/WwsmxFMZf5SFqOMgQqQs7j9n3F9dWi+e Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:40:44 -0000 --20cf3074d86262159204d0c8a22b Content-Type: text/plain; charset=UTF-8 On Thu, Dec 13, 2012 at 7:38 PM, James M Snell wrote: > Failure of a request is perfectly acceptable. If the client needs a > secured connection and the server simply does not provide for it, the > client simply won't use that server. Simple as that. > I don't want users or clients to need to opt-in to security. --20cf3074d86262159204d0c8a22b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Thu, Dec 13, 2012 at 7:38 PM, James M Snell <jasnell@gmail.com> wrote:

Fa= ilure of a request is perfectly acceptable. If the client needs a secured c= onnection and the server simply does not provide for it, the client simply = won't use that server. Simple as that.

I don't want users or clients to need to opt-in to se= curity.

--20cf3074d86262159204d0c8a22b-- From paulej@packetizer.com Thu Dec 13 20:42:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36421F8C0B for ; Thu, 13 Dec 2012 20:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqo9bC4lRRqO for ; Thu, 13 Dec 2012 20:42:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95421F8A4D for ; Thu, 13 Dec 2012 20:42:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE4g2uq031860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 23:42:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355460124; bh=ceG0mFiwkMpI6NoUgwu1M0whXXbbHyxw8sEJNDe7xq4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kf4/IY3GLAT8QdhwF+zJCh0W5yhOdqNWia5hsI1X/h53KK3293VvKndKofVII8EZy LF0K/VD+72QN68vnMnG1ylqnmSBrMZ5VEIZAw/ahkZrKvIJV8gjSk0S8B17tuoHiAS NutqLNRGypwhyV5Jka06UISmBK9XnlbqY+v78C5Q= From: "Paul E. Jones" To: "'Breno'" , References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <0! 7ee01cdd987$3827d7c0$a8 778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 23:42:15 -0500 Message-ID: <091401cdd9b5$64a0f330$2de2d990$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCyk61iAJm5c6BAgdFug0CAx/yoQFnDvE4AjBd7lKXogKKUA== Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'James M Snell' , 'Goix Laurent Walter' , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:42:06 -0000 Breno, > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure operation > is a smokescreen. Just add a disclaimer that WF is not intended to use > in secure contexts, at least it'd be honest. I don't agree with that comment, either. :-) (Let me apologize for sounding so disagreeable.) If a client needs to ensure that responses are delivered via HTTPS, it uses that exclusively. Period. There is nothing more we can do to ensure a more secure transport from the WF protocol. For all other clients that don't care too much whether a reply is delivered over HTTP or HTTPS, there is no "smokescreen". It's just a process of how the client gets a response. The client could send an HTTP query, since it does not care about security. The server might redirect the client to an HTTPS server, which is fine. It makes little difference whether the reply comes back via HTTP or HTTPS, as both have to be treated as non-secure. Paul From paulej@packetizer.com Thu Dec 13 20:48:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8C521F8536 for ; Thu, 13 Dec 2012 20:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL6hvKLFVw-L for ; Thu, 13 Dec 2012 20:48:39 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4921F848B for ; Thu, 13 Dec 2012 20:48:39 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE4maCi032125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 23:48:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355460517; bh=o7/oK0sy1iICHtL1iZ/eb5O8IdfDelB76vi9wPiWynY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ieOHCoc6r+n+/w9C4xocj23hEXuwHixLpeAnThlL39qGhOW65uamcsizEi0KpAQoI M/JSRH2oRRObj5h2EyDIgwW9QlrFbxueBaBBShyf9R7ni+Fop5h6CWRLzRrhtqk2cW jnJpGDWRHLyZ1EO9eREItP9MAhBd72ROPo0ddsFI= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , "'Breno'" , References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <0! 7ee01cdd987$3827d7c0$a8 778740$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> In-Reply-To: Date: Thu, 13 Dec 2012 23:48:49 -0500 Message-ID: <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_091D_01CDD98C.66466270" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCyk61iAJm5c6BAgdFug0CAx/yoQFnDvE4AjBd7lIBzrtahJeTji7Q Content-Language: en-us Cc: 'James M Snell' , webfinger@googlegroups.com, 'Goix Laurent Walter' Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:48:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_091D_01CDD98C.66466270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You=E2=80=99re right that we cannot have all three. But, those who are = still demanding HTTP as an option (and I=E2=80=99m still looking to hear = from those folks) are not demanding security. =20 So, what we=E2=80=99re looking at presently are really two options for = clients: 1) Secure =E2=80=93 HTTPS server 2) Non-Secure =E2=80=93 HTTP server =20 The client selects the transport based on its requirements. =20 In the case that the client needs a secure reply, it uses HTTPS and will = not try HTTP. If the server is not listening on HTTPS, then it fails. = And, that=E2=80=99s exactly what you want to avoid a security issue. =20 In the case that the client does not care about security of the = response, it queries using HTTP. The server might reply or it might = redirect, but the reply is still considered non-secure (since the HTTP = reply could be hacked). =20 In both cases, the client code is simple. There=E2=80=99s no fall back = logic in the client. Either make a secure request or don=E2=80=99t. =20 Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 11:37 PM To: Breno; webfinger@ietf.org Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels =20 I agree with Breno, in all his points and previous emails. =20 Again, I will repeat myself: we can have at most two of these three: =20 1) security 2) support HTTP servers 3) simple clients =20 We don't get all 3. We get at most 2. =20 I think everybody wants 1), so that leave us deciding between 2) and 3) = as our other feature. =20 Which is it? HTTP servers or simple clients? =20 =20 On Thu, Dec 13, 2012 at 8:19 PM, Breno = wrote: I will go further: Security is best served by simplicity: If HTTPS was only allowable protocol, that'd be the best approach security-wise. If simplicity is not available (and the decision to allow HTTPS and HTTP means it isn't), then a fully specified behavior, in all it's glorious complexity, is required for security. If that discourages the proliferation of low-quality I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client implementations, so much better for security. Put all eggs in one basket and watch that basket. The current compromise where we pretend that we can have simple client specification that allows for both complex behavior and secure operation is a smokescreen. Just add a disclaimer that WF is not intended to use in secure contexts, at least it'd be honest. On Thu, Dec 13, 2012 at 8:08 PM, Breno = wrote: > Also, I reject the notion that WF standard should be simple for > clients. If we want WF to be widely deployed, we make it easier for > servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated. > > In contrast, standard-compliant WF clients are probably going to be > less common. Even if WF is not too complex, why wouldn't you use a > library if you want to have some guarantee like security? If you want > to simply write a few curl commands and mesh the data after applying > your homebrew parser, you neither care for standard compliance or > security, and you still can get things done because the underlying > data schema is simple. > > On Thu, Dec 13, 2012 at 8:00 PM, Breno = wrote: >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones = wrote: >>> Brad, >>> >>> >>> >>> I really don=E2=80=99t like the secure-rels idea. If a rel is = secure or should be >>> treated as secure, I can mark it as such on the server without = creating more >>> names and cluttering up the link relation name space with multiple = variants >>> of the same thing. >> >> As explained above, this does not address HTTP-fallback degrade = attacks. >> >>> >>> >>> >>> There were several people opposed to the client fall back text due = to both >>> security concerns and client-side complexity. That was one of the = main >>> items we addressed with this latest proposal re-write. >> >> The proposal re-write does not seem to address any complexity. It >> simply removes guidance that would ensure implementations that can be >> 'plugged in' both in insecure and secure contexts. The likely result >> are simpler implementations that can't be used in secure contexts, >> even if they may make a claim to the contrary. >> >>> >>> >>> >>> I do realize the flakiness of the proposed solution. >> >> Yes. It's too flaky for the purposes of secure discovery. >> >>> Sometimes, the client >>> just does not work. You type in paulej@packetizer.com and it says = =E2=80=9Ccould >>> not find a thing=E2=80=9D, because the client only issued the query = over HTTPS. If >>> one needs security, I see on other way. However, if we=E2=80=99re = willing to go >>> back to the -07 text that has an allowance for fall back, the issue = is >>> addressed. In the -07 text, a client MAY re-issue a request using = HTTP. >>> >>> >>> >>> Paul >>> >>> >>> >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >>> Sent: Thursday, December 13, 2012 6:15 PM >>> To: Paul E. Jones >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >>> webfinger@ietf.org >>> >>> >>> Subject: Re: [webfinger] secure links with https rels >>> >>> >>> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones = >>> wrote: >>> >>> Walter, >>> >>> >>> >>> No, this will not work. People want to have secure content and what = is >>> secure might be determined by the server admin or user. One might = consider >>> his avatar should be served over HTTPS only. >>> >>> >>> >>> And people do not want to have to write clients that do fallback. >>> >>> >>> >>> I never saw any strong opposition against fallback. People disliked = the >>> extra complexity, but for quite awhile everybody assumed that = fallback would >>> be involved, and I think it was considered acceptable. >>> >>> >>> >>> Who was strongly anti-fallback? >>> >>> >>> >>> >>> >>> We either have to do HTTPS only or we have to live with the fact = that some >>> client requests are going to fail if a WF provider does not provide = WF >>> services over HTTPS. >>> >>> >>> >>> I strongly disagree that those are the only two options. >>> >>> >>> >>> But if you really believe that, I hope you realize that flakiness is >>> unacceptable, which leaves you with HTTPS-only. >>> >>> >>> >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy = with >>> HTTPS-only. >>> >>> >>> >>> So, >>> >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >>> >>> 2) Servers and clients MAY implement HTTP >>> >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as >>> secure since it allows for a MITM attack) >>> >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >>> >>> >>> >>> All works well, except for the case where you have an HTTPS-only = client. >>> But, I bet that will be the majority of clients, which will then = drive the >>> majority of the servers to support HTTPS. >>> >>> >>> >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. >>> >>> >>> >>> Still, it leaves the option on the table for some clients and = servers to >>> use HTTP if they wish. >>> >>> >>> >>> >> >> >> >> -- >> Breno de Medeiros > > > > -- > Breno de Medeiros -- Breno de Medeiros =20 ------=_NextPart_000_091D_01CDD98C.66466270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

You=E2=80=99re right that we cannot have all three.=C2=A0 But, those = who are still demanding HTTP as an option (and I=E2=80=99m still looking = to hear from those folks) are not demanding = security.

 

So, what we=E2=80=99re looking at presently are really two options = for clients:

1)      = Secure =E2=80=93 HTTPS server

2)      = Non-Secure =E2=80=93 HTTP server

 

The client selects the transport based on its = requirements.

 

In the case that the client needs a secure reply, it uses HTTPS and = will not try HTTP.=C2=A0 If the server is not listening on HTTPS, then = it fails.=C2=A0 And, that=E2=80=99s exactly what you want to avoid a = security issue.

 

In the case that the client does not care about security of the = response, it queries using HTTP.=C2=A0 The server might reply or it = might redirect, but the reply is still considered non-secure (since the = HTTP reply could be hacked).

 

In both cases, the client code is simple.=C2=A0 There=E2=80=99s no = fall back logic in the client.=C2=A0 Either make a secure request or = don=E2=80=99t.

 

Paul

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, = 2012 11:37 PM
To: Breno; webfinger@ietf.org
Cc: = James M Snell; webfinger@googlegroups.com; Goix Laurent = Walter
Subject: Re: [webfinger] secure links with https = rels

 

I agree with = Breno, in all his points and previous = emails.

 

Again, I = will repeat myself:  we can have at most two of these = three:

 

1) = security

2) support = HTTP servers

3) simple = clients

 

We don't get = all 3.  We get at most 2.

 

I think = everybody wants 1), so that leave us deciding between 2) and 3) as our = other feature.

 

Which is it? =  HTTP servers or simple clients?

 

 

On Thu, Dec = 13, 2012 at 8:19 PM, Breno <breno.demedeiros@gmail.com> = wrote:

I will go = further:

Security is best served by simplicity: If HTTPS was only = allowable
protocol, that'd be the best approach = security-wise.

If simplicity is not available (and the decision = to allow HTTPS and
HTTP means it isn't), then a fully specified = behavior, in all it's
glorious complexity, is required for security. = If that discourages the
proliferation of = low-quality
I-whipped-this-in-1h-while-waiting-to-board = compliant-claiming client
implementations, so much better for = security. Put all eggs in one
basket and watch that = basket.

The current compromise where we pretend that we can have = simple client
specification that allows for both complex behavior and = secure
operation is a smokescreen. Just add a disclaimer that WF is = not
intended to use in secure contexts, at least it'd be = honest.


On Thu, = Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com= > wrote:
> Also, I reject the notion that WF standard should be = simple for
> clients. If we want WF to be widely deployed, we make = it easier for
> servers so that the information is ubiquitously = deployed even by users
> and companies that are = unsophisticated.
>
> In contrast, standard-compliant WF = clients are probably going to be
> less common. Even if WF is not = too complex, why wouldn't you use a
> library if you want to have = some guarantee like security? If you want
> to simply write a few = curl commands and mesh the data after applying
> your homebrew = parser, you neither care for standard compliance or
> security, = and you still can get things done because the underlying
> data = schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM, Breno = <breno.demedeiros@gmail.com= > wrote:
>> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones = <paulej@packetizer.com> = wrote:
>>> = Brad,
>>>
>>>
>>>
>>> I = really don=E2=80=99t like the secure-rels idea.  If a rel is secure = or should be
>>> treated as secure, I can mark it as such on = the server without creating more
>>> names and cluttering up = the link relation name space with multiple variants
>>> of = the same thing.
>>
>> As explained above, this does = not address HTTP-fallback degrade = attacks.
>>
>>>
>>>
>>>
&= gt;>> There were several people opposed to the client fall back = text due to both
>>> security concerns and client-side = complexity.  That was one of the main
>>> items we = addressed with this latest proposal re-write.
>>
>> = The proposal re-write does not seem to address any complexity. = It
>> simply removes guidance that would ensure implementations = that can be
>> 'plugged in' both in insecure and secure = contexts. The likely result
>> are simpler implementations that = can't be used in secure contexts,
>> even if they may make a = claim to the = contrary.
>>
>>>
>>>
>>>
= >>> I do realize the flakiness of the proposed = solution.
>>
>> Yes. It's too flaky for the purposes = of secure discovery.
>>
>>> Sometimes, the = client
>>> just does not work.  You type in paulej@packetizer.com and it = says =E2=80=9Ccould
>>> not find a thing=E2=80=9D, because = the client only issued the query over HTTPS.  If
>>> = one needs security, I see on other way.  However, if we=E2=80=99re = willing to go
>>> back to the -07 text that has an allowance = for fall back, the issue is
>>> addressed.  In the -07 = text, a client MAY re-issue a request using = HTTP.
>>>
>>>
>>>
>>> = Paul
>>>
>>>
>>>
>>> = From: Brad Fitzpatrick [mailto:bradfitz@google.com]
>>&= gt; Sent: Thursday, December 13, 2012 6:15 PM
>>> To: Paul = E. Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com= ; James M Snell;
>>> webfinger@ietf.org
>>>=
>>>
>>> Subject: Re: [webfinger] secure links = with https = rels
>>>
>>>
>>>
>>> On = Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>
&g= t;>> wrote:
>>>
>>> = Walter,
>>>
>>>
>>>
>>> = No, this will not work.  People want to have secure content and = what is
>>> secure might be determined by the server admin = or user.  One might consider
>>> his avatar should be = served over HTTPS = only.
>>>
>>>
>>>
>>> = And people do not want to have to write clients that do = fallback.
>>>
>>>
>>>
>>>= I never saw any strong opposition against fallback.  People = disliked the
>>> extra complexity, but for quite awhile = everybody assumed that fallback would
>>> be involved, and I = think it was considered = acceptable.
>>>
>>>
>>>
>>&g= t; Who was strongly = anti-fallback?
>>>
>>>
>>>
>>= ;>
>>>
>>> We either have to do HTTPS only or = we have to live with the fact that some
>>> client requests = are going to fail if a WF provider does not provide WF
>>> = services over = HTTPS.
>>>
>>>
>>>
>>> I = strongly disagree that those are the only two = options.
>>>
>>>
>>>
>>> = But if you really believe that, I hope you realize that flakiness = is
>>> unacceptable, which leaves you with = HTTPS-only.
>>>
>>>
>>>
>>&g= t; If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy = with
>>> = HTTPS-only.
>>>
>>>
>>>
>>&g= t;  So,
>>>
>>> 1)     =  Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS
>>>
>>> 2)      Servers and = clients MAY implement HTTP
>>>
>>> 3)   =    Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as
>>> secure since it allows for a MITM = attack)
>>>
>>> 4)      Servers = MUST NOT redirect from HTTPS to = HTTP
>>>
>>>
>>>
>>> All = works well, except for the case where you have an HTTPS-only = client.
>>> But, I bet that will be the majority of clients, = which will then drive the
>>> majority of the servers to = support = HTTPS.
>>>
>>>
>>>
>>> = This is a terrible cop-out.  Flakiness in the spec is = unacceptable.
>>>
>>>
>>>
>>= >  Still, it leaves the option on the table for some clients and = servers to
>>> use HTTP if they = wish.
>>>
>>>
>>>
>>>
= >>
>>
>>
>> --
>> Breno de = Medeiros
>
>
>
> --
> Breno de = Medeiros


--
Breno de Medeiros

 

------=_NextPart_000_091D_01CDD98C.66466270-- From breno.demedeiros@gmail.com Thu Dec 13 20:56:28 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0710A21F8861 for ; Thu, 13 Dec 2012 20:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYF5YIZ5acCe for ; Thu, 13 Dec 2012 20:56:27 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5989121F8855 for ; Thu, 13 Dec 2012 20:56:27 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1927264pbc.31 for ; Thu, 13 Dec 2012 20:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y69Nj/OKl81zaAg7O/HnpM/OVzFs1HdCYUugSlWkL1M=; b=phWmZ8RGgym6I40f1rodBUY4iuEDPI1cx/9RNgAS6HRxYZfO6c8fGy5iXo1e0Bxl2x TvEvYk5wYJU0IkpBG+5Cvn18AMRLapYqJG7RGTmHE/N8/96RtuLbknLuu0WMcbtpJUqY 6mm+QOJUify6nZMRzyBxSF3g5ICZPd8CHwunZmKZw+uEZ4MIaVR4DkhfysF563tb17+N k6pD4k9It1k73oyfrCfdiE8VYuZgc4yTPTTriLVn9KTG+VBws1wL3cb+KvGGYCcgG46F EEmb4DIPBBV9ypFAEvQbQKK9uDwFK7SJ9868TyRTAsGWBLqGgoU2CgrJt3xkg4JuSz0s TiiA== MIME-Version: 1.0 Received: by 10.68.135.42 with SMTP id pp10mr12179475pbb.157.1355460987112; Thu, 13 Dec 2012 20:56:27 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:56:26 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:56:26 -0800 (PST) In-Reply-To: <091401cdd9b5$64a0f330$2de2d990$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091401cdd9b5$64a0f330$2de2d990$@packetizer.com> Date: Thu, 13 Dec 2012 20:56:26 -0800 Message-ID: From: Breno To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b10cbdfa4cc7a04d0c8da3a Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:56:28 -0000 --047d7b10cbdfa4cc7a04d0c8da3a Content-Type: text/plain; charset=ISO-8859-1 That requires everyone who uses WF to either write their own implementation or if using some other implementation to get informed about how it behaves regarding the network layer. It requires protocols that want to build on WF for secure operations to define a compatibility profile for WF clients that exceed the specification. Or a separate spec possibly with heavy reference to WF I'd prefer an HTTPS spec but HTTP proponents have made some reasoned arguments. Is it too much to expect the client-simplicity components to do the same? I am unconvinced that clients need both to be simple and spec compliant. With Brad's secure rel proposal you can have either though not in the same implementation. The only difference between the two is that only compliant implementations are secure. What are we giving up exactly? On Dec 13, 2012 8:42 PM, "Paul E. Jones" wrote: > Breno, > > > The current compromise where we pretend that we can have simple client > > specification that allows for both complex behavior and secure operation > > is a smokescreen. Just add a disclaimer that WF is not intended to use > > in secure contexts, at least it'd be honest. > > I don't agree with that comment, either. :-) (Let me apologize for > sounding > so disagreeable.) > > If a client needs to ensure that responses are delivered via HTTPS, it uses > that exclusively. Period. There is nothing more we can do to ensure a more > secure transport from the WF protocol. > > For all other clients that don't care too much whether a reply is delivered > over HTTP or HTTPS, there is no "smokescreen". It's just a process of how > the client gets a response. The client could send an HTTP query, since it > does not care about security. The server might redirect the client to an > HTTPS server, which is fine. It makes little difference whether the reply > comes back via HTTP or HTTPS, as both have to be treated as non-secure. > > Paul > > > --047d7b10cbdfa4cc7a04d0c8da3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

That requires everyone who uses WF to either write their own= implementation or if using some other implementation to get informed about= how it behaves regarding the network layer.

It requires protocols that want to build on WF for secure op= erations to define a compatibility profile for WF clients that exceed the s= pecification. Or a separate spec possibly with heavy reference to WF

I'd prefer an HTTPS spec but HTTP proponents have made s= ome reasoned arguments. Is it too much to expect the client-simplicity comp= onents to do the same? I am unconvinced that clients need both to be simple= and spec compliant. With Brad's secure rel proposal you can have eithe= r though not in the same implementation. The only difference between the tw= o is that only compliant implementations are secure. What are we giving up = exactly?

On Dec 13, 2012 8:42 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:
Breno,

> The current compromise where we pretend that we can have simple client=
> specification that allows for both complex behavior and secure operati= on
> is a smokescreen. Just add a disclaimer that WF is not intended to use=
> in secure contexts, at least it'd be honest.

I don't agree with that comment, either. :-) =A0(Let me apologize for s= ounding
so disagreeable.)

If a client needs to ensure that responses are delivered via HTTPS, it uses=
that exclusively. Period. =A0There is nothing more we can do to ensure a mo= re
secure transport from the WF protocol.

For all other clients that don't care too much whether a reply is deliv= ered
over HTTP or HTTPS, there is no "smokescreen". =A0It's just a= process of how
the client gets a response. =A0The client could send an HTTP query, since i= t
does not care about security. =A0The server might redirect the client to an=
HTTPS server, which is fine. =A0It makes little difference whether the repl= y
comes back via HTTP or HTTPS, as both have to be treated as non-secure.

Paul


--047d7b10cbdfa4cc7a04d0c8da3a-- From breno.demedeiros@gmail.com Thu Dec 13 20:59:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335E621F88E2 for ; Thu, 13 Dec 2012 20:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReZBbd9QtTv1 for ; Thu, 13 Dec 2012 20:59:52 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE021F88DA for ; Thu, 13 Dec 2012 20:59:52 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1970179pad.31 for ; Thu, 13 Dec 2012 20:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oFKNpLHw9uwoZX8JUkq8XOtXSnsd7GS75gxNSjJCm/o=; b=mSyxI2tC8A52vVLQ3c+XNQZJ+uktoE+HSwXBFN3qyC1QiPTvCcyKluuAbSyMSLAkn6 R/q8bQO3rqINlJ/IlM9C4ygNT8W7J7InzkxfcJpRnc6SCMdQ2k6hcCxX+oks4+bKrg6h PfoQHlvjztTnoOlXBjEHXpkWUKQqLUc4ErjmlBUw+AGilLd2agg12rofUQQNBNMTSlaC yJcqmncW3gqnSAEwV7x+8InGpaUqbt25p7LRRmUGm+Htel2EX7FmLGRdrPLJ2zSEatNc YQw2FMh3cHCQcYZZbqxnciwzFBpy6OvpWCaAobDLXA15nbi4PwFB0AMpXWdSjuXMpl01 itnA== MIME-Version: 1.0 Received: by 10.68.254.137 with SMTP id ai9mr12436613pbd.21.1355461192280; Thu, 13 Dec 2012 20:59:52 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:59:51 -0800 (PST) Received: by 10.66.249.131 with HTTP; Thu, 13 Dec 2012 20:59:51 -0800 (PST) In-Reply-To: <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> Date: Thu, 13 Dec 2012 20:59:51 -0800 Message-ID: From: Breno To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b2e0a15df6afc04d0c8e686 Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:59:54 -0000 --047d7b2e0a15df6afc04d0c8e686 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Our messages crossed. There's still some complexity. How does that interact with caching? On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote: > You=92re right that we cannot have all three. But, those who are still > demanding HTTP as an option (and I=92m still looking to hear from those > folks) are not demanding security.**** > > ** ** > > So, what we=92re looking at presently are really two options for clients:= *** > * > > **1) **Secure =96 HTTPS server**** > > **2) **Non-Secure =96 HTTP server**** > > ** ** > > The client selects the transport based on its requirements.**** > > ** ** > > In the case that the client needs a secure reply, it uses HTTPS and will > not try HTTP. If the server is not listening on HTTPS, then it fails. > And, that=92s exactly what you want to avoid a security issue.**** > > ** ** > > In the case that the client does not care about security of the response, > it queries using HTTP. The server might reply or it might redirect, but > the reply is still considered non-secure (since the HTTP reply could be > hacked).**** > > ** ** > > In both cases, the client code is simple. There=92s no fall back logic i= n > the client. Either make a secure request or don=92t.**** > > ** ** > > Paul**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Brad Fitzpatrick > *Sent:* Thursday, December 13, 2012 11:37 PM > *To:* Breno; webfinger@ietf.org > *Cc:* James M Snell; webfinger@googlegroups.com; Goix Laurent Walter > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > I agree with Breno, in all his points and previous emails.**** > > ** ** > > Again, I will repeat myself: we can have at most two of these three:**** > > ** ** > > 1) security**** > > 2) support HTTP servers**** > > 3) simple clients**** > > ** ** > > We don't get all 3. We get at most 2.**** > > ** ** > > I think everybody wants 1), so that leave us deciding between 2) and 3) a= s > our other feature.**** > > ** ** > > Which is it? HTTP servers or simple clients?**** > > ** ** > > ** ** > > On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote= : > **** > > I will go further: > > Security is best served by simplicity: If HTTPS was only allowable > protocol, that'd be the best approach security-wise. > > If simplicity is not available (and the decision to allow HTTPS and > HTTP means it isn't), then a fully specified behavior, in all it's > glorious complexity, is required for security. If that discourages the > proliferation of low-quality > I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client > implementations, so much better for security. Put all eggs in one > basket and watch that basket. > > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure > operation is a smokescreen. Just add a disclaimer that WF is not > intended to use in secure contexts, at least it'd be honest.**** > > > On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote= : > > Also, I reject the notion that WF standard should be simple for > > clients. If we want WF to be widely deployed, we make it easier for > > servers so that the information is ubiquitously deployed even by users > > and companies that are unsophisticated. > > > > In contrast, standard-compliant WF clients are probably going to be > > less common. Even if WF is not too complex, why wouldn't you use a > > library if you want to have some guarantee like security? If you want > > to simply write a few curl commands and mesh the data after applying > > your homebrew parser, you neither care for standard compliance or > > security, and you still can get things done because the underlying > > data schema is simple. > > > > On Thu, Dec 13, 2012 at 8:00 PM, Breno > wrote: > >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones > wrote: > >>> Brad, > >>> > >>> > >>> > >>> I really don=92t like the secure-rels idea. If a rel is secure or > should be > >>> treated as secure, I can mark it as such on the server without > creating more > >>> names and cluttering up the link relation name space with multiple > variants > >>> of the same thing. > >> > >> As explained above, this does not address HTTP-fallback degrade attack= s. > >> > >>> > >>> > >>> > >>> There were several people opposed to the client fall back text due to > both > >>> security concerns and client-side complexity. That was one of the ma= in > >>> items we addressed with this latest proposal re-write. > >> > >> The proposal re-write does not seem to address any complexity. It > >> simply removes guidance that would ensure implementations that can be > >> 'plugged in' both in insecure and secure contexts. The likely result > >> are simpler implementations that can't be used in secure contexts, > >> even if they may make a claim to the contrary. > >> > >>> > >>> > >>> > >>> I do realize the flakiness of the proposed solution. > >> > >> Yes. It's too flaky for the purposes of secure discovery. > >> > >>> Sometimes, the client > >>> just does not work. You type in paulej@packetizer.com and it says > =93could > >>> not find a thing=94, because the client only issued the query over > HTTPS. If > >>> one needs security, I see on other way. However, if we=92re willing = to > go > >>> back to the -07 text that has an allowance for fall back, the issue i= s > >>> addressed. In the -07 text, a client MAY re-issue a request using > HTTP. > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] > >>> Sent: Thursday, December 13, 2012 6:15 PM > >>> To: Paul E. Jones > >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; > >>> webfinger@ietf.org > >>> > >>> > >>> Subject: Re: [webfinger] secure links with https rels > >>> > >>> > >>> > >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones > >>> wrote: > >>> > >>> Walter, > >>> > >>> > >>> > >>> No, this will not work. People want to have secure content and what = is > >>> secure might be determined by the server admin or user. One might > consider > >>> his avatar should be served over HTTPS only. > >>> > >>> > >>> > >>> And people do not want to have to write clients that do fallback. > >>> > >>> > >>> > >>> I never saw any strong opposition against fallback. People disliked > the > >>> extra complexity, but for quite awhile everybody assumed that fallbac= k > would > >>> be involved, and I think it was considered acceptable. > >>> > >>> > >>> > >>> Who was strongly anti-fallback? > >>> > >>> > >>> > >>> > >>> > >>> We either have to do HTTPS only or we have to live with the fact that > some > >>> client requests are going to fail if a WF provider does not provide W= F > >>> services over HTTPS. > >>> > >>> > >>> > >>> I strongly disagree that those are the only two options. > >>> > >>> > >>> > >>> But if you really believe that, I hope you realize that flakiness is > >>> unacceptable, which leaves you with HTTPS-only. > >>> > >>> > >>> > >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy > with > >>> HTTPS-only. > >>> > >>> > >>> > >>> So, > >>> > >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS > >>> > >>> 2) Servers and clients MAY implement HTTP > >>> > >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as > >>> secure since it allows for a MITM attack) > >>> > >>> 4) Servers MUST NOT redirect from HTTPS to HTTP > >>> > >>> > >>> > >>> All works well, except for the case where you have an HTTPS-only > client. > >>> But, I bet that will be the majority of clients, which will then driv= e > the > >>> majority of the servers to support HTTPS. > >>> > >>> > >>> > >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. > >>> > >>> > >>> > >>> Still, it leaves the option on the table for some clients and server= s > to > >>> use HTTP if they wish. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Breno de Medeiros > > > > > > > > -- > > Breno de Medeiros > > > **** > > -- > Breno de Medeiros**** > > ** ** > --047d7b2e0a15df6afc04d0c8e686 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Our messages crossed.

There's still some complexity. How does that interact=A0= with caching?

On Dec 13, 2012 8:48 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:

You=92re right that we cannot have all three= .=A0 But, those who are still demanding HTTP as an option (and I=92m still = looking to hear from those folks) are not demanding security.=

=A0<= /p>

So, what we=92re looki= ng at presently are really two options for clients:

1)=A0=A0=A0=A0=A0 Secure =96 HTTPS server

2)=A0=A0=A0=A0=A0 Non-Secure =96 HTTP server

=A0<= /p>

The client selects the= transport based on its requirements.

=A0<= /p>

In the case that the c= lient needs a secure reply, it uses HTTPS and will not try HTTP.=A0 If the = server is not listening on HTTPS, then it fails.=A0 And, that=92s exactly w= hat you want to avoid a security issue.

=A0<= /p>

In the case that the c= lient does not care about security of the response, it queries using HTTP.= =A0 The server might reply or it might redirect, but the reply is still con= sidered non-secure (since the HTTP reply could be hacked).

=A0<= /p>

In both cases, the cli= ent code is simple.=A0 There=92s no fall back logic in the client.=A0 Eithe= r make a secure request or don=92t.

=A0<= /p>

Paul

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 PM
To: Breno; webfinger@ietf.org<= br>Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter
Subject: Re: [webfinger] secure links with https rels<= /span>

=A0

I agree with Breno, in all his points and pre= vious emails.

=A0

Again, I will repeat myself: =A0we can= have at most two of these three:

=A0

1) security=

2) support HTTP servers=

3) simple cl= ients

=A0

We don't get all 3. =A0We ge= t at most 2.

=A0

I think everybody wants 1), so t= hat leave us deciding between 2) and 3) as our other feature.=

=A0

Which is it? =A0HTTP servers or = simple clients?

=A0

=A0

On Thu, Dec 13, 2012 at 8:19 PM, Bre= no <bren= o.demedeiros@gmail.com> wrote:

I will go further:

Security is bes= t served by simplicity: If HTTPS was only allowable
protocol, that'd= be the best approach security-wise.

If simplicity is not available (and the decision to allow HTTPS and
= HTTP means it isn't), then a fully specified behavior, in all it's<= br>glorious complexity, is required for security. If that discourages the proliferation of low-quality
I-whipped-this-in-1h-while-waiting-to-board= compliant-claiming client
implementations, so much better for security.= Put all eggs in one
basket and watch that basket.

The current co= mpromise where we pretend that we can have simple client
specification that allows for both complex behavior and secure
operation= is a smokescreen. Just add a disclaimer that WF is not
intended to use = in secure contexts, at least it'd be honest.

=
On Thu, Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrot= e:
> Also, I reject the notion that WF standard should be simple for
>= ; clients. If we want WF to be widely deployed, we make it easier for
&g= t; servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated.
>
> In contrast, s= tandard-compliant WF clients are probably going to be
> less common. = Even if WF is not too complex, why wouldn't you use a
> library i= f you want to have some guarantee like security? If you want
> to simply write a few curl commands and mesh the data after applying> your homebrew parser, you neither care for standard compliance or> security, and you still can get things done because the underlying > data schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM= , Breno <breno.demedeiros@gmail.com> wrote:
>> On Thu, Dec 13, 2012= at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> Brad,
>>>
>>>
>>>
>&= gt;> I really don=92t like the secure-rels idea. =A0If a rel is secure o= r should be
>>> treated as secure, I can mark it as such on the= server without creating more
>>> names and cluttering up the link relation name space with mult= iple variants
>>> of the same thing.
>>
>> As= explained above, this does not address HTTP-fallback degrade attacks.
>>
>>>
>>>
>>>
>>> Th= ere were several people opposed to the client fall back text due to both>>> security concerns and client-side complexity. =A0That was one= of the main
>>> items we addressed with this latest proposal re-write.
>= >
>> The proposal re-write does not seem to address any complex= ity. It
>> simply removes guidance that would ensure implementatio= ns that can be
>> 'plugged in' both in insecure and secure contexts. The lik= ely result
>> are simpler implementations that can't be used i= n secure contexts,
>> even if they may make a claim to the contrar= y.
>>
>>>
>>>
>>>
>>> I = do realize the flakiness of the proposed solution.
>>
>> = Yes. It's too flaky for the purposes of secure discovery.
>> >>> Sometimes, the client
>>> just does not work. =A0Y= ou type in paule= j@packetizer.com and it says =93could
>>> not find a thing= =94, because the client only issued the query over HTTPS. =A0If
>>> one needs security, I see on other way. =A0However, if we=92re= willing to go
>>> back to the -07 text that has an allowance f= or fall back, the issue is
>>> addressed. =A0In the -07 text, a= client MAY re-issue a request using HTTP.
>>>
>>>
>>>
>>> Paul
>&g= t;>
>>>
>>>
>>> From: Brad Fitzpatri= ck [mailto:bradfit= z@google.com]
>>> Sent: Thursday, December 13, 2012 6:15 PM
>>> To: = Paul E. Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com;= James M Snell;
>>> webfin= ger@ietf.org
>>>
>>>
>>> Subject: R= e: [webfinger] secure links with https rels
>>>
>>>=
>>>
>>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones= <paulej@pack= etizer.com>
>>> wrote:
>>>
>>> W= alter,
>>>
>>>
>>>
>>> No, this will = not work. =A0People want to have secure content and what is
>>>= secure might be determined by the server admin or user. =A0One might consi= der
>>> his avatar should be served over HTTPS only.
>>>>>>
>>>
>>> And people do not want to ha= ve to write clients that do fallback.
>>>
>>>
>>>
>>> I never saw any strong opposition against fall= back. =A0People disliked the
>>> extra complexity, but for quit= e awhile everybody assumed that fallback would
>>> be involved,= and I think it was considered acceptable.
>>>
>>>
>>>
>>> Who was strong= ly anti-fallback?
>>>
>>>
>>>
>&g= t;>
>>>
>>> We either have to do HTTPS only or w= e have to live with the fact that some
>>> client requests are going to fail if a WF provider does not pr= ovide WF
>>> services over HTTPS.
>>>
>>&g= t;
>>>
>>> I strongly disagree that those are the o= nly two options.
>>>
>>>
>>>
>>> But if you rea= lly believe that, I hope you realize that flakiness is
>>> unac= ceptable, which leaves you with HTTPS-only.
>>>
>>>=
>>>
>>> If the HTTPS-for-some-rels proposal still isn&= #39;t clear, I'd be happy with
>>> HTTPS-only.
>>&= gt;
>>>
>>>
>>> =A0So,
>>><= br> >>> 1) =A0 =A0 =A0Servers SHOULD implement HTTPS and clients SHOUL= D use HTTPS
>>>
>>> 2) =A0 =A0 =A0Servers and clien= ts MAY implement HTTP
>>>
>>> 3) =A0 =A0 =A0Servers= MAY redirect from HTTP to HTTPS (this MUST NOT be treated as
>>> secure since it allows for a MITM attack)
>>>
&= gt;>> 4) =A0 =A0 =A0Servers MUST NOT redirect from HTTPS to HTTP
&= gt;>>
>>>
>>>
>>> All works well,= except for the case where you have an HTTPS-only client.
>>> But, I bet that will be the majority of clients, which will th= en drive the
>>> majority of the servers to support HTTPS.
&= gt;>>
>>>
>>>
>>> This is a terri= ble cop-out. =A0Flakiness in the spec is unacceptable.
>>>
>>>
>>>
>>> =A0Still, it l= eaves the option on the table for some clients and servers to
>>&g= t; use HTTP if they wish.
>>>
>>>
>>> >>>
>>
>>
>>
>> --
>>= Breno de Medeiros
>
>
>
> --
> Breno de Mede= iros


-- Breno de Medeiros

=A0

--047d7b2e0a15df6afc04d0c8e686-- From paulej@packetizer.com Thu Dec 13 22:36:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D10F21F8861 for ; Thu, 13 Dec 2012 22:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLMziJBWDMNW for ; Thu, 13 Dec 2012 22:36:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A70B221F881A for ; Thu, 13 Dec 2012 22:36:03 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE6a0sZ004791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 01:36:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355466961; bh=w00h7xtZI9EnNeUELMS9ngWSJZKsKtuOW2o4Rs5GWX4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=HeceFQZISnUiXowCEbVSSIEgXOgPkCdyKLKjBaqlIVdcGJtnulheaxTgBZn8XAY2u ZwnEM7HrXyq7gXOK7GvjMINAuH2XRJCCfkBIlizrJw3xVBDepPQT7Z1FgUsVZVewwp QfCV9rGnjmmF6gHwFelmCKmGb8sE+tv7azs8aeYQ= From: "Paul E. Jones" To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091401cdd9b5$64a0f330$2de2d990$@packetizer.com> In-Reply-To: Date: Fri, 14 Dec 2012 01:36:13 -0500 Message-ID: <095d01cdd9c5$4ffb33e0$eff19ba0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_095E_01CDD99B.6725C820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCZuXOgQIHRboNAgMf8qEBZw7xOAIwXe5SAmwkjfwCclZ/yJeRfrEA Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:36:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_095E_01CDD99B.6725C820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Breno, Comments are inline: That requires everyone who uses WF to either write their own implementation or if using some other implementation to get informed about how it behaves regarding the network layer. PEJ: No, not really. The WF library would offer that as a switch. This has been suggested and I have some draft text to integrate. It would likely be similar to what was suggested today on the list: wf.query("acct:paulej@packetizer.com", "secure:true") It requires protocols that want to build on WF for secure operations to define a compatibility profile for WF clients that exceed the specification. Or a separate spec possibly with heavy reference to WF PEJ: This is true, but not as complex as you describe. The OpenID Connect protocol, as one example, would have to specify that only HTTPS shall be used when performing discovery. I'd prefer an HTTPS spec but HTTP proponents have made some reasoned arguments. Is it too much to expect the client-simplicity components to do the same? I am unconvinced that clients need both to be simple and spec compliant. With Brad's secure rel proposal you can have either though not in the same implementation. The only difference between the two is that only compliant implementations are secure. What are we giving up exactly? PEJ: The secure rels proposal just creates a bunch more rels that help the server in deciding whether to provide the content via TLS or not. I can have my server make the same decision by setting a field in the database or having a list of link relations that I classify as "secure". I actually like a combination of both, since this allows me to classify the OpenID Provider URL as "secure" for all users, but then if there are particular users for which I need to guarantee that their avatar is secure, I do so by setting the appropriate field for that user and avatar. And, I can do that without defining more protocol pieces. There is one nice aspect to his proposal, and that is that the server does not have to be provisioned to know what is and is not to be conveyed via HTTP. So, I would not be opposed to the notion of saying "https:" rel types MUST be delivered only over TLS. But, this does not address all other issues. It's a bit orthogonal to the problem of deciding whether a client issues a query via HTTP or HTTPS, or whether a server shall respond to either HTTP or HTTPS. On Dec 13, 2012 8:42 PM, "Paul E. Jones" wrote: Breno, > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure operation > is a smokescreen. Just add a disclaimer that WF is not intended to use > in secure contexts, at least it'd be honest. I don't agree with that comment, either. :-) (Let me apologize for sounding so disagreeable.) If a client needs to ensure that responses are delivered via HTTPS, it uses that exclusively. Period. There is nothing more we can do to ensure a more secure transport from the WF protocol. For all other clients that don't care too much whether a reply is delivered over HTTP or HTTPS, there is no "smokescreen". It's just a process of how the client gets a response. The client could send an HTTP query, since it does not care about security. The server might redirect the client to an HTTPS server, which is fine. It makes little difference whether the reply comes back via HTTP or HTTPS, as both have to be treated as non-secure. Paul ------=_NextPart_000_095E_01CDD99B.6725C820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Breno,

 

Comments are inline:

 

That requires everyone who uses WF to either write their own = implementation or if using some other implementation to get informed = about how it behaves regarding the network layer. =

PEJ: No, not really. The WF library would offer that as a = switch.  This has been suggested and I have some draft text to = integrate.  It would likely be similar to what was suggested today = on the list: wf.query("acct:paulej@packetizer.com", = "secure:true")

It requires protocols = that want to build on WF for secure operations to define a compatibility = profile for WF clients that exceed the specification. Or a separate spec = possibly with heavy reference to WF

PEJ: This is true, but not as complex as you describe. The OpenID = Connect protocol, as one example, would have to specify that only HTTPS = shall be used when performing discovery.

I'd = prefer an HTTPS spec but HTTP proponents have made some reasoned = arguments. Is it too much to expect the client-simplicity components to = do the same? I am unconvinced that clients need both to be simple and = spec compliant. With Brad's secure rel proposal you can have either = though not in the same implementation. The only difference between the = two is that only compliant implementations are secure. What are we = giving up exactly?

PEJ: The secure rels proposal just creates a bunch more rels that = help the server in deciding whether to provide the content via TLS or = not.  I can have my server make the same decision by setting a = field in the database or having a list of link relations that I classify = as “secure”.  I actually like a combination of both, = since this allows me to classify the OpenID Provider URL as = “secure” for all users, but then if there are particular = users for which I need to guarantee that their avatar is secure, I do so = by setting the appropriate field for that user and avatar.  And, I = can do that without defining more protocol pieces.  There is one = nice aspect to his proposal, and that is that the server does not have = to be provisioned to know what is and is not to be conveyed via = HTTP.  So, I would not be opposed to the notion of saying = “https:” rel types MUST be delivered only over TLS.  = But, this does not address all other issues.  It’s a bit = orthogonal to the problem of deciding whether a client issues a query = via HTTP or HTTPS, or whether a server shall respond to either HTTP or = HTTPS.

On Dec 13, 2012 = 8:42 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Breno,

> The current compromise = where we pretend that we can have simple client
> specification = that allows for both complex behavior and secure operation
> is a = smokescreen. Just add a disclaimer that WF is not intended to = use
> in secure contexts, at least it'd be honest.

I don't = agree with that comment, either. :-)  (Let me apologize for = sounding
so disagreeable.)

If a client needs to ensure that = responses are delivered via HTTPS, it uses
that exclusively. Period. =  There is nothing more we can do to ensure a more
secure = transport from the WF protocol.

For all other clients that don't = care too much whether a reply is delivered
over HTTP or HTTPS, there = is no "smokescreen".  It's just a process of how
the = client gets a response.  The client could send an HTTP query, since = it
does not care about security.  The server might redirect the = client to an
HTTPS server, which is fine.  It makes little = difference whether the reply
comes back via HTTP or HTTPS, as both = have to be treated as = non-secure.

Paul

------=_NextPart_000_095E_01CDD99B.6725C820-- From paulej@packetizer.com Thu Dec 13 22:39:19 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E45421F880F for ; Thu, 13 Dec 2012 22:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9FJGYHqzLcK for ; Thu, 13 Dec 2012 22:38:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0ED21F85EA for ; Thu, 13 Dec 2012 22:38:39 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE6cawE004921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 01:38:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355467117; bh=9QLB++e/AkTkGIPxeupDd3OxzsFF9sfzDVGSjQKCUDY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=tYAG/RvDQQbkuoe42oMwPqFcDP1zubgBSbzHv2cqJBzIu8ZuomCmHcURGfb9TYTSX SEdiMOb+qQ5HxN2gTGMA3v/nAFSQVsxaqrhm8q+wetmSM+8RP7pQxH8TZev+NelDCN 7rVmldkj77XVk6oTa+dSsNHa/iEUBaa57w2uB7+8= From: "Paul E. Jones" To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> In-Reply-To: Date: Fri, 14 Dec 2012 01:38:49 -0500 Message-ID: <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_096B_01CDD99B.C43F8D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCZuXOgQIHRboNAgMf8qEBZw7xOAIwXe5SAc67WoQCWsSSJQJjOY04l4QQkHA= Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:39:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_096B_01CDD99B.C43F8D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit TLS data isn't cached (except perhaps on the server side where there might be a caching load balancer with the TLS certificates loaded). HTTP data can and may be cached. There is a small statement about that in the spec, but at least one person suggested I should remove it since WF is not changing the rules of how HTTP works and therefore they felt we don't need to say anything about it. Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Breno Sent: Friday, December 14, 2012 12:00 AM To: Paul E. Jones Cc: webfinger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; webfinger@googlegroups.com; James M Snell Subject: RE: [webfinger] secure links with https rels Our messages crossed. There's still some complexity. How does that interact with caching? On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote: You're right that we cannot have all three. But, those who are still demanding HTTP as an option (and I'm still looking to hear from those folks) are not demanding security. So, what we're looking at presently are really two options for clients: 1) Secure - HTTPS server 2) Non-Secure - HTTP server The client selects the transport based on its requirements. In the case that the client needs a secure reply, it uses HTTPS and will not try HTTP. If the server is not listening on HTTPS, then it fails. And, that's exactly what you want to avoid a security issue. In the case that the client does not care about security of the response, it queries using HTTP. The server might reply or it might redirect, but the reply is still considered non-secure (since the HTTP reply could be hacked). In both cases, the client code is simple. There's no fall back logic in the client. Either make a secure request or don't. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 11:37 PM To: Breno; webfinger@ietf.org Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels I agree with Breno, in all his points and previous emails. Again, I will repeat myself: we can have at most two of these three: 1) security 2) support HTTP servers 3) simple clients We don't get all 3. We get at most 2. I think everybody wants 1), so that leave us deciding between 2) and 3) as our other feature. Which is it? HTTP servers or simple clients? On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote: I will go further: Security is best served by simplicity: If HTTPS was only allowable protocol, that'd be the best approach security-wise. If simplicity is not available (and the decision to allow HTTPS and HTTP means it isn't), then a fully specified behavior, in all it's glorious complexity, is required for security. If that discourages the proliferation of low-quality I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client implementations, so much better for security. Put all eggs in one basket and watch that basket. The current compromise where we pretend that we can have simple client specification that allows for both complex behavior and secure operation is a smokescreen. Just add a disclaimer that WF is not intended to use in secure contexts, at least it'd be honest. On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote: > Also, I reject the notion that WF standard should be simple for > clients. If we want WF to be widely deployed, we make it easier for > servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated. > > In contrast, standard-compliant WF clients are probably going to be > less common. Even if WF is not too complex, why wouldn't you use a > library if you want to have some guarantee like security? If you want > to simply write a few curl commands and mesh the data after applying > your homebrew parser, you neither care for standard compliance or > security, and you still can get things done because the underlying > data schema is simple. > > On Thu, Dec 13, 2012 at 8:00 PM, Breno wrote: >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones wrote: >>> Brad, >>> >>> >>> >>> I really don't like the secure-rels idea. If a rel is secure or should be >>> treated as secure, I can mark it as such on the server without creating more >>> names and cluttering up the link relation name space with multiple variants >>> of the same thing. >> >> As explained above, this does not address HTTP-fallback degrade attacks. >> >>> >>> >>> >>> There were several people opposed to the client fall back text due to both >>> security concerns and client-side complexity. That was one of the main >>> items we addressed with this latest proposal re-write. >> >> The proposal re-write does not seem to address any complexity. It >> simply removes guidance that would ensure implementations that can be >> 'plugged in' both in insecure and secure contexts. The likely result >> are simpler implementations that can't be used in secure contexts, >> even if they may make a claim to the contrary. >> >>> >>> >>> >>> I do realize the flakiness of the proposed solution. >> >> Yes. It's too flaky for the purposes of secure discovery. >> >>> Sometimes, the client >>> just does not work. You type in paulej@packetizer.com and it says "could >>> not find a thing", because the client only issued the query over HTTPS. If >>> one needs security, I see on other way. However, if we're willing to go >>> back to the -07 text that has an allowance for fall back, the issue is >>> addressed. In the -07 text, a client MAY re-issue a request using HTTP. >>> >>> >>> >>> Paul >>> >>> >>> >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >>> Sent: Thursday, December 13, 2012 6:15 PM >>> To: Paul E. Jones >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >>> webfinger@ietf.org >>> >>> >>> Subject: Re: [webfinger] secure links with https rels >>> >>> >>> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones >>> wrote: >>> >>> Walter, >>> >>> >>> >>> No, this will not work. People want to have secure content and what is >>> secure might be determined by the server admin or user. One might consider >>> his avatar should be served over HTTPS only. >>> >>> >>> >>> And people do not want to have to write clients that do fallback. >>> >>> >>> >>> I never saw any strong opposition against fallback. People disliked the >>> extra complexity, but for quite awhile everybody assumed that fallback would >>> be involved, and I think it was considered acceptable. >>> >>> >>> >>> Who was strongly anti-fallback? >>> >>> >>> >>> >>> >>> We either have to do HTTPS only or we have to live with the fact that some >>> client requests are going to fail if a WF provider does not provide WF >>> services over HTTPS. >>> >>> >>> >>> I strongly disagree that those are the only two options. >>> >>> >>> >>> But if you really believe that, I hope you realize that flakiness is >>> unacceptable, which leaves you with HTTPS-only. >>> >>> >>> >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with >>> HTTPS-only. >>> >>> >>> >>> So, >>> >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >>> >>> 2) Servers and clients MAY implement HTTP >>> >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as >>> secure since it allows for a MITM attack) >>> >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >>> >>> >>> >>> All works well, except for the case where you have an HTTPS-only client. >>> But, I bet that will be the majority of clients, which will then drive the >>> majority of the servers to support HTTPS. >>> >>> >>> >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. >>> >>> >>> >>> Still, it leaves the option on the table for some clients and servers to >>> use HTTP if they wish. >>> >>> >>> >>> >> >> >> >> -- >> Breno de Medeiros > > > > -- > Breno de Medeiros -- Breno de Medeiros ------=_NextPart_000_096B_01CDD99B.C43F8D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TLS data isn’t cached (except perhaps on the server side where = there might be a caching load balancer with the TLS certificates = loaded).

 

HTTP data can and may be cached.  There is a small statement = about that in the spec, but at least one person suggested I should = remove it since WF is not changing the rules of how HTTP works and = therefore they felt we don’t need to say anything about = it.

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Breno
Sent: Friday, December 14, 2012 12:00 = AM
To: Paul E. Jones
Cc: webfinger@ietf.org; Goix = Laurent Walter; Brad Fitzpatrick; webfinger@googlegroups.com; James M = Snell
Subject: RE: [webfinger] secure links with https = rels

 

Our messages crossed. =

There's still some complexity. How does that = interact  with caching?

On = Dec 13, 2012 8:48 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

You’re right that we cannot have all three.  But, those = who are still demanding HTTP as an option (and I’m still looking = to hear from those folks) are not demanding = security.

 

So, what we’re looking at presently are really two options for = clients:

1)      = Secure – HTTPS server

2)      = Non-Secure – HTTP server

 

The client selects the transport based on its = requirements.

 

In the case that the client needs a secure reply, it uses HTTPS and = will not try HTTP.  If the server is not listening on HTTPS, then = it fails.  And, that’s exactly what you want to avoid a = security issue.

 

In the case that the client does not care about security of the = response, it queries using HTTP.  The server might reply or it = might redirect, but the reply is still considered non-secure (since the = HTTP reply could be hacked).

 

In both cases, the client code is simple.  There’s no fall = back logic in the client.  Either make a secure request or = don’t.

 

Paul

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 = PM
To: Breno; webfinger@ietf.org
Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent = Walter
Subject: Re: [webfinger] secure links with https = rels

 <= /o:p>

I agree with = Breno, in all his points and previous = emails.

 =

Again, I = will repeat myself:  we can have at most two of these = three:

 =

1) = security

2) support = HTTP servers

3) simple = clients

 =

We don't get = all 3.  We get at most 2.

 =

I think = everybody wants 1), so that leave us deciding between 2) and 3) as our = other feature.

 =

Which is it? =  HTTP servers or simple clients?

 =

 =

On Thu, Dec = 13, 2012 at 8:19 PM, Breno <breno.demedeiros@gmail.com> = wrote:

I will go = further:

Security is best served by simplicity: If HTTPS was only = allowable
protocol, that'd be the best approach = security-wise.

If simplicity is not available (and the decision = to allow HTTPS and
HTTP means it isn't), then a fully specified = behavior, in all it's
glorious complexity, is required for security. = If that discourages the
proliferation of = low-quality
I-whipped-this-in-1h-while-waiting-to-board = compliant-claiming client
implementations, so much better for = security. Put all eggs in one
basket and watch that = basket.

The current compromise where we pretend that we can have = simple client
specification that allows for both complex behavior and = secure
operation is a smokescreen. Just add a disclaimer that WF is = not
intended to use in secure contexts, at least it'd be = honest.


On Thu, = Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrote:
> = Also, I reject the notion that WF standard should be simple for
> = clients. If we want WF to be widely deployed, we make it easier = for
> servers so that the information is ubiquitously deployed = even by users
> and companies that are = unsophisticated.
>
> In contrast, standard-compliant WF = clients are probably going to be
> less common. Even if WF is not = too complex, why wouldn't you use a
> library if you want to have = some guarantee like security? If you want
> to simply write a few = curl commands and mesh the data after applying
> your homebrew = parser, you neither care for standard compliance or
> security, = and you still can get things done because the underlying
> data = schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM, Breno = <breno.demedeiros@gmail.com> wrote:
>> = On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> = Brad,
>>>
>>>
>>>
>>> I = really don’t like the secure-rels idea.  If a rel is secure = or should be
>>> treated as secure, I can mark it as such on = the server without creating more
>>> names and cluttering up = the link relation name space with multiple variants
>>> of = the same thing.
>>
>> As explained above, this does = not address HTTP-fallback degrade = attacks.
>>
>>>
>>>
>>>
&= gt;>> There were several people opposed to the client fall back = text due to both
>>> security concerns and client-side = complexity.  That was one of the main
>>> items we = addressed with this latest proposal re-write.
>>
>> = The proposal re-write does not seem to address any complexity. = It
>> simply removes guidance that would ensure implementations = that can be
>> 'plugged in' both in insecure and secure = contexts. The likely result
>> are simpler implementations that = can't be used in secure contexts,
>> even if they may make a = claim to the = contrary.
>>
>>>
>>>
>>>
= >>> I do realize the flakiness of the proposed = solution.
>>
>> Yes. It's too flaky for the purposes = of secure discovery.
>>
>>> Sometimes, the = client
>>> just does not work.  You type in paulej@packetizer.com and it says = “could
>>> not find a thing”, because the client = only issued the query over HTTPS.  If
>>> one needs = security, I see on other way.  However, if we’re willing to = go
>>> back to the -07 text that has an allowance for fall = back, the issue is
>>> addressed.  In the -07 text, a = client MAY re-issue a request using = HTTP.
>>>
>>>
>>>
>>> = Paul
>>>
>>>
>>>
>>> = From: Brad Fitzpatrick [mailto:bradfitz@google.com]
>>> Sent: = Thursday, December 13, 2012 6:15 PM
>>> To: Paul E. = Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M = Snell;
>>> webfinger@ietf.org
>>>
>>><= br>>>> Subject: Re: [webfinger] secure links with https = rels
>>>
>>>
>>>
>>> On = Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>
>>> = wrote:
>>>
>>> = Walter,
>>>
>>>
>>>
>>> = No, this will not work.  People want to have secure content and = what is
>>> secure might be determined by the server admin = or user.  One might consider
>>> his avatar should be = served over HTTPS = only.
>>>
>>>
>>>
>>> = And people do not want to have to write clients that do = fallback.
>>>
>>>
>>>
>>>= I never saw any strong opposition against fallback.  People = disliked the
>>> extra complexity, but for quite awhile = everybody assumed that fallback would
>>> be involved, and I = think it was considered = acceptable.
>>>
>>>
>>>
>>&g= t; Who was strongly = anti-fallback?
>>>
>>>
>>>
>>= ;>
>>>
>>> We either have to do HTTPS only or = we have to live with the fact that some
>>> client requests = are going to fail if a WF provider does not provide WF
>>> = services over = HTTPS.
>>>
>>>
>>>
>>> I = strongly disagree that those are the only two = options.
>>>
>>>
>>>
>>> = But if you really believe that, I hope you realize that flakiness = is
>>> unacceptable, which leaves you with = HTTPS-only.
>>>
>>>
>>>
>>&g= t; If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy = with
>>> = HTTPS-only.
>>>
>>>
>>>
>>&g= t;  So,
>>>
>>> 1)     =  Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS
>>>
>>> 2)      Servers and = clients MAY implement HTTP
>>>
>>> 3)   =    Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as
>>> secure since it allows for a MITM = attack)
>>>
>>> 4)      Servers = MUST NOT redirect from HTTPS to = HTTP
>>>
>>>
>>>
>>> All = works well, except for the case where you have an HTTPS-only = client.
>>> But, I bet that will be the majority of clients, = which will then drive the
>>> majority of the servers to = support = HTTPS.
>>>
>>>
>>>
>>> = This is a terrible cop-out.  Flakiness in the spec is = unacceptable.
>>>
>>>
>>>
>>= >  Still, it leaves the option on the table for some clients and = servers to
>>> use HTTP if they = wish.
>>>
>>>
>>>
>>>
= >>
>>
>>
>> --
>> Breno de = Medeiros
>
>
>
> --
> Breno de = Medeiros

--
Breno de Medeiros

 =

------=_NextPart_000_096B_01CDD99B.C43F8D70-- From jpanzer@google.com Thu Dec 13 22:49:28 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6921F8929 for ; Thu, 13 Dec 2012 22:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2Wqck7MNzUs for ; Thu, 13 Dec 2012 22:49:26 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB12321F892A for ; Thu, 13 Dec 2012 22:49:24 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2470653lbk.31 for ; Thu, 13 Dec 2012 22:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rt1PKeNFYkOfLQE4wnEcRdYSrqPp7wJg5D6p6LrWNWQ=; b=owC543U6buC9+3LNpWvEApweoutZQux2KrIbZ60WjL8LGo+Vnr5Mgp8bKUMl5oN4QI EHMkzg1Auf8szS6skjY/01pMDp2J4ncnjAWc+lJJWgzEICdXU2g/VZmledluRgUI6maS eQ/eb2s6knO4oGcgl8YzUVW1C+bLXg1cBHc90LBnfPVacjB/NLngPo2ci8g+5MX19Bkt oOMBsPJH/Ad7r/g/RbE74EFhGbtk2ec8KHqeAqYh+p3JfvinPKgEltZ6tMaz5a7fRvDP S9WNzBMZjq1UvXWuXOD9ES+VI2bXRoBUBX1WlTK/yFL81S9Ev5CfxyCDDDoiy3R9rc41 85Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Rt1PKeNFYkOfLQE4wnEcRdYSrqPp7wJg5D6p6LrWNWQ=; b=itLzBeUVdqY0vGoKJ2Y66xkedOIvZ8ijqmn4SF/B8lgTrzpdfrtAvd433x3mvCsuDY AeD8+df/g34mYAMQN2/LKY+R5u82OMaTmh7NIvVDZZGnWU8bOel3vWxmn28ZgXVzDnBi wJzAAOEGXiBeR2KzXA5ikWYiqI9ueO9juewiajqHF6FKlS6plxDE7dGeV1GIWUHVCmJY MI+BsikOgjT3i/eptYtmHvEZmQCmqHy1jrIAn+uDeQGpUB4JzkkXV5iRgcATLqECj9jg 5TqQr5bn9vjzwObjT0SmMh/8JGZibeOknn65KztgLCy73Vr89cSCmuMv+hfpfAq9D/wb taYQ== MIME-Version: 1.0 Received: by 10.112.30.200 with SMTP id u8mr1902891lbh.104.1355467763637; Thu, 13 Dec 2012 22:49:23 -0800 (PST) Received: by 10.114.5.3 with HTTP; Thu, 13 Dec 2012 22:49:23 -0800 (PST) Received: by 10.114.5.3 with HTTP; Thu, 13 Dec 2012 22:49:23 -0800 (PST) In-Reply-To: <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> Date: Thu, 13 Dec 2012 22:49:23 -0800 Message-ID: From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec52e60098e5fe504d0ca6e7a X-Gm-Message-State: ALoCoQmcF44h4jvaMuICYRE5mxYBYGHNuLOo4tbo5LBz7u345HHlYlEMS//AjScU/RcDu5HZdqNpdE01LMc5Nu+Bjet/WuF1OjzG39CxUxfKrr1s7Sdss86RyG8+dm2TLs33IFXoloLeFm5TnMkJG0XVPWVyc41C5zqz4b/XGnUH8Jo68bb5/sAFNtKZtn4h1n2W/FDLxKJe Cc: webfinger@ietf.org, James M Snell , Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:49:28 -0000 --bcaec52e60098e5fe504d0ca6e7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why would TLS data marked with cache-control: public not be cacheable on the client? Or by trusted caching proxies? On Dec 13, 2012 10:38 PM, "Paul E. Jones" wrote: > TLS data isn=92t cached (except perhaps on the server side where there mi= ght > be a caching load balancer with the TLS certificates loaded).**** > > ** ** > > HTTP data can and may be cached. There is a small statement about that i= n > the spec, but at least one person suggested I should remove it since WF i= s > not changing the rules of how HTTP works and therefore they felt we don= =92t > need to say anything about it.**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Breno > *Sent:* Friday, December 14, 2012 12:00 AM > *To:* Paul E. Jones > *Cc:* webfinger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; > webfinger@googlegroups.com; James M Snell > *Subject:* RE: [webfinger] secure links with https rels**** > > ** ** > > Our messages crossed. **** > > There's still some complexity. How does that interact with caching?**** > > On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote:**= * > * > > You=92re right that we cannot have all three. But, those who are still > demanding HTTP as an option (and I=92m still looking to hear from those > folks) are not demanding security.**** > > **** > > So, what we=92re looking at presently are really two options for clients:= *** > * > > 1) Secure =96 HTTPS server**** > > 2) Non-Secure =96 HTTP server**** > > **** > > The client selects the transport based on its requirements.**** > > **** > > In the case that the client needs a secure reply, it uses HTTPS and will > not try HTTP. If the server is not listening on HTTPS, then it fails. > And, that=92s exactly what you want to avoid a security issue.**** > > **** > > In the case that the client does not care about security of the response, > it queries using HTTP. The server might reply or it might redirect, but > the reply is still considered non-secure (since the HTTP reply could be > hacked).**** > > **** > > In both cases, the client code is simple. There=92s no fall back logic i= n > the client. Either make a secure request or don=92t.**** > > **** > > Paul**** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Brad Fitzpatrick > *Sent:* Thursday, December 13, 2012 11:37 PM > *To:* Breno; webfinger@ietf.org > *Cc:* James M Snell; webfinger@googlegroups.com; Goix Laurent Walter > *Subject:* Re: [webfinger] secure links with https rels**** > > **** > > I agree with Breno, in all his points and previous emails.**** > > **** > > Again, I will repeat myself: we can have at most two of these three:**** > > **** > > 1) security**** > > 2) support HTTP servers**** > > 3) simple clients**** > > **** > > We don't get all 3. We get at most 2.**** > > **** > > I think everybody wants 1), so that leave us deciding between 2) and 3) a= s > our other feature.**** > > **** > > Which is it? HTTP servers or simple clients?**** > > **** > > **** > > On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote= : > **** > > I will go further: > > Security is best served by simplicity: If HTTPS was only allowable > protocol, that'd be the best approach security-wise. > > If simplicity is not available (and the decision to allow HTTPS and > HTTP means it isn't), then a fully specified behavior, in all it's > glorious complexity, is required for security. If that discourages the > proliferation of low-quality > I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client > implementations, so much better for security. Put all eggs in one > basket and watch that basket. > > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure > operation is a smokescreen. Just add a disclaimer that WF is not > intended to use in secure contexts, at least it'd be honest.**** > > > On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote= : > > Also, I reject the notion that WF standard should be simple for > > clients. If we want WF to be widely deployed, we make it easier for > > servers so that the information is ubiquitously deployed even by users > > and companies that are unsophisticated. > > > > In contrast, standard-compliant WF clients are probably going to be > > less common. Even if WF is not too complex, why wouldn't you use a > > library if you want to have some guarantee like security? If you want > > to simply write a few curl commands and mesh the data after applying > > your homebrew parser, you neither care for standard compliance or > > security, and you still can get things done because the underlying > > data schema is simple. > > > > On Thu, Dec 13, 2012 at 8:00 PM, Breno > wrote: > >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones > wrote: > >>> Brad, > >>> > >>> > >>> > >>> I really don=92t like the secure-rels idea. If a rel is secure or > should be > >>> treated as secure, I can mark it as such on the server without > creating more > >>> names and cluttering up the link relation name space with multiple > variants > >>> of the same thing. > >> > >> As explained above, this does not address HTTP-fallback degrade attack= s. > >> > >>> > >>> > >>> > >>> There were several people opposed to the client fall back text due to > both > >>> security concerns and client-side complexity. That was one of the ma= in > >>> items we addressed with this latest proposal re-write. > >> > >> The proposal re-write does not seem to address any complexity. It > >> simply removes guidance that would ensure implementations that can be > >> 'plugged in' both in insecure and secure contexts. The likely result > >> are simpler implementations that can't be used in secure contexts, > >> even if they may make a claim to the contrary. > >> > >>> > >>> > >>> > >>> I do realize the flakiness of the proposed solution. > >> > >> Yes. It's too flaky for the purposes of secure discovery. > >> > >>> Sometimes, the client > >>> just does not work. You type in paulej@packetizer.com and it says > =93could > >>> not find a thing=94, because the client only issued the query over > HTTPS. If > >>> one needs security, I see on other way. However, if we=92re willing = to > go > >>> back to the -07 text that has an allowance for fall back, the issue i= s > >>> addressed. In the -07 text, a client MAY re-issue a request using > HTTP. > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] > >>> Sent: Thursday, December 13, 2012 6:15 PM > >>> To: Paul E. Jones > >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; > >>> webfinger@ietf.org > >>> > >>> > >>> Subject: Re: [webfinger] secure links with https rels > >>> > >>> > >>> > >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones > >>> wrote: > >>> > >>> Walter, > >>> > >>> > >>> > >>> No, this will not work. People want to have secure content and what = is > >>> secure might be determined by the server admin or user. One might > consider > >>> his avatar should be served over HTTPS only. > >>> > >>> > >>> > >>> And people do not want to have to write clients that do fallback. > >>> > >>> > >>> > >>> I never saw any strong opposition against fallback. People disliked > the > >>> extra complexity, but for quite awhile everybody assumed that fallbac= k > would > >>> be involved, and I think it was considered acceptable. > >>> > >>> > >>> > >>> Who was strongly anti-fallback? > >>> > >>> > >>> > >>> > >>> > >>> We either have to do HTTPS only or we have to live with the fact that > some > >>> client requests are going to fail if a WF provider does not provide W= F > >>> services over HTTPS. > >>> > >>> > >>> > >>> I strongly disagree that those are the only two options. > >>> > >>> > >>> > >>> But if you really believe that, I hope you realize that flakiness is > >>> unacceptable, which leaves you with HTTPS-only. > >>> > >>> > >>> > >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy > with > >>> HTTPS-only. > >>> > >>> > >>> > >>> So, > >>> > >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS > >>> > >>> 2) Servers and clients MAY implement HTTP > >>> > >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as > >>> secure since it allows for a MITM attack) > >>> > >>> 4) Servers MUST NOT redirect from HTTPS to HTTP > >>> > >>> > >>> > >>> All works well, except for the case where you have an HTTPS-only > client. > >>> But, I bet that will be the majority of clients, which will then driv= e > the > >>> majority of the servers to support HTTPS. > >>> > >>> > >>> > >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. > >>> > >>> > >>> > >>> Still, it leaves the option on the table for some clients and server= s > to > >>> use HTTP if they wish. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Breno de Medeiros > > > > > > > > -- > > Breno de Medeiros > > **** > > -- > Breno de Medeiros**** > > **** > --bcaec52e60098e5fe504d0ca6e7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Why would TLS data marked with cache-control: public not be = cacheable on the client?=A0 Or by trusted caching proxies?

On Dec 13, 2012 10:38 PM, "Paul E. Jones&qu= ot; <paulej@packetizer.com&= gt; wrote:

TLS data isn=92t cached (except perhaps on t= he server side where there might be a caching load balancer with the TLS ce= rtificates loaded).

=A0<= /p>

HTTP data can and may = be cached.=A0 There is a small statement about that in the spec, but at lea= st one person suggested I should remove it since WF is not changing the rul= es of how HTTP works and therefore they felt we don=92t need to say anythin= g about it.

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Breno
Sent: Friday, December 14, 2012 12:00 AM
To: Paul E. Jones=
Cc: webf= inger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; webfinger@googlegroups.com<= /a>; James M Snell
Subject: RE: [webfinger] secure links with https rels<= /span>

=A0

Our me= ssages crossed.

There's still some complexity. How= does that interact=A0 with caching?

On Dec 13, 2012 8:48 PM, "Paul E. Jones&qu= ot; <paulej@p= acketizer.com> wrote:

You=92re right that we cannot have all three.=A0= But, those who are still demanding HTTP as an option (and I=92m still look= ing to hear from those folks) are not demanding security.<= /u>

=A0<= /p>

So, what we=92re looki= ng at presently are really two options for clients:

1)=A0=A0=A0=A0=A0 Secure =96 HTTP= S server

2)=A0=A0=A0=A0=A0 Non-Secure =96 = HTTP server

=A0<= /p>

The client selects the= transport based on its requirements.

=A0<= /p>

In the case that the c= lient needs a secure reply, it uses HTTPS and will not try HTTP.=A0 If the = server is not listening on HTTPS, then it fails.=A0 And, that=92s exactly w= hat you want to avoid a security issue.

=A0<= /p>

In the case that the c= lient does not care about security of the response, it queries using HTTP.= =A0 The server might reply or it might redirect, but the reply is still con= sidered non-secure (since the HTTP reply could be hacked).=

=A0<= /p>

In both cases, the cli= ent code is simple.=A0 There=92s no fall back logic in the client.=A0 Eithe= r make a secure request or don=92t.

=A0<= /p>

Paul<= /u>

From:= webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf = Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 PM
To: Breno; webfinger@ietf.org<= br>Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter
Subject: Re: [webfinger] secure links with https rels<= u>

=A0

I agree with Breno, in all his points and pre= vious emails.

=A0

Again, I will repeat myself: =A0we can= have at most two of these three:

=A0

1) security=

2) support HTTP servers=

3) simple cl= ients

=A0

We don't get all 3. =A0We ge= t at most 2.

=A0

I think everybody wants 1), so t= hat leave us deciding between 2) and 3) as our other feature.=

=A0

Which is it? =A0HTTP servers or = simple clients?

=A0

=A0

On Thu, Dec 13, 2012 at 8:19 PM, Bre= no <bren= o.demedeiros@gmail.com> wrote:

I will go further:

Security is bes= t served by simplicity: If HTTPS was only allowable
protocol, that'd= be the best approach security-wise.

If simplicity is not available (and the decision to allow HTTPS and
= HTTP means it isn't), then a fully specified behavior, in all it's<= br>glorious complexity, is required for security. If that discourages the proliferation of low-quality
I-whipped-this-in-1h-while-waiting-to-board= compliant-claiming client
implementations, so much better for security.= Put all eggs in one
basket and watch that basket.

The current co= mpromise where we pretend that we can have simple client
specification that allows for both complex behavior and secure
operation= is a smokescreen. Just add a disclaimer that WF is not
intended to use = in secure contexts, at least it'd be honest.

=
On Thu, Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrot= e:
> Also, I reject the notion that WF standard should be simple for
>= ; clients. If we want WF to be widely deployed, we make it easier for
&g= t; servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated.
>
> In contrast, s= tandard-compliant WF clients are probably going to be
> less common. = Even if WF is not too complex, why wouldn't you use a
> library i= f you want to have some guarantee like security? If you want
> to simply write a few curl commands and mesh the data after applying> your homebrew parser, you neither care for standard compliance or> security, and you still can get things done because the underlying > data schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM= , Breno <breno.demedeiros@gmail.com> wrote:
>> On Thu, Dec 13, 2012= at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> Brad,
>>>
>>>
>>>
>&= gt;> I really don=92t like the secure-rels idea. =A0If a rel is secure o= r should be
>>> treated as secure, I can mark it as such on the= server without creating more
>>> names and cluttering up the link relation name space with mult= iple variants
>>> of the same thing.
>>
>> As= explained above, this does not address HTTP-fallback degrade attacks.
>>
>>>
>>>
>>>
>>> Th= ere were several people opposed to the client fall back text due to both>>> security concerns and client-side complexity. =A0That was one= of the main
>>> items we addressed with this latest proposal re-write.
>= >
>> The proposal re-write does not seem to address any complex= ity. It
>> simply removes guidance that would ensure implementatio= ns that can be
>> 'plugged in' both in insecure and secure contexts. The lik= ely result
>> are simpler implementations that can't be used i= n secure contexts,
>> even if they may make a claim to the contrar= y.
>>
>>>
>>>
>>>
>>> I = do realize the flakiness of the proposed solution.
>>
>> = Yes. It's too flaky for the purposes of secure discovery.
>> >>> Sometimes, the client
>>> just does not work. =A0Y= ou type in paule= j@packetizer.com and it says =93could
>>> not find a thing= =94, because the client only issued the query over HTTPS. =A0If
>>> one needs security, I see on other way. =A0However, if we=92re= willing to go
>>> back to the -07 text that has an allowance f= or fall back, the issue is
>>> addressed. =A0In the -07 text, a= client MAY re-issue a request using HTTP.
>>>
>>>
>>>
>>> Paul
>&g= t;>
>>>
>>>
>>> From: Brad Fitzpatri= ck [mailto:bradfit= z@google.com]
>>> Sent: Thursday, December 13, 2012 6:15 PM
>>> To: = Paul E. Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com;= James M Snell;
>>> webfin= ger@ietf.org
>>>
>>>
>>> Subject: R= e: [webfinger] secure links with https rels
>>>
>>>=
>>>
>>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones= <paulej@pack= etizer.com>
>>> wrote:
>>>
>>> W= alter,
>>>
>>>
>>>
>>> No, this will = not work. =A0People want to have secure content and what is
>>>= secure might be determined by the server admin or user. =A0One might consi= der
>>> his avatar should be served over HTTPS only.
>>>>>>
>>>
>>> And people do not want to ha= ve to write clients that do fallback.
>>>
>>>
>>>
>>> I never saw any strong opposition against fall= back. =A0People disliked the
>>> extra complexity, but for quit= e awhile everybody assumed that fallback would
>>> be involved,= and I think it was considered acceptable.
>>>
>>>
>>>
>>> Who was strong= ly anti-fallback?
>>>
>>>
>>>
>&g= t;>
>>>
>>> We either have to do HTTPS only or w= e have to live with the fact that some
>>> client requests are going to fail if a WF provider does not pr= ovide WF
>>> services over HTTPS.
>>>
>>&g= t;
>>>
>>> I strongly disagree that those are the o= nly two options.
>>>
>>>
>>>
>>> But if you rea= lly believe that, I hope you realize that flakiness is
>>> unac= ceptable, which leaves you with HTTPS-only.
>>>
>>>=
>>>
>>> If the HTTPS-for-some-rels proposal still isn&= #39;t clear, I'd be happy with
>>> HTTPS-only.
>>&= gt;
>>>
>>>
>>> =A0So,
>>><= br> >>> 1) =A0 =A0 =A0Servers SHOULD implement HTTPS and clients SHOUL= D use HTTPS
>>>
>>> 2) =A0 =A0 =A0Servers and clien= ts MAY implement HTTP
>>>
>>> 3) =A0 =A0 =A0Servers= MAY redirect from HTTP to HTTPS (this MUST NOT be treated as
>>> secure since it allows for a MITM attack)
>>>
&= gt;>> 4) =A0 =A0 =A0Servers MUST NOT redirect from HTTPS to HTTP
&= gt;>>
>>>
>>>
>>> All works well,= except for the case where you have an HTTPS-only client.
>>> But, I bet that will be the majority of clients, which will th= en drive the
>>> majority of the servers to support HTTPS.
&= gt;>>
>>>
>>>
>>> This is a terri= ble cop-out. =A0Flakiness in the spec is unacceptable.
>>>
>>>
>>>
>>> =A0Still, it l= eaves the option on the table for some clients and servers to
>>&g= t; use HTTP if they wish.
>>>
>>>
>>> >>>
>>
>>
>>
>> --
>>= Breno de Medeiros
>
>
>
> --
> Breno de Mede= iros

--
Breno de Medeiros

=A0

--bcaec52e60098e5fe504d0ca6e7a-- From paulej@packetizer.com Thu Dec 13 23:07:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B121F8909 for ; Thu, 13 Dec 2012 23:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je-m4hM-Ihak for ; Thu, 13 Dec 2012 23:07:20 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6913D21F8925 for ; Thu, 13 Dec 2012 23:07:20 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBE77Hk3006298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 02:07:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355468838; bh=5kU59vgawvshO8fbVM+FY2nJXQ9GMRvsCLrAi4ped3c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LkhgFlUpz3ttSHcu2CxY3HT8pnI2meylrsEIKistsxXzEIoqh543THTGQOOOK6dkw NDdKMKPwkEgVFnxxj7sra61v7ZTainbf7oUUyAnWip/CexmQ3n9p479wFS5NybMx0W FlTGsi/bfFnqTLtLSDNnaaedViV2C70gVFmCjftg= From: "Paul E. Jones" To: "'John Panzer'" , References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <0! 82001cdd98b$0d8bf510$28 a3df30$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> In-Reply-To: Date: Fri, 14 Dec 2012 02:07:30 -0500 Message-ID: <099201cdd9c9$aeae8820$0c0b9860$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0993_01CDD99F.C5DAF120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFRr6H1BQyvYciHFIvLAqGLQid2rAJaZ1yWAm+kfvEBUcsFhwLGVRnMAkSqonkCNz/uoAM3jVwkAgzDfsACrRZtLgHyttXXAjBvk08DDvPzjQIJQExQAmMTLGYCB0W6DQIDH/KhAWcO8TgCMF3uUgHOu1qEAlrEkiUCYzmNOAIPvrg/AeOfgAuXd7R9wA== Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 07:07:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0993_01CDD99F.C5DAF120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sure, the client can certainly cache it, but I figured that went without saying. What trusted proxies exist, except those service the data for the server (e.g., load balancers)? I sure as heck would not trust any entity between me and my bank, for example. In any case, WF does not change caching rules or anything else about HTTP. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of John Panzer Sent: Friday, December 14, 2012 1:49 AM To: webfinger@googlegroups.com Cc: webfinger@ietf.org; James M Snell; Goix Laurent Walter; Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels Why would TLS data marked with cache-control: public not be cacheable on the client? Or by trusted caching proxies? On Dec 13, 2012 10:38 PM, "Paul E. Jones" wrote: TLS data isn't cached (except perhaps on the server side where there might be a caching load balancer with the TLS certificates loaded). HTTP data can and may be cached. There is a small statement about that in the spec, but at least one person suggested I should remove it since WF is not changing the rules of how HTTP works and therefore they felt we don't need to say anything about it. Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Breno Sent: Friday, December 14, 2012 12:00 AM To: Paul E. Jones Cc: webfinger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; webfinger@googlegroups.com; James M Snell Subject: RE: [webfinger] secure links with https rels Our messages crossed. There's still some complexity. How does that interact with caching? On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote: You're right that we cannot have all three. But, those who are still demanding HTTP as an option (and I'm still looking to hear from those folks) are not demanding security. So, what we're looking at presently are really two options for clients: 1) Secure - HTTPS server 2) Non-Secure - HTTP server The client selects the transport based on its requirements. In the case that the client needs a secure reply, it uses HTTPS and will not try HTTP. If the server is not listening on HTTPS, then it fails. And, that's exactly what you want to avoid a security issue. In the case that the client does not care about security of the response, it queries using HTTP. The server might reply or it might redirect, but the reply is still considered non-secure (since the HTTP reply could be hacked). In both cases, the client code is simple. There's no fall back logic in the client. Either make a secure request or don't. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Brad Fitzpatrick Sent: Thursday, December 13, 2012 11:37 PM To: Breno; webfinger@ietf.org Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter Subject: Re: [webfinger] secure links with https rels I agree with Breno, in all his points and previous emails. Again, I will repeat myself: we can have at most two of these three: 1) security 2) support HTTP servers 3) simple clients We don't get all 3. We get at most 2. I think everybody wants 1), so that leave us deciding between 2) and 3) as our other feature. Which is it? HTTP servers or simple clients? On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote: I will go further: Security is best served by simplicity: If HTTPS was only allowable protocol, that'd be the best approach security-wise. If simplicity is not available (and the decision to allow HTTPS and HTTP means it isn't), then a fully specified behavior, in all it's glorious complexity, is required for security. If that discourages the proliferation of low-quality I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client implementations, so much better for security. Put all eggs in one basket and watch that basket. The current compromise where we pretend that we can have simple client specification that allows for both complex behavior and secure operation is a smokescreen. Just add a disclaimer that WF is not intended to use in secure contexts, at least it'd be honest. On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote: > Also, I reject the notion that WF standard should be simple for > clients. If we want WF to be widely deployed, we make it easier for > servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated. > > In contrast, standard-compliant WF clients are probably going to be > less common. Even if WF is not too complex, why wouldn't you use a > library if you want to have some guarantee like security? If you want > to simply write a few curl commands and mesh the data after applying > your homebrew parser, you neither care for standard compliance or > security, and you still can get things done because the underlying > data schema is simple. > > On Thu, Dec 13, 2012 at 8:00 PM, Breno wrote: >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones wrote: >>> Brad, >>> >>> >>> >>> I really don't like the secure-rels idea. If a rel is secure or should be >>> treated as secure, I can mark it as such on the server without creating more >>> names and cluttering up the link relation name space with multiple variants >>> of the same thing. >> >> As explained above, this does not address HTTP-fallback degrade attacks. >> >>> >>> >>> >>> There were several people opposed to the client fall back text due to both >>> security concerns and client-side complexity. That was one of the main >>> items we addressed with this latest proposal re-write. >> >> The proposal re-write does not seem to address any complexity. It >> simply removes guidance that would ensure implementations that can be >> 'plugged in' both in insecure and secure contexts. The likely result >> are simpler implementations that can't be used in secure contexts, >> even if they may make a claim to the contrary. >> >>> >>> >>> >>> I do realize the flakiness of the proposed solution. >> >> Yes. It's too flaky for the purposes of secure discovery. >> >>> Sometimes, the client >>> just does not work. You type in paulej@packetizer.com and it says "could >>> not find a thing", because the client only issued the query over HTTPS. If >>> one needs security, I see on other way. However, if we're willing to go >>> back to the -07 text that has an allowance for fall back, the issue is >>> addressed. In the -07 text, a client MAY re-issue a request using HTTP. >>> >>> >>> >>> Paul >>> >>> >>> >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >>> Sent: Thursday, December 13, 2012 6:15 PM >>> To: Paul E. Jones >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >>> webfinger@ietf.org >>> >>> >>> Subject: Re: [webfinger] secure links with https rels >>> >>> >>> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones >>> wrote: >>> >>> Walter, >>> >>> >>> >>> No, this will not work. People want to have secure content and what is >>> secure might be determined by the server admin or user. One might consider >>> his avatar should be served over HTTPS only. >>> >>> >>> >>> And people do not want to have to write clients that do fallback. >>> >>> >>> >>> I never saw any strong opposition against fallback. People disliked the >>> extra complexity, but for quite awhile everybody assumed that fallback would >>> be involved, and I think it was considered acceptable. >>> >>> >>> >>> Who was strongly anti-fallback? >>> >>> >>> >>> >>> >>> We either have to do HTTPS only or we have to live with the fact that some >>> client requests are going to fail if a WF provider does not provide WF >>> services over HTTPS. >>> >>> >>> >>> I strongly disagree that those are the only two options. >>> >>> >>> >>> But if you really believe that, I hope you realize that flakiness is >>> unacceptable, which leaves you with HTTPS-only. >>> >>> >>> >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with >>> HTTPS-only. >>> >>> >>> >>> So, >>> >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >>> >>> 2) Servers and clients MAY implement HTTP >>> >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as >>> secure since it allows for a MITM attack) >>> >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >>> >>> >>> >>> All works well, except for the case where you have an HTTPS-only client. >>> But, I bet that will be the majority of clients, which will then drive the >>> majority of the servers to support HTTPS. >>> >>> >>> >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. >>> >>> >>> >>> Still, it leaves the option on the table for some clients and servers to >>> use HTTP if they wish. >>> >>> >>> >>> >> >> >> >> -- >> Breno de Medeiros > > > > -- > Breno de Medeiros -- Breno de Medeiros ------=_NextPart_000_0993_01CDD99F.C5DAF120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, the client can certainly cache it, but I figured that went = without saying.  What trusted proxies exist, except those service = the data for the server (e.g., load balancers)?  I sure as heck = would not trust any entity between me and my bank, for = example.

 

In any case, WF does not change caching rules or anything else about = HTTP.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of John Panzer
Sent: Friday, December 14, 2012 1:49 = AM
To: webfinger@googlegroups.com
Cc: = webfinger@ietf.org; James M Snell; Goix Laurent Walter; Brad = Fitzpatrick
Subject: Re: [webfinger] secure links with https = rels

 

Why would TLS data marked with = cache-control: public not be cacheable on the client?  Or by = trusted caching proxies?

On Dec = 13, 2012 10:38 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

TLS data isn’t cached (except perhaps on the server side where = there might be a caching load balancer with the TLS certificates = loaded).

 

HTTP data can and may be cached.  There is a small statement = about that in the spec, but at least one person suggested I should = remove it since WF is not changing the rules of how HTTP works and = therefore they felt we don’t need to say anything about = it.

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Breno
Sent: Friday, December 14, 2012 12:00 = AM
To: Paul E. Jones
Cc: webfinger@ietf.org; Goix Laurent Walter; Brad = Fitzpatrick; webfinger@googlegroups.com; James M = Snell
Subject: RE: [webfinger] secure links with https = rels

 <= /o:p>

Our messages crossed.

There's still some = complexity. How does that interact  with = caching?

On Dec 13, = 2012 8:48 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

You’re right that we cannot have all three.  But, those = who are still demanding HTTP as an option (and I’m still looking = to hear from those folks) are not demanding = security.

 

So, what we’re looking at presently are really two options for = clients:

1)      = Secure – HTTPS server

2)      = Non-Secure – HTTP server

 

The client selects the transport based on its = requirements.

 

In the case that the client needs a secure reply, it uses HTTPS and = will not try HTTP.  If the server is not listening on HTTPS, then = it fails.  And, that’s exactly what you want to avoid a = security issue.

 

In the case that the client does not care about security of the = response, it queries using HTTP.  The server might reply or it = might redirect, but the reply is still considered non-secure (since the = HTTP reply could be hacked).

 

In both cases, the client code is simple.  There’s no fall = back logic in the client.  Either make a secure request or = don’t.

 

Paul

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 = PM
To: Breno; webfinger@ietf.org
Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent = Walter
Subject: Re: [webfinger] secure links with https = rels

 <= /o:p>

I agree with = Breno, in all his points and previous = emails.

 =

Again, I = will repeat myself:  we can have at most two of these = three:

 =

1) = security

2) support = HTTP servers

3) simple = clients

 =

We don't get = all 3.  We get at most 2.

 =

I think = everybody wants 1), so that leave us deciding between 2) and 3) as our = other feature.

 =

Which is it? =  HTTP servers or simple clients?

 =

 =

On Thu, Dec = 13, 2012 at 8:19 PM, Breno <breno.demedeiros@gmail.com> = wrote:

I will go = further:

Security is best served by simplicity: If HTTPS was only = allowable
protocol, that'd be the best approach = security-wise.

If simplicity is not available (and the decision = to allow HTTPS and
HTTP means it isn't), then a fully specified = behavior, in all it's
glorious complexity, is required for security. = If that discourages the
proliferation of = low-quality
I-whipped-this-in-1h-while-waiting-to-board = compliant-claiming client
implementations, so much better for = security. Put all eggs in one
basket and watch that = basket.

The current compromise where we pretend that we can have = simple client
specification that allows for both complex behavior and = secure
operation is a smokescreen. Just add a disclaimer that WF is = not
intended to use in secure contexts, at least it'd be = honest.


On Thu, = Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrote:
> = Also, I reject the notion that WF standard should be simple for
> = clients. If we want WF to be widely deployed, we make it easier = for
> servers so that the information is ubiquitously deployed = even by users
> and companies that are = unsophisticated.
>
> In contrast, standard-compliant WF = clients are probably going to be
> less common. Even if WF is not = too complex, why wouldn't you use a
> library if you want to have = some guarantee like security? If you want
> to simply write a few = curl commands and mesh the data after applying
> your homebrew = parser, you neither care for standard compliance or
> security, = and you still can get things done because the underlying
> data = schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM, Breno = <breno.demedeiros@gmail.com> wrote:
>> = On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> = Brad,
>>>
>>>
>>>
>>> I = really don’t like the secure-rels idea.  If a rel is secure = or should be
>>> treated as secure, I can mark it as such on = the server without creating more
>>> names and cluttering up = the link relation name space with multiple variants
>>> of = the same thing.
>>
>> As explained above, this does = not address HTTP-fallback degrade = attacks.
>>
>>>
>>>
>>>
&= gt;>> There were several people opposed to the client fall back = text due to both
>>> security concerns and client-side = complexity.  That was one of the main
>>> items we = addressed with this latest proposal re-write.
>>
>> = The proposal re-write does not seem to address any complexity. = It
>> simply removes guidance that would ensure implementations = that can be
>> 'plugged in' both in insecure and secure = contexts. The likely result
>> are simpler implementations that = can't be used in secure contexts,
>> even if they may make a = claim to the = contrary.
>>
>>>
>>>
>>>
= >>> I do realize the flakiness of the proposed = solution.
>>
>> Yes. It's too flaky for the purposes = of secure discovery.
>>
>>> Sometimes, the = client
>>> just does not work.  You type in paulej@packetizer.com and it says = “could
>>> not find a thing”, because the client = only issued the query over HTTPS.  If
>>> one needs = security, I see on other way.  However, if we’re willing to = go
>>> back to the -07 text that has an allowance for fall = back, the issue is
>>> addressed.  In the -07 text, a = client MAY re-issue a request using = HTTP.
>>>
>>>
>>>
>>> = Paul
>>>
>>>
>>>
>>> = From: Brad Fitzpatrick [mailto:bradfitz@google.com]
>>> Sent: = Thursday, December 13, 2012 6:15 PM
>>> To: Paul E. = Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M = Snell;
>>> webfinger@ietf.org
>>>
>>><= br>>>> Subject: Re: [webfinger] secure links with https = rels
>>>
>>>
>>>
>>> On = Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>
>>> = wrote:
>>>
>>> = Walter,
>>>
>>>
>>>
>>> = No, this will not work.  People want to have secure content and = what is
>>> secure might be determined by the server admin = or user.  One might consider
>>> his avatar should be = served over HTTPS = only.
>>>
>>>
>>>
>>> = And people do not want to have to write clients that do = fallback.
>>>
>>>
>>>
>>>= I never saw any strong opposition against fallback.  People = disliked the
>>> extra complexity, but for quite awhile = everybody assumed that fallback would
>>> be involved, and I = think it was considered = acceptable.
>>>
>>>
>>>
>>&g= t; Who was strongly = anti-fallback?
>>>
>>>
>>>
>>= ;>
>>>
>>> We either have to do HTTPS only or = we have to live with the fact that some
>>> client requests = are going to fail if a WF provider does not provide WF
>>> = services over = HTTPS.
>>>
>>>
>>>
>>> I = strongly disagree that those are the only two = options.
>>>
>>>
>>>
>>> = But if you really believe that, I hope you realize that flakiness = is
>>> unacceptable, which leaves you with = HTTPS-only.
>>>
>>>
>>>
>>&g= t; If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy = with
>>> = HTTPS-only.
>>>
>>>
>>>
>>&g= t;  So,
>>>
>>> 1)     =  Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS
>>>
>>> 2)      Servers and = clients MAY implement HTTP
>>>
>>> 3)   =    Servers MAY redirect from HTTP to HTTPS (this MUST NOT be = treated as
>>> secure since it allows for a MITM = attack)
>>>
>>> 4)      Servers = MUST NOT redirect from HTTPS to = HTTP
>>>
>>>
>>>
>>> All = works well, except for the case where you have an HTTPS-only = client.
>>> But, I bet that will be the majority of clients, = which will then drive the
>>> majority of the servers to = support = HTTPS.
>>>
>>>
>>>
>>> = This is a terrible cop-out.  Flakiness in the spec is = unacceptable.
>>>
>>>
>>>
>>= >  Still, it leaves the option on the table for some clients and = servers to
>>> use HTTP if they = wish.
>>>
>>>
>>>
>>>
= >>
>>
>>
>> --
>> Breno de = Medeiros
>
>
>
> --
> Breno de = Medeiros

--
Breno de Medeiros

 =

------=_NextPart_000_0993_01CDD99F.C5DAF120-- From zellyn@gmail.com Thu Dec 13 08:17:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500321F8A12 for ; Thu, 13 Dec 2012 08:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r86EodFDbjBf for ; Thu, 13 Dec 2012 08:17:21 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 119E221F89F8 for ; Thu, 13 Dec 2012 08:17:20 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2196973obc.31 for ; Thu, 13 Dec 2012 08:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbzLh4cJsyIMLVJmLXMtHGsRcYoMTiWp6C4InUjWWa8=; b=QxxOG0P9JeKCSVHyVac5R0bRNKGUzAKIu0Ca+gFL8uC6cGLZxNl193xwZKIvIQIfaz iLmgVlfhiHc+cIMhPNPqxD+2PCPsURIBtNhIY4zUj88QCYmzuWjmXi2NLvsCFUJ6u8hw jicYjvSTqjjS7OnXeVUCoPlyTM8w4hY5nsKa4AMnlqNDRoD9cWuRIvOCUVPLCq1Ev+87 mwhJVBKkgLEtZ0klcfCEygUaMFlQfkdhsKFSfweFsmpmY5kSgc5eSCTZs/pdxnRzIqZq PtCKJuFGGlgJJ1RwVUL+vAnw91NFsfRHVKT9yHOG47TSWsUuC6aU/kaHY/0wiSbq2UeT jm2A== MIME-Version: 1.0 Received: by 10.60.31.195 with SMTP id c3mr1943856oei.57.1355415440573; Thu, 13 Dec 2012 08:17:20 -0800 (PST) Received: by 10.76.129.36 with HTTP; Thu, 13 Dec 2012 08:17:20 -0800 (PST) In-Reply-To: <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 08:17:20 -0800 Message-ID: From: Zellyn Hunter To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8fb1ebc0dbc31c04d0be3fef X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:17:22 -0000 --e89a8fb1ebc0dbc31c04d0be3fef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The http links seem to work okay... http://profiles.google.com/zellyn http://plus.google.com/110196407167832022215 On Thu, Dec 13, 2012 at 7:58 AM, Paul E. Jones wrote= : > Oh, I don=92t like that. Suppose I want to provide a URL to my profile p= age > on Google+. There=92s no security-related issues with that (as far as I= =92m > concerned), but the URL scheme is =91https=92 for Google+. (And I say = =93as far > as I=92m concerned=94, since if you issue a query for my profile page and= end > up at the wrong place due to a hacker=92s actions, it=92s no different th= an > visiting my homepage today. I don=92t secure that, either.)**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Brad Fitzpatrick > *Sent:* Thursday, December 13, 2012 10:30 AM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > On Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones > wrote:**** > > But what if I=92m not looking for a specific link, but just want all of t= he > links related to foo@example.com? I might be building a =93profile=94 ty= pe > page or I might accept a number of different pieces of data (vcard, hcard= , > xcard, portable contact, avatar, =93preferred name=94, etc.). Then what?= **** > > ** ** > > If a successful connection to HTTPS was made, all the links would be > returned.**** > > ** ** > > If plain HTTP was used, all links beginning with "https:" would be > filtered out by the client. (just like in the single rel lookup case)***= * > > ** ** > > I thought that followed obviously from the proposal, sorry.**** > --e89a8fb1ebc0dbc31c04d0be3fef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The http links seem to work okay...
<= a href=3D"http://plus.google.com/110196407167832022215">http://plus.google.= com/110196407167832022215


On Thu,= Dec 13, 2012 at 7:58 AM, Paul E. Jones <paulej@packetizer.com>= wrote:

Oh, I don=92t= like that.=A0 Suppose I want to provide a URL to my profile page on Google= +.=A0 There=92s no security-related issues with that (as far as I=92m conce= rned), but the URL scheme is =91https=92 for Google+.=A0 (And I say =93as f= ar as I=92m concerned=94, since if you issue a query for my profile page an= d end up at the wrong place due to a hacker=92s actions, it=92s no differen= t than visiting my homepage today.=A0 I don=92t secure that, either.)

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Brad Fitzpatrick
Sent: Thursday, December 13, 2012 10:30 AM
To: webfinger@googlegroups= .com
Cc: webfinger@ietf.org
Subject: Re: [webfinger] secure links with https rels<= /span>

= =A0

On Wed, Dec 12, 2012 a= t 11:23 PM, Paul E. Jones <paulej@packetizer.com> wrote:

But what if I=92m not looking for= a specific link, but just want all of the links related to foo@example.com?=A0 I might be bu= ilding a =93profile=94 type page or I might accept a number of different pi= eces of data (vcard, hcard, xcard, portable contact, avatar, =93preferred n= ame=94, etc.).=A0 Then what?

=A0<= u>

If a successf= ul connection to HTTPS was made, all the links would be returned.=

=A0

If plain HTTP was used, all link= s beginning with "https:" would be filtered out by the client. = =A0(just like in the single rel lookup case)

=A0

I thought that followed obv= iously from the proposal, sorry.

--e89a8fb1ebc0dbc31c04d0be3fef-- From zellyn@gmail.com Thu Dec 13 09:01:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549A221F8B85 for ; Thu, 13 Dec 2012 09:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2r-0sO-0NvD for ; Thu, 13 Dec 2012 09:01:10 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE321F8B9F for ; Thu, 13 Dec 2012 09:00:58 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2405388oag.31 for ; Thu, 13 Dec 2012 09:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jo/dECTOKSa/loi8OV1cvgW0GJQ5JF8OQV+AMdcbnYg=; b=MRWHFT6zX8IJqZ3giJxY2jQzq8wqmdxiMXS674ik3nNGikB9eG4db5MGS5jW4gmDFU RW+xF+So0D8eX09+DvWN2aQ6TWiQhMngu97nbRnJRzEOoVgGj/DvcMkX1TJMXqXZSrC1 ZIXwhnihXlVsZbzcdSB7gk4TBJ9Z2/ULtuHLIl1pzXRwIgW+rtqHY16xRdRgZfdcWP3M ch01i91ejCQ90XMpfOuMxH6HR3tXAD9wYOuPtPY71HupzzOkQt98KErUQxaDhvcyPPtz 4cUF2z4P0bvTAnip9fIamBsT+Nik2fKARdH2BQtb/v0m6zzJ6owGyH9FTkh4cYCQrijZ umuA== MIME-Version: 1.0 Received: by 10.182.212.35 with SMTP id nh3mr2138652obc.10.1355418047614; Thu, 13 Dec 2012 09:00:47 -0800 (PST) Received: by 10.76.129.36 with HTTP; Thu, 13 Dec 2012 09:00:47 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> Date: Thu, 13 Dec 2012 09:00:47 -0800 Message-ID: From: Zellyn Hunter To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f5039dc400df704d0bedb54 X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:01:22 -0000 --e89a8f5039dc400df704d0bedb54 Content-Type: text/plain; charset=ISO-8859-1 Right you are. Color me temporarily confused too! :-) On Thu, Dec 13, 2012 at 8:19 AM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 8:17 AM, Zellyn Hunter wrote: > >> The http links seem to work okay... >> http://profiles.google.com/zellyn >> http://plus.google.com/110196407167832022215 >> > > See my previous email. This isn't the issue. > > --e89a8f5039dc400df704d0bedb54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Right you are. Color me temporarily confused too! :-)


On Thu, Dec 13, 2012 at 8:19 AM, Br= ad Fitzpatrick <bradfitz@google.com> wrote:
On Thu, Dec 13, 2012 at 8:17 AM,= Zellyn Hunter <zellyn@gmail.com> wrote:
The http links seem to work okay...

See my previous email. =A0This isn't the = issue.


--e89a8f5039dc400df704d0bedb54-- From wnorris@gmail.com Thu Dec 13 11:16:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7C21F892E for ; Thu, 13 Dec 2012 11:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2yDYaZTtfB3 for ; Thu, 13 Dec 2012 11:16:33 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 809C521F8901 for ; Thu, 13 Dec 2012 11:16:33 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1521922eek.31 for ; Thu, 13 Dec 2012 11:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=MRiDKKQbaxXrHWj3YxtaJDYt/dikYo9rsKv6xVEcrbs=; b=JAImFegu0IG5NLQO9fMXW9VpRoE10IoyrEU0m0gUgpgRBJXwqpoF7sibDW5eBiw6uu SOlFOPD+m79Hw9i0gn3Hbt61JeVvjF8Dx4QZr0FkAJg7yoWEsxLiG5UGDUgPZ905+Kl7 YbfNfN4KMrI/SpnraFdwRTQyuZEEmtLPHfsdBI0r7EfGF3ozkpDnG4ochRUIjj1Y8oqH jswlAu7Ss7FnmP9jhkK4rz0QEB3r7Yy1V6JN62G/bLCU40paYsU8IfLEmhztN6HEUMeM fIOOCb7XZd4yVM/Q4AFy3/MD7iypsVNZChvQ8Iwgnb5YBUOuTnJSwqD6D8sEBlBfImW3 Z83w== Received: by 10.14.0.133 with SMTP id 5mr7660243eeb.29.1355426192672; Thu, 13 Dec 2012 11:16:32 -0800 (PST) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.223.153.198 with HTTP; Thu, 13 Dec 2012 11:16:02 -0800 (PST) In-Reply-To: References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <2C660016-7BF9-4975-B7B5-7EFC1BDF88AF@telecomitalia.it> From: Will Norris Date: Thu, 13 Dec 2012 11:16:02 -0800 X-Google-Sender-Auth: _zYv-X-lfmUuJdUvRrPkPDVQadY Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: "webfinger@ietf.org" , Brad Fitzpatrick , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:16:34 -0000 On Thu, Dec 13, 2012 at 11:11 AM, James M Snell wrote: > Per RFC5988, you are certainly free to register individual link relations > that add constraints around the resources being linked to. Registering > something like "secure-canonical" that indicates that the href must always > point to an https: url would certainly be possible and well within what > rfc5988 allows. Whether or not it's a good idea is separate issue. I don't > believe it is. You wouldn't specify that the "secure-canonical" link must *point* to an https URL. You're right that that provides no additional security. Rather you would specify that it must be *retrieved* from an https URL. For protocols where security is required, they would only ever specify https rel values, meaning that clients should only ever trust them when they are retrieved from a document that was transmited over https. > > Consider: > > { > "rel": "secure-canonical", > "href": "https://example.org" > } > > is no more or less secure in practice than > > { > "rel": "canonical", > "href": "https://example.org" > } > > In either case, the browser still has to ultimately look at the href value. > Further, it's not even clear exactly which problem would be addressed by > this. Introducing some notion of a "Secure" link rel will not prevent or > mitigate an attack. From the examples given in this thread, the attack > occurs well before the client processes the JRD document at all. In such > cases, *none* of the information in the JRD can be trusted and the client > should simply refuse to process it at all. > > - James > > > On Thu, Dec 13, 2012 at 11:01 AM, Brad Fitzpatrick > wrote: >> >> >> >> On Thu, Dec 13, 2012 at 10:58 AM, James M Snell wrote: >>> >>> >>> >>> >>> On Thu, Dec 13, 2012 at 10:52 AM, Brad Fitzpatrick >>> wrote: >>>> >>>> On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter >>>> wrote: >>>>> >>>>> Then it means that no iana-registered link rel could ever be considered >>>>> as secure, correct? That seems way too limiting to me... >>>> >>>> >>>> Correct, unless iana-registered can include those with an "https:" >>>> prefix. Any technical reason we couldn't register full URL rels with the >>>> IANA? >>>> >>> >>> http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type >>> names MUST conform to the reg-rel-type rule" >>> >>> LOALPHA = >>> reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) >>> >>> You would have to update and obsolete RFC 5988 to register full URLs. I >>> certainly would be -1 on any effort to do so. >> >> >> Okay: begins with "https:" or begins with "secure-". >> > > From zellyn@gmail.com Thu Dec 13 11:36:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0F21F8A32 for ; Thu, 13 Dec 2012 11:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rlR3NtL3yqs for ; Thu, 13 Dec 2012 11:36:39 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 965C121F89F9 for ; Thu, 13 Dec 2012 11:36:39 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so2619080oag.31 for ; Thu, 13 Dec 2012 11:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/x/tBSpiEy4KrxAmJu5CBqpI1azqOIZjTrBX/Q5n9wk=; b=MfpBlmm6BLErYnXBiv84q41dLHr8UWcViJhE0Sfw5W40ig0R6VeIPEiJmF6kW4044i MBbVvNzy35mn4Wh6XbkuFAbX91ViB0Us1YX0Ar6smyprhQEqXi5eDYykT3sW7sAYYsSZ WjkVb9ETCuajs8zoIBISpu6xWL2ncJjxsp8E7CY6QFcPy64aVQAc6Fq/QvYUeE2UipVg mwCbGHAD9N4Qu7O/usuwMLY0NIpm3f9Ke1D/3Hg7cWFiiksPWcwKWZ9pbQb74LYO0nt6 JY7KBrmmEfNbJh60X1Bhoqp2imFpbTNEUvNzxHbFVG9cqkqtgdscCfzqrFwnycJd+OdD eqAQ== MIME-Version: 1.0 Received: by 10.182.110.1 with SMTP id hw1mr2514293obb.68.1355427399053; Thu, 13 Dec 2012 11:36:39 -0800 (PST) Received: by 10.76.129.36 with HTTP; Thu, 13 Dec 2012 11:36:38 -0800 (PST) In-Reply-To: <069f01cdd968$34447420$9ccd5c60$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <069f01cdd968$34447420$9ccd5c60$@packetizer.com> Date: Thu, 13 Dec 2012 11:36:38 -0800 Message-ID: From: Zellyn Hunter To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04430354a3aff604d0c108be X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:36:40 -0000 --f46d04430354a3aff604d0c108be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Only if by "query to an HTTPs URL" and "query to an HTTP URL", you mean a "webfinger client query" rather than a plain old "http(s) query". The onus is on the *client* to reject "secure" items retrieved over HTTP. The server can return the same content in both cases. In other words, if you ask the webfinger client for my "secure-cat-picture", you will never get an answer unless the answer was retrieved over HTTPS, regardless of whether it's in the HTTP response or not. Zellyn On Thu, Dec 13, 2012 at 11:29 AM, Paul E. Jones wrot= e: > No, I understand the downgrade attack, but that is totally unrelated to > what we were talking about.**** > > ** ** > > What we were discussing is that a query to an HTTPS URL might return a > different set of link relations than a query to an HTTP URL. More > specifically, a query to an HTTPS URL might return things the server > believes should only be returned over HTTPS, such as links to an OpenID > Provider.**** > > ** ** > > Nowhere in the currently proposed =93compromise=94 text is there a propos= al to > fall back as you=92re showing it. A client either requests WF via HTTPS = or > HTTP, not both. In the case of the latter, it=92s not looking for secure > content or security is a non-issue.**** > > ** ** > > Paul**** > > ** ** > > *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] > *Sent:* Thursday, December 13, 2012 11:54 AM > > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; webfinger@ietf.org > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones > wrote:**** > > Don=92t put it on the wire. You want the server to filter before sending= a > reply.**** > > ** ** > > I'm concerned you're still confused about how a downgrade attack works.**= * > * > > ** ** > > Again: it DOES NOT MATTER what the server thinks it's filtering if the > client has been tricked into talking to a DIFFERENT SERVER which is then > returning malicious results.**** > > ** ** > > Such as:**** > > -- client wants "all links" for foo@example.com.**** > > -- client requests secure > https://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com= *** > * > > -- EVIL HIJACKER BLOCKS PORT 443**** > > -- client then requests plain > http://example.com/.well-known/webfinger?resource=3Dacct:foo@example.com*= *** > > -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:*= * > ** > > {**** > > "rel" : "https://openid.net/connect/server",**** > > "type" : "text/html",**** > > "href" : "https://attacker.openid.server/"**** > > },**** > > ** ** > > See what happened there?**** > > We need the *client* to say "whoa whoa, wait a minute... I contacted this > webfinger server over HTTP---- what's it doing returning rels starting wi= th > https:? I'm gonna skip over those (or just return an error)."**** > > ** ** > > The real webfinger server _was never even contacted_, so it doesn't matte= r > whether it was filtering or not.**** > > ** ** > --f46d04430354a3aff604d0c108be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Only if by "query to an HTTPs URL" and "query to an HTT= P URL", you mean a "webfinger client query" rather than a pl= ain old "http(s) query". The onus is on the *client* to reject &q= uot;secure" items retrieved over HTTP. The server can return the same = content in both cases.

In other words, if you ask the webfinger client for my = "secure-cat-picture", you will never get an answer unless the ans= wer was retrieved over HTTPS, regardless of whether it's in the HTTP re= sponse or not.

Zellyn


On Thu, Dec 13, 2012 at 11:29 AM, Paul E. Jones &= lt;paulej@packet= izer.com> wrote:

No, I underst= and the downgrade attack, but that is totally unrelated to what we were tal= king about.

=A0<= /p>

What we were discussin= g is that a query to an HTTPS URL might return a different set of link rela= tions than a query to an HTTP URL.=A0 More specifically, a query to an HTTP= S URL might return things the server believes should only be returned over = HTTPS, such as links to an OpenID Provider.

=A0<= /p>

Nowhere in the current= ly proposed =93compromise=94 text is there a proposal to fall back as you= =92re showing it.=A0 A client either requests WF via HTTPS or HTTP, not bot= h.=A0 In the case of the latter, it=92s not looking for secure content or s= ecurity is a non-issue.

=A0<= /p>

Paul

=A0<= /p>

From: Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 11:54 AM


To: Paul E. Jones
Cc: webfinger@googlegroups.com; webfinger@ietf.org
Subject: Re: [webfinger] secure links with https rels<= /div>

=A0

On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jo= nes <paulej@p= acketizer.com> wrote:

Don=92t pu= t it on the wire.=A0 You want the server to filter before sending a reply.<= /span>

=A0<= u>

I'm conce= rned you're still confused about how a downgrade attack works.

=A0

Again: it DOES NOT MATTER what t= he server thinks it's filtering if the client has been tricked into tal= king to a DIFFERENT SERVER which is then returning malicious results.

=A0

= Such as:

-- client wants "all link= s" for foo@exampl= e.com.

-- EVIL HIJACKER BLOCKS PORT 4= 43

-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:

=A0 =A0 =A0 =A0 =A0{

=A0 =A0 = =A0 =A0 =A0 =A0"rel" : "https://openid.net/connect/server",=

=A0 =A0 =A0 =A0 =A0 =A0"t= ype" : "text/html",

=A0 =A0 =A0 =A0 =A0 =A0"href" : "https://attacker.openid.serve= r/"

=A0 =A0 =A0 =A0 =A0},

= =A0

See what happened there?

We need the *client* to say "whoa whoa, wait a minute... I = contacted this webfinger server over HTTP---- what's it doing returning= rels starting with https:? I'm gonna skip over those (or just return a= n error)."

=A0

The real webfinger server _was n= ever even contacted_, so it doesn't matter whether it was filtering or = not.

=A0


--f46d04430354a3aff604d0c108be-- From zellyn@gmail.com Thu Dec 13 11:55:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31B421F88CE for ; Thu, 13 Dec 2012 11:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPk936nkQhzr for ; Thu, 13 Dec 2012 11:55:42 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA45821F852C for ; Thu, 13 Dec 2012 11:55:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2479293obc.31 for ; Thu, 13 Dec 2012 11:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sSsXlhMrE7Nk312DAOTHbeyA1aKMXRyAqD1rkq3gOoM=; b=dt5BOAC8MAJQvbtbuHWucIjWHrntbut0XnmXyekSsXDG+RHdXvU8drSaxUJoFG5TcQ g3zKgPtqFeEkFnV4Il6FZw+8Uw9LgE481VJVykhwkWSJ5MKvZud0RvBE1E4H+E0IwfeP vLpJNa4y/TBH2mNWiWlRs+8ULzvyybpnXQBf30m8NjKAPKQ1XqeIvtvMkNrncZ7LLQ+z 3Yv55hCQ6oPgkO4ZJgSEtqmCc8QU/A8SVff0h51p3PsLM1FfOe8iY6bN60B849G30S6h 1NuyyoVkc1tM55d4mPMS+yvpW8uJYtwCdEigGfhCinPj6PRPsl5+Iyk9tSii/WCcaHf4 l7cA== MIME-Version: 1.0 Received: by 10.182.64.38 with SMTP id l6mr2602074obs.51.1355428542119; Thu, 13 Dec 2012 11:55:42 -0800 (PST) Received: by 10.76.129.36 with HTTP; Thu, 13 Dec 2012 11:55:41 -0800 (PST) In-Reply-To: <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> References: <04a501cdd902$b6cd1cf0$246756d0$@packetizer.com> <053301cdd94a$be9fe690$3bdfb3b0$@packetizer.com> <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> Date: Thu, 13 Dec 2012 11:55:41 -0800 Message-ID: From: Zellyn Hunter To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae93b5ceec580e104d0c14c9b X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: Brad Fitzpatrick , James M Snell , webfinger@ietf.org Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:55:43 -0000 --14dae93b5ceec580e104d0c14c9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, It has to happen on the client. 1. Application code tries to look up "secure-openid-server" 2. Client tries to connect to https://www.zellyn.com/ 3. Evil adversary blocks the request. 4. Client falls back to HTTP. 5. Evil adversary returns a response that includes a value for rel=3D"secure-openid-server" 6. Profit. On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones wrot= e: > Brad,**** > > ** ** > > I agree the idea of marking a =93rel=94 as secure using https makes sense= . > That said, is my profile page to be marked secure or not? Do we define t= o > rel values for a profile page, one that=92s secure and one that=92s not, = then > let the user specify the rel type based on preference?**** > > ** ** > > What I think makes more sense if for the WF server admin to select what > information to convey via HTTP or HTTPS. I would have no objection to > certain things (e.g., the URI used to identify the OpenID Provider) to be > specified using https, thereby aiding in helping the server (and admin) i= n > making that decision.**** > > ** ** > > But, many rel values are just simple token strings. How do we deal with > those?**** > > ** ** > > I still think this should be a server-side decision to filter. Better, > have the HTTP server redirect to HTTPS. HTTPS servers NEVER redirect to > HTTP. And clients that need security NEVER use HTTP.**** > > ** ** > > Paul**** > > ** ** > > *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] > *Sent:* Thursday, December 13, 2012 1:40 PM > *To:* James M Snell > *Cc:* Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com > > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > On Thu, Dec 13, 2012 at 10:36 AM, James M Snell wrote= : > **** > > ** ** > > ** ** > > On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick > wrote:**** > > [snip]**** > > ** ** > > ** ** > > No... that's just nonsense. The real issue here is that the client has > absolutely no way of detecting that the evil hijacker intercepted the > request and provided false information in the first place. It should not > matter at all if the returned document contains link rels with "https:" i= n > them or not. **** > > ** ** > > You can never detect with HTTP that the connection was intercepted. That > doesn't matter, because the client does know one thing: that it used HTT= P > (and not HTTPS). So the client can filter out links which should not eve= r > appear over plain HTTP. I'm proposing that rels which begin with "https:= " > should never go over HTTP, and I've started calling those "secure rels". > Maybe that's a bad name, if enough people (including you now, in your > earlier email) assume that I'm talking about the value (the href).**** > > ** ** > > I'm open to alternative name suggestions.**** > > ** ** > > ** ** > > I'm -1 on the whole proposal. The notion of "insecure" and "secure" link > relations makes absolutely no sense at all.**** > > ** ** > > I'd like to ask that you think about and understand it before being so > negative on it.**** > > ** ** > > I promise it makes sense.**** > > **** > > It may not be possible to detect if the HTTP connection was intercepted, > but it is possible to determine if the information provided is trustworth= y. > That is what cryptographic signatures are for.**** > > ** ** > > That is outside the scope of WebFinger, and may be used in subsequent > hops. We're trying to provide a secure basis for the first hop. If we > can't get any attribute securely for foo@example.com, where are we > getting the public key from to verify subsequent use of "cryptographic > signatures".**** > > ** ** > --14dae93b5ceec580e104d0c14c9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,

It has to happen on the client.

1. Application code tries to look up "secure-openid-server"=A0
2. Client tries to connect to http= s://www.zellyn.com/
3. Evil adversary blocks the request.
4. Client falls back to HTTP.
5. Evil adversary returns a = response that includes a value for rel=3D"secure-openid-server"
6. Profit.



On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Brad,<= u>

=A0<= /p>

I agree the idea of ma= rking a =93rel=94 as secure using https makes sense.=A0 That said, is my pr= ofile page to be marked secure or not?=A0 Do we define to rel values for a = profile page, one that=92s secure and one that=92s not, then let the user s= pecify the rel type based on preference?

=A0<= /p>

What I think makes mor= e sense if for the WF server admin to select what information to convey via= HTTP or HTTPS.=A0 I would have no objection to certain things (e.g., the U= RI used to identify the OpenID Provider) to be specified using https, there= by aiding in helping the server (and admin) in making that decision.=

=A0<= /p>

But, many rel values a= re just simple token strings.=A0 How do we deal with those?

=A0<= /p>

I still think this sho= uld be a server-side decision to filter.=A0 Better, have the HTTP server re= direct to HTTPS.=A0 HTTPS servers NEVER redirect to HTTP.=A0 And clients th= at need security NEVER use HTTP.

=A0<= /p>

Paul

=A0<= /p>

From: Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snel= l
Cc: Paul E. Jones; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] secure links with htt= ps rels

=A0

On Thu, Dec 13, 2012 = at 10:36 AM, James M Snell <jasnell@gmail.com> wrote:

=A0

=A0

On Thu, Dec 1= 3, 2012 at 10:30 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

[snip]

=

=A0

=A0

No... that's just nonsense. The= real issue here is that the client has absolutely no way of detecting that= the evil hijacker intercepted the request and provided false information i= n the first place. It should not matter at all if the returned document con= tains link rels with "https:" in them or not.=A0

=A0

= You can never detect with HTTP that the connection was intercepted. =A0That= doesn't matter, because the client does know one thing: =A0that it use= d HTTP (and not HTTPS). =A0So the client can filter out links which should = not ever appear over plain HTTP. =A0I'm proposing that rels which begin= with "https:" should never go over HTTP, and I've started ca= lling those "secure rels". =A0Maybe that's a bad name, if eno= ugh people (including you now, in your earlier email) assume that I'm t= alking about the value (the href).

=A0

I'm open to alternative name= suggestions.

=A0

=A0=

I'm -1 on the whole propos= al. The notion of "insecure" and "secure" link relation= s makes absolutely no sense at all.

=A0=

I'd like t= o ask that you think about and understand it before being so negative on it= .

=A0=

I promise it makes sense.<= u>

=A0

It may not be possible to detect if = the HTTP connection was intercepted, but it is possible to determine if the= information provided is trustworthy. That is what cryptographic signatures= are for.

=A0=

That is outside the= scope of WebFinger, and may be used in subsequent hops. =A0We're tryin= g to provide a secure basis for the first hop. =A0If we can't get any a= ttribute securely for = foo@example.com, where are we getting the public key from to verify sub= sequent use of "cryptographic signatures".

=A0


--14dae93b5ceec580e104d0c14c9b-- From markus.lanthaler@gmx.net Thu Dec 13 13:57:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52421F8BE9 for ; Thu, 13 Dec 2012 13:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=-1.320, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDw7Qz5ViKNg for ; Thu, 13 Dec 2012 13:57:53 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2E77921F8BE7 for ; Thu, 13 Dec 2012 13:57:52 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2012 21:57:51 -0000 Received: from unknown (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp034) with SMTP; 13 Dec 2012 22:57:51 +0100 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+7zcpMCgq7mdOKRdNXAf3mlqlXQV3D2rbtWWpRC4 pMfZ/Y6M3ZlZSp From: "Markus Lanthaler" To: =?utf-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?= References: <014701cdce69$c51ef240$4f5cd6c0$@packetizer.com> <3C24A51B-2D83-4142-896F-8C587BC045D2@josephholsten.com> <7A879D5E-5012-4EB6-9017-BB13FAB65A0A@josephholsten.com> <00ac01cdceef$84a7fdc0$8df7f940$@lanthaler@gmx.net> <1354276043-sup-1914@heahdk.net> <50b8b1ba.a74fec0a.307d.1b98SMTPIN_ADDED_BROKEN@gmr-mx.google.com> <1355258144-sup-4085@heahdk.net> In-Reply-To: <1355258144-sup-4085@heahdk.net> Date: Thu, 13 Dec 2012 22:57:47 +0100 Message-ID: <013701cdd97c$e4403e40$acc0bac0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3X37xGDZGf0W8uT8y+ea4wSM/IhQBnPgYg Content-Language: de X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 13 Dec 2012 23:58:44 -0800 Cc: 'IETF Webfinger' , 'webfinger' Subject: Re: [webfinger] [apps-discuss] WebFinger payload as array or object X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:57:54 -0000 On Tuesday, December 11, 2012 9:40 PM, =E2=98=AE elf Pavlik =E2=98=AE = wrote: > thank you for clarifying! >=20 > also just recalled JSON-LD Macros project which could maybe help with > providing common transformations for webfinger profiles to JSON-LD: > https://github.com/antoniogarrote/json-ld-macros Right. Of course you could always use some simple pre-processing steps = to transform it to sensible JSON-LD. -- Markus Lanthaler @markuslanthaler From mmn@hethane.se Fri Dec 14 00:43:41 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB56821F8689 for ; Fri, 14 Dec 2012 00:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzX+3vlWuy5N for ; Fri, 14 Dec 2012 00:43:40 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id B9F5821F860A for ; Fri, 14 Dec 2012 00:43:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Dec 2012 09:43:30 +0100 From: Mikael Nordfeldth To: In-Reply-To: <50CA4D4D.6020002@status.net> References: <50CA4D4D.6020002@status.net> Message-ID: X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:43:41 -0000 13.12.2012 22:49 skrev Evan Prodromou: > Brad, > > Can I suggest another possibility? > > 1. The Webfinger spec mandates HTTPS-only. > 2. Those of us who want to support HTTP fall back to RFC 6415 (going > through HostMeta and LRDD). > 3. If there's a pressing need for an HTTP-accessible > /.well-known/webfinger endpoint, we do another teeny-tiny spec for > that. ("Do Webfinger, but on HTTP. QED.") Talk about client complexity! However, since noone would likely write a _new_ client with a RFC6415 fallback functionality I see it more as a way things would be nonetheless if verified-HTTPS-only becomes the Webfinger spec. (unimplemented HTTP Webfinger causes continued use of legacy RFCs) Regarding #3 though I think that specification will rise from a harsh reality rather than a desired specification. I imagine people defying the specification and: * running HTTP-doubling webfinger servers (which serve less-verified/secure data) * clients doing lookups to unverified HTTPS/HTTP servers, simply reporting back whether the connection was signed with a trusted SSL certificate or not. > I can definitely live with this; MMN? Honestly, I have a hard time seeing what would in practice become two specifications, "webfinger-ssl" and "webfinger", when the differences and caveats of the added "S" are already well-known from HTTPS/HTTP. Too redundant, I think. Though as mentioned previously, my main personal issues are difficult deployment of HTTPS and also a false sense of security that arises with blind faith in HTTPS. -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From ve7jtb@ve7jtb.com Fri Dec 14 01:18:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F296821F8440 for ; Fri, 14 Dec 2012 01:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zWkkMszWuBC for ; Fri, 14 Dec 2012 01:18:03 -0800 (PST) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0799A21F860A for ; Fri, 14 Dec 2012 01:17:52 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id s35so692562yhf.27 for ; Fri, 14 Dec 2012 01:17:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=X7gbTJn/wH+C2YCgGDabs7QrGb1WwcxT1oWJyNcOddY=; b=nnTdjpO7ha75/6jTaqdLrDOAYCdKaIjcmlqCDzbZ8w53oSLIYHDFE3MnfxvCqYg0pR KIndLFhhrHogJAU2/LGVnrw6cnf6S446SXQILrFZhnlRDNS8EfONiin+7rNsdwqVC1dU 4EmtTrvp1xAqbvpsM40SRktIc3NHDaIVuJSv3LxNTK8QKqqkrnaezYBrQGXxs6Vg4xGO 8wWIMm9OpH3zpH1t9AS3PGB/zWI2OgMkBeo2u8gzTh2TECJwp2Yv/KgbNBpdpRM7VyxV 1GG753AnnVy0nON+nnV9J0lX0hsd70us8qyURlZxcZvSlLcdvMux3Ydd6yWzUkxmCw46 cdOg== Received: by 10.236.52.194 with SMTP id e42mr4944369yhc.114.1355476672582; Fri, 14 Dec 2012 01:17:52 -0800 (PST) Received: from [192.168.125.40] ([200.211.176.101]) by mx.google.com with ESMTPS id i26sm4020923yhc.10.2012.12.14.01.17.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 01:17:51 -0800 (PST) References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08c101cdd9a6$e6ff9340$b4feb9c0$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8EF71911-B4EA-40C4-BF8F-D73A7E6607FC; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: John Bradley Date: Fri, 14 Dec 2012 07:17:48 -0200 To: Brad Fitzpatrick X-Gm-Message-State: ALoCoQm1YJB3OxNGhQXRlx66ge0FOZeg38JFhObzFI0ItbRXjVcrX5Zew31xjGH2Bx0mM5SXcg5E Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:18:04 -0000 --Apple-Mail-8EF71911-B4EA-40C4-BF8F-D73A7E6607FC Content-Type: multipart/alternative; boundary=Apple-Mail-426D6BC0-F19C-4619-948D-A809BCD58320 Content-Transfer-Encoding: 7bit --Apple-Mail-426D6BC0-F19C-4619-948D-A809BCD58320 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am on record supporting https: only as the only sane way to have a simple= client with security.=20 John B.=20 Sent from my iPad On 2012-12-14, at 1:00 AM, Brad Fitzpatrick wrote: > On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones wro= te: >> Never mind that question. If we go that path, we might as well just mand= ate HTTPS. >>=20 >=20 > Phew, that saved me a very confused email. Yes. > =20 >> So, who still is NOT in favor of just mandating use of HTTPS? >>=20 >=20 > Also curious on this. >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail-426D6BC0-F19C-4619-948D-A809BCD58320 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I am on record supporting  https: only as the only sane way to have a simple client with security. 

John B. 

Sent from my iPad

On 2012-12-14, at 1:00 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Never mind that question.  If we go that path, we might as well just mandate HTTPS.


Phew, that saved me a very confused email.  Yes.
 

 So, who still is NOT in favor of just mandating use of HTTPS?


Also curious on this.

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger
--Apple-Mail-426D6BC0-F19C-4619-948D-A809BCD58320-- --Apple-Mail-8EF71911-B4EA-40C4-BF8F-D73A7E6607FC Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTIxNDA5MTc1MVowIwYJKoZIhvcNAQkEMRYEFMG2 GfOsBfBtKbTTke0MTFSNb49IMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBABBLGP3U0jjtKHbxkvgBN23xylEp/d4XBihI g+6FK7FHtqXtNMQm4Xm0y3r0kr6ye5Z8V4Q0NzGstUgx9CQV35ZamUg9GTGdR49VHlWOHh/yGAgj xTrBf9DOwmrhUbFzTOdeqkkVGIVLlVr71FGYtx3tU6xHypT3lnsazhuNoxeSmK4Eyk3Gy46gZCL7 xjfltxJeUHm3LP/D/Vbnq1CUzHErf8zhUeUH87OiXJ0LCWk6b6BmHkFzTRhbtPpOQHbRpNzoNmaO hbVOAUM3nsVQocoTp+1vAJSEYGCcr/PkRsrwwNvaEpLlHlcOslRKkT1vq3juDfsmLxVleNgoYZ+m 100AAAAAAAA= --Apple-Mail-8EF71911-B4EA-40C4-BF8F-D73A7E6607FC-- From laurentwalter.goix@telecomitalia.it Fri Dec 14 01:30:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56321F8510 for ; Fri, 14 Dec 2012 01:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwOEl5pqtaVw for ; Fri, 14 Dec 2012 01:30:04 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id BFD3921F8504 for ; Fri, 14 Dec 2012 01:29:54 -0800 (PST) Content-Type: multipart/mixed; boundary="_99299070-93de-40cc-a232-d9dc82947ab1_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 14 Dec 2012 10:29:52 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 14 Dec 2012 10:29:52 +0100 From: Goix Laurent Walter To: Evan Prodromou , "webfinger@ietf.org" Date: Fri, 14 Dec 2012 10:29:50 +0100 Thread-Topic: [webfinger] the conflicting goals Thread-Index: Ac3Ze66AbsnnYUQjR2SpeBbOlCwBnwAYchxA Message-ID: References: <50CA4D4D.6020002@status.net> In-Reply-To: <50CA4D4D.6020002@status.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: Mikael Nordfeldth Subject: [webfinger] R: the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:30:07 -0000 --_99299070-93de-40cc-a232-d9dc82947ab1_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA885CGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA885CGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would also avoid this as this is ok for a transitional period only but su= pposes that eventually once the community has migrated, only https is suppo= rted. Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per cont= o di Evan Prodromou Inviato: gioved=EC 13 dicembre 2012 22.49 A: webfinger@ietf.org Cc: Mikael Nordfeldth Oggetto: Re: [webfinger] the conflicting goals Brad, Can I suggest another possibility? 1. The Webfinger spec mandates HTTPS-only. 2. Those of us who want to support HTTP fall back to RFC 6415 (going thro= ugh HostMeta and LRDD). 3. If there's a pressing need for an HTTP-accessible /.well-known/webfing= er endpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on= HTTP. QED.") It's going to take a while for /.well-known/webfinger endpoints to get depl= oyed, and falling back to /.well-known/host-meta will probably be part of o= ur world for a while, so it's not really that big a loss. I can definitely live with this; MMN? -Evan On 12-12-13 02:35 PM, Brad Fitzpatrick wrote: Here are the conflicting forces at work in the WebFinger spec, as I see it: 1) security (the HTTPS-only camp, and people who want to use WebFinger for = the base of e.g. OpenID Connect). It should be possible to get a key/value= pair ("link") only over HTTPS. 2) HTTP-permitted (status.net, Blaine, Paul, et al ... a= lso those who just want to use WebFinger for casual things... names & avata= rs, or doing their own crypto/signing out of band, and/or don't like the Ro= ot CA system) 3) client simplicity. I believe that we can only have 2 of those 3. We've heard proposals for di= fferent sets of those two: 1+2: secure rel proposal (clients filtering out secure rels from HTTP respo= nses). requires some complexity in clients to filter out insecure rels. 1+3: HTTPS-only. 2: contact either HTTP or HTTPS. servers SHOULD run on both? latest propo= sal, which I feel will be error-prone. 2+~3: contact both HTTP & HTTPS in parallel or with fallback, use whatever = you can connect to. No security. Originally I voted for HTTPS-only (which is 1+3), but enough people on this= list want 2), so I think we need to give up 3) and go with 1+2. I remain fine with HTTPS-only, but I don't think it has enough support. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA885CGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would also avoid this as this is ok for a transitional per= iod only but supposes that eventually once the community has migrated, only= https is supported.

 

Da: = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per conto di Evan Prodromou
Inviato: gioved=EC 13 dicembre 2012 22.49
A: webfinger@ietf.org
Cc: Mikael Nordfeldth
Oggetto: Re: [webfinger] the conflicting goals

 

Brad,

Can I suggest another possibility?

  1. The Webfinger spec mandates HTTPS-only.
  2. Those of us who want to support HTTP fall back to RFC 6415 (going through H= ostMeta and LRDD).
  3. If there's a pressing need for an HTTP-accessible /.well-known/webfinger en= dpoint, we do another teeny-tiny spec for that. ("Do Webfinger, but on= HTTP. QED.")

It's going to take a while for /.well-known/webfinge= r endpoints to get deployed, and falling back to /.well-known/host-meta wil= l probably be part of our world for a while, so it's not really that big a = loss.

I can definitely live with this; MMN?

-Evan

On 12-12-13 02:35 PM, Brad Fitzpatrick wrote:

Here are the conflict= ing forces at work in the WebFinger spec, as I see it:

1) security (the HTTPS-only camp, and peo= ple who want to use WebFinger for the base of e.g. OpenID Connect).  I= t should be possible to get a key/value pair ("link") only over HTTPS.

 

2) HTTP-permitted (status.net, Blaine, Paul, et al ... also those who just want to= use WebFinger for casual things... names & avatars, or doing their own crypto/signing out of band, and/or don't like the Root CA system= )

 

3) client simplicity.

 

I believe that we can only have 2 of thos= e 3.  We've heard proposals for different sets of those two:

 

1+2: secure rel proposal (clients fil= tering out secure rels from HTTP responses).  requires some complexity= in clients to filter out insecure rels.

1+3: HTTPS-only.

2: contact either HTTP or HTTPS.  se= rvers SHOULD run on both?  latest proposal, which I feel will be error= -prone.

2+~3: contact both HTTP & HTTPS i= n parallel or with fallback, use whatever you can connect to. No security.<= o:p>

 

Originally I voted for HTTPS-only (which = is 1+3), but enough people on this list want 2), so I think we need to = give up 3) and go with 1+2.

 

I remain fine with HTTPS-only, but I don'= t think it has enough support.

 




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/webfinger




-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-51=
4-554-3826
= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA885CGRFMBX704BA02_-- --_99299070-93de-40cc-a232-d9dc82947ab1_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_99299070-93de-40cc-a232-d9dc82947ab1_-- From laurentwalter.goix@telecomitalia.it Fri Dec 14 01:43:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5158D21F84BB for ; Fri, 14 Dec 2012 01:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFZtjL32rhAo for ; Fri, 14 Dec 2012 01:43:06 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71021F8414 for ; Fri, 14 Dec 2012 01:43:02 -0800 (PST) Content-Type: multipart/mixed; boundary="_725d34b1-9ee3-49eb-86cb-d4dcf668e8df_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 14 Dec 2012 10:43:01 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 14 Dec 2012 10:43:01 +0100 From: Goix Laurent Walter To: Brad Fitzpatrick , James M Snell Date: Fri, 14 Dec 2012 10:42:58 +0100 Thread-Topic: [webfinger] The HTTP/HTTPS Issue Thread-Index: Ac3ZtS/hR6kAqihfT+m0MRYxj52/YgAJo8GA Message-ID: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: [webfinger] R: The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:43:07 -0000 --_725d34b1-9ee3-49eb-86cb-d4dcf668e8df_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA887DGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA887DGRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2XigJlyZSB0YWxraW5nIGFib3V0IGNsaWVudHMgYnV0IG5vdCBhcHBsaWNhdGlvbnMuIElmIGNs aWVudHMgYXJlIHRoZSBpbXBsZW1lbnRhdGlvbiBzdGFja3Mgb2YgdGhlIHNwZWMsIHRoZW4gdGhl eSBzaG91bGQgZ2l2ZSB0aGUgd2hvbGUgZmxleGliaWxpdHkgb2YgaXQuIEl0IGlzIHVwIHRvIHRo ZSBhcHAgKHJlcHJlc2VudGluZyB0aGUgc3BlY2lmaWMgdXNlLWNhc2UpIHRvIGRlY2lkZSB3aGV0 aGVyIGl0IG5lZWRzIHNlY3VyaXR5IG9yIG5vdCwgYW5kIHdoZXRoZXIgZmFsbGJhY2sgbWF5IGJl IGFjY2VwdGFibGUgb3Igbm90LiBJZiBodHRwcy10by1odHRwIGZhbGxiYWNrIGlzIHBlcmZvcm1l ZCBhdCBhcHBsaWNhdGlvbiBsZXZlbCBhbmQgbm90IGF1dG9tYXRpY2FsbHkgYnkgdGhlIGNsaWVu dCB0aGVuIHdlIG1heSBhbGwgY29udmVyZ2UuDQoNCkxldCBtZSBnaXZlIGFuIGV4YW1wbGU6DQoN Ci0gICAgICAgICAgVXNlIGNhc2UgdHlwZSAxICjigJxhdXRvY29uZmlndXJhdGlvbi9sb2dpbuKA nSk6IE15IHdlYnNpdGUgaXMgcHJvdmlkaW5nIHJlZ2lzdHJhdGlvbiB0aHJvdWdoIG9wZW5pZGNv bm5lY3Qgd2hlcmUgdGhlIHVzZXIgY2FuIGlucHV0IGhpcyBpZGVudGl0eS4gU2luY2UgdGhpcyBp cyB3aGF0IEkgY2FuIGNhbGwgYXV0b2NvbmZpZ3VyYXRpb24gdXNlIGNhc2UgKGluIHRoYXQgc2Vu c2Ugc2ltaWxhciB0byBkaXNjb3ZlcmluZyBteSBvYXV0aCogZW5kcG9pbnRzKSB0aGUgYXBwICht eSB3ZWJzaXRlKSAxKSBuZWVkcyBzZWN1cml0eSBhbmQgMikga25vd3MgcHJldHR5IG11Y2ggdGhl IGxpbmsgcmVscyBpdOKAmXMgaW50ZXJlc3RlZCBpbi4gaXQgdGhlbiBpc3N1ZXMgdGhlIHdmIHJl cXVlc3Qgb3ZlciBodHRwcyBvbmx5IChvcHRpb25hbGx5IGFkZGluZyB0aGUgZXhwbGljaXQgbGlz dCBvZiBsaW5rcykuIElmIHRoYXQgcmVxdWVzdCBmYWlscyBiZWNhdXNlIHRoZSBpZHAgaXMgbm90 IHJ1bm5pbmcgb3ZlciBodHRwcywgdGhlbiBteSB3ZWJzaXRlIChub3IgdGhlIHVuZGVybHlpbmcg d2YgY2xpZW50KSBkb2VzIG5vdCBmYWxsYmFjayBvdmVyIGh0dHAgYW5kIHRlbGxzIHRoZSB1c2Vy IHRoYXQgaGUgY2Fubm90IHVzZSB0aGF0IGlkZW50aXR5LiBTaW1pbGFybHkgaWYgSSB3YW50IHRv IGF1dG9jb25maWd1cmUgbXkgZmF2b3JpdGUgYXBwIGJhc2VkIG9uIG15IGlkZW50aXR5IGFuZCBk aXNjb3ZlciBhIGJ1bmNoIG9mIGVuZHBvaW50cyBteSBjbGllbnQgc2hvdWxkIG5vdCBmYWxsYmFj ayB0byBodHRwLg0KDQotICAgICAgICAgIFVzZSBjYXNlIHR5cGUgMiAo4oCccHVibGljIGluZm8g ZGlzY292ZXJ54oCdKTogTXkgZmF2b3JpdGUgZW1haWwgYXBwIGhhcyBhIHBsdWdpbiB0aGF0IHJl c29sdmVzIGVtYWlsIGFkZHJlc3NlcyB0byBzaG93IHRoZSB1c2Vy4oCZcyBhdmF0YXIuIEZvciBl YWNoIGVtYWlsIGFkZHJlc3MgaXQgaXNzdWVzIGEgd2YgcmVxdWVzdCBhbmQgY2FuIGRlY2lkZSB3 aGV0aGVyIHRvIHRyeSBodHRwcyBmaXJzdCBvciBkaXJlY3RseSBodHRwLiBTdXBwb3NlIGl0ICph c2tzIHRoZSBjbGllbnQgdG8gdHJ5IGh0dHBzIGZpcnN0IChtYXkgYmUgdGhlIGRlZmF1bHQpKi4g SWYgdGhlIGNsaWVudCBmYWlscyBmb3IgdGhlIHNhbWUgcmVhc29uLCB0aGVuICp0aGUgYXBwKiBj YW4gZGVjaWRlIHRvIHRyeSBhZ2FpbiBvdmVyIHBsYWluIGh0dHAgYW5kIGRlY2lkZSB3aGF0IHRv IGRvIHdpdGggdGhlIHByb3ZpZGVkIGluZm9ybWF0aW9uIChlZyBhY2NlcHQgaXQgYXMgYXZhdGFy IG1heSBiZSBjb25zaWRlcmVkIGxlc3Mgc2Vuc2l0aXZlKS4NCg0KSWYgd2UgbW92ZSB0aGUgc2Vj dXJpdHkgY29uY2VybiBhdCBhcHAgbGV2ZWwgdGhlbiB3ZSBuZWVkIGEgbWVjaGFuaXNtIHRvIHRl bGwgc28sIHdoaWNoIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHNwZWNpZmljIGNvZGViYXNlIGFu ZC9vciBhcGkgc2lnbmF0dXJlLiBPbmUgcG9zc2liaWxpdHkgY291bGQgYmUgaW4gdGhlIHJlc291 cmNlIFVSSSBpdHNlbGYgdGhhdCB3ZSBhcmUgcXVlcnlpbmcuIFdlIGFscmVhZHkgc2FpZCB0aGF0 IGFueSB0eXBlIG9mIHVyaSBpcyBzdXBwb3J0ZWQgd2l0aCBhIHNwZWNpZmljIG1lbnRpb24gb2Yg YWNjdDouIFdoYXQgYWJvdXQgaW50cm9kdWNpbmcgYWNjdHM6IGZvciB0aGlzIHB1cnBvc2U/IFNp cHM6LCB3c3M6LCBodHRwczogYXJlIGFsbCBleGFtcGxlcyBvZiB1cmlzIHRoYXQgZXhwbGljaXRs eSBjYWxsIGZvciB0bHMuIEluIHRoYXQgY2FzZSBpZiB0aGUgYXBwIHJlcXVlc3RzIHdmLmRpc2Nv dmVyKOKAnGFjY3RzOnVzZXJAZXhhbXBsZS5jb23igJ0pIHRoZSBjbGllbnQgd291bGQga25vdyB0 aGF0IGl0IGhhcyB0byBydW4gb3ZlciBodHRwcy4gQW5kIGl0IHdvcmtzIGZvciBodHRwczogVVJJ cyBhcyB3ZWxsIGFuZCBvdGhlcnMuDQoNCldpdGggdGhpcyBhcnRpZmFjdCB3ZSBjYW4gZ2V0IHJp ZCBvZiB0aGUgZmFsbGJhY2sgcHJvYmxlbSBvbiB0aGUgY2xpZW50IHNpZGUgYW5kIHN0YXkgd2l0 aCB0aGUgY3VycmVudCB0ZXh0IGluIHNheWluZyB0aGF0IGl0IG11c3Qgbm90IHRyeSBpbiBwYXJh bGxlbCBvciBpbiBzZXF1ZW5jZSAobWVhbnQgYXMg4oCcYXV0b21hdGljYWxseeKAnSkuIEJ1dCBp dCBtYXkgYmUgcmVxdWVzdGVkIHRvIGRvIHNvIGJ5IHRoZSBhcHAgaWYgYWZ0ZXIgYSBmYWlsdXJl IG92ZXIgaHR0cHMgKGVnIGZvciB1c2UgY2FzZSB0eXBlIDIpIHRoZSBhcHAgZGVjaWRlcyB0byBn byBvdmVyIHBsYWluIGh0dHAgKHVzaW5nIGFjY3Q6IFVSSSkuDQoNCldoYXQgSSB3b3VsZCB1cGRh dGUgaXMgc2ltcGx5IHRoYXQgc2VydmVyIE1VU1QgZXhwb3NlIG92ZXIgaHR0cCBhbmQgU0hPVUxE IG92ZXIgSFRUUFMgc28gdGhhdCBldmVyeSBjYXNlIHdvcmtzIHdpdGggdGhlIGFib3ZlIHNjZW5h cmlvLCBmdXJ0aGVyIGNsYXJpZnlpbmcgKGFzIHNoYXJlZCB3aXRoIG5pY2spIHRoYXQgc2VydmVy cyBNVVNUIE5PVCBpbmNsdWRlICdzZWN1cmUnICpocmVmKiAodGhlIG9uZXMgd2hvc2Ugc2NoZW1l IGlzIGVuZGluZyB3aXRoIGFuIOKAmHPigJkpIHdoZW4gYW5zd2VyaW5nIG92ZXIgcGxhaW4gaHR0 cCBBTkQgY2xpZW50cyBNVVNUIGlnbm9yZSB0aG9zZSBocmVmcyBzaG91bGQgdGhleSBiZSBhbnl3 YXkgaW5jbHVkZWQgaW4gdGhlIGpyZCByZXRyaWV2ZWQgb3ZlciBodHRwIChhcyBhbiBhdHRhY2sp Lg0KQXMgcGF1bCBwb2ludGVkIG91dCB0aGUgb25seSBsaW1pdGF0aW9uIGlzIGlmIG15IGF2YXRh ciBpcyBvbmx5IGV4cG9zZWQgb3ZlciBhbiBodHRwcyBlbmRwb2ludCBidXQgbm90IG15IHdmIGVu ZHBvaW50IGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIHJlYWwgaXNzdWXigKYNCg0Kd2Fs dGVyDQoNCkRhOiB3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndlYmZpbmdlci1i b3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkgQnJhZCBGaXR6cGF0cmljaw0KSW52aWF0bzog dmVuZXJkw6wgMTQgZGljZW1icmUgMjAxMiA1LjQxDQpBOiBKYW1lcyBNIFNuZWxsDQpDYzogUGF1 bCBFLiBKb25lczsgd2ViZmluZ2VyQGlldGYub3JnDQpPZ2dldHRvOiBSZTogW3dlYmZpbmdlcl0g VGhlIEhUVFAvSFRUUFMgSXNzdWUNCg0KT24gVGh1LCBEZWMgMTMsIDIwMTIgYXQgNzozOCBQTSwg SmFtZXMgTSBTbmVsbCA8amFzbmVsbEBnbWFpbC5jb208bWFpbHRvOmphc25lbGxAZ21haWwuY29t Pj4gd3JvdGU6DQoNCkZhaWx1cmUgb2YgYSByZXF1ZXN0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxl LiBJZiB0aGUgY2xpZW50IG5lZWRzIGEgc2VjdXJlZCBjb25uZWN0aW9uIGFuZCB0aGUgc2VydmVy IHNpbXBseSBkb2VzIG5vdCBwcm92aWRlIGZvciBpdCwgdGhlIGNsaWVudCBzaW1wbHkgd29uJ3Qg dXNlIHRoYXQgc2VydmVyLiBTaW1wbGUgYXMgdGhhdC4NCkkgZG9uJ3Qgd2FudCB1c2VycyBvciBj bGllbnRzIHRvIG5lZWQgdG8gb3B0LWluIHRvIHNlY3VyaXR5Lg0KDQpRdWVzdG8gbWVzc2FnZ2lv IGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw M0BUSS5EaXNjbGFpbWVyXVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEg bWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA887DGRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglw YW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDIuMGNtIDIuMGNtIDIuMGNtO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24x O30NCiAvKiBMaXN0IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAx NjgwNjY1MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTE2MTU4ODg4NiAtNDkzOTUyMjM0IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5 IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtc3RhcnQtYXQ6MzAwMDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+DQo8 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5XZeKAmXJlIHRh bGtpbmcgYWJvdXQgY2xpZW50cyBidXQgbm90IGFwcGxpY2F0aW9ucy4gSWYgY2xpZW50cyBhcmUg dGhlIGltcGxlbWVudGF0aW9uIHN0YWNrcyBvZiB0aGUgc3BlYywgdGhlbiB0aGV5IHNob3VsZCBn aXZlIHRoZSB3aG9sZSBmbGV4aWJpbGl0eQ0KIG9mIGl0LiBJdCBpcyB1cCB0byB0aGUgYXBwIChy ZXByZXNlbnRpbmcgdGhlIHNwZWNpZmljIHVzZS1jYXNlKSB0byBkZWNpZGUgd2hldGhlciBpdCBu ZWVkcyBzZWN1cml0eSBvciBub3QsIGFuZCB3aGV0aGVyIGZhbGxiYWNrIG1heSBiZSBhY2NlcHRh YmxlIG9yIG5vdC4gSWYgaHR0cHMtdG8taHR0cCBmYWxsYmFjayBpcyBwZXJmb3JtZWQgYXQgYXBw bGljYXRpb24gbGV2ZWwgYW5kIG5vdCBhdXRvbWF0aWNhbGx5IGJ5IHRoZSBjbGllbnQgdGhlbg0K IHdlIG1heSBhbGwgY29udmVyZ2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+TGV0IG1lIGdpdmUgYW4gZXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VXNlIGNhc2UgdHlwZSAx ICjigJxhdXRvY29uZmlndXJhdGlvbi9sb2dpbuKAnSk6IE15IHdlYnNpdGUgaXMgcHJvdmlkaW5n IHJlZ2lzdHJhdGlvbiB0aHJvdWdoIG9wZW5pZGNvbm5lY3Qgd2hlcmUgdGhlIHVzZXIgY2FuIGlu cHV0IGhpcw0KIGlkZW50aXR5LiBTaW5jZSB0aGlzIGlzIHdoYXQgSSBjYW4gY2FsbCBhdXRvY29u ZmlndXJhdGlvbiB1c2UgY2FzZSAoaW4gdGhhdCBzZW5zZSBzaW1pbGFyIHRvIGRpc2NvdmVyaW5n IG15IG9hdXRoKiBlbmRwb2ludHMpIHRoZSBhcHAgKG15IHdlYnNpdGUpIDEpIG5lZWRzIHNlY3Vy aXR5IGFuZCAyKSBrbm93cyBwcmV0dHkgbXVjaCB0aGUgbGluayByZWxzIGl04oCZcyBpbnRlcmVz dGVkIGluLiBpdCB0aGVuIGlzc3VlcyB0aGUgd2YgcmVxdWVzdCBvdmVyDQogaHR0cHMgb25seSAo b3B0aW9uYWxseSBhZGRpbmcgdGhlIGV4cGxpY2l0IGxpc3Qgb2YgbGlua3MpLiBJZiB0aGF0IHJl cXVlc3QgZmFpbHMgYmVjYXVzZSB0aGUgaWRwIGlzIG5vdCBydW5uaW5nIG92ZXIgaHR0cHMsIHRo ZW4gbXkgd2Vic2l0ZSAobm9yIHRoZSB1bmRlcmx5aW5nIHdmIGNsaWVudCkgZG9lcyBub3QgZmFs bGJhY2sgb3ZlciBodHRwIGFuZCB0ZWxscyB0aGUgdXNlciB0aGF0IGhlIGNhbm5vdCB1c2UgdGhh dCBpZGVudGl0eS4gU2ltaWxhcmx5DQogaWYgSSB3YW50IHRvIGF1dG9jb25maWd1cmUgbXkgZmF2 b3JpdGUgYXBwIGJhc2VkIG9uIG15IGlkZW50aXR5IGFuZCBkaXNjb3ZlciBhIGJ1bmNoIG9mIGVu ZHBvaW50cyBteSBjbGllbnQgc2hvdWxkIG5vdCBmYWxsYmFjayB0byBodHRwLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Vc2UgY2FzZSB0eXBlIDIgKOKAnHB1YmxpYyBpbmZvIGRpc2NvdmVyeeKAnSk6IE15IGZhdm9y aXRlIGVtYWlsIGFwcCBoYXMgYSBwbHVnaW4gdGhhdCByZXNvbHZlcyBlbWFpbCBhZGRyZXNzZXMg dG8gc2hvdyB0aGUgdXNlcuKAmXMgYXZhdGFyLg0KIEZvciBlYWNoIGVtYWlsIGFkZHJlc3MgaXQg aXNzdWVzIGEgd2YgcmVxdWVzdCBhbmQgY2FuIGRlY2lkZSB3aGV0aGVyIHRvIHRyeSBodHRwcyBm aXJzdCBvciBkaXJlY3RseSBodHRwLiBTdXBwb3NlIGl0ICo8Yj5hc2tzIHRoZSBjbGllbnQgdG8g dHJ5IGh0dHBzIGZpcnN0IChtYXkgYmUgdGhlIGRlZmF1bHQpPC9iPiouIElmIHRoZSBjbGllbnQg ZmFpbHMgZm9yIHRoZSBzYW1lIHJlYXNvbiwgdGhlbiAqPGI+dGhlIGFwcDwvYj4qIGNhbiBkZWNp ZGUNCiB0byB0cnkgYWdhaW4gb3ZlciBwbGFpbiBodHRwIGFuZCBkZWNpZGUgd2hhdCB0byBkbyB3 aXRoIHRoZSBwcm92aWRlZCBpbmZvcm1hdGlvbiAoZWcgYWNjZXB0IGl0IGFzIGF2YXRhciBtYXkg YmUgY29uc2lkZXJlZCBsZXNzIHNlbnNpdGl2ZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj5JZiB3ZSBtb3ZlIHRoZSBzZWN1cml0eSBjb25jZXJuIGF0IGFwcCBsZXZl bCB0aGVuIHdlIG5lZWQgYSBtZWNoYW5pc20gdG8gdGVsbCBzbywgd2hpY2ggaXMgaW5kZXBlbmRl bnQgZnJvbSB0aGUgc3BlY2lmaWMgY29kZWJhc2UgYW5kL29yIGFwaQ0KIHNpZ25hdHVyZS4gT25l IHBvc3NpYmlsaXR5IGNvdWxkIGJlIGluIHRoZSByZXNvdXJjZSBVUkkgaXRzZWxmIHRoYXQgd2Ug YXJlIHF1ZXJ5aW5nLiBXZSBhbHJlYWR5IHNhaWQgdGhhdCBhbnkgdHlwZSBvZiB1cmkgaXMgc3Vw cG9ydGVkIHdpdGggYSBzcGVjaWZpYyBtZW50aW9uIG9mIGFjY3Q6LiBXaGF0IGFib3V0IGludHJv ZHVjaW5nIGFjY3RzOiBmb3IgdGhpcyBwdXJwb3NlPyBTaXBzOiwgd3NzOiwgaHR0cHM6IGFyZSBh bGwgZXhhbXBsZXMgb2YNCiB1cmlzIHRoYXQgZXhwbGljaXRseSBjYWxsIGZvciB0bHMuIEluIHRo YXQgY2FzZSBpZiB0aGUgYXBwIHJlcXVlc3RzIHdmLmRpc2NvdmVyKOKAnGFjY3RzOnVzZXJAZXhh bXBsZS5jb23igJ0pIHRoZSBjbGllbnQgd291bGQga25vdyB0aGF0IGl0IGhhcyB0byBydW4gb3Zl ciBodHRwcy4gQW5kIGl0IHdvcmtzIGZvciBodHRwczogVVJJcyBhcyB3ZWxsIGFuZCBvdGhlcnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5XaXRoIHRoaXMgYXJ0aWZh Y3Qgd2UgY2FuIGdldCByaWQgb2YgdGhlIGZhbGxiYWNrIHByb2JsZW0gb24gdGhlIGNsaWVudCBz aWRlIGFuZCBzdGF5IHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpbiBzYXlpbmcgdGhhdCBpdCBtdXN0 IG5vdCB0cnkgaW4NCiBwYXJhbGxlbCBvciBpbiBzZXF1ZW5jZSAobWVhbnQgYXMg4oCcYXV0b21h dGljYWxseeKAnSkuIEJ1dCBpdCBtYXkgYmUgcmVxdWVzdGVkIHRvIGRvIHNvIGJ5IHRoZSBhcHAg aWYgYWZ0ZXIgYSBmYWlsdXJlIG92ZXIgaHR0cHMgKGVnIGZvciB1c2UgY2FzZSB0eXBlIDIpIHRo ZSBhcHAgZGVjaWRlcyB0byBnbyBvdmVyIHBsYWluIGh0dHAgKHVzaW5nIGFjY3Q6IFVSSSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5XaGF0IEkgd291bGQgdXBkYXRl IGlzIHNpbXBseSB0aGF0IHNlcnZlciBNVVNUIGV4cG9zZSBvdmVyIGh0dHAgYW5kIFNIT1VMRCBv dmVyIEhUVFBTIHNvIHRoYXQgZXZlcnkgY2FzZSB3b3JrcyB3aXRoIHRoZSBhYm92ZSBzY2VuYXJp bywgZnVydGhlcg0KIGNsYXJpZnlpbmcgKGFzIHNoYXJlZCB3aXRoIG5pY2spIHRoYXQgc2VydmVy cyBNVVNUIE5PVCBpbmNsdWRlICdzZWN1cmUnICpocmVmKiAodGhlIG9uZXMgd2hvc2Ugc2NoZW1l IGlzIGVuZGluZyB3aXRoIGFuIOKAmHPigJkpIHdoZW4gYW5zd2VyaW5nIG92ZXIgcGxhaW4gaHR0 cCBBTkQgY2xpZW50cyBNVVNUIGlnbm9yZSB0aG9zZSBocmVmcyBzaG91bGQgdGhleSBiZSBhbnl3 YXkgaW5jbHVkZWQgaW4gdGhlIGpyZCByZXRyaWV2ZWQgb3ZlciBodHRwIChhcw0KIGFuIGF0dGFj aykuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5BcyBwYXVs IHBvaW50ZWQgb3V0IHRoZSBvbmx5IGxpbWl0YXRpb24gaXMgaWYgbXkgYXZhdGFyIGlzIG9ubHkg ZXhwb3NlZCBvdmVyIGFuIGh0dHBzIGVuZHBvaW50IGJ1dCBub3QgbXkgd2YgZW5kcG9pbnQgYnV0 IEkgZG9u4oCZdCB0aGluayB0aGlzDQogaXMgYSByZWFsIGlzc3Vl4oCmPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj53YWx0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJVCIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHdlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2Vi ZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QZXIgY29udG8gZGkgPC9iPkJyYWQgRml0enBh dHJpY2s8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gdmVuZXJkw6wgMTQgZGljZW1icmUgMjAxMiA1LjQx PGJyPg0KPGI+QTo8L2I+IEphbWVzIE0gU25lbGw8YnI+DQo8Yj5DYzo8L2I+IFBhdWwgRS4gSm9u ZXM7IHdlYmZpbmdlckBpZXRmLm9yZzxicj4NCjxiPk9nZ2V0dG86PC9iPiBSZTogW3dlYmZpbmdl cl0gVGhlIEhUVFAvSFRUUFMgSXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gVGh1LCBE ZWMgMTMsIDIwMTIgYXQgNzozOCBQTSwgSmFtZXMgTSBTbmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv Omphc25lbGxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFzbmVsbEBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDsNCm1hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RmFpbHVyZSBvZiBhIHJlcXVlc3QgaXMgcGVy ZmVjdGx5IGFjY2VwdGFibGUuIElmIHRoZSBjbGllbnQgbmVlZHMgYSBzZWN1cmVkIGNvbm5lY3Rp b24gYW5kIHRoZSBzZXJ2ZXIgc2ltcGx5IGRvZXMgbm90IHByb3ZpZGUgZm9yIGl0LCB0aGUgY2xp ZW50IHNpbXBseSB3b24ndCB1c2UgdGhhdCBzZXJ2ZXIuIFNpbXBsZSBhcyB0aGF0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbid0IHdhbnQgdXNlcnMgb3IgY2xpZW50 cyB0byBuZWVkIHRvIG9wdC1pbiB0byBzZWN1cml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnNwYW4uR3Jh bUUge21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0tPg0KPC9zdHlsZT4N Cjx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i d2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9udC1zaXplOjEycHg7 IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KPGRpdiBhbGln bj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxs YSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZp ZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJv cmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNh emlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBH cmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5v cm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBlLW1haWwgYW5kIGFu eSBhdHRhY2htZW50czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6DQogIDcuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6VmVy ZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xhc3M9IkdyYW1FIj5p czwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOg0KICA3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVO LUdCIj5jb25maWRlbnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5 aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXINCiBieSByZXR1 cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+PGltZyBzcmM9ImNp ZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVyIiBhbHQ9InJp c3BldHRhIGwnYW1iaWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+UmlzcGV0dGEgbCdhbWJp ZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bh bj48L2I+DQo8cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA887DGRFMBX704BA02_-- --_725d34b1-9ee3-49eb-86cb-d4dcf668e8df_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_725d34b1-9ee3-49eb-86cb-d4dcf668e8df_-- From romeda@gmail.com Fri Dec 14 03:01:30 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1F821F874D for ; Fri, 14 Dec 2012 03:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9wvwG9LZpTY for ; Fri, 14 Dec 2012 03:01:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC1AA21F8741 for ; Fri, 14 Dec 2012 03:01:29 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2134492pbc.31 for ; Fri, 14 Dec 2012 03:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=+XkVhl/auyV/x31Bg072aNMyKkb/KcLp/dUbfEhTt1c=; b=r6CPNi88ynkh0FhSnX12N5Whsmn1CfQd4FKYAxU2nEA/fy8RvPrkvGmDcEqbhfRnBo Okqp8/fkGFeXw+lJtZuZ1OcluSQ7bFu/r0pZ8S3EpnoYp4xUcwP0Lf3pvp6daGN3fBy5 cxx7In2lCtaoQjDNcI7/3TczJ4yULSYS7+/UstJeu9QYPq1JpGF96Br02KWSj70nWnfh uvz7nP3oMfTokfmbtWlfJ8meUaaEk8qEMbO8leJOK75IFucjQoCkfotXbcK9VOjdZfxn Xi3Zq0byLRqnRwViC6GtCQjXmcvHoPllnnmKsCjdaVW+7rP5BLjEj7N7SlLyT0kRrpjE pH6w== Received: by 10.68.226.71 with SMTP id rq7mr14637020pbc.60.1355482889698; Fri, 14 Dec 2012 03:01:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Fri, 14 Dec 2012 03:01:08 -0800 (PST) From: Blaine Cook Date: Fri, 14 Dec 2012 11:01:08 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff252e623bb8a04d0cdf4af Cc: John Panzer , webfinger@ietf.org, James M Snell , Goix Laurent Walter , Brad Fitzpatrick Subject: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 11:01:31 -0000 --e89a8ff252e623bb8a04d0cdf4af Content-Type: text/plain; charset=UTF-8 So, all this has me thinking. And I'm going to propose something totally against much of what I've been saying. Why not introduce a SECOND scheme, "accts" If you want a secure lookup, your request (from a client-library perspective) will look like: webfinger.lookup('accts://bob@example.com') or just webfinger.lookup('bob@example.com') which will default to "accts", since that's the best-most-secure option. If you want an unsecured lookup, use the "acct" scheme explicitly, so as follows: webfinger.lookup('acct://bob@example.com') For applications where it doesn't matter, and you want to do a lookup and get EITHER the secure or unsecured profile, it's trivial for library authors to provide an explicit flag, like so: webfinger.lookup('bob@example.com', { allow_fallback: true }) OR it's easy enough for developers to do the lookup explicitly, like so: webfinger.lookup('accts://bob@example.com', function (err, result) { if (result) { // do something with the secure result callback(err, result) } else { // c'mon, I just need a link to their public phonecam shots profile webfinger.lookup('acct://bob@example.com', callback) } } Does this make sense? I think it errs on the side of the HTTPS-only crowd, which I sympathise with even if I can't lend 100% support to. It also errs on the side of client simplicity, and mirrors HTTP behaviours (but defaults to secure instead of insecure, as with HTTP). Thoughts? Happy to try to write up some copy if this works for people. b. --e89a8ff252e623bb8a04d0cdf4af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, all this has me thinking. And I'm going to propose something totall= y against much of what I've been saying.

Why not int= roduce a SECOND scheme, "accts"

If you w= ant a secure lookup, your request (from a client-library perspective) will = look like:

webfinger.lookup('accts://bob@example.com')

or just
<= div>webfinger.lookup('bob@example.co= m')

which will default to "accts", since that'= ;s the best-most-secure option.

If you want an uns= ecured lookup, use the "acct" scheme explicitly, so as follows:

webfinger.lookup('acct://bob@example.com')

For application= s where it doesn't matter, and you want to do a lookup and get EITHER t= he secure or unsecured profile, it's trivial for library authors to pro= vide an explicit flag, like so:

webfinger.lookup('bob@example.com', { allow_fallback: true })

<= div>OR it's easy enough for developers to do the lookup explicitly, lik= e so:

webfinger.lookup('accts://bob@example.com', function (err, result) {
=C2= =A0 if (result) {
=C2=A0 =C2=A0 // do something with the secure r= esult
=C2=A0 =C2=A0 callback(err, result)
=C2=A0 } else {
=C2= =A0 =C2=A0 // c'mon, I just need a link to their public phonecam shots = profile
=C2=A0 =C2=A0 webfinger.lookup('acct://bob@example.com', callback)
=C2=A0 }
}

Does this make sense? I = think it errs on the side of the HTTPS-only crowd, which I sympathise with = even if I can't lend 100% support to. It also errs on the side of clien= t simplicity, and mirrors HTTP behaviours (but defaults to secure instead o= f insecure, as with HTTP).

Thoughts? Happy to try to write up some copy if this wo= rks for people.

b.
--e89a8ff252e623bb8a04d0cdf4af-- From mmn@hethane.se Fri Dec 14 03:07:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A7621F8767 for ; Fri, 14 Dec 2012 03:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_EQ_SE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoVSMWsXfzl5 for ; Fri, 14 Dec 2012 03:07:38 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7A75021F875B for ; Fri, 14 Dec 2012 03:07:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Dec 2012 12:07:33 +0100 From: Mikael Nordfeldth To: In-Reply-To: <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> Message-ID: <710078c85ac94e0ea42e3b116428998e@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 11:07:39 -0000 PLEASE remember that mandating HTTPS implies that EVERY single Wordpress (or other mass-hosted FOSS) blog out there will REQUIRE https for it to serve webfinger data. What a marvellous thing it would be if every Wordpress installation in the world could overnight get Webfinger support. Just like that! A software update and suddenly there are TENS OF MILLIONS of Webfinger implementations! A blog like your average Wordpress won't have any real authenticity in itself. Anyone can open up a blog with any pseudonym and publish data pretending to be someone. But their METADATA is still usable for OTHER bloggers/etc! Also, the blog's webfinger could link to the same pseudonym's social web accounts and such. (where in the end a human is more likely to use the data and verify it than any automated mechanism) And there's no reason for HTTPS-only clients to connect at all to a non-HTTPS resource. So they won't be buggered by all these critters with blogs! But this vast implementation outside of corporate use will only be reality if we allow Webfinger use for your average blogger-type-of-user. ...and some more elaboration for the ones who have time to read it all: 14.12.2012 04:36 skrev Paul E. Jones: > I that text still seemed to be controversial, since it would mean > there is a possibility that clients requiring secure connections > would > fail when a domain did not implement WF on HTTPS. Yes, just as my web browser "fails" when I try to access futurelotteryticketnumbers.com to retrieve authentic lottery ticket numbers that will give me millions of dollars. If HTTPS doesn't exist, and you require it, you can't connect to it. Tough luck, not every domain in the world will implement Webfinger anyway. If your client requires HTTPS due to the contents of the request/reply, and HTTPS isn't available, then it will fail. No surprise. The amount of "failures" in this sense will be _much_ larger if verified-https-only is mandated. For no apparent reason, as there is no guarantee the actual DATA over HTTPS is true anyway. There are tons of cases where you just want data - any data - which can later be verified by a third party. Example of non-trustworthy data (out of band for HTTPS certificate verification): * I can do a rel-me with mailto:obama@whitehouse.gov * This can only be falsified by a human unless we're increasing the complexity of data verification, second-server lookups and requiring Webfinger use on every domain out there) -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From laurentwalter.goix@telecomitalia.it Fri Dec 14 04:25:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5081521F85C6 for ; Fri, 14 Dec 2012 04:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulqx7I4BGor6 for ; Fri, 14 Dec 2012 04:25:26 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id B096821F85A7 for ; Fri, 14 Dec 2012 04:25:25 -0800 (PST) Content-Type: multipart/mixed; boundary="_a641b653-58ec-49cd-92ca-99d798b35617_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 14 Dec 2012 13:25:21 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 14 Dec 2012 13:25:21 +0100 From: Goix Laurent Walter To: Blaine Cook , "webfinger@googlegroups.com" Date: Fri, 14 Dec 2012 13:25:19 +0100 Thread-Topic: A third (or is it twelfth?) way [was: secure links with https rels] Thread-Index: Ac3Z6mKo1ynXfy5zT1y5X/YJm3RoXQAC5IOQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: John Panzer , "webfinger@ietf.org" , James M Snell , Brad Fitzpatrick Subject: [webfinger] R: A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:25:27 -0000 --_a641b653-58ec-49cd-92ca-99d798b35617_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89F8GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89F8GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuIFRoYXTigJlzIGZ1bGx5IGluIGxpbmUgd2l0aCBteSBwcm9wb3NhbCBvZiBzb21lIGhvdXJz IGFnbywgdGhhdCBJIHJlYWxpemVkIHdhcyBub3Qgc2VudCBvdmVyIHdlYmZpbmdlciBnb29nbGUg Z3JvdXAgKHJlLXNlbmRpbmcgc2VwYXJhdGVseSkNCg0KRGE6IEJsYWluZSBDb29rIFttYWlsdG86 cm9tZWRhQGdtYWlsLmNvbV0NCkludmlhdG86IHZlbmVyZMOsIDE0IGRpY2VtYnJlIDIwMTIgMTIu MDENCkE6IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tDQpDYzogSm9obiBQYW56ZXI7IHdlYmZp bmdlckBpZXRmLm9yZzsgSmFtZXMgTSBTbmVsbDsgR29peCBMYXVyZW50IFdhbHRlcjsgQnJhZCBG aXR6cGF0cmljaw0KT2dnZXR0bzogQSB0aGlyZCAob3IgaXMgaXQgdHdlbGZ0aD8pIHdheSBbd2Fz OiBzZWN1cmUgbGlua3Mgd2l0aCBodHRwcyByZWxzXQ0KDQpTbywgYWxsIHRoaXMgaGFzIG1lIHRo aW5raW5nLiBBbmQgSSdtIGdvaW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIHRvdGFsbHkgYWdhaW5z dCBtdWNoIG9mIHdoYXQgSSd2ZSBiZWVuIHNheWluZy4NCg0KV2h5IG5vdCBpbnRyb2R1Y2UgYSBT RUNPTkQgc2NoZW1lLCAiYWNjdHMiDQoNCklmIHlvdSB3YW50IGEgc2VjdXJlIGxvb2t1cCwgeW91 ciByZXF1ZXN0IChmcm9tIGEgY2xpZW50LWxpYnJhcnkgcGVyc3BlY3RpdmUpIHdpbGwgbG9vayBs aWtlOg0KDQp3ZWJmaW5nZXIubG9va3VwKCdhY2N0czovL2JvYkBleGFtcGxlLmNvbTxtYWlsdG86 Ym9iQGV4YW1wbGUuY29tPicpDQoNCm9yIGp1c3QNCndlYmZpbmdlci5sb29rdXAoJ2JvYkBleGFt cGxlLmNvbTxtYWlsdG86Ym9iQGV4YW1wbGUuY29tPicpDQoNCndoaWNoIHdpbGwgZGVmYXVsdCB0 byAiYWNjdHMiLCBzaW5jZSB0aGF0J3MgdGhlIGJlc3QtbW9zdC1zZWN1cmUgb3B0aW9uLg0KDQpJ ZiB5b3Ugd2FudCBhbiB1bnNlY3VyZWQgbG9va3VwLCB1c2UgdGhlICJhY2N0IiBzY2hlbWUgZXhw bGljaXRseSwgc28gYXMgZm9sbG93czoNCg0Kd2ViZmluZ2VyLmxvb2t1cCgnYWNjdDovL2JvYkBl eGFtcGxlLmNvbTxtYWlsdG86Ym9iQGV4YW1wbGUuY29tPicpDQoNCkZvciBhcHBsaWNhdGlvbnMg d2hlcmUgaXQgZG9lc24ndCBtYXR0ZXIsIGFuZCB5b3Ugd2FudCB0byBkbyBhIGxvb2t1cCBhbmQg Z2V0IEVJVEhFUiB0aGUgc2VjdXJlIG9yIHVuc2VjdXJlZCBwcm9maWxlLCBpdCdzIHRyaXZpYWwg Zm9yIGxpYnJhcnkgYXV0aG9ycyB0byBwcm92aWRlIGFuIGV4cGxpY2l0IGZsYWcsIGxpa2Ugc286 DQoNCndlYmZpbmdlci5sb29rdXAoJ2JvYkBleGFtcGxlLmNvbTxtYWlsdG86Ym9iQGV4YW1wbGUu Y29tPicsIHsgYWxsb3dfZmFsbGJhY2s6IHRydWUgfSkNCg0KT1IgaXQncyBlYXN5IGVub3VnaCBm b3IgZGV2ZWxvcGVycyB0byBkbyB0aGUgbG9va3VwIGV4cGxpY2l0bHksIGxpa2Ugc286DQoNCndl YmZpbmdlci5sb29rdXAoJ2FjY3RzOi8vYm9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBs ZS5jb20+JywgZnVuY3Rpb24gKGVyciwgcmVzdWx0KSB7DQogIGlmIChyZXN1bHQpIHsNCiAgICAv LyBkbyBzb21ldGhpbmcgd2l0aCB0aGUgc2VjdXJlIHJlc3VsdA0KICAgIGNhbGxiYWNrKGVyciwg cmVzdWx0KQ0KICB9IGVsc2Ugew0KICAgIC8vIGMnbW9uLCBJIGp1c3QgbmVlZCBhIGxpbmsgdG8g dGhlaXIgcHVibGljIHBob25lY2FtIHNob3RzIHByb2ZpbGUNCiAgICB3ZWJmaW5nZXIubG9va3Vw KCdhY2N0Oi8vYm9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5jb20+JywgY2FsbGJh Y2spDQogIH0NCn0NCg0KRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IEkgdGhpbmsgaXQgZXJycyBvbiB0 aGUgc2lkZSBvZiB0aGUgSFRUUFMtb25seSBjcm93ZCwgd2hpY2ggSSBzeW1wYXRoaXNlIHdpdGgg ZXZlbiBpZiBJIGNhbid0IGxlbmQgMTAwJSBzdXBwb3J0IHRvLiBJdCBhbHNvIGVycnMgb24gdGhl IHNpZGUgb2YgY2xpZW50IHNpbXBsaWNpdHksIGFuZCBtaXJyb3JzIEhUVFAgYmVoYXZpb3VycyAo YnV0IGRlZmF1bHRzIHRvIHNlY3VyZSBpbnN0ZWFkIG9mIGluc2VjdXJlLCBhcyB3aXRoIEhUVFAp Lg0KDQpUaG91Z2h0cz8gSGFwcHkgdG8gdHJ5IHRvIHdyaXRlIHVwIHNvbWUgY29weSBpZiB0aGlz IHdvcmtzIGZvciBwZW9wbGUuDQoNCmIuDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVn YXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRl LiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRl IGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVu dGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVy IGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29t dW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlv bmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRl bnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcg b3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkg YXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5r cy4NCg0KW2NpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFpbWVy XVJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg bmVjZXNzYXJpby4NCg0K --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89F8GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2Ut MToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDIuMGNtIDIuMGNtIDIuMGNtO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNl Y3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+JiM0MzsxLiBUaGF04oCZcyBmdWxseSBpbiBsaW5lIHdpdGggbXkgcHJvcG9zYWwgb2Yg c29tZSBob3VycyBhZ28sIHRoYXQgSSByZWFsaXplZCB3YXMgbm90IHNlbnQgb3ZlciB3ZWJmaW5n ZXIgZ29vZ2xlIGdyb3VwIChyZS1zZW5kaW5nIHNlcGFyYXRlbHkpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i SVQiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRhOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iSVQi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCbGFpbmUgQ29vayBbbWFpbHRvOnJvbWVkYUBnbWFp bC5jb21dDQo8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gdmVuZXJkw6wgMTQgZGljZW1icmUgMjAxMiAx Mi4wMTxicj4NCjxiPkE6PC9iPiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTxicj4NCjxiPkNj OjwvYj4gSm9obiBQYW56ZXI7IHdlYmZpbmdlckBpZXRmLm9yZzsgSmFtZXMgTSBTbmVsbDsgR29p eCBMYXVyZW50IFdhbHRlcjsgQnJhZCBGaXR6cGF0cmljazxicj4NCjxiPk9nZ2V0dG86PC9iPiBB IHRoaXJkIChvciBpcyBpdCB0d2VsZnRoPykgd2F5IFt3YXM6IHNlY3VyZSBsaW5rcyB3aXRoIGh0 dHBzIHJlbHNdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U28sIGFsbCB0aGlzIGhhcyBtZSB0aGlua2luZy4gQW5kIEknbSBnb2luZyB0byBwcm9wb3NlIHNv bWV0aGluZyB0b3RhbGx5IGFnYWluc3QgbXVjaCBvZiB3aGF0IEkndmUgYmVlbiBzYXlpbmcuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgbm90IGludHJv ZHVjZSBhIFNFQ09ORCBzY2hlbWUsICZxdW90O2FjY3RzJnF1b3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IGEgc2VjdXJl IGxvb2t1cCwgeW91ciByZXF1ZXN0IChmcm9tIGEgY2xpZW50LWxpYnJhcnkgcGVyc3BlY3RpdmUp IHdpbGwgbG9vayBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj53ZWJmaW5nZXIubG9va3VwKCdhY2N0czovLzxhIGhyZWY9Im1haWx0bzpi b2JAZXhhbXBsZS5jb20iPmJvYkBleGFtcGxlLmNvbTwvYT4nKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vciBqdXN0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZWJmaW5nZXIubG9va3VwKCc8 YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIj5ib2JAZXhhbXBsZS5jb208L2E+Jyk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2gg d2lsbCBkZWZhdWx0IHRvICZxdW90O2FjY3RzJnF1b3Q7LCBzaW5jZSB0aGF0J3MgdGhlIGJlc3Qt bW9zdC1zZWN1cmUgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugd2FudCBhbiB1bnNlY3VyZWQgbG9va3VwLCB1c2UgdGhl ICZxdW90O2FjY3QmcXVvdDsgc2NoZW1lIGV4cGxpY2l0bHksIHNvIGFzIGZvbGxvd3M6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlYmZpbmdl ci5sb29rdXAoJ2FjY3Q6Ly88YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIj5ib2JAZXhh bXBsZS5jb208L2E+Jyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIGFwcGxpY2F0aW9ucyB3aGVyZSBpdCBkb2Vzbid0IG1hdHRlciwgYW5k IHlvdSB3YW50IHRvIGRvIGEgbG9va3VwIGFuZCBnZXQgRUlUSEVSIHRoZSBzZWN1cmUgb3IgdW5z ZWN1cmVkIHByb2ZpbGUsIGl0J3MgdHJpdmlhbCBmb3IgbGlicmFyeSBhdXRob3JzIHRvIHByb3Zp ZGUgYW4gZXhwbGljaXQgZmxhZywgbGlrZSBzbzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2ViZmluZ2VyLmxvb2t1cCgnPGEgaHJlZj0ibWFp bHRvOmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4YW1wbGUuY29tPC9hPicsIHsgYWxsb3dfZmFsbGJh Y2s6IHRydWUgfSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T1IgaXQncyBlYXN5IGVub3VnaCBmb3IgZGV2ZWxvcGVycyB0byBkbyB0aGUgbG9v a3VwIGV4cGxpY2l0bHksIGxpa2Ugc286PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlYmZpbmdlci5sb29rdXAoJ2FjY3RzOi8vPGEgaHJlZj0i bWFpbHRvOmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4YW1wbGUuY29tPC9hPicsIGZ1bmN0aW9uIChl cnIsIHJlc3VsdCkgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IGlmIChyZXN1bHQpIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgLy8gZG8gc29tZXRoaW5nIHdp dGggdGhlIHNlY3VyZSByZXN1bHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgY2FsbGJhY2soZXJyLCByZXN1bHQpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgfSBl bHNlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgLy8gYydtb24sIEkganVzdCBuZWVkIGEgbGluayB0byB0aGVpciBwdWJs aWMgcGhvbmVjYW0gc2hvdHMgcHJvZmlsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB3ZWJmaW5nZXIubG9va3VwKCdhY2N0 Oi8vPGEgaHJlZj0ibWFpbHRvOmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4YW1wbGUuY29tPC9hPics IGNhbGxiYWNrKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IEkgdGhpbmsgaXQgZXJycyBvbiB0aGUgc2lk ZSBvZiB0aGUgSFRUUFMtb25seSBjcm93ZCwgd2hpY2ggSSBzeW1wYXRoaXNlIHdpdGggZXZlbiBp ZiBJIGNhbid0IGxlbmQgMTAwJSBzdXBwb3J0IHRvLiBJdCBhbHNvIGVycnMgb24gdGhlIHNpZGUg b2YgY2xpZW50IHNpbXBsaWNpdHksIGFuZCBtaXJyb3JzIEhUVFAgYmVoYXZpb3VycyAoYnV0IGRl ZmF1bHRzIHRvIHNlY3VyZQ0KIGluc3RlYWQgb2YgaW5zZWN1cmUsIGFzIHdpdGggSFRUUCkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3Vn aHRzPyBIYXBweSB0byB0cnkgdG8gd3JpdGUgdXAgc29tZSBjb3B5IGlmIHRoaXMgd29ya3MgZm9y IHBlb3BsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Yi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzdHlsZSB0 eXBlPSJ0ZXh0L2NzcyI+DQo8IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCglt c28tZ3JhbS1lOnllczt9DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4 OyI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTog VmVyZGFuYSwgQXJpYWw7IGZvbnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBq dXN0aWZ5IiB3aWR0aD0iMzk1Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8g bWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVu dGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFz aQ0KIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5m b3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmlj ZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVn YXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJv dnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rp dj4NCjxwIGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tR0IiPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxp PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1m b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t R0IiPiZuYnNwOzxzcGFuIGNsYXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48 aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1p bHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48 L2k+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8 L3NwYW4+PC9zcGFuPjwvcD4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZv bnQtZmFtaWx5OlZlcmRhbmEiPjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDNAVEkuRGlzY2xhaW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0i MjYiIGhlaWdodD0iNDAiPlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEg bWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89F8GRFMBX704BA02_-- --_a641b653-58ec-49cd-92ca-99d798b35617_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_a641b653-58ec-49cd-92ca-99d798b35617_-- From laurentwalter.goix@telecomitalia.it Fri Dec 14 04:26:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A0121F8818 for ; Fri, 14 Dec 2012 04:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62eptrJYNu+0 for ; Fri, 14 Dec 2012 04:26:16 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 731C321F85F7 for ; Fri, 14 Dec 2012 04:26:15 -0800 (PST) Content-Type: multipart/mixed; boundary="_bc725f8e-1976-49f4-bb39-9548efc83ccd_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 14 Dec 2012 13:26:14 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 14 Dec 2012 13:26:14 +0100 From: Goix Laurent Walter To: Brad Fitzpatrick , James M Snell Date: Fri, 14 Dec 2012 13:26:12 +0100 Thread-Topic: [webfinger] The HTTP/HTTPS Issue Thread-Index: Ac3ZtS/hR6kAqihfT+m0MRYxj52/YgAJo8GAAAaaQ8A= Message-ID: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: [webfinger] R: The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:26:17 -0000 --_bc725f8e-1976-49f4-bb39-9548efc83ccd_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89FAGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89FAGRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KFJlIHNlbmRpbmcgaW5jbHVkaW5nIHRoZSBnb29nbGUgZ3JvdXApDQoNCkRhOiBHb2l4IExhdXJl bnQgV2FsdGVyDQpJbnZpYXRvOiB2ZW5lcmTDrCAxNCBkaWNlbWJyZSAyMDEyIDEwLjQzDQpBOiAn QnJhZCBGaXR6cGF0cmljayc7IEphbWVzIE0gU25lbGwNCkNjOiBQYXVsIEUuIEpvbmVzOyB3ZWJm aW5nZXJAaWV0Zi5vcmcNCk9nZ2V0dG86IFI6IFt3ZWJmaW5nZXJdIFRoZSBIVFRQL0hUVFBTIElz c3VlDQoNCldl4oCZcmUgdGFsa2luZyBhYm91dCBjbGllbnRzIGJ1dCBub3QgYXBwbGljYXRpb25z LiBJZiBjbGllbnRzIGFyZSB0aGUgaW1wbGVtZW50YXRpb24gc3RhY2tzIG9mIHRoZSBzcGVjLCB0 aGVuIHRoZXkgc2hvdWxkIGdpdmUgdGhlIHdob2xlIGZsZXhpYmlsaXR5IG9mIGl0LiBJdCBpcyB1 cCB0byB0aGUgYXBwIChyZXByZXNlbnRpbmcgdGhlIHNwZWNpZmljIHVzZS1jYXNlKSB0byBkZWNp ZGUgd2hldGhlciBpdCBuZWVkcyBzZWN1cml0eSBvciBub3QsIGFuZCB3aGV0aGVyIGZhbGxiYWNr IG1heSBiZSBhY2NlcHRhYmxlIG9yIG5vdC4gSWYgaHR0cHMtdG8taHR0cCBmYWxsYmFjayBpcyBw ZXJmb3JtZWQgYXQgYXBwbGljYXRpb24gbGV2ZWwgYW5kIG5vdCBhdXRvbWF0aWNhbGx5IGJ5IHRo ZSBjbGllbnQgdGhlbiB3ZSBtYXkgYWxsIGNvbnZlcmdlLg0KDQpMZXQgbWUgZ2l2ZSBhbiBleGFt cGxlOg0KDQotICAgICAgICAgIFVzZSBjYXNlIHR5cGUgMSAo4oCcYXV0b2NvbmZpZ3VyYXRpb24v bG9naW7igJ0pOiBNeSB3ZWJzaXRlIGlzIHByb3ZpZGluZyByZWdpc3RyYXRpb24gdGhyb3VnaCBv cGVuaWRjb25uZWN0IHdoZXJlIHRoZSB1c2VyIGNhbiBpbnB1dCBoaXMgaWRlbnRpdHkuIFNpbmNl IHRoaXMgaXMgd2hhdCBJIGNhbiBjYWxsIGF1dG9jb25maWd1cmF0aW9uIHVzZSBjYXNlIChpbiB0 aGF0IHNlbnNlIHNpbWlsYXIgdG8gZGlzY292ZXJpbmcgbXkgb2F1dGgqIGVuZHBvaW50cykgdGhl IGFwcCAobXkgd2Vic2l0ZSkgMSkgbmVlZHMgc2VjdXJpdHkgYW5kIDIpIGtub3dzIHByZXR0eSBt dWNoIHRoZSBsaW5rIHJlbHMgaXTigJlzIGludGVyZXN0ZWQgaW4uIGl0IHRoZW4gaXNzdWVzIHRo ZSB3ZiByZXF1ZXN0IG92ZXIgaHR0cHMgb25seSAob3B0aW9uYWxseSBhZGRpbmcgdGhlIGV4cGxp Y2l0IGxpc3Qgb2YgbGlua3MpLiBJZiB0aGF0IHJlcXVlc3QgZmFpbHMgYmVjYXVzZSB0aGUgaWRw IGlzIG5vdCBydW5uaW5nIG92ZXIgaHR0cHMsIHRoZW4gbXkgd2Vic2l0ZSAobm9yIHRoZSB1bmRl cmx5aW5nIHdmIGNsaWVudCkgZG9lcyBub3QgZmFsbGJhY2sgb3ZlciBodHRwIGFuZCB0ZWxscyB0 aGUgdXNlciB0aGF0IGhlIGNhbm5vdCB1c2UgdGhhdCBpZGVudGl0eS4gU2ltaWxhcmx5IGlmIEkg d2FudCB0byBhdXRvY29uZmlndXJlIG15IGZhdm9yaXRlIGFwcCBiYXNlZCBvbiBteSBpZGVudGl0 eSBhbmQgZGlzY292ZXIgYSBidW5jaCBvZiBlbmRwb2ludHMgbXkgY2xpZW50IHNob3VsZCBub3Qg ZmFsbGJhY2sgdG8gaHR0cC4NCg0KLSAgICAgICAgICBVc2UgY2FzZSB0eXBlIDIgKOKAnHB1Ymxp YyBpbmZvIGRpc2NvdmVyeeKAnSk6IE15IGZhdm9yaXRlIGVtYWlsIGFwcCBoYXMgYSBwbHVnaW4g dGhhdCByZXNvbHZlcyBlbWFpbCBhZGRyZXNzZXMgdG8gc2hvdyB0aGUgdXNlcuKAmXMgYXZhdGFy LiBGb3IgZWFjaCBlbWFpbCBhZGRyZXNzIGl0IGlzc3VlcyBhIHdmIHJlcXVlc3QgYW5kIGNhbiBk ZWNpZGUgd2hldGhlciB0byB0cnkgaHR0cHMgZmlyc3Qgb3IgZGlyZWN0bHkgaHR0cC4gU3VwcG9z ZSBpdCAqYXNrcyB0aGUgY2xpZW50IHRvIHRyeSBodHRwcyBmaXJzdCAobWF5IGJlIHRoZSBkZWZh dWx0KSouIElmIHRoZSBjbGllbnQgZmFpbHMgZm9yIHRoZSBzYW1lIHJlYXNvbiwgdGhlbiAqdGhl IGFwcCogY2FuIGRlY2lkZSB0byB0cnkgYWdhaW4gb3ZlciBwbGFpbiBodHRwIGFuZCBkZWNpZGUg d2hhdCB0byBkbyB3aXRoIHRoZSBwcm92aWRlZCBpbmZvcm1hdGlvbiAoZWcgYWNjZXB0IGl0IGFz IGF2YXRhciBtYXkgYmUgY29uc2lkZXJlZCBsZXNzIHNlbnNpdGl2ZSkuDQoNCklmIHdlIG1vdmUg dGhlIHNlY3VyaXR5IGNvbmNlcm4gYXQgYXBwIGxldmVsIHRoZW4gd2UgbmVlZCBhIG1lY2hhbmlz bSB0byB0ZWxsIHNvLCB3aGljaCBpcyBpbmRlcGVuZGVudCBmcm9tIHRoZSBzcGVjaWZpYyBjb2Rl YmFzZSBhbmQvb3IgYXBpIHNpZ25hdHVyZS4gT25lIHBvc3NpYmlsaXR5IGNvdWxkIGJlIGluIHRo ZSByZXNvdXJjZSBVUkkgaXRzZWxmIHRoYXQgd2UgYXJlIHF1ZXJ5aW5nLiBXZSBhbHJlYWR5IHNh aWQgdGhhdCBhbnkgdHlwZSBvZiB1cmkgaXMgc3VwcG9ydGVkIHdpdGggYSBzcGVjaWZpYyBtZW50 aW9uIG9mIGFjY3Q6LiBXaGF0IGFib3V0IGludHJvZHVjaW5nIGFjY3RzOiBmb3IgdGhpcyBwdXJw b3NlPyBTaXBzOiwgd3NzOiwgaHR0cHM6IGFyZSBhbGwgZXhhbXBsZXMgb2YgdXJpcyB0aGF0IGV4 cGxpY2l0bHkgY2FsbCBmb3IgdGxzLiBJbiB0aGF0IGNhc2UgaWYgdGhlIGFwcCByZXF1ZXN0cyB3 Zi5kaXNjb3ZlcijigJxhY2N0czp1c2VyQGV4YW1wbGUuY29t4oCdKSB0aGUgY2xpZW50IHdvdWxk IGtub3cgdGhhdCBpdCBoYXMgdG8gcnVuIG92ZXIgaHR0cHMuIEFuZCBpdCB3b3JrcyBmb3IgaHR0 cHM6IFVSSXMgYXMgd2VsbCBhbmQgb3RoZXJzLg0KDQpXaXRoIHRoaXMgYXJ0aWZhY3Qgd2UgY2Fu IGdldCByaWQgb2YgdGhlIGZhbGxiYWNrIHByb2JsZW0gb24gdGhlIGNsaWVudCBzaWRlIGFuZCBz dGF5IHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpbiBzYXlpbmcgdGhhdCBpdCBtdXN0IG5vdCB0cnkg aW4gcGFyYWxsZWwgb3IgaW4gc2VxdWVuY2UgKG1lYW50IGFzIOKAnGF1dG9tYXRpY2FsbHnigJ0p LiBCdXQgaXQgbWF5IGJlIHJlcXVlc3RlZCB0byBkbyBzbyBieSB0aGUgYXBwIGlmIGFmdGVyIGEg ZmFpbHVyZSBvdmVyIGh0dHBzIChlZyBmb3IgdXNlIGNhc2UgdHlwZSAyKSB0aGUgYXBwIGRlY2lk ZXMgdG8gZ28gb3ZlciBwbGFpbiBodHRwICh1c2luZyBhY2N0OiBVUkkpLg0KDQpXaGF0IEkgd291 bGQgdXBkYXRlIGlzIHNpbXBseSB0aGF0IHNlcnZlciBNVVNUIGV4cG9zZSBvdmVyIGh0dHAgYW5k IFNIT1VMRCBvdmVyIEhUVFBTIHNvIHRoYXQgZXZlcnkgY2FzZSB3b3JrcyB3aXRoIHRoZSBhYm92 ZSBzY2VuYXJpbywgZnVydGhlciBjbGFyaWZ5aW5nIChhcyBzaGFyZWQgd2l0aCBuaWNrKSB0aGF0 IHNlcnZlcnMgTVVTVCBOT1QgaW5jbHVkZSAnc2VjdXJlJyAqaHJlZiogKHRoZSBvbmVzIHdob3Nl IHNjaGVtZSBpcyBlbmRpbmcgd2l0aCBhbiDigJhz4oCZKSB3aGVuIGFuc3dlcmluZyBvdmVyIHBs YWluIGh0dHAgQU5EIGNsaWVudHMgTVVTVCBpZ25vcmUgdGhvc2UgaHJlZnMgc2hvdWxkIHRoZXkg YmUgYW55d2F5IGluY2x1ZGVkIGluIHRoZSBqcmQgcmV0cmlldmVkIG92ZXIgaHR0cCAoYXMgYW4g YXR0YWNrKS4NCkFzIHBhdWwgcG9pbnRlZCBvdXQgdGhlIG9ubHkgbGltaXRhdGlvbiBpcyBpZiBt eSBhdmF0YXIgaXMgb25seSBleHBvc2VkIG92ZXIgYW4gaHR0cHMgZW5kcG9pbnQgYnV0IG5vdCBt eSB3ZiBlbmRwb2ludCBidXQgSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYSByZWFsIGlzc3Vl4oCm DQoNCndhbHRlcg0KDQpEYTogd2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWJm aW5nZXItYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEJyYWQgRml0enBhdHJpY2sNCklu dmlhdG86IHZlbmVyZMOsIDE0IGRpY2VtYnJlIDIwMTIgNS40MQ0KQTogSmFtZXMgTSBTbmVsbA0K Q2M6IFBhdWwgRS4gSm9uZXM7IHdlYmZpbmdlckBpZXRmLm9yZw0KT2dnZXR0bzogUmU6IFt3ZWJm aW5nZXJdIFRoZSBIVFRQL0hUVFBTIElzc3VlDQoNCk9uIFRodSwgRGVjIDEzLCAyMDEyIGF0IDc6 MzggUE0sIEphbWVzIE0gU25lbGwgPGphc25lbGxAZ21haWwuY29tPG1haWx0bzpqYXNuZWxsQGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpGYWlsdXJlIG9mIGEgcmVxdWVzdCBpcyBwZXJmZWN0bHkgYWNj ZXB0YWJsZS4gSWYgdGhlIGNsaWVudCBuZWVkcyBhIHNlY3VyZWQgY29ubmVjdGlvbiBhbmQgdGhl IHNlcnZlciBzaW1wbHkgZG9lcyBub3QgcHJvdmlkZSBmb3IgaXQsIHRoZSBjbGllbnQgc2ltcGx5 IHdvbid0IHVzZSB0aGF0IHNlcnZlci4gU2ltcGxlIGFzIHRoYXQuDQpJIGRvbid0IHdhbnQgdXNl cnMgb3IgY2xpZW50cyB0byBuZWVkIHRvIG9wdC1pbiB0byBzZWN1cml0eS4NCg0KUXVlc3RvIG1l c3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRl IGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kg YWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1h emlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0 byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkg ZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVk ZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRp b24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jp c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBi eSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDNAVEkuRGlzY2xhaW1lcl1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUg cXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg== --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89FAGRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0N CiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1 IDIgNCAyIDQgMiAyIDM7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5TdGlsZU1lc3Nh Z2dpb0RpUG9zdGFFbGV0dHJvbmljYTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gMi4wY20gMi4wY207fQ0KZGl2LlNlY3Rpb24x DQoJe3BhZ2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxMDE2ODA2NjUyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxMTYxNTg4ODg2IC00OTM5NTIyMzQgNjc4OTUyOTkgNjc4OTUzMDEg Njc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozMDAwOw0KCW1zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4o UmUgc2VuZGluZyBpbmNsdWRpbmcgdGhlIGdvb2dsZSBncm91cCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJ VCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEdvaXggTGF1cmVudCBXYWx0ZXINCjxicj4NCjxiPklu dmlhdG86PC9iPiB2ZW5lcmTDrCAxNCBkaWNlbWJyZSAyMDEyIDEwLjQzPGJyPg0KPGI+QTo8L2I+ ICdCcmFkIEZpdHpwYXRyaWNrJzsgSmFtZXMgTSBTbmVsbDxicj4NCjxiPkNjOjwvYj4gUGF1bCBF LiBKb25lczsgd2ViZmluZ2VyQGlldGYub3JnPGJyPg0KPGI+T2dnZXR0bzo8L2I+IFI6IFt3ZWJm aW5nZXJdIFRoZSBIVFRQL0hUVFBTIElzc3VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPldl4oCZcmUgdGFsa2luZyBhYm91dCBjbGllbnRzIGJ1dCBub3Qg YXBwbGljYXRpb25zLiBJZiBjbGllbnRzIGFyZSB0aGUgaW1wbGVtZW50YXRpb24gc3RhY2tzIG9m IHRoZSBzcGVjLCB0aGVuIHRoZXkgc2hvdWxkIGdpdmUgdGhlIHdob2xlIGZsZXhpYmlsaXR5DQog b2YgaXQuIEl0IGlzIHVwIHRvIHRoZSBhcHAgKHJlcHJlc2VudGluZyB0aGUgc3BlY2lmaWMgdXNl LWNhc2UpIHRvIGRlY2lkZSB3aGV0aGVyIGl0IG5lZWRzIHNlY3VyaXR5IG9yIG5vdCwgYW5kIHdo ZXRoZXIgZmFsbGJhY2sgbWF5IGJlIGFjY2VwdGFibGUgb3Igbm90LiBJZiBodHRwcy10by1odHRw IGZhbGxiYWNrIGlzIHBlcmZvcm1lZCBhdCBhcHBsaWNhdGlvbiBsZXZlbCBhbmQgbm90IGF1dG9t YXRpY2FsbHkgYnkgdGhlIGNsaWVudCB0aGVuDQogd2UgbWF5IGFsbCBjb252ZXJnZS4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5MZXQgbWUgZ2l2ZSBhbiBleGFtcGxl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsN CmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Vc2UgY2FzZSB0eXBlIDEgKOKAnGF1dG9jb25maWd1cmF0aW9uL2xvZ2lu 4oCdKTogTXkgd2Vic2l0ZSBpcyBwcm92aWRpbmcgcmVnaXN0cmF0aW9uIHRocm91Z2ggb3Blbmlk Y29ubmVjdCB3aGVyZSB0aGUgdXNlciBjYW4gaW5wdXQgaGlzDQogaWRlbnRpdHkuIFNpbmNlIHRo aXMgaXMgd2hhdCBJIGNhbiBjYWxsIGF1dG9jb25maWd1cmF0aW9uIHVzZSBjYXNlIChpbiB0aGF0 IHNlbnNlIHNpbWlsYXIgdG8gZGlzY292ZXJpbmcgbXkgb2F1dGgqIGVuZHBvaW50cykgdGhlIGFw cCAobXkgd2Vic2l0ZSkgMSkgbmVlZHMgc2VjdXJpdHkgYW5kIDIpIGtub3dzIHByZXR0eSBtdWNo IHRoZSBsaW5rIHJlbHMgaXTigJlzIGludGVyZXN0ZWQgaW4uIGl0IHRoZW4gaXNzdWVzIHRoZSB3 ZiByZXF1ZXN0IG92ZXINCiBodHRwcyBvbmx5IChvcHRpb25hbGx5IGFkZGluZyB0aGUgZXhwbGlj aXQgbGlzdCBvZiBsaW5rcykuIElmIHRoYXQgcmVxdWVzdCBmYWlscyBiZWNhdXNlIHRoZSBpZHAg aXMgbm90IHJ1bm5pbmcgb3ZlciBodHRwcywgdGhlbiBteSB3ZWJzaXRlIChub3IgdGhlIHVuZGVy bHlpbmcgd2YgY2xpZW50KSBkb2VzIG5vdCBmYWxsYmFjayBvdmVyIGh0dHAgYW5kIHRlbGxzIHRo ZSB1c2VyIHRoYXQgaGUgY2Fubm90IHVzZSB0aGF0IGlkZW50aXR5LiBTaW1pbGFybHkNCiBpZiBJ IHdhbnQgdG8gYXV0b2NvbmZpZ3VyZSBteSBmYXZvcml0ZSBhcHAgYmFzZWQgb24gbXkgaWRlbnRp dHkgYW5kIGRpc2NvdmVyIGEgYnVuY2ggb2YgZW5kcG9pbnRzIG15IGNsaWVudCBzaG91bGQgbm90 IGZhbGxiYWNrIHRvIGh0dHAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVzZSBjYXNlIHR5cGUgMiAo4oCccHVibGlj IGluZm8gZGlzY292ZXJ54oCdKTogTXkgZmF2b3JpdGUgZW1haWwgYXBwIGhhcyBhIHBsdWdpbiB0 aGF0IHJlc29sdmVzIGVtYWlsIGFkZHJlc3NlcyB0byBzaG93IHRoZSB1c2Vy4oCZcyBhdmF0YXIu DQogRm9yIGVhY2ggZW1haWwgYWRkcmVzcyBpdCBpc3N1ZXMgYSB3ZiByZXF1ZXN0IGFuZCBjYW4g ZGVjaWRlIHdoZXRoZXIgdG8gdHJ5IGh0dHBzIGZpcnN0IG9yIGRpcmVjdGx5IGh0dHAuIFN1cHBv c2UgaXQgKjxiPmFza3MgdGhlIGNsaWVudCB0byB0cnkgaHR0cHMgZmlyc3QgKG1heSBiZSB0aGUg ZGVmYXVsdCk8L2I+Ki4gSWYgdGhlIGNsaWVudCBmYWlscyBmb3IgdGhlIHNhbWUgcmVhc29uLCB0 aGVuICo8Yj50aGUgYXBwPC9iPiogY2FuIGRlY2lkZQ0KIHRvIHRyeSBhZ2FpbiBvdmVyIHBsYWlu IGh0dHAgYW5kIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGggdGhlIHByb3ZpZGVkIGluZm9ybWF0aW9u IChlZyBhY2NlcHQgaXQgYXMgYXZhdGFyIG1heSBiZSBjb25zaWRlcmVkIGxlc3Mgc2Vuc2l0aXZl KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPklmIHdlIG1vdmUgdGhl IHNlY3VyaXR5IGNvbmNlcm4gYXQgYXBwIGxldmVsIHRoZW4gd2UgbmVlZCBhIG1lY2hhbmlzbSB0 byB0ZWxsIHNvLCB3aGljaCBpcyBpbmRlcGVuZGVudCBmcm9tIHRoZSBzcGVjaWZpYyBjb2RlYmFz ZSBhbmQvb3IgYXBpDQogc2lnbmF0dXJlLiBPbmUgcG9zc2liaWxpdHkgY291bGQgYmUgaW4gdGhl IHJlc291cmNlIFVSSSBpdHNlbGYgdGhhdCB3ZSBhcmUgcXVlcnlpbmcuIFdlIGFscmVhZHkgc2Fp ZCB0aGF0IGFueSB0eXBlIG9mIHVyaSBpcyBzdXBwb3J0ZWQgd2l0aCBhIHNwZWNpZmljIG1lbnRp b24gb2YgYWNjdDouIFdoYXQgYWJvdXQgaW50cm9kdWNpbmcgYWNjdHM6IGZvciB0aGlzIHB1cnBv c2U/IFNpcHM6LCB3c3M6LCBodHRwczogYXJlIGFsbCBleGFtcGxlcyBvZg0KIHVyaXMgdGhhdCBl eHBsaWNpdGx5IGNhbGwgZm9yIHRscy4gSW4gdGhhdCBjYXNlIGlmIHRoZSBhcHAgcmVxdWVzdHMg d2YuZGlzY292ZXIo4oCcYWNjdHM6dXNlckBleGFtcGxlLmNvbeKAnSkgdGhlIGNsaWVudCB3b3Vs ZCBrbm93IHRoYXQgaXQgaGFzIHRvIHJ1biBvdmVyIGh0dHBzLiBBbmQgaXQgd29ya3MgZm9yIGh0 dHBzOiBVUklzIGFzIHdlbGwgYW5kIG90aGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPldpdGggdGhpcyBhcnRpZmFjdCB3ZSBjYW4gZ2V0IHJpZCBvZiB0aGUgZmFs bGJhY2sgcHJvYmxlbSBvbiB0aGUgY2xpZW50IHNpZGUgYW5kIHN0YXkgd2l0aCB0aGUgY3VycmVu dCB0ZXh0IGluIHNheWluZyB0aGF0IGl0IG11c3Qgbm90IHRyeSBpbg0KIHBhcmFsbGVsIG9yIGlu IHNlcXVlbmNlIChtZWFudCBhcyDigJxhdXRvbWF0aWNhbGx54oCdKS4gQnV0IGl0IG1heSBiZSBy ZXF1ZXN0ZWQgdG8gZG8gc28gYnkgdGhlIGFwcCBpZiBhZnRlciBhIGZhaWx1cmUgb3ZlciBodHRw cyAoZWcgZm9yIHVzZSBjYXNlIHR5cGUgMikgdGhlIGFwcCBkZWNpZGVzIHRvIGdvIG92ZXIgcGxh aW4gaHR0cCAodXNpbmcgYWNjdDogVVJJKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPldoYXQgSSB3b3VsZCB1cGRhdGUgaXMgc2ltcGx5IHRoYXQgc2VydmVyIE1VU1Qg ZXhwb3NlIG92ZXIgaHR0cCBhbmQgU0hPVUxEIG92ZXIgSFRUUFMgc28gdGhhdCBldmVyeSBjYXNl IHdvcmtzIHdpdGggdGhlIGFib3ZlIHNjZW5hcmlvLCBmdXJ0aGVyDQogY2xhcmlmeWluZyAoYXMg c2hhcmVkIHdpdGggbmljaykgdGhhdCBzZXJ2ZXJzIE1VU1QgTk9UIGluY2x1ZGUgJ3NlY3VyZScg KmhyZWYqICh0aGUgb25lcyB3aG9zZSBzY2hlbWUgaXMgZW5kaW5nIHdpdGggYW4g4oCYc+KAmSkg d2hlbiBhbnN3ZXJpbmcgb3ZlciBwbGFpbiBodHRwIEFORCBjbGllbnRzIE1VU1QgaWdub3JlIHRo b3NlIGhyZWZzIHNob3VsZCB0aGV5IGJlIGFueXdheSBpbmNsdWRlZCBpbiB0aGUganJkIHJldHJp ZXZlZCBvdmVyIGh0dHAgKGFzDQogYW4gYXR0YWNrKS4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPkFzIHBhdWwgcG9pbnRlZCBvdXQgdGhlIG9ubHkgbGltaXRh dGlvbiBpcyBpZiBteSBhdmF0YXIgaXMgb25seSBleHBvc2VkIG92ZXIgYW4gaHR0cHMgZW5kcG9p bnQgYnV0IG5vdCBteSB3ZiBlbmRwb2ludCBidXQgSSBkb27igJl0IHRoaW5rIHRoaXMNCiBpcyBh IHJlYWwgaXNzdWXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPndh bHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gd2ViZmluZ2Vy LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZ10NCjxi PlBlciBjb250byBkaSA8L2I+QnJhZCBGaXR6cGF0cmljazxicj4NCjxiPkludmlhdG86PC9iPiB2 ZW5lcmTDrCAxNCBkaWNlbWJyZSAyMDEyIDUuNDE8YnI+DQo8Yj5BOjwvYj4gSmFtZXMgTSBTbmVs bDxicj4NCjxiPkNjOjwvYj4gUGF1bCBFLiBKb25lczsgd2ViZmluZ2VyQGlldGYub3JnPGJyPg0K PGI+T2dnZXR0bzo8L2I+IFJlOiBbd2ViZmluZ2VyXSBUaGUgSFRUUC9IVFRQUyBJc3N1ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBUaHUsIERlYyAxMywgMjAxMiBhdCA3OjM4IFBNLCBKYW1l cyBNIFNuZWxsICZsdDs8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5qYXNuZWxsQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0Ow0KbWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RmFpbHVyZSBvZiBhIHJlcXVl c3QgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUuIElmIHRoZSBjbGllbnQgbmVlZHMgYSBzZWN1cmVk IGNvbm5lY3Rpb24gYW5kIHRoZSBzZXJ2ZXIgc2ltcGx5IGRvZXMgbm90IHByb3ZpZGUgZm9yIGl0 LCB0aGUgY2xpZW50IHNpbXBseSB3b24ndCB1c2UgdGhhdCBzZXJ2ZXIuIFNpbXBsZSBhcyB0aGF0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbid0IHdhbnQgdXNlcnMg b3IgY2xpZW50cyB0byBuZWVkIHRvIG9wdC1pbiB0byBzZWN1cml0eS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi Pg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7 fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFs OyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9 IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29u ZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlv bmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25v IHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBk b2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBz dWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0i anVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5U aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3Bh biBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhl IHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48 L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJk YW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRp c2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQw Ij5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOo IG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE53A5BA89FAGRFMBX704BA02_-- --_bc725f8e-1976-49f4-bb39-9548efc83ccd_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_bc725f8e-1976-49f4-bb39-9548efc83ccd_-- From jpanzer@google.com Fri Dec 14 07:18:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBD821F85C9 for ; Fri, 14 Dec 2012 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVFaAwT8PWIk for ; Fri, 14 Dec 2012 07:18:24 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87E21F85BF for ; Fri, 14 Dec 2012 07:18:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2873957lbk.31 for ; Fri, 14 Dec 2012 07:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2didcYTpPiHRhap5tDrnlWWgqsmVuXt59YN57UT0jvg=; b=I1JPj8ygNNF6iEBJgni1C8C+RZH2dqaXs7myTTN0lbvabtLY3dgs+ggxM5CKKi32Cu SjZ8FMBXkPc5r7DKo203f1hS7ofeZixFnxmz31SU1okJaz8+2miKobf2Pq+tOKAsFrNw /JXCENa2jpJiRz7gN9rhqWgnSW0BV2lHB337WhKVzcR5BE4IEMO1Tjy1LxX+cqKmRI7h Sdtn/YuERtiM/f4xr3eFXaYZFHr09lp6R0+TVpl+QqyfVn2T2Qeoa/pL5SxA9zPsgaOX HGwRwig1CZhjcxfcDxbChIhLh1ad99nnzumkpm8Va1/2eq99Dd44tJ2olmORVC7noIQ6 gQ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2didcYTpPiHRhap5tDrnlWWgqsmVuXt59YN57UT0jvg=; b=ph7L8wszOrK+/fSh5JfMCEPSpIN/eqYgFGFdnsWxCHADx6rju1GSACjH6TQ6DCrOiA aE6LcE2bAm3/auOrj5tieYXgCOt2qYKvDUV7XkpnWHW9HOihhdV7yBQ3qF/bKfoGKva0 vrzLS0JmYLItOY+k0iYcKAactaEIa/UxRHKLA34yRnETXgDDfSIYuoMhxW88IAI7WEW/ NGdxGNX4tnvji1sFhvQ2G2Cc02C07xnKMJRkVzKg4mJE5RTgaqBIO7S6lKwXAALLBfK3 fTirUCh3S8Cq5tCdne5eyDvXzkP2AX3Q8OJ+2b+Ut1bRFLM/ABhaUmF0vHSSDTAA1C9+ hfgQ== MIME-Version: 1.0 Received: by 10.112.44.161 with SMTP id f1mr2448297lbm.29.1355498299089; Fri, 14 Dec 2012 07:18:19 -0800 (PST) Received: by 10.114.5.3 with HTTP; Fri, 14 Dec 2012 07:18:18 -0800 (PST) Received: by 10.114.5.3 with HTTP; Fri, 14 Dec 2012 07:18:18 -0800 (PST) In-Reply-To: <099201cdd9c9$aeae8820$0c0b9860$@packetizer.com> References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> <099201cdd9c9$aeae8820$0c0b9860$@packetizer.com> Date: Fri, 14 Dec 2012 07:18:18 -0800 Message-ID: From: John Panzer To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec554d1fe9c660004d0d18a0b X-Gm-Message-State: ALoCoQkeiIy9RLXxDF1vqdSti/OFqcDgWOZGlzUdTQ+xGnQ6DsF1v0aWL5szqKMz/SiRfuwrXtrC2z5As5voHvQ+pf/aAGDnfBkQsuVZJgw+vAYmtGT+TkZw24WXtu4R/IJmmyQG1L4ZCIJpmfWDQ19IoRitGgLq4It8mIxPf6FfZ4eqXOGpixOmrlaJATl7ACJPgsTzidt2 Cc: webfinger@ietf.org, James M Snell , webfinger@googlegroups.com, Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:18:25 -0000 --bcaec554d1fe9c660004d0d18a0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK good :). Large server farms that do WF lookups will want to be able to cache the results via proxy for scalability, the same as any other http request. I think this means nothing really needs to be said, though people misunderstand this enough that a "normal http caching rules apply" reminder might make sense. On Dec 13, 2012 11:07 PM, "Paul E. Jones" wrote: > Sure, the client can certainly cache it, but I figured that went without > saying. What trusted proxies exist, except those service the data for th= e > server (e.g., load balancers)? I sure as heck would not trust any entity > between me and my bank, for example.**** > > ** ** > > In any case, WF does not change caching rules or anything else about HTTP= . > **** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *John Panzer > *Sent:* Friday, December 14, 2012 1:49 AM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org; James M Snell; Goix Laurent Walter; Brad > Fitzpatrick > *Subject:* Re: [webfinger] secure links with https rels**** > > ** ** > > Why would TLS data marked with cache-control: public not be cacheable on > the client? Or by trusted caching proxies?**** > > On Dec 13, 2012 10:38 PM, "Paul E. Jones" wrote:*= * > ** > > TLS data isn=92t cached (except perhaps on the server side where there mi= ght > be a caching load balancer with the TLS certificates loaded).**** > > **** > > HTTP data can and may be cached. There is a small statement about that i= n > the spec, but at least one person suggested I should remove it since WF i= s > not changing the rules of how HTTP works and therefore they felt we don= =92t > need to say anything about it.**** > > **** > > Paul**** > > **** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Breno > *Sent:* Friday, December 14, 2012 12:00 AM > *To:* Paul E. Jones > *Cc:* webfinger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; > webfinger@googlegroups.com; James M Snell > *Subject:* RE: [webfinger] secure links with https rels**** > > **** > > Our messages crossed. **** > > There's still some complexity. How does that interact with caching?**** > > On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote:**= * > * > > You=92re right that we cannot have all three. But, those who are still > demanding HTTP as an option (and I=92m still looking to hear from those > folks) are not demanding security.**** > > **** > > So, what we=92re looking at presently are really two options for clients:= *** > * > > 1) Secure =96 HTTPS server**** > > 2) Non-Secure =96 HTTP server**** > > **** > > The client selects the transport based on its requirements.**** > > **** > > In the case that the client needs a secure reply, it uses HTTPS and will > not try HTTP. If the server is not listening on HTTPS, then it fails. > And, that=92s exactly what you want to avoid a security issue.**** > > **** > > In the case that the client does not care about security of the response, > it queries using HTTP. The server might reply or it might redirect, but > the reply is still considered non-secure (since the HTTP reply could be > hacked).**** > > **** > > In both cases, the client code is simple. There=92s no fall back logic i= n > the client. Either make a secure request or don=92t.**** > > **** > > Paul**** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Brad Fitzpatrick > *Sent:* Thursday, December 13, 2012 11:37 PM > *To:* Breno; webfinger@ietf.org > *Cc:* James M Snell; webfinger@googlegroups.com; Goix Laurent Walter > *Subject:* Re: [webfinger] secure links with https rels**** > > **** > > I agree with Breno, in all his points and previous emails.**** > > **** > > Again, I will repeat myself: we can have at most two of these three:**** > > **** > > 1) security**** > > 2) support HTTP servers**** > > 3) simple clients**** > > **** > > We don't get all 3. We get at most 2.**** > > **** > > I think everybody wants 1), so that leave us deciding between 2) and 3) a= s > our other feature.**** > > **** > > Which is it? HTTP servers or simple clients?**** > > **** > > **** > > On Thu, Dec 13, 2012 at 8:19 PM, Breno wrote= : > **** > > I will go further: > > Security is best served by simplicity: If HTTPS was only allowable > protocol, that'd be the best approach security-wise. > > If simplicity is not available (and the decision to allow HTTPS and > HTTP means it isn't), then a fully specified behavior, in all it's > glorious complexity, is required for security. If that discourages the > proliferation of low-quality > I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client > implementations, so much better for security. Put all eggs in one > basket and watch that basket. > > The current compromise where we pretend that we can have simple client > specification that allows for both complex behavior and secure > operation is a smokescreen. Just add a disclaimer that WF is not > intended to use in secure contexts, at least it'd be honest.**** > > > On Thu, Dec 13, 2012 at 8:08 PM, Breno wrote= : > > Also, I reject the notion that WF standard should be simple for > > clients. If we want WF to be widely deployed, we make it easier for > > servers so that the information is ubiquitously deployed even by users > > and companies that are unsophisticated. > > > > In contrast, standard-compliant WF clients are probably going to be > > less common. Even if WF is not too complex, why wouldn't you use a > > library if you want to have some guarantee like security? If you want > > to simply write a few curl commands and mesh the data after applying > > your homebrew parser, you neither care for standard compliance or > > security, and you still can get things done because the underlying > > data schema is simple. > > > > On Thu, Dec 13, 2012 at 8:00 PM, Breno > wrote: > >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones > wrote: > >>> Brad, > >>> > >>> > >>> > >>> I really don=92t like the secure-rels idea. If a rel is secure or > should be > >>> treated as secure, I can mark it as such on the server without > creating more > >>> names and cluttering up the link relation name space with multiple > variants > >>> of the same thing. > >> > >> As explained above, this does not address HTTP-fallback degrade attack= s. > >> > >>> > >>> > >>> > >>> There were several people opposed to the client fall back text due to > both > >>> security concerns and client-side complexity. That was one of the ma= in > >>> items we addressed with this latest proposal re-write. > >> > >> The proposal re-write does not seem to address any complexity. It > >> simply removes guidance that would ensure implementations that can be > >> 'plugged in' both in insecure and secure contexts. The likely result > >> are simpler implementations that can't be used in secure contexts, > >> even if they may make a claim to the contrary. > >> > >>> > >>> > >>> > >>> I do realize the flakiness of the proposed solution. > >> > >> Yes. It's too flaky for the purposes of secure discovery. > >> > >>> Sometimes, the client > >>> just does not work. You type in paulej@packetizer.com and it says > =93could > >>> not find a thing=94, because the client only issued the query over > HTTPS. If > >>> one needs security, I see on other way. However, if we=92re willing = to > go > >>> back to the -07 text that has an allowance for fall back, the issue i= s > >>> addressed. In the -07 text, a client MAY re-issue a request using > HTTP. > >>> > >>> > >>> > >>> Paul > >>> > >>> > >>> > >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] > >>> Sent: Thursday, December 13, 2012 6:15 PM > >>> To: Paul E. Jones > >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; > >>> webfinger@ietf.org > >>> > >>> > >>> Subject: Re: [webfinger] secure links with https rels > >>> > >>> > >>> > >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones > >>> wrote: > >>> > >>> Walter, > >>> > >>> > >>> > >>> No, this will not work. People want to have secure content and what = is > >>> secure might be determined by the server admin or user. One might > consider > >>> his avatar should be served over HTTPS only. > >>> > >>> > >>> > >>> And people do not want to have to write clients that do fallback. > >>> > >>> > >>> > >>> I never saw any strong opposition against fallback. People disliked > the > >>> extra complexity, but for quite awhile everybody assumed that fallbac= k > would > >>> be involved, and I think it was considered acceptable. > >>> > >>> > >>> > >>> Who was strongly anti-fallback? > >>> > >>> > >>> > >>> > >>> > >>> We either have to do HTTPS only or we have to live with the fact that > some > >>> client requests are going to fail if a WF provider does not provide W= F > >>> services over HTTPS. > >>> > >>> > >>> > >>> I strongly disagree that those are the only two options. > >>> > >>> > >>> > >>> But if you really believe that, I hope you realize that flakiness is > >>> unacceptable, which leaves you with HTTPS-only. > >>> > >>> > >>> > >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy > with > >>> HTTPS-only. > >>> > >>> > >>> > >>> So, > >>> > >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS > >>> > >>> 2) Servers and clients MAY implement HTTP > >>> > >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be > treated as > >>> secure since it allows for a MITM attack) > >>> > >>> 4) Servers MUST NOT redirect from HTTPS to HTTP > >>> > >>> > >>> > >>> All works well, except for the case where you have an HTTPS-only > client. > >>> But, I bet that will be the majority of clients, which will then driv= e > the > >>> majority of the servers to support HTTPS. > >>> > >>> > >>> > >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. > >>> > >>> > >>> > >>> Still, it leaves the option on the table for some clients and server= s > to > >>> use HTTP if they wish. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Breno de Medeiros > > > > > > > > -- > > Breno de Medeiros**** > > -- > Breno de Medeiros**** > > **** > --bcaec554d1fe9c660004d0d18a0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

OK good :).

Large server farms that do WF lookups will want to be able t= o cache the results via proxy for scalability, the same as any other http r= equest.

I think this means nothing really needs to be said, though p= eople misunderstand this enough that a "normal http caching rules appl= y" reminder might make sense.

On Dec 13, 2012 11:07 PM, "Paul E. Jones&qu= ot; <paulej@packetizer.com&= gt; wrote:

Sure, the client can certainly cache it, but= I figured that went without saying.=A0 What trusted proxies exist, except = those service the data for the server (e.g., load balancers)?=A0 I sure as = heck would not trust any entity between me and my bank, for example.=

=A0<= /p>

In any case, WF does n= ot change caching rules or anything else about HTTP.

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = John Panzer
Sent: Friday, December 14, 2012 1:49 AM
To: webfinger@googlegroups.co= m
Cc: webfinger@ietf.org; James M Snell; Goix Laurent Walter; Brad Fitzpatri= ck
Subject: Re: [webfinger] secure links with https rels<= /span>

=A0

Why wo= uld TLS data marked with cache-control: public not be cacheable on the clie= nt?=A0 Or by trusted caching proxies?

On Dec 13, 2012 10:38 PM, "Paul E. Jones&q= uot; <paulej@= packetizer.com> wrote:

TLS data isn=92t cached (except perhaps on the s= erver side where there might be a caching load balancer with the TLS certif= icates loaded).

=A0<= /p>

HTTP data can and may = be cached.=A0 There is a small statement about that in the spec, but at lea= st one person suggested I should remove it since WF is not changing the rul= es of how HTTP works and therefore they felt we don=92t need to say anythin= g about it.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: webfi= nger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Breno
Sent: Friday, December 14, 2012 12:00 AM
To: Paul E. Jones=
Cc: webf= inger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; webfinger@googlegroups.com<= /a>; James M Snell
Subject: RE: [webfinger] secure links with https rels<= u>

=A0

Our me= ssages crossed.

There's still some complexity. How= does that interact=A0 with caching?

On Dec 13, 2012 8:48 PM, "Paul E. Jones&qu= ot; <paulej@p= acketizer.com> wrote:

You=92re right that we cannot have all three.=A0= But, those who are still demanding HTTP as an option (and I=92m still look= ing to hear from those folks) are not demanding security.<= /u>

=A0<= /p>

So, what we=92re looki= ng at presently are really two options for clients:

1)=A0=A0=A0=A0=A0 Secure =96 HTTP= S server

2)=A0=A0=A0=A0=A0 Non-Secure =96 = HTTP server

=A0<= /p>

The client selects the= transport based on its requirements.

=A0<= /p>

In the case that the c= lient needs a secure reply, it uses HTTPS and will not try HTTP.=A0 If the = server is not listening on HTTPS, then it fails.=A0 And, that=92s exactly w= hat you want to avoid a security issue.

=A0<= /p>

In the case that the c= lient does not care about security of the response, it queries using HTTP.= =A0 The server might reply or it might redirect, but the reply is still con= sidered non-secure (since the HTTP reply could be hacked).=

=A0<= /p>

In both cases, the cli= ent code is simple.=A0 There=92s no fall back logic in the client.=A0 Eithe= r make a secure request or don=92t.

=A0<= /p>

Paul<= /u>

From:= webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf = Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 PM
To: Breno; webfinger@ietf.org<= br>Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter
Subject: Re: [webfinger] secure links with https rels<= u>

=A0

I agree with Breno, in all his points and pre= vious emails.

=A0

Again, I will repeat myself: =A0we can= have at most two of these three:

=A0

1) security=

2) support HTTP servers=

3) simple cl= ients

=A0

We don't get all 3. =A0We ge= t at most 2.

=A0

I think everybody wants 1), so t= hat leave us deciding between 2) and 3) as our other feature.=

=A0

Which is it? =A0HTTP servers or = simple clients?

=A0

=A0

On Thu, Dec 13, 2012 at 8:19 PM, Bre= no <bren= o.demedeiros@gmail.com> wrote:

I will go further:

Security is bes= t served by simplicity: If HTTPS was only allowable
protocol, that'd= be the best approach security-wise.

If simplicity is not available (and the decision to allow HTTPS and
= HTTP means it isn't), then a fully specified behavior, in all it's<= br>glorious complexity, is required for security. If that discourages the proliferation of low-quality
I-whipped-this-in-1h-while-waiting-to-board= compliant-claiming client
implementations, so much better for security.= Put all eggs in one
basket and watch that basket.

The current co= mpromise where we pretend that we can have simple client
specification that allows for both complex behavior and secure
operation= is a smokescreen. Just add a disclaimer that WF is not
intended to use = in secure contexts, at least it'd be honest.

=
On Thu, Dec 13, 2012 at 8:08 PM, Breno <breno.demedeiros@gmail.com> wrot= e:
> Also, I reject the notion that WF standard should be simple for
>= ; clients. If we want WF to be widely deployed, we make it easier for
&g= t; servers so that the information is ubiquitously deployed even by users > and companies that are unsophisticated.
>
> In contrast, s= tandard-compliant WF clients are probably going to be
> less common. = Even if WF is not too complex, why wouldn't you use a
> library i= f you want to have some guarantee like security? If you want
> to simply write a few curl commands and mesh the data after applying> your homebrew parser, you neither care for standard compliance or> security, and you still can get things done because the underlying > data schema is simple.
>
> On Thu, Dec 13, 2012 at 8:00 PM= , Breno <breno.demedeiros@gmail.com> wrote:
>> On Thu, Dec 13, 2012= at 3:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>>> Brad,
>>>
>>>
>>>
>&= gt;> I really don=92t like the secure-rels idea. =A0If a rel is secure o= r should be
>>> treated as secure, I can mark it as such on the= server without creating more
>>> names and cluttering up the link relation name space with mult= iple variants
>>> of the same thing.
>>
>> As= explained above, this does not address HTTP-fallback degrade attacks.
>>
>>>
>>>
>>>
>>> Th= ere were several people opposed to the client fall back text due to both>>> security concerns and client-side complexity. =A0That was one= of the main
>>> items we addressed with this latest proposal re-write.
>= >
>> The proposal re-write does not seem to address any complex= ity. It
>> simply removes guidance that would ensure implementatio= ns that can be
>> 'plugged in' both in insecure and secure contexts. The lik= ely result
>> are simpler implementations that can't be used i= n secure contexts,
>> even if they may make a claim to the contrar= y.
>>
>>>
>>>
>>>
>>> I = do realize the flakiness of the proposed solution.
>>
>> = Yes. It's too flaky for the purposes of secure discovery.
>> >>> Sometimes, the client
>>> just does not work. =A0Y= ou type in paule= j@packetizer.com and it says =93could
>>> not find a thing= =94, because the client only issued the query over HTTPS. =A0If
>>> one needs security, I see on other way. =A0However, if we=92re= willing to go
>>> back to the -07 text that has an allowance f= or fall back, the issue is
>>> addressed. =A0In the -07 text, a= client MAY re-issue a request using HTTP.
>>>
>>>
>>>
>>> Paul
>&g= t;>
>>>
>>>
>>> From: Brad Fitzpatri= ck [mailto:bradfit= z@google.com]
>>> Sent: Thursday, December 13, 2012 6:15 PM
>>> To: = Paul E. Jones
>>> Cc: Goix Laurent Walter; webfinger@googlegroups.com;= James M Snell;
>>> webfin= ger@ietf.org
>>>
>>>
>>> Subject: R= e: [webfinger] secure links with https rels
>>>
>>>=
>>>
>>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones= <paulej@pack= etizer.com>
>>> wrote:
>>>
>>> W= alter,
>>>
>>>
>>>
>>> No, this will = not work. =A0People want to have secure content and what is
>>>= secure might be determined by the server admin or user. =A0One might consi= der
>>> his avatar should be served over HTTPS only.
>>>>>>
>>>
>>> And people do not want to ha= ve to write clients that do fallback.
>>>
>>>
>>>
>>> I never saw any strong opposition against fall= back. =A0People disliked the
>>> extra complexity, but for quit= e awhile everybody assumed that fallback would
>>> be involved,= and I think it was considered acceptable.
>>>
>>>
>>>
>>> Who was strong= ly anti-fallback?
>>>
>>>
>>>
>&g= t;>
>>>
>>> We either have to do HTTPS only or w= e have to live with the fact that some
>>> client requests are going to fail if a WF provider does not pr= ovide WF
>>> services over HTTPS.
>>>
>>&g= t;
>>>
>>> I strongly disagree that those are the o= nly two options.
>>>
>>>
>>>
>>> But if you rea= lly believe that, I hope you realize that flakiness is
>>> unac= ceptable, which leaves you with HTTPS-only.
>>>
>>>=
>>>
>>> If the HTTPS-for-some-rels proposal still isn&= #39;t clear, I'd be happy with
>>> HTTPS-only.
>>&= gt;
>>>
>>>
>>> =A0So,
>>><= br> >>> 1) =A0 =A0 =A0Servers SHOULD implement HTTPS and clients SHOUL= D use HTTPS
>>>
>>> 2) =A0 =A0 =A0Servers and clien= ts MAY implement HTTP
>>>
>>> 3) =A0 =A0 =A0Servers= MAY redirect from HTTP to HTTPS (this MUST NOT be treated as
>>> secure since it allows for a MITM attack)
>>>
&= gt;>> 4) =A0 =A0 =A0Servers MUST NOT redirect from HTTPS to HTTP
&= gt;>>
>>>
>>>
>>> All works well,= except for the case where you have an HTTPS-only client.
>>> But, I bet that will be the majority of clients, which will th= en drive the
>>> majority of the servers to support HTTPS.
&= gt;>>
>>>
>>>
>>> This is a terri= ble cop-out. =A0Flakiness in the spec is unacceptable.
>>>
>>>
>>>
>>> =A0Still, it l= eaves the option on the table for some clients and servers to
>>&g= t; use HTTP if they wish.
>>>
>>>
>>> >>>
>>
>>
>>
>> --
>>= Breno de Medeiros
>
>
>
> --
> Breno de Mede= iros

--
Breno de Medeiros

=A0

--bcaec554d1fe9c660004d0d18a0b-- From nick@silverbucket.net Fri Dec 14 07:20:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A396F21F84ED for ; Fri, 14 Dec 2012 07:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuTH+nF04qTo for ; Fri, 14 Dec 2012 07:20:06 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4606721F87F4 for ; Fri, 14 Dec 2012 07:20:05 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2860901lah.31 for ; Fri, 14 Dec 2012 07:20:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=teDE42TIPXJFgykSatnk6TDOta8wklbGXY6IUTiEzMw=; b=FT3wLnmk8HyjJYnvhQjPuXWf6Dyy4n9bh5RcScUNO1JVt6hGXFPByZbbURnDHDBoEK vjMceTufmNQ4d7jbEq9MKJ3UrW2uHW7FLf1MHeQuLDX++biv0db9RPYjDDhIWQ+Tc2NU BJF6j/b7PUE3rdcfQ4ZKsKNO6eUZ9KYTmSkKweoTyOXvOoHPy2Kz8x2R0aBkaOMBVqWV rKav8YW+aykMK50OUSCFl0737yAF3Jey8rT62tPDZq+vraRMlJu3Zz7gQ1e8/bU52Tm8 3f7oRXaYrWHRmPNlteZ/89UjDqM8qgrT/AZw7D9GBtLLD3I/qfG14sO9XgEnxWcuBSdV GUeg== Received: by 10.112.82.202 with SMTP id k10mr2533139lby.22.1355498403858; Fri, 14 Dec 2012 07:20:03 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id ee5sm2009692lbb.14.2012.12.14.07.20.02 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 07:20:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2860877lah.31 for ; Fri, 14 Dec 2012 07:20:02 -0800 (PST) Received: by 10.152.106.4 with SMTP id gq4mr2826877lab.44.1355498402373; Fri, 14 Dec 2012 07:20:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Fri, 14 Dec 2012 07:19:31 -0800 (PST) In-Reply-To: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> From: Nick Jennings Date: Fri, 14 Dec 2012 16:19:31 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04083e0fc461e204d0d190c6 X-Gm-Message-State: ALoCoQkLtCp7htgXb3+CnN6zsY+Ph/MyRC7+kXDEQYK02ub6a2X+03JJJ8bo+YaviUmcbbVCGQNF Cc: "webfinger@ietf.org" , Brad Fitzpatrick , James M Snell , "Paul E. Jones" Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:20:07 -0000 --f46d04083e0fc461e204d0d190c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I pretty much agree with what Goix is explaining here. The more I think about it, though, the more I think we're worrying way too much about 'client complexity'. The client will be complex, we're programmers, we can handle that. It's not a big deal. What's important is that we a) make clear the security implications, and precautions to consider for potential client developers b) make sure the servers will take sufficient responsibility for the data they provide to not become compromised due to a bug in a client library. Other than those two points, i think we need to make WF as flexible and applicable to the different use-cases as possible (for wide-spread server adoption). That means: (A) Servers MUST answer on HTTP and SHOULD answer on HTTPS. A server MAY upgrade an HTTP request to HTTPS if they want all of their data to be retrieved via HTTPS. -- This accounts for those that do not want to have to purchase a cert just to participate in providing lookup ability for simple user data. Wordpress blogs, simple one-man domains, etc. (B) Servers MUST filter 'secure' data from HTTP replies -- How 'secure' data is defined is still up in the air, but I think it's sufficiently clear that this needs to happen to some degree to protect against possible MITM attacks or poorly implemented client libraries. (C) Client libraries SHOULD NOT use HTTP for any secure data retrieval AND MUST filter any 'secure' links from an HTTP response. (D) Client libraries MAY provide fallback (HTTP->HTTPS or vice versa) as a configuration option, BUT IF SO: 1. They MUST NOT fallback to HTTP when accessing secure information. 2. They MUST provide a method of disabling fallback and specifying one protocol for the attempt(s). I think that covers all our use cases, and takes care of (1: security) and (2: HTTP)... I think client complexity is a much better sacrifice to make here for several reasons: 1. This only works if there are a lot of servers adopting WF 2. There will (hopefully) be MANY more servers than client libraries 3. You don't have to be a WF nerd to get a server going ... and (below)... 4. If you want to WRITE a client library, you're going to be more technical and are more than likely going to read the spec. / know a thing or two. And if you don't so what? (the servers can handle it if they follow the spec) I think those points make client complexity the clear compromise. What do you guys think? -Nick On Fri, Dec 14, 2012 at 1:26 PM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > (Re sending including the google group)**** > > ** ** > > *Da:* Goix Laurent Walter > *Inviato:* venerd=C3=AC 14 dicembre 2012 10.43 > *A:* 'Brad Fitzpatrick'; James M Snell > > *Cc:* Paul E. Jones; webfinger@ietf.org > *Oggetto:* R: [webfinger] The HTTP/HTTPS Issue**** > > ** ** > > We=E2=80=99re talking about clients but not applications. If clients are = the > implementation stacks of the spec, then they should give the whole > flexibility of it. It is up to the app (representing the specific use-cas= e) > to decide whether it needs security or not, and whether fallback may be > acceptable or not. If https-to-http fallback is performed at application > level and not automatically by the client then we may all converge. **** > > ** ** > > Let me give an example:**** > > **- **Use case type 1 (=E2=80=9Cautoconfiguration/login=E2=80=9D= ): My website is > providing registration through openidconnect where the user can input his > identity. Since this is what I can call autoconfiguration use case (in th= at > sense similar to discovering my oauth* endpoints) the app (my website) 1) > needs security and 2) knows pretty much the link rels it=E2=80=99s intere= sted in. > it then issues the wf request over https only (optionally adding the > explicit list of links). If that request fails because the idp is not > running over https, then my website (nor the underlying wf client) does n= ot > fallback over http and tells the user that he cannot use that identity. > Similarly if I want to autoconfigure my favorite app based on my identity > and discover a bunch of endpoints my client should not fallback to http.*= * > ** > > **- **Use case type 2 (=E2=80=9Cpublic info discovery=E2=80=9D):= My favorite > email app has a plugin that resolves email addresses to show the user=E2= =80=99s > avatar. For each email address it issues a wf request and can decide > whether to try https first or directly http. Suppose it **asks the client > to try https first (may be the default)**. If the client fails for the > same reason, then **the app** can decide to try again over plain http and > decide what to do with the provided information (eg accept it as avatar m= ay > be considered less sensitive).**** > > ** ** > > If we move the security concern at app level then we need a mechanism to > tell so, which is independent from the specific codebase and/or api > signature. One possibility could be in the resource URI itself that we ar= e > querying. We already said that any type of uri is supported with a specif= ic > mention of acct:. What about introducing accts: for this purpose? Sips:, > wss:, https: are all examples of uris that explicitly call for tls. In th= at > case if the app requests wf.discover(=E2=80=9Caccts:user@example.com=E2= =80=9D) the client > would know that it has to run over https. And it works for https: URIs as > well and others.**** > > ** ** > > With this artifact we can get rid of the fallback problem on the client > side and stay with the current text in saying that it must not try in > parallel or in sequence (meant as =E2=80=9Cautomatically=E2=80=9D). But i= t may be requested > to do so by the app if after a failure over https (eg for use case type 2= ) > the app decides to go over plain http (using acct: URI).**** > > ** ** > > What I would update is simply that server MUST expose over http and SHOUL= D > over HTTPS so that every case works with the above scenario, further > clarifying (as shared with nick) that servers MUST NOT include 'secure' > *href* (the ones whose scheme is ending with an =E2=80=98s=E2=80=99) when= answering over > plain http AND clients MUST ignore those hrefs should they be anyway > included in the jrd retrieved over http (as an attack). **** > > As paul pointed out the only limitation is if my avatar is only exposed > over an https endpoint but not my wf endpoint but I don=E2=80=99t think t= his is a > real issue=E2=80=A6**** > > ** ** > > walter**** > > ** ** > > *Da:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *Per > conto di *Brad Fitzpatrick > > *Inviato:* venerd=C3=AC 14 dicembre 2012 5.41 > *A:* James M Snell > *Cc:* Paul E. Jones; webfinger@ietf.org > *Oggetto:* Re: [webfinger] The HTTP/HTTPS Issue**** > > ** ** > > On Thu, Dec 13, 2012 at 7:38 PM, James M Snell wrote:= * > *** > > Failure of a request is perfectly acceptable. If the client needs a > secured connection and the server simply does not provide for it, the > client simply won't use that server. Simple as that.**** > > I don't want users or clients to need to opt-in to security.**** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =C3=A8 necessario.* > > --f46d04083e0fc461e204d0d190c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I pretty much agree with what Goix is explaining here. The more I think abo= ut it, though, the more I think we're worrying way too much about '= client complexity'. The client will be complex, we're programmers, = we can handle that. It's not a big deal. What's important is that w= e a) make clear the security implications, and precautions to consider for = potential client developers b) make sure the servers will take sufficient r= esponsibility for the data they provide to not become compromised due to a = bug in a client library. Other than those two points, i think we need to ma= ke WF as flexible and applicable to the different use-cases as possible (fo= r wide-spread server adoption). That means:

(A) =C2=A0 Servers MUST answer on HTTP and SHOULD answer on = HTTPS. A server MAY upgrade an HTTP request to HTTPS if they want all of th= eir data to be retrieved via HTTPS.

=C2=A0-- This = accounts for those that do not want to have to purchase a cert just to part= icipate in providing lookup ability for simple user data. Wordpress blogs, = simple one-man domains, etc.

(B) =C2=A0 Servers MUST filter 'secure' data fr= om HTTP replies

=C2=A0-- How 'secure' data= is defined is still up in the air, but I think it's sufficiently clear= that this needs to happen to some degree to protect against possible MITM = attacks or poorly implemented client libraries.

(C) =C2=A0 Client libraries SHOULD NOT use HTTP for any= secure data retrieval AND MUST filter any 'secure' links from an H= TTP response.

(D) =C2=A0 Client libraries MAY prov= ide fallback (HTTP->HTTPS or vice versa) as a configuration option, BUT = IF SO:

=C2=A0 =C2=A01. They MUST NOT fallback to HTTP when acc= essing secure information.
=C2=A0 =C2=A02. They MUST provide a me= thod of disabling fallback and specifying one protocol for the attempt(s).<= /div>
=C2=A0 =C2=A0

I think that covers all our use= cases, and takes care of (1: security) and (2: HTTP)... I think client com= plexity is a much better sacrifice to make here for several reasons:
<= div>
1. This only works if there are a lot of servers adopting WF

2. There will (hopefully) be MANY more servers than c= lient libraries

3. You don't have to be a WF n= erd to get a server going ... and (below)...

4. If you want to WRITE a client library, you're go= ing to be more technical and are more than likely going to read the spec. /= know a thing or two. And if you don't so what? (the servers can handle= it if they follow the spec)


I think those points make client complex= ity the clear compromise.=C2=A0
What do you guys think?
-Nick



On Fri, = Dec 14, 2012 at 1:26 PM, Goix Laurent Walter <laurentwa= lter.goix@telecomitalia.it> wrote:

(Re sendin= g including the google group)

=C2=A0

Da: Goix Laurent Walter
Inviato: venerd=C3=AC 14 dicembre 2012 10.43
A: 'Brad Fitzpatrick'; James M Snell


Cc: Paul E. Jones; webfinger@ietf.org
Oggetto: R: [webfinger] The HTTP/HTTPS Issue

<= /p>

=C2=A0

We=E2=80= =99re talking about clients but not applications. If clients are the implem= entation stacks of the spec, then they should give the whole flexibility of it. It is up to the app (representing the specific use-case) to decide = whether it needs security or not, and whether fallback may be acceptable or= not. If https-to-http fallback is performed at application level and not a= utomatically by the client then we may all converge.

=C2= =A0

Let me giv= e an example:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Use c= ase type 1 (=E2=80=9Cautoconfiguration/login=E2=80=9D): My website is provi= ding registration through openidconnect where the user can input his identity. Since this is what I can call autoconfiguration use case (in tha= t sense similar to discovering my oauth* endpoints) the app (my website) 1)= needs security and 2) knows pretty much the link rels it=E2=80=99s interes= ted in. it then issues the wf request over https only (optionally adding the explicit list of links). If that request= fails because the idp is not running over https, then my website (nor the = underlying wf client) does not fallback over http and tells the user that h= e cannot use that identity. Similarly if I want to autoconfigure my favorite app based on my identity and discov= er a bunch of endpoints my client should not fallback to http.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Use c= ase type 2 (=E2=80=9Cpublic info discovery=E2=80=9D): My favorite email app= has a plugin that resolves email addresses to show the user=E2=80=99s avat= ar. For each email address it issues a wf request and can decide whether to tr= y https first or directly http. Suppose it *asks the client to try https= first (may be the default)*. If the client fails for the same reason, = then *the app* can decide to try again over plain http and decide what to do with the provided infor= mation (eg accept it as avatar may be considered less sensitive).=

=C2= =A0

If we move= the security concern at app level then we need a mechanism to tell so, whi= ch is independent from the specific codebase and/or api signature. One possibility could be in the resource URI itself that we are= querying. We already said that any type of uri is supported with a specifi= c mention of acct:. What about introducing accts: for this purpose? Sips:, = wss:, https: are all examples of uris that explicitly call for tls. In that case if the app requests wf.dis= cover(=E2=80=9Caccts:user@example.com=E2=80=9D) the client would know that it has to= run over https. And it works for https: URIs as well and others.=

=C2= =A0

With this = artifact we can get rid of the fallback problem on the client side and stay= with the current text in saying that it must not try in parallel or in sequence (meant as =E2=80=9Cautomatically=E2=80=9D). But it= may be requested to do so by the app if after a failure over https (eg for= use case type 2) the app decides to go over plain http (using acct: URI).<= u>

=C2= =A0

What I wou= ld update is simply that server MUST expose over http and SHOULD over HTTPS= so that every case works with the above scenario, further clarifying (as shared with nick) that servers MUST NOT include 'secure= ' *href* (the ones whose scheme is ending with an =E2=80=98s=E2=80=99) = when answering over plain http AND clients MUST ignore those hrefs should t= hey be anyway included in the jrd retrieved over http (as an attack).

As paul po= inted out the only limitation is if my avatar is only exposed over an https= endpoint but not my wf endpoint but I don=E2=80=99t think this is a real issue=E2=80=A6

=C2= =A0

walter<= /u>

=C2=A0

Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per conto di Brad Fitzpatrick


Inviato: venerd=C3=AC 14 dicembre 2012 5.41
A: James M Snell
Cc: Paul E. Jones; webfinger@ietf.org
Oggetto: Re: [webfinger] The HTTP/HTTPS Issue

=

=C2=A0

On Thu, Dec 13, 2012 at 7:38 PM, James M = Snell <jasnell@gm= ail.com> wrote:

Failure of a request is perfectly acceptable. If the client n= eeds a secured connection and the server simply does not provide for it, th= e client simply won't use that server. Simple as that.

I don't want users or clients to need= to opt-in to security.

=C2=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=C2=A0is= =C2=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =C3=A8 necessario.


--f46d04083e0fc461e204d0d190c6-- From tbray@textuality.com Fri Dec 14 09:01:53 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450321F89B9 for ; Fri, 14 Dec 2012 09:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36otXyjsp8Qi for ; Fri, 14 Dec 2012 09:01:52 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A97F21F8907 for ; Fri, 14 Dec 2012 09:01:51 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3741661oag.31 for ; Fri, 14 Dec 2012 09:01:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aE1OWR7y/RdnPhRhbYJyvavQQ0s+0+o5UR68ZEg2xOg=; b=Z2i3POJa9xlFhsUhkdWNJ13NLHWMPzSs3+TwS8YAJtwCApuesBb8UgvfMZyHNbhyVG 2Ehkmt8jXJc8rlga1ixsBNj2YOV+Iz9pcQdZrM7zYYIs12HD2tOySWRdB4EVY5eBN8G9 5TJ1Vi6cvFubT355yUCJobkRmaJ7YXtQ9yULo4galGp7yh3QTV9zKK2NOc3zmdNftJrw EcX3KxxzaBNp4sUQ4LYC7QEPypMBCS+n9z1FP+M5Xn72bBfX7IvFTtmiXwHRkDf8S42f MDbLFUcMb0AS+3gDubFCrfiLYIwqCHFom2LUJVv9PyEIsZihVi0QWdvbVHvuvfWSfLzd lLlw== MIME-Version: 1.0 Received: by 10.182.52.105 with SMTP id s9mr5180686obo.25.1355504506781; Fri, 14 Dec 2012 09:01:46 -0800 (PST) Received: by 10.76.12.134 with HTTP; Fri, 14 Dec 2012 09:01:46 -0800 (PST) X-Originating-IP: [74.198.150.229] Received: by 10.76.12.134 with HTTP; Fri, 14 Dec 2012 09:01:46 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 09:01:46 -0800 Message-ID: From: Tim Bray To: Blaine Cook Content-Type: multipart/alternative; boundary=14dae93994299e413a04d0d2fc2f X-Gm-Message-State: ALoCoQnF9/Xn6nXmSz2zPj/UMuQvNAGdjLOSenSHbosSFk6VxqsNXAsz4HiD+9zqqYuc/HmUuKwl Cc: John Panzer , webfinger@googlegroups.com, James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:01:53 -0000 --14dae93994299e413a04d0d2fc2f Content-Type: text/plain; charset=ISO-8859-1 That's 3 different mechanisms that've been proposed for explicit client signaling that https-only is required. Which is the right goal IMHO. I was OK with Paul's latest no-fallback language too. On Dec 14, 2012 3:01 AM, "Blaine Cook" wrote: > So, all this has me thinking. And I'm going to propose something totally > against much of what I've been saying. > > Why not introduce a SECOND scheme, "accts" > > If you want a secure lookup, your request (from a client-library > perspective) will look like: > > webfinger.lookup('accts://bob@example.com') > > or just > webfinger.lookup('bob@example.com') > > which will default to "accts", since that's the best-most-secure option. > > If you want an unsecured lookup, use the "acct" scheme explicitly, so as > follows: > > webfinger.lookup('acct://bob@example.com') > > For applications where it doesn't matter, and you want to do a lookup and > get EITHER the secure or unsecured profile, it's trivial for library > authors to provide an explicit flag, like so: > > webfinger.lookup('bob@example.com', { allow_fallback: true }) > > OR it's easy enough for developers to do the lookup explicitly, like so: > > webfinger.lookup('accts://bob@example.com', function (err, result) { > if (result) { > // do something with the secure result > callback(err, result) > } else { > // c'mon, I just need a link to their public phonecam shots profile > webfinger.lookup('acct://bob@example.com', callback) > } > } > > Does this make sense? I think it errs on the side of the HTTPS-only crowd, > which I sympathise with even if I can't lend 100% support to. It also errs > on the side of client simplicity, and mirrors HTTP behaviours (but defaults > to secure instead of insecure, as with HTTP). > > Thoughts? Happy to try to write up some copy if this works for people. > > b. > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93994299e413a04d0d2fc2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

That's 3 different mechanisms that've been proposed = for explicit client signaling that https-only is required.=A0 Which is the = right goal IMHO. I was OK with Paul's latest no-fallback language too.<= /p>

On Dec 14, 2012 3:01 AM, "Blaine Cook"= <romeda@gmail.com> wrote:
So, all this has me thinking. And I'm going to propose something totall= y against much of what I've been saying.

Why not int= roduce a SECOND scheme, "accts"

If you w= ant a secure lookup, your request (from a client-library perspective) will = look like:

webfinger.lookup('accts://bob@example.com')

<= div>or just
webfinger.lookup('bob@example.com')

which will default to "accts", since that'= ;s the best-most-secure option.

If you want an uns= ecured lookup, use the "acct" scheme explicitly, so as follows:

webfinger.lookup('acct://bob@example.com')

For applications where it doesn't matter, and you want to do a looku= p and get EITHER the secure or unsecured profile, it's trivial for libr= ary authors to provide an explicit flag, like so:

webfinger.lookup('bob@example.com', { allow_fallback: true })

OR it's easy enough for developers to do the look= up explicitly, like so:

webfinger.lookup('accts://bob@example.com', function (err, result= ) {
=A0 if (result) {
=A0 =A0 // do something with the = secure result
=A0 =A0 callback(err, result)
=A0 } else {
=A0 =A0 // c= 'mon, I just need a link to their public phonecam shots profile
=A0 =A0 webfinger.lookup('acct://bob@example.com', callback)
=A0 }
}

Does this make sense? I thi= nk it errs on the side of the HTTPS-only crowd, which I sympathise with eve= n if I can't lend 100% support to. It also errs on the side of client s= implicity, and mirrors HTTP behaviours (but defaults to secure instead of i= nsecure, as with HTTP).

Thoughts? Happy to try to write up some copy if this wo= rks for people.

b.

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--14dae93994299e413a04d0d2fc2f-- From jasnell@gmail.com Fri Dec 14 09:05:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5999321F8925 for ; Fri, 14 Dec 2012 09:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dntbuNpV-T6L for ; Fri, 14 Dec 2012 09:05:33 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 506CA21F8907 for ; Fri, 14 Dec 2012 09:05:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6300231ieb.31 for ; Fri, 14 Dec 2012 09:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VakX1iaOFgt71iXZRED+K6wShw9f9RztAyK/24kGXj4=; b=rpx04o7uzlHZSvUl0c7UUn9/v+uyzUenCZTxV7nnemsBtDJiMQuMXz/M64w6tBWuLX 6863j4BscuOJg0zHyfnPJMumcukJ4TiOnCFthtWQMyf5Wo/B9Uj5tPRt6kQQ5L7WRSG0 t6hf0ioxgTFAOISV+jPy61u7BLVzXOPzK5wacqH/y9/fJmGcr8rAGALAD6RcACUotZgD zTOcT8wcdBr/x4Ch/7Zb5204V76eltuUi6sU25kdS0k9uxXTxxC0r/5mTRhBIOlp1oN+ PFzz95M6/gI2X1gAmyMJmcd5QawHl4Atvgm96AnVTH0ZyQ53z2zmLArEs3+Wb7hgmKhj xGDg== Received: by 10.42.41.144 with SMTP id p16mr5002034ice.39.1355504730686; Fri, 14 Dec 2012 09:05:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 09:05:09 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Fri, 14 Dec 2012 09:05:09 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=20cf301d4232f6c4c104d0d30964 Cc: John Panzer , "webfinger@googlegroups.com" , Goix Laurent Walter , Blaine Cook , "webfinger@ietf.org" , Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:05:35 -0000 --20cf301d4232f6c4c104d0d30964 Content-Type: text/plain; charset=UTF-8 Paul's latest language gives us the most flexibility in the long run without sacrificing security or trying to be too clever. With the proposed text, implementers who are strongly HTTPS-only are free to implement things that way. The market will decide from there. - James On Fri, Dec 14, 2012 at 9:01 AM, Tim Bray wrote: > That's 3 different mechanisms that've been proposed for explicit client > signaling that https-only is required. Which is the right goal IMHO. I was > OK with Paul's latest no-fallback language too. > On Dec 14, 2012 3:01 AM, "Blaine Cook" wrote: > >> So, all this has me thinking. And I'm going to propose something totally >> against much of what I've been saying. >> >> Why not introduce a SECOND scheme, "accts" >> >> If you want a secure lookup, your request (from a client-library >> perspective) will look like: >> >> webfinger.lookup('accts://bob@example.com') >> >> or just >> webfinger.lookup('bob@example.com') >> >> which will default to "accts", since that's the best-most-secure option. >> >> If you want an unsecured lookup, use the "acct" scheme explicitly, so as >> follows: >> >> webfinger.lookup('acct://bob@example.com') >> >> For applications where it doesn't matter, and you want to do a lookup and >> get EITHER the secure or unsecured profile, it's trivial for library >> authors to provide an explicit flag, like so: >> >> webfinger.lookup('bob@example.com', { allow_fallback: true }) >> >> OR it's easy enough for developers to do the lookup explicitly, like so: >> >> webfinger.lookup('accts://bob@example.com', function (err, result) { >> if (result) { >> // do something with the secure result >> callback(err, result) >> } else { >> // c'mon, I just need a link to their public phonecam shots profile >> webfinger.lookup('acct://bob@example.com', callback) >> } >> } >> >> Does this make sense? I think it errs on the side of the HTTPS-only >> crowd, which I sympathise with even if I can't lend 100% support to. It >> also errs on the side of client simplicity, and mirrors HTTP behaviours >> (but defaults to secure instead of insecure, as with HTTP). >> >> Thoughts? Happy to try to write up some copy if this works for people. >> >> b. >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> --20cf301d4232f6c4c104d0d30964 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul's latest language gives us t= he most flexibility in the long run without sacrificing security or trying = to be too clever. With the proposed text, implementers who are strongly HTT= PS-only are free to implement things that way. The market will decide from = there.

- James

<= br>
On Fri, Dec 14, 2012 at 9:01 AM, Tim Bray <tbray@textuality.com> wrote:

That's 3 different mechan= isms that've been proposed for explicit client signaling that https-onl= y is required.=C2=A0 Which is the right goal IMHO. I was OK with Paul's= latest no-fallback language too.

On Dec 14, 2012 3:01 AM, = "Blaine Cook" <romeda@gmail.com> wrote:
=
So, all this has me thinking. And I'm going to propose something totall= y against much of what I've been saying.

Why not int= roduce a SECOND scheme, "accts"

If you w= ant a secure lookup, your request (from a client-library perspective) will = look like:

webfinger.lookup('accts://bob@example.com')

<= div>or just
webfinger.lookup('bob@example.com')

which will default to "accts", since that'= ;s the best-most-secure option.

If you want an uns= ecured lookup, use the "acct" scheme explicitly, so as follows:

webfinger.lookup('acct://bob@example.com')

For applications where it doesn't matter, and you want to do a looku= p and get EITHER the secure or unsecured profile, it's trivial for libr= ary authors to provide an explicit flag, like so:

webfinger.lookup('bob@example.com', { allow_fallback: true })

OR it's easy enough for developers to do the look= up explicitly, like so:

webfinger.lookup('accts://bob@example.com', function (err, result= ) {
=C2=A0 if (result) {
=C2=A0 =C2=A0 // do something = with the secure result
=C2=A0 =C2=A0 callback(err, result)
=C2=A0 } else {
=C2= =A0 =C2=A0 // c'mon, I just need a link to their public phonecam shots = profile
=C2=A0 =C2=A0 webfinger.lookup('acct://bob@example.com', callback)<= /div>
=C2=A0 }
}

Does this make sense? I = think it errs on the side of the HTTPS-only crowd, which I sympathise with = even if I can't lend 100% support to. It also errs on the side of clien= t simplicity, and mirrors HTTP behaviours (but defaults to secure instead o= f insecure, as with HTTP).

Thoughts? Happy to try to write up some copy if this wo= rks for people.

b.

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


--20cf301d4232f6c4c104d0d30964-- From breno.demedeiros@gmail.com Fri Dec 14 09:14:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CA621F8992 for ; Fri, 14 Dec 2012 09:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq2YMQqOh1AD for ; Fri, 14 Dec 2012 09:14:04 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5457D21F89E8 for ; Fri, 14 Dec 2012 09:14:04 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4347744vcb.31 for ; Fri, 14 Dec 2012 09:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/7pHrwgn4SpiLbQ95dgTUuC9GHOb8kpGicy/ruk0R4I=; b=VUcmtzjSbfvOuhr4NL2sblUP1aDg9nIOFT98jkEhcAGkhcX3t4eWHNjyWAaG4ov42A 6/WoNtjPmQ/CUzq5ZAU+DLuwX3GguBcv4bo+UNGQFqQsBLE5WDBNyIWJeQyK12aVs0ab BM+kwgVL5nYtBjAQqFsHVeoT6YluxRcD85cs/AgjyRJnrAAF3EORqfL3JbW5lteI32iJ GXl1AzZefmHK5mTYglAW+ivRv2TMrwpX/qcaQMYw2hS/fF14tHkcAUSKcohz5z27aqM1 DQfhSNYD94bDCt25J/eNuDn7U4Eay36xXpeVzWr0RXcXtT0i5r93fXQrE7qXvX4HPiW4 3PGA== MIME-Version: 1.0 Received: by 10.52.67.133 with SMTP id n5mr8887020vdt.24.1355505243672; Fri, 14 Dec 2012 09:14:03 -0800 (PST) Received: by 10.58.11.130 with HTTP; Fri, 14 Dec 2012 09:14:03 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <082001cdd98b$0d8bf510$28a3df30$@packetizer.com> <091c01cdd9b6$4f1a4790$ed4ed6b0$@packetizer.com> <096a01cdd9c5$ad137290$073a57b0$@packetizer.com> Date: Fri, 14 Dec 2012 09:14:03 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: webfinger@ietf.org, James M Snell , Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:14:05 -0000 On Thu, Dec 13, 2012 at 10:49 PM, John Panzer wrote: > Why would TLS data marked with cache-control: public not be cacheable on = the > client? Or by trusted caching proxies? TLS data is cached on the client if served with cache directives, as long as cache is allowed. Even cache-control:private doesn't disable caching, simply restricts it to the client. If the client is a trusted caching proxy (a fairly common scenario) then that means that the cache is used across individual clients. > > On Dec 13, 2012 10:38 PM, "Paul E. Jones" wrote: >> >> TLS data isn=92t cached (except perhaps on the server side where there m= ight >> be a caching load balancer with the TLS certificates loaded). >> >> >> >> HTTP data can and may be cached. There is a small statement about that = in >> the spec, but at least one person suggested I should remove it since WF = is >> not changing the rules of how HTTP works and therefore they felt we don= =92t >> need to say anything about it. >> >> >> >> Paul >> >> >> >> From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On >> Behalf Of Breno >> Sent: Friday, December 14, 2012 12:00 AM >> To: Paul E. Jones >> Cc: webfinger@ietf.org; Goix Laurent Walter; Brad Fitzpatrick; >> webfinger@googlegroups.com; James M Snell >> Subject: RE: [webfinger] secure links with https rels >> >> >> >> Our messages crossed. >> >> There's still some complexity. How does that interact with caching? >> >> On Dec 13, 2012 8:48 PM, "Paul E. Jones" wrote: >> >> You=92re right that we cannot have all three. But, those who are still >> demanding HTTP as an option (and I=92m still looking to hear from those = folks) >> are not demanding security. >> >> >> >> So, what we=92re looking at presently are really two options for clients= : >> >> 1) Secure =96 HTTPS server >> >> 2) Non-Secure =96 HTTP server >> >> >> >> The client selects the transport based on its requirements. >> >> >> >> In the case that the client needs a secure reply, it uses HTTPS and will >> not try HTTP. If the server is not listening on HTTPS, then it fails. = And, >> that=92s exactly what you want to avoid a security issue. >> >> >> >> In the case that the client does not care about security of the response= , >> it queries using HTTP. The server might reply or it might redirect, but= the >> reply is still considered non-secure (since the HTTP reply could be hack= ed). >> >> >> >> In both cases, the client code is simple. There=92s no fall back logic = in >> the client. Either make a secure request or don=92t. >> >> >> >> Paul >> >> From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On >> Behalf Of Brad Fitzpatrick >> Sent: Thursday, December 13, 2012 11:37 PM >> To: Breno; webfinger@ietf.org >> Cc: James M Snell; webfinger@googlegroups.com; Goix Laurent Walter >> Subject: Re: [webfinger] secure links with https rels >> >> >> >> I agree with Breno, in all his points and previous emails. >> >> >> >> Again, I will repeat myself: we can have at most two of these three: >> >> >> >> 1) security >> >> 2) support HTTP servers >> >> 3) simple clients >> >> >> >> We don't get all 3. We get at most 2. >> >> >> >> I think everybody wants 1), so that leave us deciding between 2) and 3) = as >> our other feature. >> >> >> >> Which is it? HTTP servers or simple clients? >> >> >> >> >> >> On Thu, Dec 13, 2012 at 8:19 PM, Breno wrot= e: >> >> I will go further: >> >> Security is best served by simplicity: If HTTPS was only allowable >> protocol, that'd be the best approach security-wise. >> >> If simplicity is not available (and the decision to allow HTTPS and >> HTTP means it isn't), then a fully specified behavior, in all it's >> glorious complexity, is required for security. If that discourages the >> proliferation of low-quality >> I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client >> implementations, so much better for security. Put all eggs in one >> basket and watch that basket. >> >> The current compromise where we pretend that we can have simple client >> specification that allows for both complex behavior and secure >> operation is a smokescreen. Just add a disclaimer that WF is not >> intended to use in secure contexts, at least it'd be honest. >> >> >> On Thu, Dec 13, 2012 at 8:08 PM, Breno wrot= e: >> > Also, I reject the notion that WF standard should be simple for >> > clients. If we want WF to be widely deployed, we make it easier for >> > servers so that the information is ubiquitously deployed even by users >> > and companies that are unsophisticated. >> > >> > In contrast, standard-compliant WF clients are probably going to be >> > less common. Even if WF is not too complex, why wouldn't you use a >> > library if you want to have some guarantee like security? If you want >> > to simply write a few curl commands and mesh the data after applying >> > your homebrew parser, you neither care for standard compliance or >> > security, and you still can get things done because the underlying >> > data schema is simple. >> > >> > On Thu, Dec 13, 2012 at 8:00 PM, Breno >> > wrote: >> >> On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones >> >> wrote: >> >>> Brad, >> >>> >> >>> >> >>> >> >>> I really don=92t like the secure-rels idea. If a rel is secure or >> >>> should be >> >>> treated as secure, I can mark it as such on the server without >> >>> creating more >> >>> names and cluttering up the link relation name space with multiple >> >>> variants >> >>> of the same thing. >> >> >> >> As explained above, this does not address HTTP-fallback degrade >> >> attacks. >> >> >> >>> >> >>> >> >>> >> >>> There were several people opposed to the client fall back text due t= o >> >>> both >> >>> security concerns and client-side complexity. That was one of the >> >>> main >> >>> items we addressed with this latest proposal re-write. >> >> >> >> The proposal re-write does not seem to address any complexity. It >> >> simply removes guidance that would ensure implementations that can be >> >> 'plugged in' both in insecure and secure contexts. The likely result >> >> are simpler implementations that can't be used in secure contexts, >> >> even if they may make a claim to the contrary. >> >> >> >>> >> >>> >> >>> >> >>> I do realize the flakiness of the proposed solution. >> >> >> >> Yes. It's too flaky for the purposes of secure discovery. >> >> >> >>> Sometimes, the client >> >>> just does not work. You type in paulej@packetizer.com and it says >> >>> =93could >> >>> not find a thing=94, because the client only issued the query over >> >>> HTTPS. If >> >>> one needs security, I see on other way. However, if we=92re willing= to >> >>> go >> >>> back to the -07 text that has an allowance for fall back, the issue = is >> >>> addressed. In the -07 text, a client MAY re-issue a request using >> >>> HTTP. >> >>> >> >>> >> >>> >> >>> Paul >> >>> >> >>> >> >>> >> >>> From: Brad Fitzpatrick [mailto:bradfitz@google.com] >> >>> Sent: Thursday, December 13, 2012 6:15 PM >> >>> To: Paul E. Jones >> >>> Cc: Goix Laurent Walter; webfinger@googlegroups.com; James M Snell; >> >>> webfinger@ietf.org >> >>> >> >>> >> >>> Subject: Re: [webfinger] secure links with https rels >> >>> >> >>> >> >>> >> >>> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones >> >>> wrote: >> >>> >> >>> Walter, >> >>> >> >>> >> >>> >> >>> No, this will not work. People want to have secure content and what >> >>> is >> >>> secure might be determined by the server admin or user. One might >> >>> consider >> >>> his avatar should be served over HTTPS only. >> >>> >> >>> >> >>> >> >>> And people do not want to have to write clients that do fallback. >> >>> >> >>> >> >>> >> >>> I never saw any strong opposition against fallback. People disliked >> >>> the >> >>> extra complexity, but for quite awhile everybody assumed that fallba= ck >> >>> would >> >>> be involved, and I think it was considered acceptable. >> >>> >> >>> >> >>> >> >>> Who was strongly anti-fallback? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> We either have to do HTTPS only or we have to live with the fact tha= t >> >>> some >> >>> client requests are going to fail if a WF provider does not provide = WF >> >>> services over HTTPS. >> >>> >> >>> >> >>> >> >>> I strongly disagree that those are the only two options. >> >>> >> >>> >> >>> >> >>> But if you really believe that, I hope you realize that flakiness is >> >>> unacceptable, which leaves you with HTTPS-only. >> >>> >> >>> >> >>> >> >>> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy >> >>> with >> >>> HTTPS-only. >> >>> >> >>> >> >>> >> >>> So, >> >>> >> >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >> >>> >> >>> 2) Servers and clients MAY implement HTTP >> >>> >> >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be >> >>> treated as >> >>> secure since it allows for a MITM attack) >> >>> >> >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >> >>> >> >>> >> >>> >> >>> All works well, except for the case where you have an HTTPS-only >> >>> client. >> >>> But, I bet that will be the majority of clients, which will then dri= ve >> >>> the >> >>> majority of the servers to support HTTPS. >> >>> >> >>> >> >>> >> >>> This is a terrible cop-out. Flakiness in the spec is unacceptable. >> >>> >> >>> >> >>> >> >>> Still, it leaves the option on the table for some clients and serve= rs >> >>> to >> >>> use HTTP if they wish. >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Breno de Medeiros >> > >> > >> > >> > -- >> > Breno de Medeiros >> >> -- >> Breno de Medeiros >> >> --=20 Breno de Medeiros From ve7jtb@ve7jtb.com Fri Dec 14 09:16:55 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F278521F8A08 for ; Fri, 14 Dec 2012 09:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLJO13c+1zIY for ; Fri, 14 Dec 2012 09:16:54 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD11F21F8A00 for ; Fri, 14 Dec 2012 09:16:53 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so774867ghb.31 for ; Fri, 14 Dec 2012 09:16:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to:x-mailer :x-gm-message-state; bh=IG+679vFRKQ+TWRR5RJqi57OnqfNC4onJspEIo46WLw=; b=DlBabD16tPM72F68ggpZmA75Zob/ToGmCHcuN0GKqqJ8Wv0Z0+8yYx0XHJgDTC+ZRn gkUZxVIExl6ecgm1dDAwKNxyz+wYg9altbGujhBwHv7IjQC3rkTRTZx8sXp5VRP5hVpR CJIUiTIBBsHFJtWT1lqW5ngbl3feoDD+9n6hkpkRGgKvShs7ZYrzTQhCBdzYO8mp8mEj UV7eNqX48EtGI8DtphVrCUhnIXfQGHVvoablMFyNi3c3j2u1iysjz17Oy0vTkl68iWTc iIq7/VGrRVvDyB6vNinTHWIP6DS+ejGoxhbj+JtyyWmmFk0iDqp8/63hOhxLaNDv9Kr+ J4Rg== Received: by 10.236.91.195 with SMTP id h43mr6455113yhf.101.1355505413255; Fri, 14 Dec 2012 09:16:53 -0800 (PST) Received: from [192.168.1.39] (190-20-28-21.baf.movistar.cl. [190.20.28.21]) by mx.google.com with ESMTPS id i23sm2874682yhl.22.2012.12.14.09.16.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:16:51 -0800 (PST) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-BCE11536-1A3B-4CE5-9DB4-55BCFC1BB3F5; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <69 5443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> From: John Bradley Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Fri, 14 Dec 2012 07:52:04 -0200 To: "webfinger@googlegroups.com" X-Mailer: iPad Mail (10A523) X-Gm-Message-State: ALoCoQnEa+SrKTIAax17nL4vk4BXsTjs3gxsbbbZ+hIR1qzXpJpzQCyrgUzoPFCSISUbAGmcSiSg Cc: "webfinger@googlegroups.com" , "Paul E. Jones" , James M Snell , Goix Laurent Walter , Brad Fitzpatrick , "webfinger@ietf.org" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:16:55 -0000 --Apple-Mail-BCE11536-1A3B-4CE5-9DB4-55BCFC1BB3F5 Content-Type: multipart/alternative; boundary=Apple-Mail-46FBB749-1FB9-4ADB-BDC1-7E134F5DF120 Content-Transfer-Encoding: 7bit --Apple-Mail-46FBB749-1FB9-4ADB-BDC1-7E134F5DF120 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes silent fallback to http is unacceptable.=20 Sent from my iPad On 2012-12-13, at 9:17 PM, Tim Bray wrote: > On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick wr= ote: >> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wr= ote: >>=20 >> I never saw any strong opposition against fallback. People disliked the e= xtra complexity, but for quite awhile everybody assumed that fallback would b= e involved, and I think it was considered acceptable. >>=20 >> Who was strongly anti-fallback?'''' >=20 > Um, maybe me. What is unacceptable for some applications is if I tell the= client =E2=80=9CFetch https://example.com/.well-known/whatever=E2=80=9D and= for some reason it silently falls back to HTTP. -T >=20 > =20 >>=20 >>=20 >>> We either have to do HTTPS only or we have to live with the fact that so= me client requests are going to fail if a WF provider does not provide WF se= rvices over HTTPS. >>>=20 >>=20 >> I strongly disagree that those are the only two options. >>=20 >> But if you really believe that, I hope you realize that flakiness is unac= ceptable, which leaves you with HTTPS-only. >>=20 >> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with H= TTPS-only. >> =20 >>> So, >>>=20 >>> 1) Servers SHOULD implement HTTPS and clients SHOULD use HTTPS >>>=20 >>> 2) Servers and clients MAY implement HTTP >>>=20 >>> 3) Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treate= d as secure since it allows for a MITM attack) >>>=20 >>> 4) Servers MUST NOT redirect from HTTPS to HTTP >>>=20 >>> =20 >>>=20 >>> All works well, except for the case where you have an HTTPS-only client.= But, I bet that will be the majority of clients, which will then drive the= majority of the servers to support HTTPS. >>>=20 >>=20 >> This is a terrible cop-out. Flakiness in the spec is unacceptable. >> =20 >>> Still, it leaves the option on the table for some clients and servers t= o use HTTP if they wish. >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >=20 --Apple-Mail-46FBB749-1FB9-4ADB-BDC1-7E134F5DF120 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes silent fallback to http is unaccep= table. 

Sent from my iPad

On 2012-12-13, at 9:17 P= M, Tim Bray <tbray@textuality.com= > wrote:

On Thu, Dec 13, 2= 012 at 3:15 PM, Brad Fitzpatrick <bradfitz@google.com> wrote= :
On Thu,= Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com> wrote:

I never saw any strong opposition agains= t fallback.  People disliked the extra complexity, but for quite awhile= everybody assumed that fallback would be involved, and I think it was consi= dered acceptable.

Who was strongly anti-fallback?''''

Um, maybe me.  What is unacceptable for some applica= tions is if I tell the client =E2=80=9CFetch https://example.com/.well-known/whatever=E2=80=9D a= nd for some reason it silently falls back to HTTP.   -T

 

<= /div>

We either have to do HTTPS only or<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:= 11pt"> we have to live with the fact that some client requests are going to f= ail if a WF provider does not provide WF services over HTTPS.


I strongly disagree that those are th= e only two options.

But if you really believe that,= I hope you realize that flakiness is unacceptable, which leaves you with HT= TPS-only.

If the HTTPS-for-some-rels proposal still isn't clear, I= 'd be happy with HTTPS-only.
 

 So,

1)      <= u>Servers SHOULD implement HTTPS and clients S= HOULD use HTTPS

2)      <= u>Servers and clients MAY implement HTTP

3)      <= u>Servers MAY redirect from HTTP to HTTPS (thi= s MUST NOT be treated as secure since it allows for a MITM attack)=

4)      <= u>Servers MUST NOT redirect from HTTPS to HTTP=

 =

All works well, except f= or the case where you have an HTTPS-only client.  But, I bet that will b= e the majority of clients, which will then drive the majority of the servers= to support HTTPS.


This is a terrible cop-out.  Fla= kiness in the spec is unacceptable.
 

 Still, it leaves the option= on the table for some clients and servers to use HTTP if they wish.<= /p>




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


= --Apple-Mail-46FBB749-1FB9-4ADB-BDC1-7E134F5DF120-- --Apple-Mail-BCE11536-1A3B-4CE5-9DB4-55BCFC1BB3F5 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTIxNDA5NTIwNVowIwYJKoZIhvcNAQkEMRYEFMzO 2qiCOzAQn3O0e+0cRRWt3ZgVMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAHZ6AfEhmgmM3mf2EVaezz2l+doE68tcTphY Pwzeq7/a21nQ7kooBlroEIba4nlBco5dJ6qO3gLMsbgr86dQND3h78rmmBNgUyQk7Wihynd9DQxC jLSZPk8XeC8mLPY8KSdtSlG1wKaqCeSSPM94dcsrXq2Z6YmlHM3iBbGgmmE68BXa58UIXf+2LSu9 3zzAr98JpqjEqfOttVz/uQMnaxO0qxVXO3EX496j+ymL+3iDk/kAKnKmdSV1VW9JF0YA9u7cF6H+ HbFnbb6h3sVeZWDg12Yv3Nl+EJeCgd6W5H+qICIJo2pKgzX8SU+wpiC/SAE0lW0u7tUFEXJkyYkM IGkAAAAAAAA= --Apple-Mail-BCE11536-1A3B-4CE5-9DB4-55BCFC1BB3F5-- From dick.hardt@gmail.com Fri Dec 14 09:38:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ADA21F84CE for ; Fri, 14 Dec 2012 09:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfDpMBS7whbK for ; Fri, 14 Dec 2012 09:38:04 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD17721F8417 for ; Fri, 14 Dec 2012 09:38:03 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1479268dae.31 for ; Fri, 14 Dec 2012 09:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=g1FsbvvbwEDdsYUxFQ6SXUuhzKfHTFiyckHan+7qRbw=; b=m8+8NdyAKLRq0z6RXhvMjp/fOVHEbQT7BJ8sjB0ARIYbPXne5clz0BYiEpcr+7vj/G OYzeLTWzHKFhEFnrNBpHckx4taNzNikqBi0Qzz4yWQhGtx8lcgNWA1q5AXf3N5mHZmPF dfyl8DdXDbxS+eV1WAJuyOVvBXdX4IyKPanszbWD23cv7iZ+4dXNtgaTu+0PmLrPtEsa FVPIfD2ztZ8Aavc+RFLyXHjCLQp2Dal7vBB+NG2dDVKwjMpTrjtiP27VkyPJGX9Al4Zr zPnzC05Dlju8yaAuwthszWqFcAfJ/N3MRzEp1f8rVpEy0G8UApM5bwLIAZsvVlQxjct5 0DuA== Received: by 10.66.77.200 with SMTP id u8mr17670533paw.43.1355506676109; Fri, 14 Dec 2012 09:37:56 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ni8sm3249779pbc.70.2012.12.14.09.37.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:37:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A21DD8CD-3B5D-4383-8067-DC274B5E42FD" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Fri, 14 Dec 2012 09:36:38 -0800 Message-Id: <11AF44B4-10FE-47AF-87E9-3975D2016CB0@gmail.com> References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> To: Goix Laurent Walter X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" , Brad Fitzpatrick , James M Snell , "Paul E. Jones" Subject: Re: [webfinger] R: The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:38:05 -0000 --Apple-Mail=_A21DD8CD-3B5D-4383-8067-DC274B5E42FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think that a good spec enables applications to implement the specs = directly, so there is no difference between clients and apps. OAuth 2.0 = does not need a library to implement the client. -- Dick On Dec 14, 2012, at 1:42 AM, Goix Laurent Walter = wrote: > We=92re talking about clients but not applications. If clients are the = implementation stacks of the spec, then they should give the whole = flexibility of it. It is up to the app (representing the specific = use-case) to decide whether it needs security or not, and whether = fallback may be acceptable or not. If https-to-http fallback is = performed at application level and not automatically by the client then = we may all converge. > =20 > Let me give an example: > - Use case type 1 (=93autoconfiguration/login=94): My website = is providing registration through openidconnect where the user can input = his identity. Since this is what I can call autoconfiguration use case = (in that sense similar to discovering my oauth* endpoints) the app (my = website) 1) needs security and 2) knows pretty much the link rels it=92s = interested in. it then issues the wf request over https only (optionally = adding the explicit list of links). If that request fails because the = idp is not running over https, then my website (nor the underlying wf = client) does not fallback over http and tells the user that he cannot = use that identity. Similarly if I want to autoconfigure my favorite app = based on my identity and discover a bunch of endpoints my client should = not fallback to http. > - Use case type 2 (=93public info discovery=94): My favorite = email app has a plugin that resolves email addresses to show the user=92s = avatar. For each email address it issues a wf request and can decide = whether to try https first or directly http. Suppose it *asks the client = to try https first (may be the default)*. If the client fails for the = same reason, then *the app* can decide to try again over plain http and = decide what to do with the provided information (eg accept it as avatar = may be considered less sensitive). > =20 > If we move the security concern at app level then we need a mechanism = to tell so, which is independent from the specific codebase and/or api = signature. One possibility could be in the resource URI itself that we = are querying. We already said that any type of uri is supported with a = specific mention of acct:. What about introducing accts: for this = purpose? Sips:, wss:, https: are all examples of uris that explicitly = call for tls. In that case if the app requests = wf.discover(=93accts:user@example.com=94) the client would know that it = has to run over https. And it works for https: URIs as well and others. > =20 > With this artifact we can get rid of the fallback problem on the = client side and stay with the current text in saying that it must not = try in parallel or in sequence (meant as =93automatically=94). But it = may be requested to do so by the app if after a failure over https (eg = for use case type 2) the app decides to go over plain http (using acct: = URI). > =20 > What I would update is simply that server MUST expose over http and = SHOULD over HTTPS so that every case works with the above scenario, = further clarifying (as shared with nick) that servers MUST NOT include = 'secure' *href* (the ones whose scheme is ending with an =91s=92) when = answering over plain http AND clients MUST ignore those hrefs should = they be anyway included in the jrd retrieved over http (as an attack). > As paul pointed out the only limitation is if my avatar is only = exposed over an https endpoint but not my wf endpoint but I don=92t = think this is a real issue=85 > =20 > walter > =20 > Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per = conto di Brad Fitzpatrick > Inviato: venerd=EC 14 dicembre 2012 5.41 > A: James M Snell > Cc: Paul E. Jones; webfinger@ietf.org > Oggetto: Re: [webfinger] The HTTP/HTTPS Issue > =20 > On Thu, Dec 13, 2012 at 7:38 PM, James M Snell = wrote: > Failure of a request is perfectly acceptable. If the client needs a = secured connection and the server simply does not provide for it, the = client simply won't use that server. Simple as that. >=20 > I don't want users or clients to need to opt-in to security. > =20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario. >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_A21DD8CD-3B5D-4383-8067-DC274B5E42FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think that a good spec = enables applications to implement the specs directly, so there is no = difference between clients and apps. OAuth 2.0 does not need a library = to implement the client.

-- = Dick

On Dec 14, 2012, at 1:42 AM, Goix Laurent = Walter <laurentwalter.goix@tel= ecomitalia.it> wrote:

We=92re talking about clients but = not applications. If clients are the implementation stacks of the spec, = then they should give the whole flexibility of it. It is up to the app = (representing the specific use-case) to decide whether it needs security = or not, and whether fallback may be acceptable or not. If https-to-http = fallback is performed at application level and not automatically by the = client then we may all converge.
Let me give an example:
- Use case type 1 = (=93autoconfiguration/login=94): My website is providing registration = through openidconnect where the user can input his identity. Since this = is what I can call autoconfiguration use case (in that sense similar to = discovering my oauth* endpoints) the app (my website) 1) needs security = and 2) knows pretty much the link rels it=92s interested in. it then = issues the wf request over https only (optionally adding the explicit = list of links). If that request fails because the idp is not running = over https, then my website (nor the underlying wf client) does not = fallback over http and tells the user that he cannot use that identity. = Similarly if I want to autoconfigure my favorite app based on my = identity and discover a bunch of endpoints my client should not fallback = to http.
 Use case type 2 (=93public info = discovery=94): My favorite email app has a plugin that resolves email = addresses to show the user=92s avatar. For each email address it issues = a wf request and can decide whether to try https first or directly http. = Suppose it *asks the client to try https first (may be the = default)*. If the client fails for the same reason, then *the = app* can decide to try again over plain http and decide what to do = with the provided information (eg accept it as avatar may be considered = less sensitive).
 
If we move = the security concern at app level then we need a mechanism to tell so, = which is independent from the specific codebase and/or api signature. = One possibility could be in the resource URI itself that we are = querying. We already said that any type of uri is supported with a = specific mention of acct:. What about introducing accts: for this = purpose? Sips:, wss:, https: are all examples of uris that explicitly = call for tls. In that case if the app requests = wf.discover(=93accts:user@example.com=94) the client = would know that it has to run over https. And it works for https: URIs = as well and others.
 
With this = artifact we can get rid of the fallback problem on the client side and = stay with the current text in saying that it must not try in parallel or = in sequence (meant as =93automatically=94). But it may be requested to = do so by the app if after a failure over https (eg for use case type 2) = the app decides to go over plain http (using acct: = URI).
 
What I = would update is simply that server MUST expose over http and SHOULD over = HTTPS so that every case works with the above scenario, further = clarifying (as shared with nick) that servers MUST NOT include 'secure' = *href* (the ones whose scheme is ending with an =91s=92) when answering = over plain http AND clients MUST ignore those hrefs should they be = anyway included in the jrd retrieved over http (as an = attack).
As paul pointed out the only = limitation is if my avatar is only exposed over an https endpoint but = not my wf endpoint but I don=92t think this is a real = issue=85
 
 
 webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per conto di Brad = Fitzpatrick
Inviato: venerd=EC 14 dicembre 2012 = 5.41
A: James = M Snell
Cc: Paul E. Jones;  Re: [webfinger] The = HTTP/HTTPS Issue

Failure of a = request is perfectly acceptable. If the client needs a secured = connection and the server simply does not provide for it, the client = simply won't use that server. Simple as = that.

I = don't want users or clients to need to opt-in to = security.
Questo messaggio e i suoi allegati sono = indirizzati esclusivamente alle persone indicate. La diffusione, copia o = qualsiasi altra azione derivante dalla conoscenza di queste informazioni = sono rigorosamente vietate. Qualora abbiate ricevuto questo documento = per errore siete cortesemente pregati di darne immediata comunicazione = al mittente e di provvedere alla sua distruzione, = Grazie.

This e-mail and any = attachments is confidential and may = contain privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, = Thanks.

<logo = Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

&= lt;logo = Ambiente_foglia2.jpg>___________________________________________= ____
webfinger mailing list
, James M Snell , "Paul E. Jones" , Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] R: The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:49:00 -0000 --f46d0408915948183404d0d3a5a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2012 at 6:36 PM, Dick Hardt wrote: > I think that a good spec enables applications to implement the specs > directly, so there is no difference between clients and apps. OAuth 2.0 > does not need a library to implement the client. > > You don't *need* a client here as well, it's just an HTTP/S request (one OR two if you really want to cover your bases). That's all. In this case, the client library is to make things as simple as possible, not to make things possible at all. > -- Dick > > On Dec 14, 2012, at 1:42 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > > We=E2=80=99re talking about clients but not applications. If clients are= the > implementation stacks of the spec, then they should give the whole > flexibility of it. It is up to the app (representing the specific use-cas= e) > to decide whether it needs security or not, and whether fallback may be > acceptable or not. If https-to-http fallback is performed at application > level and not automatically by the client then we may all converge.**** > > Let me give an example:**** > - Use case type 1 (=E2=80=9Cautoconfiguration/login=E2=80=9D): M= y website is > providing registration through openidconnect where the user can input his > identity. Since this is what I can call autoconfiguration use case (in th= at > sense similar to discovering my oauth* endpoints) the app (my website) 1) > needs security and 2) knows pretty much the link rels it=E2=80=99s intere= sted in. > it then issues the wf request over https only (optionally adding the > explicit list of links). If that request fails because the idp is not > running over https, then my website (nor the underlying wf client) does n= ot > fallback over http and tells the user that he cannot use that identity. > Similarly if I want to autoconfigure my favorite app based on my identity > and discover a bunch of endpoints my client should not fallback to http.*= * > ** > - Use case type 2 (=E2=80=9Cpublic info discovery=E2=80=9D): My = favorite email > app has a plugin that resolves email addresses to show the user=E2=80=99s= avatar. > For each email address it issues a wf request and can decide whether to t= ry > https first or directly http. Suppose it **asks the client to try https > first (may be the default)**. If the client fails for the same reason, > then **the app** can decide to try again over plain http and decide what > to do with the provided information (eg accept it as avatar may be > considered less sensitive).**** > > If we move the security concern at app level then we need a mechanism to > tell so, which is independent from the specific codebase and/or api > signature. One possibility could be in the resource URI itself that we ar= e > querying. We already said that any type of uri is supported with a specif= ic > mention of acct:. What about introducing accts: for this purpose? Sips:, > wss:, https: are all examples of uris that explicitly call for tls. In th= at > case if the app requests wf.discover(=E2=80=9Caccts:user@example.com=E2= =80=9D) the client > would know that it has to run over https. And it works for https: URIs as > well and others.**** > > With this artifact we can get rid of the fallback problem on the client > side and stay with the current text in saying that it must not try in > parallel or in sequence (meant as =E2=80=9Cautomatically=E2=80=9D). But i= t may be requested > to do so by the app if after a failure over https (eg for use case type 2= ) > the app decides to go over plain http (using acct: URI).**** > > What I would update is simply that server MUST expose over http and SHOUL= D > over HTTPS so that every case works with the above scenario, further > clarifying (as shared with nick) that servers MUST NOT include 'secure' > *href* (the ones whose scheme is ending with an =E2=80=98s=E2=80=99) when= answering over > plain http AND clients MUST ignore those hrefs should they be anyway > included in the jrd retrieved over http (as an attack).**** > As paul pointed out the only limitation is if my avatar is only exposed > over an https endpoint but not my wf endpoint but I don=E2=80=99t think t= his is a > real issue=E2=80=A6**** > > walter**** > > *Da:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *Per > conto di *Brad Fitzpatrick > *Inviato:* venerd=C3=AC 14 dicembre 2012 5.41 > *A:* James M Snell > *Cc:* Paul E. Jones; webfinger@ietf.org > *Oggetto:* Re: [webfinger] The HTTP/HTTPS Issue**** > ** ** > On Thu, Dec 13, 2012 at 7:38 PM, James M Snell wrote:= * > *** > > Failure of a request is perfectly acceptable. If the client needs a > secured connection and the server simply does not provide for it, the > client simply won't use that server. Simple as that.**** > > I don't want users or clients to need to opt-in to security.**** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *Rispetta l'ambiente. Non stampare questa mail > se non =C3=A8 necessario.* > > ______________________________________________= _ > > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --f46d0408915948183404d0d3a5a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 14, 2012 at 6:36 PM, Dick Ha= rdt <dick.hardt@gmail.com> wrote:
I think that a good spec enables applic= ations to implement the specs directly, so there is no difference between c= lients and apps. OAuth 2.0 does not need a library to implement the client.=


You don't *need* a cli= ent here as well, it's just an HTTP/S request (one OR two if you really= want to cover your bases). That's all. In this case, the client librar= y is to make things as simple as possible, not to make things possible at a= ll.


=C2=A0
-- Dick
On Dec 14, 2012, at 1:42 AM, Goix Laurent Walte= r <laurentwalter.goix@telecomitalia.it> wrote:

W= e=E2=80=99re talking about clients but not applications. If clients are the= implementation stacks of the spec, then they should give the whole flexibi= lity of it. It is up to the app (representing the specific use-case) to dec= ide whether it needs security or not, and whether fallback may be acceptabl= e or not. If https-to-http fallback is performed at application level and n= ot automatically by the client then we may all converge.
=C2=A0
Let me give an example:
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Use case = type 1 (=E2=80=9Cautoconfiguration/login=E2=80=9D): My website is providing= registration through openidconnect where the user can input his identity. = Since this is what I can call autoconfiguration use case (in that sense sim= ilar to discovering my oauth* endpoints) the app (my website) 1) needs secu= rity and 2) knows pretty much the link rels it=E2=80=99s interested in. it = then issues the wf request over https only (optionally adding the explicit = list of links). If that request fails because the idp is not running over h= ttps, then my website (nor the underlying wf client) does not fallback over= http and tells the user that he cannot use that identity. Similarly if I w= ant to autoconfigure my favorite app based on my identity and discover a bu= nch of endpoints my client should not fallback to http.
-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Use case type 2 (=E2=80=9Cpublic info discovery=E2=80= =9D): My favorite email app has a plugin that resolves email addresses to s= how the user=E2=80=99s avatar. For each email address it issues a wf reques= t and can decide whether to try https first or directly http. Suppose it *<= b>asks the client to try https first (may be the default)*. If the clie= nt fails for the same reason, then *the app* can decide to try again= over plain http and decide what to do with the provided information (eg ac= cept it as avatar may be considered less sensitive).
=C2=A0
If we move the security concern at app level then we= need a mechanism to tell so, which is independent from the specific codeba= se and/or api signature. One possibility could be in the resource URI itsel= f that we are querying. We already said that any type of uri is supported w= ith a specific mention of acct:. What about introducing accts: for this pur= pose? Sips:, wss:, https: are all examples of uris that explicitly call for= tls. In that case if the app requests wf.discover(=E2=80=9Caccts:user@example.com=E2=80=9D) the client would know that it = has to run over https. And it works for https: URIs as well and others.<= /u>
=C2=A0
With this artifact we can get rid of the fallback pr= oblem on the client side and stay with the current text in saying that it m= ust not try in parallel or in sequence (meant as =E2=80=9Cautomatically=E2= =80=9D). But it may be requested to do so by the app if after a failure ove= r https (eg for use case type 2) the app decides to go over plain http (usi= ng acct: URI).
=C2=A0
What I would update is simply that server MUST expos= e over http and SHOULD over HTTPS so that every case works with the above s= cenario, further clarifying (as shared with nick) that servers MUST NOT inc= lude 'secure' *href* (the ones whose scheme is ending with an =E2= =80=98s=E2=80=99) when answering over plain http AND clients MUST ignore th= ose hrefs should they be anyway included in the jrd retrieved over http (as= an attack).
As paul pointed out the only = limitation is if my avatar is only exposed over an https endpoint but not m= y wf endpoint but I don=E2=80=99t think this is a real issue=E2=80=A6
=C2=A0
walter
=C2=A0
Da:=C2=A0<= /span>webfinger-bounces@ietf.org<= span>=C2=A0[mailto:w= ebfinger-bounces@ietf.org]=C2=A0<= /span>Per conto di=C2=A0Brad Fitzpatrick
Inviato:=C2=A0venerd=C3=AC 14 dicembre 2012 5.41
= A:=C2=A0James M Snell
Cc:=C2=A0Paul= E. Jones;=C2=A0webfinger@ietf.o= rg
Oggetto:=C2=A0Re: [webfinger] The HTTP/HTTPS Issue
=C2=A0
On Thu, Dec 13, 2012 at 7:38 PM, James M Snell <jasnell@gmail.com> wrote:

Failure of a re= quest is perfectly acceptable. If the client needs a secured connection and= the server simply does not provide for it, the client simply won't use= that server. Simple as that.

I don't want users or clients to need to opt-= in to security.
=C2=A0
<= /div>
Questo messaggio e i suoi allegati sono indirizzati esclusivame= nte alle persone indicate. La diffusione, copia o qualsiasi altra azione de= rivante dalla conoscenza di queste informazioni sono rigorosamente vietate.= Qualora abbiate ricevuto questo documento per errore siete cortesemente pr= egati di darne immediata comunicazione al mittente e di provvedere alla sua= distruzione, Grazie.

This e-mail and any attachments=C2=A0is=C2=A0confidential and may contain privilege= d information intended for the addressee(s) only. Dissemination, copying, p= rinting or use by anybody else is unauthorised. If you are not the intended= recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

&l= t;logo Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare= questa mail se non =C3=A8 necessario.

<logo Ambiente_foglia2.jpg>= _______________________________________________
webfinger mailing list
webfinger@ietf.org=
https://www.ietf.org/ma= ilman/listinfo/webfinger


_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--f46d0408915948183404d0d3a5a8-- From perpetual-tripper@wwelves.org Fri Dec 14 10:31:41 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84321F8AFB for ; Fri, 14 Dec 2012 10:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUGvJ+qkczcK for ; Fri, 14 Dec 2012 10:31:40 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFC21F8AE1 for ; Fri, 14 Dec 2012 10:31:40 -0800 (PST) X-Originating-IP: 217.70.178.149 Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 7161DA807D; Fri, 14 Dec 2012 19:31:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id s3ybRmnC7v90; Fri, 14 Dec 2012 19:31:28 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 0BFFDA8093; Fri, 14 Dec 2012 19:31:28 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Paul E. Jones In-reply-to: <081e01cdd989$66344160$329cc420$@packetizer.com> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> Date: Fri, 14 Dec 2012 18:31:27 +0000 Message-Id: <1355509733-sup-5469@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:31:41 -0000 Excerpts from Paul E. Jones's message of 2012-12-13 23:27:20 +0000: > WebFinger servers operating on HTTP MAY redirect a client using > an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. > Likewise, WebFinger servers operating on HTTPS MAY redirect a > client to another HTTPS URI, but MUST NOT redirect a client to an > HTTP URI. Further, clients MUST NOT follow a redirection from an > HTTPS URI to an HTTP URI, but SHOULD automatically follow all > other server redirects. i see in many places this topic of HTTP request redirected to HTTPS and m= ust say that i don't understand for which scenario we need it? From nick@silverbucket.net Fri Dec 14 10:37:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62621F8A7C for ; Fri, 14 Dec 2012 10:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WZVw1OsgnKf for ; Fri, 14 Dec 2012 10:37:02 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54B2221F8A75 for ; Fri, 14 Dec 2012 10:37:02 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3059260lbk.31 for ; Fri, 14 Dec 2012 10:37:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=CknSy5uiex4pQfBgemU8v1//4StLKPst9hil9zABnak=; b=iUGm53s2GCQ/feUxuOYt2woESWKvlrdkV8pXsc9gR7ZEPod1f63k5wEzUoZASiJnXX 3UNe9fN/E8mQe1aribDkDoaQ7WsCgFCgyqYMLAwXOFDRlA2q7WHx+B0v+zJB0MwCW/2h tkQ1j3wu2IjIfDMFV1pNPkaNvKipZmbo8GfXc5cdvOBqoa5D3vhxbKtX69O0M9RgCyUr KiL79X2N5lztO8wj3ZjMwG4VpQtacKUFOhHZeD0MgobkHUl29ibVvoX89gP2l1SBWBZp T9BtowcuBhCE9/Wl6HBKgcVvDO0YQIkOSHA1ooYFK6d1Oo1TgOQlyBwdnnXdU56uv93l AI1A== Received: by 10.152.129.197 with SMTP id ny5mr3531172lab.43.1355510221290; Fri, 14 Dec 2012 10:37:01 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id p5sm2172397lbh.2.2012.12.14.10.37.00 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 10:37:00 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3059247lbk.31 for ; Fri, 14 Dec 2012 10:37:00 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr2702932lbd.54.1355510219997; Fri, 14 Dec 2012 10:36:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Fri, 14 Dec 2012 10:36:29 -0800 (PST) In-Reply-To: <1355509733-sup-5469@heahdk.net> References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> <1355509733-sup-5469@heahdk.net> From: Nick Jennings Date: Fri, 14 Dec 2012 19:36:29 +0100 Message-ID: To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmmzH66RFl5hSaycFB/Hd4WzO42wexgqjhAyneMCD41ok6hAIEQjFZeTVqmSk3vGTKlYP8Q Cc: "Paul E. Jones" , webfinger Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:37:03 -0000 On Fri, Dec 14, 2012 at 7:31 PM, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Paul E. Jones's message of 2012-12-13 23:27:20 +0000: > >> WebFinger servers operating on HTTP MAY redirect a client using >> an _appropriate_ HTTP status code to another HTTP or an HTTPS URI. >> Likewise, WebFinger servers operating on HTTPS MAY redirect a >> client to another HTTPS URI, but MUST NOT redirect a client to an >> HTTP URI. Further, clients MUST NOT follow a redirection from an >> HTTPS URI to an HTTP URI, but SHOULD automatically follow all >> other server redirects. > i see in many places this topic of HTTP request redirected to HTTPS and m= ust say that i don't understand for which scenario we need it? I agree, I would prefer this not to happen. HTTP and HTTPS shouldn't fallback (from the server perspective). I added it in my suggestion because it seemed like others (most notably Paul) wanted it. > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From mmn@hethane.se Fri Dec 14 12:08:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8921F84F3 for ; Fri, 14 Dec 2012 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2DhpY1bwz-q for ; Fri, 14 Dec 2012 12:08:28 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id C519621F84EE for ; Fri, 14 Dec 2012 12:08:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Dec 2012 21:08:20 +0100 From: Mikael Nordfeldth To: In-Reply-To: References: <089601cdd9a6$5d8358e0$188a0aa0$@packetizer.com> <08f001cdd9ac$2ec4bca0$8c4e35e0$@packetizer.com> Message-ID: <1c1352f8d611fa32bcff7fe51ad6f182@hethane.se> X-Sender: mmn@hethane.se User-Agent: Roundcube Webmail/0.7.1 Subject: Re: [webfinger] The HTTP/HTTPS Issue X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:08:29 -0000 14.12.2012 16:19 skrev Nick Jennings: > (A) Servers MUST answer on HTTP and SHOULD answer on HTTPS. A > server MAY > upgrade an HTTP request to HTTPS if they want all of their data to be > retrieved via HTTPS. I just wish to point out that it's entirely legitimate NOT to listen to HTTP at all. There's no reason an HTTPS server must also serve HTTP. So there's no point in requiring the use of either protocol. The chosen protocol should be up to the client (purpose) and the situation (content). And the worst case scenario, which is far from applicable in every situation, is a two-round trip. But as a Webfinger client, I can have a personal policy of verified-HTTPS-only (which I believe many of the "+1 HTTPS-only" people will have) and not be bothered at all with the non-HTTPS implementations out there. Not forcing any combination - and leaving the protocol to the client - is the best, most humble way of avoiding issues caused by unfortunate implicit encryption that HTTPS is. (and I think discussing a possible future of STARTTLS over HTTP is pretty much off-topic here). -- Mikael Nordfeldth http://blog.mmn-o.se/ mmn@hethane.se +46705657637 From melvincarvalho@gmail.com Fri Dec 14 04:59:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4D21F84DA for ; Fri, 14 Dec 2012 04:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncJKT9Uzr6hZ for ; Fri, 14 Dec 2012 04:59:07 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1A21F8630 for ; Fri, 14 Dec 2012 04:59:06 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so5841034ieb.31 for ; Fri, 14 Dec 2012 04:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tA7j9ISOoNKPmfH/LftolIryZYZ2lKyuzv49jTvoSco=; b=qIcethIr0Gc7kPSak5HgKe0TH1cW8oGYYcrlY3B+7CDNu8Hp7GB0N4FUs0gCuOGH1C YtHWoaPafJG8zZ2w8kzzZDmXlWqBa5Ke+gZgCt56zNhcy9/PJqlv0f0AoN4H4yGKap/h LvvwS1xAsG6DINSQVrcEVWFK/7fkRQ/2BI8aTt3/DKo2sS+AG98fPyH9QEXWQ8/zDIeo 4ErXAP94pmuF6y9vmfpI/kmNjg6dlwZTj2ynXUWpf5hQoIJ64rWRhhVEB5CNUMBGWHbl hsHSa2oRdPhwxeerzv0lc3mIOfJvZuVBmCL8LhV5YLkWLMOah/v5apKpxy6gcWbtlvpi 0/7w== MIME-Version: 1.0 Received: by 10.50.179.99 with SMTP id df3mr1437306igc.20.1355489946395; Fri, 14 Dec 2012 04:59:06 -0800 (PST) Received: by 10.42.61.203 with HTTP; Fri, 14 Dec 2012 04:59:06 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 13:59:06 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9340347c063e104d0cf987c X-Mailman-Approved-At: Fri, 14 Dec 2012 13:39:31 -0800 Cc: John Panzer , webfinger@ietf.org, James M Snell , Goix Laurent Walter , Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:59:08 -0000 --14dae9340347c063e104d0cf987c Content-Type: text/plain; charset=ISO-8859-1 On 14 December 2012 12:01, Blaine Cook wrote: > So, all this has me thinking. And I'm going to propose something totally > against much of what I've been saying. > > Why not introduce a SECOND scheme, "accts" > Is there an issue on whether IANA will approve two separate schemes? > > If you want a secure lookup, your request (from a client-library > perspective) will look like: > > webfinger.lookup('accts://bob@example.com') > > or just > webfinger.lookup('bob@example.com') > > which will default to "accts", since that's the best-most-secure option. > > If you want an unsecured lookup, use the "acct" scheme explicitly, so as > follows: > > webfinger.lookup('acct://bob@example.com') > > For applications where it doesn't matter, and you want to do a lookup and > get EITHER the secure or unsecured profile, it's trivial for library > authors to provide an explicit flag, like so: > > webfinger.lookup('bob@example.com', { allow_fallback: true }) > > OR it's easy enough for developers to do the lookup explicitly, like so: > > webfinger.lookup('accts://bob@example.com', function (err, result) { > if (result) { > // do something with the secure result > callback(err, result) > } else { > // c'mon, I just need a link to their public phonecam shots profile > webfinger.lookup('acct://bob@example.com', callback) > } > } > > Does this make sense? I think it errs on the side of the HTTPS-only crowd, > which I sympathise with even if I can't lend 100% support to. It also errs > on the side of client simplicity, and mirrors HTTP behaviours (but defaults > to secure instead of insecure, as with HTTP). > > Thoughts? Happy to try to write up some copy if this works for people. > > b. > --14dae9340347c063e104d0cf987c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 14 December 2012 12:01, Blaine Cook <= span dir=3D"ltr"><= romeda@gmail.com> wrote:
So, all this has me thinking. And I'm going to propose something totall= y against much of what I've been saying.

Why not int= roduce a SECOND scheme, "accts"

Is the= re an issue on whether IANA will approve two separate schemes?
=A0

If you want a s= ecure lookup, your request (from a client-library perspective) will look li= ke:

webfinger.lookup('accts://bob@example.com')

<= div>or just
webfinger.lookup('bob@example.com')

which will default to "accts", since that'= ;s the best-most-secure option.

If you want an uns= ecured lookup, use the "acct" scheme explicitly, so as follows:

webfinger.lookup('acct://bob@example.com')

For applications where it doesn't matter, and you want to do a looku= p and get EITHER the secure or unsecured profile, it's trivial for libr= ary authors to provide an explicit flag, like so:

webfinger.lookup('bob@example.com', { allow_fallback: true })

OR it's easy enough for developers to do the look= up explicitly, like so:

webfinger.lookup('accts://bob@example.com', function (err, result= ) {
=A0 if (result) {
=A0 =A0 // do something with the = secure result
=A0 =A0 callback(err, result)
=A0 } else {
=A0 =A0 // c= 'mon, I just need a link to their public phonecam shots profile
=A0 =A0 webfinger.lookup('acct://bob@example.com', callback)
=A0 }
}

Does this make sense? I thi= nk it errs on the side of the HTTPS-only crowd, which I sympathise with eve= n if I can't lend 100% support to. It also errs on the side of client s= implicity, and mirrors HTTP behaviours (but defaults to secure instead of i= nsecure, as with HTTP).

Thoughts? Happy to try to write up some copy if this wo= rks for people.
b.

--14dae9340347c063e104d0cf987c-- From barryleiba.mailing.lists@gmail.com Fri Dec 14 15:17:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB221F8B57 for ; Fri, 14 Dec 2012 15:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRVZrRIi3hOp for ; Fri, 14 Dec 2012 15:17:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5EB021F8B5D for ; Fri, 14 Dec 2012 15:17:02 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3227200lah.31 for ; Fri, 14 Dec 2012 15:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G4lRRsE0cXYI9xN0uXBZiDmQaN3mBX3MXMDc1bEzSBg=; b=0+SXNoZBEncKDiQdUGVXg06GKG21399rXzNuHB6a4FWNg1eMtnz4g1/KoD81+PUQIQ 4vox469O3ZKdpLDibxOgYo6AYOqlZL/mKSilvhej3+vIuqDvqFiXAKV9dd13BgFPTgXv aGQq1x9Lv1ZTvFj8oGlxZtPSsIGkcqjR/M6CCkiFNKyn8aIwjlGlvDfMkTz2l0cB4Ico Iu6tSGtAk6a7G1d91FPByprRBztHMZDP8xD+EvY+6Q0Lvk0fP4e2fvWHQXMrEF62iSHJ 5mN1dK+A0dh0y6e9iX11/hLEpbgJ7ICjedMej9LxSBOGPakNbnPisvoqPtdFa6mWv0mw Mfag== MIME-Version: 1.0 Received: by 10.152.148.4 with SMTP id to4mr3975076lab.39.1355527021772; Fri, 14 Dec 2012 15:17:01 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Fri, 14 Dec 2012 15:17:01 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 18:17:01 -0500 X-Google-Sender-Auth: 177XduzxsqXRPXBRNqPE9XMZLOA Message-ID: From: Barry Leiba To: Melvin Carvalho Content-Type: text/plain; charset=ISO-8859-1 Cc: John Panzer , webfinger@googlegroups.com, James M Snell , Goix Laurent Walter , Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:17:11 -0000 Sanity intervention: >> Why not introduce a SECOND scheme, "accts" > > Is there an issue on whether IANA will approve two separate schemes? IANA doesn't "approve" anything; they administer the registries. The IESG and the Designated Expert are the ones responsible for the approvals. If you'd like to have a discussion of whether separate schemes make sense, I suggest you loop in Graham Klyne, the Designated Expert for URI-schemes. And if y'all want the IESG to approve anything, you'll have to find a way to get to rough consensus. That means compromises; that means understanding that if a bunch of people have strong technical reasons for going in one direction or another, it might make sense to agree to head that way, and use the good will you earn to help you in another fight. I see a lot of spinning and churning here, with various attempts to say, "OK, how about *this* compromise" (a GOOD approach), followed by too much maintenance of the trenches. Let's find the compromise and move ahead. Barry, Applications AD From breno.demedeiros@gmail.com Fri Dec 14 17:21:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FBA21F8B1D for ; Fri, 14 Dec 2012 17:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-qb86hbHAzd for ; Fri, 14 Dec 2012 17:21:17 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD321F8B16 for ; Fri, 14 Dec 2012 17:21:17 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4891169vbb.31 for ; Fri, 14 Dec 2012 17:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=inU5pHVvxp5dLp3HJxALRAj13ntIq6hCaSN0EmlnNb8=; b=jb1HeI6Usp+0oVLxvyPvfp4lsVFaadSfk1Q0QekH4f9pUXPs7ttKvvN1Dkr1jrpC5J /0YzDP3YgBVQp4EakpBDepEtgexWUtuLB6nVJNN7i3PeCpKOwmvnZQf4HwMKbYi5zST2 u/JvxGxeGuedfV/FDvRfOj6TWALkYecZNo+G6nXcICgxd+udNH8LAZtJJtaWWUwGKlnw N0ZRKmJKEeHhyUhJ+9OcxpGhUMJ4ubf0ihw6MQYf67T/XB8CEozqbzOy0Pc9cL3MriDI NEA6Ssys1C/Z86pioz4pq0ljtpyeuSg11AYq57pjEcm87C+Y3n/2kyUMwfkl/5IYGeQX W6BQ== MIME-Version: 1.0 Received: by 10.220.239.143 with SMTP id kw15mr11835862vcb.62.1355534476828; Fri, 14 Dec 2012 17:21:16 -0800 (PST) Received: by 10.58.11.130 with HTTP; Fri, 14 Dec 2012 17:21:16 -0800 (PST) Received: by 10.58.11.130 with HTTP; Fri, 14 Dec 2012 17:21:16 -0800 (PST) In-Reply-To: References: <05ab01cdd951$54a17c20$fde47460$@packetizer.com> <06c901cdd96b$4aa2be40$dfe83ac0$@packetizer.com> <078101cdd97f$c8b96680$5a2c3380$@packetizer.com> <695443B7-917E-4E4C-9231-F32FB160D2AD@telecomitalia.it> <07ee01cdd987$3827d7c0$a8778740$@packetizer.com> Date: Fri, 14 Dec 2012 17:21:16 -0800 Message-ID: From: Breno To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9ccd4eef8e19504d0d9f675 Cc: webfinger@ietf.org, Brad Fitzpatrick , James M Snell , Goix Laurent Walter , "Paul E. Jones" Subject: Re: [webfinger] secure links with https rels X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 01:21:18 -0000 --14dae9ccd4eef8e19504d0d9f675 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thinking about it again, as long as no silent fallback is NOT allowed caching should not be an issue as HTTPS and HTTP URLs remain different resources On Dec 14, 2012 9:16 AM, "John Bradley" wrote: > Yes silent fallback to http is unacceptable. > > Sent from my iPad > > On 2012-12-13, at 9:17 PM, Tim Bray wrote: > > On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick wr= ote: > >> On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones wr= ote: >> >> I never saw any strong opposition against fallback. People disliked the >> extra complexity, but for quite awhile everybody assumed that fallback >> would be involved, and I think it was considered acceptable. >> >> Who was strongly anti-fallback?'''' >> > > Um, maybe me. What is unacceptable for some applications is if I tell th= e > client =93Fetch https://example.com/.well-known/whatever=94 and for some > reason it silently falls back to HTTP. -T > > > >> >> >> **** >>> >>> We either have to do HTTPS only *or* we have to live with the fact that >>> some client requests are going to fail if a WF provider does not provid= e WF >>> services over HTTPS. >>> >> >> I strongly disagree that those are the only two options. >> >> But if you really believe that, I hope you realize that flakiness is >> unacceptable, which leaves you with HTTPS-only. >> >> If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with >> HTTPS-only. >> >> >>> ** So, >>> >>> **1) **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS= * >>> *** >>> >>> **2) **Servers and clients MAY implement HTTP**** >>> >>> **3) **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be >>> treated as secure since it allows for a MITM attack)**** >>> >>> **4) **Servers MUST NOT redirect from HTTPS to HTTP**** >>> >>> ** ** >>> >>> All works well, except for the case where you have an HTTPS-only >>> client. But, I bet that will be the majority of clients, which will th= en >>> drive the majority of the servers to support HTTPS. >>> >> >> This is a terrible cop-out. Flakiness in the spec is unacceptable. >> >> >>> **** >>> >>> ** Still, it leaves the option on the table for some clients and >>> servers to use HTTP if they wish. >>> >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --14dae9ccd4eef8e19504d0d9f675 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thinking about it again, as long as no silent fallback is NO= T allowed caching should not be an issue as HTTPS and HTTP URLs remain diff= erent resources

On Dec 14, 2012 9:16 AM, "John Bradley"= ; <ve7jtb@ve7jtb.com> wrote:=
Yes silent fallback to http is unacceptable.=A0
<= br>Sent from my iPad

On 2012-12-13, at 9:17 PM, Tim Bray <= tbray@textuality.= com> wrote:

On Thu, Dec 13, 2012 at 3:15 PM, B= rad Fitzpatrick <bradfitz@google.com> wrote:
On Thu= , Dec 13, 2012 at 3:11 PM, Paul E. Jones <paulej@packetizer.com>= ; wrote:

I never saw any strong opposition again= st fallback. =A0People disliked the extra complexity, but for quite awhile = everybody assumed that fallback would be involved, and I think it was consi= dered acceptable.

Who was strongly anti-fallback?''''

Um, maybe me.=A0 What is unacceptable f= or some applications is if I tell the client =93Fetch https://example.com/.well= -known/whatever=94 and for some reason it silently falls back to HTTP.= =A0=A0 -T

=A0

<= /div>

=

We either have to do HTTPS only = or we have to live with the fact that some client requests are = going to fail if a WF provider does not provide WF services over HTTPS.


I strongly disagree that those are t= he only two options.

But if you really believe tha= t, I hope you realize that flakiness is unacceptable, which leaves you with= HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't cle= ar, I'd be happy with HTTPS-only.
=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0So,

1)=A0=A0=A0=A0=A0 Servers SHOULD implement HTTPS and clients SHOULD use = HTTPS

2)=A0=A0=A0=A0=A0 Servers and clients MAY implement HTTP

3)=A0=A0=A0=A0=A0 Servers MAY redirect from HTTP to HTTPS (this MUST NOT= be treated as secure since it allows for a MITM attack)

4)=A0=A0=A0=A0=A0 Servers MUST NOT redirect from HTTPS to HTTP=

=A0<= /p>

All works well, except= for the case where you have an HTTPS-only client.=A0 But, I bet that will = be the majority of clients, which will then drive the majority of the serve= rs to support HTTPS.


This is a terrible cop-out. =A0Flaki= ness in the spec is unacceptable.
=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0Still, it leaves the opt= ion on the table for some clients and servers to use HTTP if they wish.




_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


--14dae9ccd4eef8e19504d0d9f675-- From jasnell@gmail.com Fri Dec 14 20:25:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9587421F8A21 for ; Fri, 14 Dec 2012 20:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.693 X-Spam-Level: X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQYpNP650USt for ; Fri, 14 Dec 2012 20:25:02 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C89A821F8992 for ; Fri, 14 Dec 2012 20:25:02 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7025647ieb.31 for ; Fri, 14 Dec 2012 20:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/E7X/PBdmBPVvMbYd53O+szUBdRKKgHlRFJQihvM72k=; b=WEobFH9TRzMkLDoF2MbmTloEWNXhpo8meabvnvbEo2T3MjQS0FIDArDb4yCMzT5kwf g3UXoF5lOmscVGKPFKvg1i8sYuW7d4v613G+IaSGm61SIJBDB+BMUVmHCADs2dS2XxB/ ukh1f1C59T5OvI5tf1Po1Wlb0JN+p59F80KBfz3M9MEmwMpUf+tBWaNtQBKrJxa+mKzX XGThrF8w/QaUHpnon/WE4+/Nrd+BH8hP+ObAU2V18CYlBO7lTR6Zt3BAy+Hw2Vz+/TSJ 5HvxxG2BcPK+B3L+29V8B8wiGOvPQN+j9/YFgsY0wWiHx+EO3JmKb8SDVZaHuy6TUZg7 8SvA== MIME-Version: 1.0 Received: by 10.50.77.166 with SMTP id t6mr3644143igw.72.1355545502409; Fri, 14 Dec 2012 20:25:02 -0800 (PST) Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 20:25:02 -0800 (PST) Received: by 10.64.7.19 with HTTP; Fri, 14 Dec 2012 20:25:02 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 20:25:02 -0800 Message-ID: From: James M Snell To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8f3baff725e28904d0dc88dc Cc: Goix Laurent Walter , John Panzer , webfinger@googlegroups.com, Melvin Carvalho , Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 04:25:03 -0000 --e89a8f3baff725e28904d0dc88dc Content-Type: text/plain; charset=UTF-8 WRT the issue of https-only, a consensus call was already made. The chair posted afterwards indicating that there was no obvious consensus for https-only. The only reasonable solution at this point should be clear. The draft language posted by Paul yesterday that allows http or https but not https-to-http fallback provides the least restrictive, most flexible model without introducing significant security concerns or complexity. Those who are in the https-only camp would be free to implement https-only webfinger endpoints and clients. Those who want http would have what they want to. From there, the market will decide which is the preferred choice and someone can come along later a write up a BCP or update the spec if implementation experience proves that one particular point of view is better than the other. If someone wishes to define a secure link rel concept, that can be done independent of web finger, and should be done as an update to rfc5988. It is completely orthogonal to the basic definition of web finger. If someone wishes to implement some notion of secure-only links within a web finger document, that too can be done independently of the basic web finger protocol. There really should not be anything left to debate on this. There are a few other remaining issues that should be dealt with then we should call it a day. - james On Dec 14, 2012 3:17 PM, "Barry Leiba" wrote: > Sanity intervention: > > >> Why not introduce a SECOND scheme, "accts" > > > > Is there an issue on whether IANA will approve two separate schemes? > > IANA doesn't "approve" anything; they administer the registries. > > The IESG and the Designated Expert are the ones responsible for the > approvals. If you'd like to have a discussion of whether separate > schemes make sense, I suggest you loop in Graham Klyne, the Designated > Expert for URI-schemes. > > And if y'all want the IESG to approve anything, you'll have to find a > way to get to rough consensus. That means compromises; that means > understanding that if a bunch of people have strong technical reasons > for going in one direction or another, it might make sense to agree to > head that way, and use the good will you earn to help you in another > fight. I see a lot of spinning and churning here, with various > attempts to say, "OK, how about *this* compromise" (a GOOD approach), > followed by too much maintenance of the trenches. > > Let's find the compromise and move ahead. > > Barry, Applications AD > --e89a8f3baff725e28904d0dc88dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

WRT the issue of https-only, a consensus call was already ma= de. The chair posted afterwards indicating that there was no obvious consen= sus for https-only. The only reasonable solution at this point should be cl= ear.

The draft language posted by Paul yesterday that allows http= or https but not https-to-http fallback provides the least restrictive, mo= st flexible model without introducing significant security concerns or comp= lexity. Those who are in the https-only camp would be free to implement htt= ps-only webfinger endpoints and clients. Those who want http would have wha= t they want to. From there, the market will decide which is the preferred c= hoice and someone can come along later a write up a BCP or update the spec = if implementation experience proves that one particular point of view is be= tter than the other.

If someone wishes to define a secure link rel concept, that = can be done independent of web finger, and should be done as an update to r= fc5988. It is completely orthogonal to the basic definition of web finger.<= /p>

If someone wishes to implement some notion of secure-only li= nks within a web finger document, that too can be done independently of the= basic web finger protocol.

There really should not be anything left to debate on this. = There are a few other remaining issues that should be dealt with then we sh= ould call it a day.

- james

On Dec 14, 2012 3:17 PM, "Barry Leiba"= <barryleiba@computer.org= > wrote:
Sanity intervention:

>> Why not introduce a SECOND scheme, "accts"
>
> Is there an issue on whether IANA will approve two separate schemes?
IANA doesn't "approve" anything; they administer the registri= es.

The IESG and the Designated Expert are the ones responsible for the
approvals. =C2=A0If you'd like to have a discussion of whether separate=
schemes make sense, I suggest you loop in Graham Klyne, the Designated
Expert for URI-schemes.

And if y'all want the IESG to approve anything, you'll have to find= a
way to get to rough consensus. =C2=A0That means compromises; that means
understanding that if a bunch of people have strong technical reasons
for going in one direction or another, it might make sense to agree to
head that way, and use the good will you earn to help you in another
fight. =C2=A0I see a lot of spinning and churning here, with various
attempts to say, "OK, how about *this* compromise" (a GOOD approa= ch),
followed by too much maintenance of the trenches.

Let's find the compromise and move ahead.

Barry, Applications AD
--e89a8f3baff725e28904d0dc88dc-- From paulej@packetizer.com Fri Dec 14 23:34:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4321F89F6 for ; Fri, 14 Dec 2012 23:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfIwLDJqmz0t for ; Fri, 14 Dec 2012 23:34:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7992221F89D0 for ; Fri, 14 Dec 2012 23:34:25 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBF7YOFM006038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 02:34:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355556864; bh=Xicd4zyk2q6pPMbJ7pZzUd2RIrcPZxpxFOQ8P0jZ18g=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EvlEygLaSNt/RKwWfEUJtVLN6IZiYKxMTN1sEz4GJ8NSQOeb323iOt3E9T2uRttVu eHmzhAs9h4QhQQGxU1nZ7vpkhVjoNYBqC45UsOOwKTv9viE3MfmVDErfpQqITNqxxb f22KQylXjtDHGSMrGWVBBeJPB8ZnpYidy0DplPsQ= From: "Paul E. Jones" To: "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> <1355509733-sup-5469@heahdk.net> In-Reply-To: <1355509733-sup-5469@heahdk.net> Date: Sat, 15 Dec 2012 02:34:38 -0500 Message-ID: <0b9501cdda96$a3fd79e0$ebf86da0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrQJNGg2YATtEkl0CW7tvJgKUQTeYAjoH2foCAZndYgMOveMEAbE3eq4BspAHhQJ/JwHvAqZSqGUBIydM3QKwRqFjljjMlGA= Content-Language: en-us Cc: 'webfinger' Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:34:26 -0000 It's just there to make it clear that redirecting to HTTPS it OK, but = not the other way around. Paul > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On > Behalf Of ? elf Pavlik ? > Sent: Friday, December 14, 2012 1:31 PM > To: Paul E. Jones > Cc: webfinger > Subject: Re: [webfinger] the conflicting goals >=20 > Excerpts from Paul E. Jones's message of 2012-12-13 23:27:20 +0000: > > > WebFinger servers operating on HTTP MAY redirect a client using > > an _appropriate_ HTTP status code to another HTTP or an HTTPS = URI. > > Likewise, WebFinger servers operating on HTTPS MAY redirect a > > client to another HTTPS URI, but MUST NOT redirect a client to = an > > HTTP URI. Further, clients MUST NOT follow a redirection from = an > > HTTPS URI to an HTTP URI, but SHOULD automatically follow all > > other server redirects. > i see in many places this topic of HTTP request redirected to HTTPS = and > must say that i don't understand for which scenario we need it? > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Fri Dec 14 23:37:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C78B21F89D0 for ; Fri, 14 Dec 2012 23:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUjXPa18cCLL for ; Fri, 14 Dec 2012 23:37:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B54DF21F89F6 for ; Fri, 14 Dec 2012 23:37:16 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBF7bDrV006160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 02:37:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355557033; bh=MDhYaAvOYGr5t6N3/YGMddXmEcKKQ57i3lU3DTWPrII=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jRHHe6VyiDpfFdaR24b7/Hu+IGu61ErZwZQYeIQ3hsuwqkEzPiDxz9ZzOV4y7a/G7 XwxZaDTfrtcTIvqmoODj6XRdmTNn8Du0TwohYBOelQT11dR8REkdcCbpJZY5Ftkzh0 EURd+/0T7rBWZVz00u7f/dMmowOYN7qBO1XN4kGo= From: "Paul E. Jones" To: "'Nick Jennings'" , "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" References: <073401cdd971$24b7ce90$6e276bb0$@packetizer.com> <077401cdd97e$e78210e0$b68632a0$@packetizer.com> <081e01cdd989$66344160$329cc420$@packetizer.com> <1355509733-sup-5469@heahdk.net> In-Reply-To: Date: Sat, 15 Dec 2012 02:37:27 -0500 Message-ID: <0b9701cdda97$08bd8f50$1a38adf0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNsqKmO9K9kmL8pCHsfTTALASKrQJNGg2YATtEkl0CW7tvJgKUQTeYAjoH2foCAZndYgMOveMEAbE3eq4BspAHhQJ/JwHvAqZSqGUBIydM3QKwRqFjAc2+55GWKl7gwA== Content-Language: en-us Cc: 'webfinger' Subject: Re: [webfinger] the conflicting goals X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:37:20 -0000 I think we need to say something here, but I'm open on the wording. Many sites (including my own) tend to redirect, say, packetizer.com to = www.packetizer.com. The same thing might happen with particular = resources like "webfinger". That's OK, but we don't want https:// to = get redirected to "http://". Absolutely nothing wrong with the other = way around. With all of the debate over HTTPS, I cannot imagine letting this spec go = out with language about when it is and is not valid to redirect a = client. Paul > -----Original Message----- > From: Nick Jennings [mailto:nick@silverbucket.net] > Sent: Friday, December 14, 2012 1:36 PM > To: =E2=98=AE elf Pavlik =E2=98=AE > Cc: Paul E. Jones; webfinger > Subject: Re: [webfinger] the conflicting goals >=20 > On Fri, Dec 14, 2012 at 7:31 PM, =E2=98=AE elf Pavlik =E2=98=AE = tripper@wwelves.org> wrote: > > Excerpts from Paul E. Jones's message of 2012-12-13 23:27:20 +0000: > > > >> WebFinger servers operating on HTTP MAY redirect a client using > >> an _appropriate_ HTTP status code to another HTTP or an HTTPS = URI. > >> Likewise, WebFinger servers operating on HTTPS MAY redirect a > >> client to another HTTPS URI, but MUST NOT redirect a client to = an > >> HTTP URI. Further, clients MUST NOT follow a redirection from = an > >> HTTPS URI to an HTTP URI, but SHOULD automatically follow all > >> other server redirects. > > i see in many places this topic of HTTP request redirected to HTTPS > and must say that i don't understand for which scenario we need it? >=20 > I agree, I would prefer this not to happen. HTTP and HTTPS shouldn't > fallback (from the server perspective). I added it in my suggestion > because it seemed like others (most notably Paul) wanted it. >=20 >=20 > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Fri Dec 14 23:43:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472B221F8A28 for ; Fri, 14 Dec 2012 23:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44TlgQ54Tmyg for ; Fri, 14 Dec 2012 23:43:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1016121F8634 for ; Fri, 14 Dec 2012 23:43:39 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBF7hXjO006406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 02:43:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355557414; bh=56v5RMmbhQaogR2d6licxw+hxN/hgjFdFhevrk7wP5U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=C9/VLSfKyiU6VhApIIKMdMqY0YMdWFeCfik7YSyDTqOY+QZXGv7K+0JySm7hgjNgb 5hlQEbqtlct1kH2tDsp2l0iNvjkNjPdIgL9TKRbvsF09Sy6Gto3yX5afP3nifdOjwa ZKV5606EJpofN0RByXxNeb8RWB0kNSBpC5KPHNrs= From: "Paul E. Jones" To: "'Blaine Cook'" , References: In-Reply-To: Date: Sat, 15 Dec 2012 02:43:48 -0500 Message-ID: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B9A_01CDDA6E.02D147E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQELUdhvAhw3xu53UQOPgZBHozChcJmeivyQ Content-Language: en-us Cc: 'John Panzer' , webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:43:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B9A_01CDDA6E.02D147E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Blaine, =20 How does this help us? Let=E2=80=99s say I visit Bob=E2=80=99s blog and = want to log in. I enter my email address and Bob=E2=80=99s blog server = will issue a WF query. It knows it need to make a secure query, because = it knows its own security requirements. It would be that client code = that would have to create the =E2=80=9Caccts=E2=80=9D URI out of what I = enter. So, if it=E2=80=99s going to do that, why not just issue the = query to whatever underlying library is un use like: =20 webfinger.lookup('acct:paulej@packetizer.com', 'secure:true'); =20 Or similar. If a library is used at all, we can signal that only an = HTTPS query shall be made. =20 Perhaps I=E2=80=99m missing something? =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Blaine Cook Sent: Friday, December 14, 2012 6:01 AM To: webfinger@googlegroups.com Cc: John Panzer; webfinger@ietf.org; James M Snell; Goix Laurent Walter; = Brad Fitzpatrick Subject: [webfinger] A third (or is it twelfth?) way [was: secure links = with https rels] =20 So, all this has me thinking. And I'm going to propose something totally = against much of what I've been saying. =20 Why not introduce a SECOND scheme, "accts" =20 If you want a secure lookup, your request (from a client-library = perspective) will look like: =20 webfinger.lookup('accts://bob@example.com') =20 or just webfinger.lookup('bob@example.com') =20 which will default to "accts", since that's the best-most-secure option. =20 If you want an unsecured lookup, use the "acct" scheme explicitly, so as = follows: =20 webfinger.lookup('acct://bob@example.com') =20 For applications where it doesn't matter, and you want to do a lookup = and get EITHER the secure or unsecured profile, it's trivial for library = authors to provide an explicit flag, like so: =20 webfinger.lookup('bob@example.com', { allow_fallback: true }) =20 OR it's easy enough for developers to do the lookup explicitly, like so: =20 webfinger.lookup('accts://bob@example.com', function (err, result) { if (result) { // do something with the secure result callback(err, result) } else { // c'mon, I just need a link to their public phonecam shots profile webfinger.lookup('acct://bob@example.com', callback) } } =20 Does this make sense? I think it errs on the side of the HTTPS-only = crowd, which I sympathise with even if I can't lend 100% support to. It = also errs on the side of client simplicity, and mirrors HTTP behaviours = (but defaults to secure instead of insecure, as with HTTP). =20 Thoughts? Happy to try to write up some copy if this works for people. =20 b. ------=_NextPart_000_0B9A_01CDDA6E.02D147E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Blaine,

 

How does this help us?=C2=A0 Let=E2=80=99s say I visit Bob=E2=80=99s = blog and want to log in.=C2=A0 I enter my email address and = Bob=E2=80=99s blog server will issue a WF query.=C2=A0 It knows it need = to make a secure query, because it knows its own security = requirements.=C2=A0 It would be that client code that would have to = create the =E2=80=9Caccts=E2=80=9D URI out of what I enter.=C2=A0 So, if = it=E2=80=99s going to do that, why not just issue the query to whatever = underlying library is un use like:

 

webfinger.lookup('acct:paulej@packetizer.com', = 'secure:true');

 

Or similar.=C2=A0 If a library is used at all, we can signal that = only an HTTPS query shall be made.

 

Perhaps I=E2=80=99m missing something?

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Blaine Cook
Sent: Friday, December 14, 2012 6:01 = AM
To: webfinger@googlegroups.com
Cc: John Panzer; = webfinger@ietf.org; James M Snell; Goix Laurent Walter; Brad = Fitzpatrick
Subject: [webfinger] A third (or is it twelfth?) = way [was: secure links with https = rels]

 

So, all this = has me thinking. And I'm going to propose something totally against much = of what I've been saying.

 

Why not introduce a SECOND scheme, = "accts"

 

If you want a secure lookup, your request (from a = client-library perspective) will look like:

 

webfinger.lookup('accts://bob@example.com')

 

or just

webfinger.lookup('bob@example.com')

 

which will default to "accts", since that's = the best-most-secure option.

 

If you want an unsecured lookup, use the = "acct" scheme explicitly, so as = follows:

 

webfinger.lookup('acct://bob@example.com')

 

For applications where it doesn't matter, and you want = to do a lookup and get EITHER the secure or unsecured profile, it's = trivial for library authors to provide an explicit flag, like = so:

 

webfinger.lookup('bob@example.com', { allow_fallback: = true })

 

OR it's easy enough for developers to do the lookup = explicitly, like so:

 

webfinger.lookup('accts://bob@example.com', function (err, = result) {

  if = (result) {

    = // do something with the secure result

    callback(err, = result)

  } else = {

    // c'mon, = I just need a link to their public phonecam shots = profile

    = webfinger.lookup('acct://bob@example.com', = callback)

  = }

}

 

Does this make sense? I think it errs on the side of = the HTTPS-only crowd, which I sympathise with even if I can't lend 100% = support to. It also errs on the side of client simplicity, and mirrors = HTTP behaviours (but defaults to secure instead of insecure, as with = HTTP).

 

Thoughts? Happy to try to write up some copy if this = works for people.

 

b.

------=_NextPart_000_0B9A_01CDDA6E.02D147E0-- From paulej@packetizer.com Fri Dec 14 23:56:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A99A21F88A6 for ; Fri, 14 Dec 2012 23:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P03qkusDmD4 for ; Fri, 14 Dec 2012 23:56:46 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9B21F84ED for ; Fri, 14 Dec 2012 23:56:46 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBF7uiCu006938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Dec 2012 02:56:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355558205; bh=2F9VhPEEt8+I6Cml1QhEigeElzv5/Jb3m50cv7tFb1k=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=dvLQwWbLFkFvCpejs8BfPvPvZGfUyJW2l529hv67SpV1w0Z/RysGl17Yjnpka/xI2 UPYvF/MTSWecyf5jOM7hsFiuxclRtqQjpNFSdW+ps58e+1tH1U4jGLIY6mA4yQkZte oyMVr+hgBFhOzYsT6RvCM2HCQG0n3ltDqnqRMhAU= From: "Paul E. Jones" To: , Date: Sat, 15 Dec 2012 02:56:59 -0500 Message-ID: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BAD_01CDDA6F.DA164510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3amALgvnxjkjA3RduDjxaxI2go0w== Content-Language: en-us Subject: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:56:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BAD_01CDDA6F.DA164510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Here's the current language. I get the feeling more people like this than what we had before. Now, what fine-tuning do we need to do? Or are people still of the mind that we need HTTPS only no matter what? Current language: Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. I would like to suggest we strike ", but MUST NOT attempt to use both, either serially or in parallel". Let the client decide what to do based on its security requirements. I would like to suggest we change "If a query is issued using HTTPS" to "If a query is issued using HTTPS because it has strict security requirements". Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user's avatar and it fails, why not let it use HTTP? Actually, we could probably just remove this whole second paragraph. We could just speak to the certificate checking on the security section as it relates to secure clients. Thus, I propose we go with this (with or without the middle paragraph): Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. Paul ------=_NextPart_000_0BAD_01CDDA6F.DA164510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Here’s = the current language.  I get the feeling more people like this than = what we had before.  Now, what fine-tuning do we need to do?  = Or are people still of the mind that we need HTTPS only no matter = what?

 

Current language:

 

Clients MAY issue a query to the WebFinger server = using either HTTPS or HTTP, but MUST NOT attempt to use both, either = serially or in parallel.  The choice of transport protocols depends = on the client’s security requirements, though use of HTTPS is = RECOMMENDED in most situations.

 

If a query = is issued using HTTPS and the server has an invalid certificate, the = server returns a 4xx or 5xx status code, or the HTTPS connection cannot = be established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP.

 

WebFinger servers operating on HTTP MAY redirect a = client using an appropriate HTTP status code to another HTTP or an HTTPS = URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a = client to another HTTPS URI, but MUST NOT redirect a client to an HTTP = URI.  Further, clients MUST NOT follow a redirection from an HTTPS = URI to an HTTP URI, but SHOULD automatically follow all other server = redirects.

 

I would like = to suggest we strike “, but MUST NOT attempt to use both, either = serially or in parallel”.  Let the client decide what to do = based on its security requirements.

 

I would like = to suggest we change “If a query is issued using HTTPS” to = “If a query is issued using HTTPS because it has strict security = requirements”.  Reasoning, again, is that if a client like a = blog server issues a query via HTTPS looking for a user’s avatar = and it fails, why not let it use HTTP?  Actually, we could probably = just remove this whole second paragraph.  We could just speak to = the certificate checking on the security section as it relates to secure = clients.

 

Thus, I propose we go with this (with or without the = middle paragraph):

 

Clients MAY issue a query to the WebFinger server = using either HTTPS or HTTP.  The choice of transport protocols = depends on the client’s security requirements, though use of HTTPS = is RECOMMENDED in most situations.

 

If a = query is issued using HTTPS because it has strict security requirements = and the server has an invalid certificate, the server returns a 4xx or = 5xx status code, or the HTTPS connection cannot be established for any = reason, the client MUST accept that the WebFinger query has failed and = MUST NOT attempt to reissue the WebFinger request using = HTTP.

 

WebFinger servers operating on HTTP MAY redirect a = client using an appropriate HTTP status code to another HTTP or an HTTPS = URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a = client to another HTTPS URI, but MUST NOT redirect a client to an HTTP = URI.  Further, clients MUST NOT follow a redirection from an HTTPS = URI to an HTTP URI, but SHOULD automatically follow all other server = redirects.

 

Paul

 

------=_NextPart_000_0BAD_01CDDA6F.DA164510-- From laurentwalter.goix@telecomitalia.it Sat Dec 15 03:32:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5721F87F6 for ; Sat, 15 Dec 2012 03:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vATUsuidEELb for ; Sat, 15 Dec 2012 03:32:39 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id F3AF721F8742 for ; Sat, 15 Dec 2012 03:32:38 -0800 (PST) Content-Type: multipart/mixed; boundary="_ffdb0877-8ba8-440c-9f21-4ffc4c403d04_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Sat, 15 Dec 2012 12:32:30 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Sat, 15 Dec 2012 12:32:29 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Sat, 15 Dec 2012 12:32:21 +0100 Thread-Topic: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] Thread-Index: Ac3at9zxOalab0B2QhKrRoJvOJDWGA== Message-ID: References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> In-Reply-To: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: John Panzer , "webfinger@googlegroups.com" , "webfinger@ietf.org" , James M Snell , Brad Fitzpatrick , Blaine Cook Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 11:32:40 -0000 --_ffdb0877-8ba8-440c-9f21-4ffc4c403d04_ Content-Type: multipart/alternative; boundary="_000_C3AA7D03B6BB4F7B80FCFF534C977DE4telecomitaliait_" --_000_C3AA7D03B6BB4F7B80FCFF534C977DE4telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc2tlZCBteXNlbGYgdGhlIHNhbWUgcXVlc3Rpb24gYW5kIGVuZGVkIHVwIHdpdGggYWNjdHM6 IHRvIGJlIGluZGVwZW5kZW50IGZyb20gdGhlIHNpbmdsZSBjbGllbnQgbGlicmFyeSBzaWduYXR1 cmUuIEhhdmluZyB0aGUgc2VjdXJlIGZsYWcgaW4gdGhlIHVyaSBpdHNlbGYgaXMgdGhlIG1vc3Qg c3RhbmRhcmQgd2F5IG9mIHJlcXVlc3RpbmcgdGxzLiBTaXBzOiB1cmkgc2NoZW1lIHdhcyBjb2lu ZWQgZm9yIHRoaXMgZXhhY3QgbmVlZCBhcyB3ZWxsIHdydCBzaXA6IHBsYWluIHNjaGVtZS4NCk90 aGVyd2lzZSB5b3UgZG9uJ3Qga25vdyBob3cgbWFueSBjbGllbnQgbGlicmFyaWVzIHdpbGwgcG9w IHVwIGFuZCB0aGV5IHByb2JhYmx5IHdvbid0IHNoYXJlIHRoZSBzYW1lIHNpZ25hdHVyZSBpbiB0 aGVpciAqbG9va3VwL2Rpc2NvdmVyeSogbWV0aG9kIGFuZCBtYXkgbm90IGFsbCBleHBvc2UgdGhl IHNlY3VyZSBmbGFnIGF0IGFsbCwgb3IgbWF5IG9ubHkgc3VwcG9ydCBzZWN1cmUgY2FsbHMsIHRo dXMgZnJhZ21lbnRpbmcgdGhlaXIgdXNhZ2UgZGVwZW5kaW5nIG9uIHRoZSB1c2UgY2FzZSB0eXBl cy4gVGhlIHNjaGVtZSBvcHRpb24gaXMgdGhlIGNsZWFuZXN0IGluIHRoaXMgcmVzcGVjdCBhbmQg c2VlbXMgdG8gc29sdmUgYWxsIGNvbmNlcm5zLiBCdXQgb3RoZXIgKm5vdCBmb3VuZCB5ZXQqIG9w dGlvbnMgYXJlIHdlbGNvbWUgOikNCg0KTGUgMTUgZMOpYy4gMjAxMiDDoCAwODo0MywgIlBhdWwg RS4gSm9uZXMiIDxwYXVsZWpAcGFja2V0aXplci5jb208bWFpbHRvOnBhdWxlakBwYWNrZXRpemVy LmNvbT4+IGEgw6ljcml0IDoNCg0KQmxhaW5lLA0KDQpIb3cgZG9lcyB0aGlzIGhlbHAgdXM/ICBM ZXTigJlzIHNheSBJIHZpc2l0IEJvYuKAmXMgYmxvZyBhbmQgd2FudCB0byBsb2cgaW4uICBJIGVu dGVyIG15IGVtYWlsIGFkZHJlc3MgYW5kIEJvYuKAmXMgYmxvZyBzZXJ2ZXIgd2lsbCBpc3N1ZSBh IFdGIHF1ZXJ5LiAgSXQga25vd3MgaXQgbmVlZCB0byBtYWtlIGEgc2VjdXJlIHF1ZXJ5LCBiZWNh dXNlIGl0IGtub3dzIGl0cyBvd24gc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiAgSXQgd291bGQgYmUg dGhhdCBjbGllbnQgY29kZSB0aGF0IHdvdWxkIGhhdmUgdG8gY3JlYXRlIHRoZSDigJxhY2N0c+KA nSBVUkkgb3V0IG9mIHdoYXQgSSBlbnRlci4gIFNvLCBpZiBpdOKAmXMgZ29pbmcgdG8gZG8gdGhh dCwgd2h5IG5vdCBqdXN0IGlzc3VlIHRoZSBxdWVyeSB0byB3aGF0ZXZlciB1bmRlcmx5aW5nIGxp YnJhcnkgaXMgdW4gdXNlIGxpa2U6DQoNCndlYmZpbmdlci5sb29rdXAoJ2FjY3Q6cGF1bGVqQHBh Y2tldGl6ZXIuY29tPGh0dHA6Ly9wYWNrZXRpemVyLmNvbT4nLCAnc2VjdXJlOnRydWUnKTsNCg0K T3Igc2ltaWxhci4gIElmIGEgbGlicmFyeSBpcyB1c2VkIGF0IGFsbCwgd2UgY2FuIHNpZ25hbCB0 aGF0IG9ubHkgYW4gSFRUUFMgcXVlcnkgc2hhbGwgYmUgbWFkZS4NCg0KUGVyaGFwcyBJ4oCZbSBt aXNzaW5nIHNvbWV0aGluZz8NCg0KUGF1bA0KDQpGcm9tOiB3ZWJmaW5nZXItYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86d2ViZmluZ2Vy LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFpbmUgQ29vaw0KU2VudDogRnJpZGF5 LCBEZWNlbWJlciAxNCwgMjAxMiA2OjAxIEFNDQpUbzogd2ViZmluZ2VyQGdvb2dsZWdyb3Vwcy5j b208bWFpbHRvOndlYmZpbmdlckBnb29nbGVncm91cHMuY29tPg0KQ2M6IEpvaG4gUGFuemVyOyB3 ZWJmaW5nZXJAaWV0Zi5vcmc8bWFpbHRvOndlYmZpbmdlckBpZXRmLm9yZz47IEphbWVzIE0gU25l bGw7IEdvaXggTGF1cmVudCBXYWx0ZXI7IEJyYWQgRml0enBhdHJpY2sNClN1YmplY3Q6IFt3ZWJm aW5nZXJdIEEgdGhpcmQgKG9yIGlzIGl0IHR3ZWxmdGg/KSB3YXkgW3dhczogc2VjdXJlIGxpbmtz IHdpdGggaHR0cHMgcmVsc10NCg0KU28sIGFsbCB0aGlzIGhhcyBtZSB0aGlua2luZy4gQW5kIEkn bSBnb2luZyB0byBwcm9wb3NlIHNvbWV0aGluZyB0b3RhbGx5IGFnYWluc3QgbXVjaCBvZiB3aGF0 IEkndmUgYmVlbiBzYXlpbmcuDQoNCldoeSBub3QgaW50cm9kdWNlIGEgU0VDT05EIHNjaGVtZSwg ImFjY3RzIg0KDQpJZiB5b3Ugd2FudCBhIHNlY3VyZSBsb29rdXAsIHlvdXIgcmVxdWVzdCAoZnJv bSBhIGNsaWVudC1saWJyYXJ5IHBlcnNwZWN0aXZlKSB3aWxsIGxvb2sgbGlrZToNCg0Kd2ViZmlu Z2VyLmxvb2t1cCgnYWNjdHM6Ly9ib2JAZXhhbXBsZS5jb208bWFpbHRvOmJvYkBleGFtcGxlLmNv bT4nKQ0KDQpvciBqdXN0DQp3ZWJmaW5nZXIubG9va3VwKCdib2JAZXhhbXBsZS5jb208bWFpbHRv OmJvYkBleGFtcGxlLmNvbT4nKQ0KDQp3aGljaCB3aWxsIGRlZmF1bHQgdG8gImFjY3RzIiwgc2lu Y2UgdGhhdCdzIHRoZSBiZXN0LW1vc3Qtc2VjdXJlIG9wdGlvbi4NCg0KSWYgeW91IHdhbnQgYW4g dW5zZWN1cmVkIGxvb2t1cCwgdXNlIHRoZSAiYWNjdCIgc2NoZW1lIGV4cGxpY2l0bHksIHNvIGFz IGZvbGxvd3M6DQoNCndlYmZpbmdlci5sb29rdXAoJ2FjY3Q6Ly9ib2JAZXhhbXBsZS5jb208bWFp bHRvOmJvYkBleGFtcGxlLmNvbT4nKQ0KDQpGb3IgYXBwbGljYXRpb25zIHdoZXJlIGl0IGRvZXNu J3QgbWF0dGVyLCBhbmQgeW91IHdhbnQgdG8gZG8gYSBsb29rdXAgYW5kIGdldCBFSVRIRVIgdGhl IHNlY3VyZSBvciB1bnNlY3VyZWQgcHJvZmlsZSwgaXQncyB0cml2aWFsIGZvciBsaWJyYXJ5IGF1 dGhvcnMgdG8gcHJvdmlkZSBhbiBleHBsaWNpdCBmbGFnLCBsaWtlIHNvOg0KDQp3ZWJmaW5nZXIu bG9va3VwKCdib2JAZXhhbXBsZS5jb208bWFpbHRvOmJvYkBleGFtcGxlLmNvbT4nLCB7IGFsbG93 X2ZhbGxiYWNrOiB0cnVlIH0pDQoNCk9SIGl0J3MgZWFzeSBlbm91Z2ggZm9yIGRldmVsb3BlcnMg dG8gZG8gdGhlIGxvb2t1cCBleHBsaWNpdGx5LCBsaWtlIHNvOg0KDQp3ZWJmaW5nZXIubG9va3Vw KCdhY2N0czovL2JvYkBleGFtcGxlLmNvbTxtYWlsdG86Ym9iQGV4YW1wbGUuY29tPicsIGZ1bmN0 aW9uIChlcnIsIHJlc3VsdCkgew0KICBpZiAocmVzdWx0KSB7DQogICAgLy8gZG8gc29tZXRoaW5n IHdpdGggdGhlIHNlY3VyZSByZXN1bHQNCiAgICBjYWxsYmFjayhlcnIsIHJlc3VsdCkNCiAgfSBl bHNlIHsNCiAgICAvLyBjJ21vbiwgSSBqdXN0IG5lZWQgYSBsaW5rIHRvIHRoZWlyIHB1YmxpYyBw aG9uZWNhbSBzaG90cyBwcm9maWxlDQogICAgd2ViZmluZ2VyLmxvb2t1cCgnYWNjdDovL2JvYkBl eGFtcGxlLmNvbTxtYWlsdG86Ym9iQGV4YW1wbGUuY29tPicsIGNhbGxiYWNrKQ0KICB9DQp9DQoN CkRvZXMgdGhpcyBtYWtlIHNlbnNlPyBJIHRoaW5rIGl0IGVycnMgb24gdGhlIHNpZGUgb2YgdGhl IEhUVFBTLW9ubHkgY3Jvd2QsIHdoaWNoIEkgc3ltcGF0aGlzZSB3aXRoIGV2ZW4gaWYgSSBjYW4n dCBsZW5kIDEwMCUgc3VwcG9ydCB0by4gSXQgYWxzbyBlcnJzIG9uIHRoZSBzaWRlIG9mIGNsaWVu dCBzaW1wbGljaXR5LCBhbmQgbWlycm9ycyBIVFRQIGJlaGF2aW91cnMgKGJ1dCBkZWZhdWx0cyB0 byBzZWN1cmUgaW5zdGVhZCBvZiBpbnNlY3VyZSwgYXMgd2l0aCBIVFRQKS4NCg0KVGhvdWdodHM/ IEhhcHB5IHRvIHRyeSB0byB3cml0ZSB1cCBzb21lIGNvcHkgaWYgdGhpcyB3b3JrcyBmb3IgcGVv cGxlLg0KDQpiLg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGly aXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9u ZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2Nl bnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1 YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUg Y29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwg bWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoN ClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2Vl KHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFu ZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltjaWQ6MDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEkuRGlzY2xhaW1lcl1SaXNwZXR0YSBsJ2Ft YmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoN Cg== --_000_C3AA7D03B6BB4F7B80FCFF534C977DE4telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkkgYXNrZWQgbXlzZWxmIHRoZSBzYW1lIHF1ZXN0aW9uIGFuZCBlbmRlZCB1cCB3aXRoIGFj Y3RzOiB0byBiZSBpbmRlcGVuZGVudCBmcm9tIHRoZSBzaW5nbGUgY2xpZW50IGxpYnJhcnkgc2ln bmF0dXJlLiBIYXZpbmcgdGhlIHNlY3VyZSBmbGFnIGluIHRoZSB1cmkgaXRzZWxmIGlzIHRoZSBt b3N0IHN0YW5kYXJkIHdheSBvZiByZXF1ZXN0aW5nIHRscy4gU2lwczogdXJpIHNjaGVtZSB3YXMg Y29pbmVkIGZvciB0aGlzIGV4YWN0IG5lZWQgYXMNCiB3ZWxsIHdydCBzaXA6IHBsYWluIHNjaGVt ZS4mbmJzcDs8L2Rpdj4NCjxkaXY+T3RoZXJ3aXNlIHlvdSBkb24ndCBrbm93IGhvdyBtYW55IGNs aWVudCBsaWJyYXJpZXMgd2lsbCBwb3AgdXAgYW5kIHRoZXkgcHJvYmFibHkgd29uJ3Qgc2hhcmUg dGhlIHNhbWUgc2lnbmF0dXJlIGluIHRoZWlyICpsb29rdXAvZGlzY292ZXJ5KiBtZXRob2QgYW5k IG1heSBub3QgYWxsIGV4cG9zZSB0aGUgc2VjdXJlIGZsYWcgYXQgYWxsLCBvciBtYXkgb25seSBz dXBwb3J0IHNlY3VyZSBjYWxscywgdGh1cyBmcmFnbWVudGluZyB0aGVpciB1c2FnZQ0KIGRlcGVu ZGluZyBvbiB0aGUgdXNlIGNhc2UgdHlwZXMuIFRoZSBzY2hlbWUgb3B0aW9uIGlzIHRoZSBjbGVh bmVzdCBpbiB0aGlzIHJlc3BlY3QgYW5kIHNlZW1zIHRvIHNvbHZlIGFsbCBjb25jZXJucy4gQnV0 IG90aGVyICpub3QgZm91bmQgeWV0KiBvcHRpb25zIGFyZSB3ZWxjb21lIDopPGJyPg0KPGJyPg0K TGUgMTUgZMOpYy4gMjAxMiDDoCAwODo0MywgJnF1b3Q7UGF1bCBFLiBKb25lcyZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbSI+cGF1bGVqQHBhY2tldGl6ZXIu Y29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250 IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2lt U3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CbGFpbmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgZG9lcyB0aGlzIGhlbHAgdXM/Jm5ic3A7IExl dOKAmXMgc2F5IEkgdmlzaXQgQm9i4oCZcyBibG9nIGFuZCB3YW50IHRvIGxvZyBpbi4mbmJzcDsg SSBlbnRlciBteSBlbWFpbCBhZGRyZXNzIGFuZCBCb2LigJlzIGJsb2cgc2VydmVyIHdpbGwgaXNz dWUgYSBXRiBxdWVyeS4mbmJzcDsgSXQga25vd3MgaXQNCiBuZWVkIHRvIG1ha2UgYSBzZWN1cmUg cXVlcnksIGJlY2F1c2UgaXQga25vd3MgaXRzIG93biBzZWN1cml0eSByZXF1aXJlbWVudHMuJm5i c3A7IEl0IHdvdWxkIGJlIHRoYXQgY2xpZW50IGNvZGUgdGhhdCB3b3VsZCBoYXZlIHRvIGNyZWF0 ZSB0aGUg4oCcYWNjdHPigJ0gVVJJIG91dCBvZiB3aGF0IEkgZW50ZXIuJm5ic3A7IFNvLCBpZiBp dOKAmXMgZ29pbmcgdG8gZG8gdGhhdCwgd2h5IG5vdCBqdXN0IGlzc3VlIHRoZSBxdWVyeSB0byB3 aGF0ZXZlciB1bmRlcmx5aW5nIGxpYnJhcnkNCiBpcyB1biB1c2UgbGlrZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+d2ViZmluZ2VyLmxvb2t1cCgnYWNjdDpwYXVsZWpAPGEg aHJlZj0iaHR0cDovL3BhY2tldGl6ZXIuY29tIj5wYWNrZXRpemVyLmNvbTwvYT4nLCAnc2VjdXJl OnRydWUnKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3Igc2ltaWxhci4m bmJzcDsgSWYgYSBsaWJyYXJ5IGlzIHVzZWQgYXQgYWxsLCB3ZSBjYW4gc2lnbmFsIHRoYXQgb25s eSBhbiBIVFRQUyBxdWVyeSBzaGFsbCBiZSBtYWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcyBJ4oCZbSBt aXNzaW5nIHNvbWV0aGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXItYm91bmNlc0Bp ZXRmLm9yZyI+d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86 d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp3ZWJmaW5nZXItYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJsYWluZSBDb29rPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgRGVjZW1iZXIgMTQsIDIwMTIgNjowMSBBTTxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOndlYmZpbmdlckBnb29nbGVncm91cHMuY29tIj53ZWJmaW5nZXJAZ29vZ2xl Z3JvdXBzLmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IEpvaG4gUGFuemVyOyA8YSBocmVmPSJtYWls dG86d2ViZmluZ2VyQGlldGYub3JnIj53ZWJmaW5nZXJAaWV0Zi5vcmc8L2E+OyBKYW1lcyBNIFNu ZWxsOyBHb2l4IExhdXJlbnQgV2FsdGVyOyBCcmFkIEZpdHpwYXRyaWNrPGJyPg0KPGI+U3ViamVj dDo8L2I+IFt3ZWJmaW5nZXJdIEEgdGhpcmQgKG9yIGlzIGl0IHR3ZWxmdGg/KSB3YXkgW3dhczog c2VjdXJlIGxpbmtzIHdpdGggaHR0cHMgcmVsc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgYWxsIHRoaXMgaGFzIG1lIHRoaW5raW5nLiBBbmQgSSdt IGdvaW5nIHRvIHByb3Bvc2Ugc29tZXRoaW5nIHRvdGFsbHkgYWdhaW5zdCBtdWNoIG9mIHdoYXQg SSd2ZSBiZWVuIHNheWluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoeSBub3QgaW50cm9kdWNlIGEgU0VDT05EIHNjaGVtZSwgJnF1b3Q7YWNjdHMmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgeW91IHdhbnQgYSBzZWN1cmUgbG9va3VwLCB5b3VyIHJlcXVlc3QgKGZyb20gYSBjbGllbnQt bGlicmFyeSBwZXJzcGVjdGl2ZSkgd2lsbCBsb29rIGxpa2U6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlYmZpbmdlci5sb29rdXAoJ2FjY3Rz Oi8vPGEgaHJlZj0ibWFpbHRvOmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4YW1wbGUuY29tPC9hPicp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9y IGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PndlYmZpbmdlci5sb29rdXAoJzxhIGhyZWY9Im1haWx0bzpib2JAZXhhbXBsZS5jb20iPmJvYkBl eGFtcGxlLmNvbTwvYT4nKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj53aGljaCB3aWxsIGRlZmF1bHQgdG8gJnF1b3Q7YWNjdHMmcXVvdDssIHNp bmNlIHRoYXQncyB0aGUgYmVzdC1tb3N0LXNlY3VyZSBvcHRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IGFuIHVuc2Vj dXJlZCBsb29rdXAsIHVzZSB0aGUgJnF1b3Q7YWNjdCZxdW90OyBzY2hlbWUgZXhwbGljaXRseSwg c28gYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+d2ViZmluZ2VyLmxvb2t1cCgnYWNjdDovLzxhIGhyZWY9Im1haWx0bzpib2JA ZXhhbXBsZS5jb20iPmJvYkBleGFtcGxlLmNvbTwvYT4nKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgYXBwbGljYXRpb25zIHdoZXJlIGl0 IGRvZXNuJ3QgbWF0dGVyLCBhbmQgeW91IHdhbnQgdG8gZG8gYSBsb29rdXAgYW5kIGdldCBFSVRI RVIgdGhlIHNlY3VyZSBvciB1bnNlY3VyZWQgcHJvZmlsZSwgaXQncyB0cml2aWFsIGZvciBsaWJy YXJ5IGF1dGhvcnMgdG8gcHJvdmlkZSBhbiBleHBsaWNpdCBmbGFnLCBsaWtlIHNvOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZWJmaW5nZXIu bG9va3VwKCc8YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIj5ib2JAZXhhbXBsZS5jb208 L2E+JywgeyBhbGxvd19mYWxsYmFjazogdHJ1ZSB9KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PUiBpdCdzIGVhc3kgZW5vdWdoIGZvciBkZXZl bG9wZXJzIHRvIGRvIHRoZSBsb29rdXAgZXhwbGljaXRseSwgbGlrZSBzbzo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2ViZmluZ2VyLmxvb2t1 cCgnYWNjdHM6Ly88YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIj5ib2JAZXhhbXBsZS5j b208L2E+JywgZnVuY3Rpb24gKGVyciwgcmVzdWx0KSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgaWYgKHJlc3VsdCkgezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAvLyBkbyBzb21ldGhpbmcgd2l0aCB0aGUgc2VjdXJlIHJlc3VsdDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjYWxsYmFj ayhlcnIsIHJlc3VsdCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyB9IGVsc2UgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAvLyBjJ21vbiwgSSBqdXN0IG5lZWQg YSBsaW5rIHRvIHRoZWlyIHB1YmxpYyBwaG9uZWNhbSBzaG90cyBwcm9maWxlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IHdl YmZpbmdlci5sb29rdXAoJ2FjY3Q6Ly88YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIj5i b2JAZXhhbXBsZS5jb208L2E+JywgY2FsbGJhY2spPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoaXMgbWFrZSBzZW5zZT8gSSB0aGlu ayBpdCBlcnJzIG9uIHRoZSBzaWRlIG9mIHRoZSBIVFRQUy1vbmx5IGNyb3dkLCB3aGljaCBJIHN5 bXBhdGhpc2Ugd2l0aCBldmVuIGlmIEkgY2FuJ3QgbGVuZCAxMDAlIHN1cHBvcnQgdG8uIEl0IGFs c28gZXJycyBvbiB0aGUgc2lkZSBvZiBjbGllbnQgc2ltcGxpY2l0eSwgYW5kIG1pcnJvcnMgSFRU UCBiZWhhdmlvdXJzIChidXQgZGVmYXVsdHMgdG8gc2VjdXJlDQogaW5zdGVhZCBvZiBpbnNlY3Vy ZSwgYXMgd2l0aCBIVFRQKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhvdWdodHM/IEhhcHB5IHRvIHRyeSB0byB3cml0ZSB1cCBzb21lIGNv cHkgaWYgdGhpcyB3b3JrcyBmb3IgcGVvcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi Pg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7 fQ0KLS0+DQo8L3N0eWxlPg0KPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFs OyBmb250LXNpemU6MTJweDsgY29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9 IjM5NSI+DQo8ZGl2IGFsaWduPSJqdXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29u ZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlv bmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25v IHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBk b2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBp bW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBz dWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0i anVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5U aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3Bh biBjbGFzcz0iR3JhbUUiPmlzPC9zcGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhl IHNlbmRlcg0KIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48 L3A+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJk YW5hIj48aW1nIHNyYz0iY2lkOjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRp c2NsYWltZXIiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQw Ij5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOo IG5lY2Vzc2FyaW8uPC9zcGFuPjwvYj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C3AA7D03B6BB4F7B80FCFF534C977DE4telecomitaliait_-- --_ffdb0877-8ba8-440c-9f21-4ffc4c403d04_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_ffdb0877-8ba8-440c-9f21-4ffc4c403d04_-- From romeda@gmail.com Sat Dec 15 04:45:02 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7321F8856 for ; Sat, 15 Dec 2012 04:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdpP-Tq7kFLb for ; Sat, 15 Dec 2012 04:45:01 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB8A121F884D for ; Sat, 15 Dec 2012 04:45:00 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2800562pad.31 for ; Sat, 15 Dec 2012 04:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JbwbIbE4Jn9HA3BOZ+FinoQOyz3+AYuz0re9+Gv7qKY=; b=k2NzAbgtAMaIWm6yfh7/v/+6crmifj45ilqq5ofh4nNd8cWq68+RulnK2GyZH6pE/O bJvUf7phLG2AX6uOm/wN3QmCov14NZDSu8bPp7FeGAUOkelmEAVyYF44CabhSG1Wx5vA dxueSgkaH6+aMnDyPbWZF2RbcJPGvX2MQfyY3++4HhhZKgHjVTkEAA/rZzRwETcWgtln 0MsoVqjS5t59ohvUpTl94inAB+oKSPxe7C/YB+++PMLfbWHiB4ttZARSVpDQE/tAlUei qNe9QZj5AfYWE0g3k4H+kHZsoRgVT+XT2+qUOj0UbmI/55FVfRRMIy2X5PEq496j4YM7 HDrA== Received: by 10.68.247.134 with SMTP id ye6mr24672113pbc.69.1355575500332; Sat, 15 Dec 2012 04:45:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Sat, 15 Dec 2012 04:44:40 -0800 (PST) In-Reply-To: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> From: Blaine Cook Date: Sat, 15 Dec 2012 12:44:40 +0000 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b2e110129de5004d0e384b3 Cc: John Panzer , webfinger@googlegroups.com, James M Snell , Goix Laurent Walter , Brad Fitzpatrick , webfinger@ietf.org Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 12:45:02 -0000 --047d7b2e110129de5004d0e384b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Laurent's comments here. What I think we're both saying is that it seems clear that there is a desire to include language that prefers secure lookups of webfinger data, but allows lookups of unsecured data. Rather than inventing some way to signal to client developers, providers, and authors of dependent protocols, let's just use the existing approach that has been re-used in many places before. HTTP made the "wrong" default choice from a security perspective; when we type in a URL into a browser, the default scheme is "http", not "https". That's fine, from an historical perspective, but things like HSTS and default-HTTPS lists embedded in browsers, and indeed all of this discussion on "securing webfinger" is a reaction to that default. Look, the only reason I'm advocating for non-SSL requests being allowed is purely from a deployment perspective. There are loads of programmers (re: early adopters) who use github pages to host their personal domains (re: webfinger IDs). I raised this as an issue here, and received zero comments acknowledging that as a real deployment scenario. There's a whole community that's not present here ("indyweb") that's advocating for people owning their own domains as being the only way forward (I disagree with their absolutism on the question of hosted services, but sympathise). It's fine if the participants here from Google and Microsoft and the IETF security community want to claim that they can provide secure services to their users; the fact is that there are real scenarios today and for the foreseeable future where having real non-TLS lookups of webfinger data would be useful. I want this thing to be deployable. I want this community to make a commitment to supporting users outside this community. I *really* dislike the "acct" scheme, as I've made clear a number of times. There's no "dns" scheme, and there doesn't need to be. I think the same is true of "acct". However, as Bob Wyman has expressed, there *should have been* a dns scheme. We have a chance to fix that for webfinger lookups, and "accts" convinces me of the need for a scheme-based approach. Indeed, if we're going to have schemes at all, and if we can (please) assume that it's at least possible to have insecure webfinger lookups, then it demands us to ask the question why *isn't* there an accts scheme? Sorry for my sporadic and lengthy participation. I can't devote the time necessary to be on the list all the time. b. On 15 December 2012 07:43, Paul E. Jones wrote: > Blaine,**** > > ** ** > > How does this help us? Let=E2=80=99s say I visit Bob=E2=80=99s blog and = want to log in. > I enter my email address and Bob=E2=80=99s blog server will issue a WF qu= ery. It > knows it need to make a secure query, because it knows its own security > requirements. It would be that client code that would have to create the > =E2=80=9Caccts=E2=80=9D URI out of what I enter. So, if it=E2=80=99s goi= ng to do that, why not > just issue the query to whatever underlying library is un use like:**** > > ** ** > > webfinger.lookup('acct:paulej@packetizer.com', 'secure:true');**** > > ** ** > > Or similar. If a library is used at all, we can signal that only an HTTP= S > query shall be made.**** > > ** ** > > Perhaps I=E2=80=99m missing something?**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Blaine Cook > *Sent:* Friday, December 14, 2012 6:01 AM > *To:* webfinger@googlegroups.com > > *Cc:* John Panzer; webfinger@ietf.org; James M Snell; Goix Laurent > Walter; Brad Fitzpatrick > *Subject:* [webfinger] A third (or is it twelfth?) way [was: secure links > with https rels]**** > > ** ** > > So, all this has me thinking. And I'm going to propose something totally > against much of what I've been saying.**** > > ** ** > > Why not introduce a SECOND scheme, "accts"**** > > ** ** > > If you want a secure lookup, your request (from a client-library > perspective) will look like:**** > > ** ** > > webfinger.lookup('accts://bob@example.com')**** > > ** ** > > or just**** > > webfinger.lookup('bob@example.com')**** > > ** ** > > which will default to "accts", since that's the best-most-secure option.*= * > ** > > ** ** > > If you want an unsecured lookup, use the "acct" scheme explicitly, so as > follows:**** > > ** ** > > webfinger.lookup('acct://bob@example.com')**** > > ** ** > > For applications where it doesn't matter, and you want to do a lookup and > get EITHER the secure or unsecured profile, it's trivial for library > authors to provide an explicit flag, like so:**** > > ** ** > > webfinger.lookup('bob@example.com', { allow_fallback: true })**** > > ** ** > > OR it's easy enough for developers to do the lookup explicitly, like so:*= * > ** > > ** ** > > webfinger.lookup('accts://bob@example.com', function (err, result) {**** > > if (result) {**** > > // do something with the secure result**** > > callback(err, result)**** > > } else {**** > > // c'mon, I just need a link to their public phonecam shots profile**= * > * > > webfinger.lookup('acct://bob@example.com', callback)**** > > }**** > > }**** > > ** ** > > Does this make sense? I think it errs on the side of the HTTPS-only crowd= , > which I sympathise with even if I can't lend 100% support to. It also err= s > on the side of client simplicity, and mirrors HTTP behaviours (but defaul= ts > to secure instead of insecure, as with HTTP).**** > > ** ** > > Thoughts? Happy to try to write up some copy if this works for people.***= * > > ** ** > > b.**** > --047d7b2e110129de5004d0e384b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Laurent's comments here.

What I think w= e're both saying is that it seems clear that there is a desire to inclu= de language that prefers secure lookups of webfinger data, but allows looku= ps of unsecured data. Rather than inventing some way to signal to client de= velopers, providers, and authors of dependent protocols, let's just use= the existing approach that has been re-used in many places before.

HTTP made the "wrong" default choice from a s= ecurity perspective; when we type in a URL into a browser, the default sche= me is "http", not "https". That's fine, from an his= torical perspective, but things like HSTS and default-HTTPS lists embedded = in browsers, and indeed all of this discussion on "securing webfinger&= quot; is a reaction to that default.

Look, the only reason I'm advocating for non-SSL re= quests being allowed is purely from a deployment perspective. There are loa= ds of programmers (re: early adopters) who use github pages to host their p= ersonal domains (re: webfinger IDs). I raised this as an issue here, and re= ceived zero comments acknowledging that as a real deployment scenario.=C2= =A0There's a whole community that's not present here ("indyweb= ") that's advocating for people owning their own domains as being = the only way forward (I disagree with their absolutism on the question of h= osted services, but sympathise). It's fine if the participants here fro= m Google and Microsoft and the IETF security community want to claim that t= hey can provide secure services to their users; the fact is that there are = real scenarios today and for the foreseeable future where having real non-T= LS lookups of webfinger data would be useful.

I want this thing to be deployable. I want this communi= ty to make a commitment to supporting users outside this community.

I *really* dislike the "acct" scheme, as I'= ve made clear a number of times. There's no "dns" scheme, and= there doesn't need to be. I think the same is true of "acct"= . However, as Bob Wyman has expressed, there *should have been* a dns schem= e. We have a chance to fix that for webfinger lookups, and "accts"= ; convinces me of the need for a scheme-based approach. Indeed, if we'r= e going to have schemes at all, and if we can (please) assume that it's= at least possible to have insecure webfinger lookups, then it demands us t= o ask the question why *isn't* there an accts scheme?

Sorry for my sporadic and lengthy participation. I can&= #39;t devote the time necessary to be on the list all the time.
<= br>
b.




On 15 December 2012 07:43, Paul E. Jones= <paulej@packetizer.com> wrote:

Blaine,

=C2=A0

How does this help us?=C2=A0 Let=E2=80=99s= say I visit Bob=E2=80=99s blog and want to log in.=C2=A0 I enter my email = address and Bob=E2=80=99s blog server will issue a WF query.=C2=A0 It knows= it need to make a secure query, because it knows its own security requirem= ents.=C2=A0 It would be that client code that would have to create the =E2= =80=9Caccts=E2=80=9D URI out of what I enter.=C2=A0 So, if it=E2=80=99s goi= ng to do that, why not just issue the query to whatever underlying library = is un use like:

=C2=A0

webfinger.lookup('acct:paulej@packetizer.com', 'secure:true= ');

=C2=A0

Or similar.=C2=A0 If a library is used at all, we can signal that = only an HTTPS query shall be made.

=C2=A0

Perhaps I=E2=80=99m= missing something?

=C2=A0

Paul<= /span>

=C2=A0

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Blaine Cook
Sent: Friday, December 14, 2012 6:01 AM
To: webfinger@googlegroups.co= m


Cc: John Panzer; webfinger@ietf.org; James M = Snell; Goix Laurent Walter; Brad Fitzpatrick
Subject: [webfinger] A third (or is it twelfth?) way [was: sec= ure links with https rels]

=C2=A0

So, all this has me thinking. And I'm going to propose something tot= ally against much of what I've been saying.

=C2=A0

Why not introduce a SECOND scheme, "accts"

=C2=A0

=

If you want a secure lookup, your request (from a client-library perspectiv= e) will look like:

=C2=A0

webfinger.lookup('= accts://bob@example.co= m')

=C2=A0

or just

webfinger.lookup('bob@example.com')

=C2=A0

which will default to "accts", since that's = the best-most-secure option.

=C2=A0

If you want an unsecured lookup, use the = "acct" scheme explicitly, so as follows:

<= div>

=C2=A0

webfinger.lookup('acct://bob@example.com')

=C2=A0

For appl= ications where it doesn't matter, and you want to do a lookup and get E= ITHER the secure or unsecured profile, it's trivial for library authors= to provide an explicit flag, like so:

=C2=A0

webfinger.lookup('bob@example.com', { allow_fallback: true })=

=C2=A0

OR it's easy enough for developers to do the lookup ex= plicitly, like so:

=C2=A0

webfinger.lookup('accts://bob@example.com', functio= n (err, result) {

=C2=A0= if (result) {

=C2=A0 =C2=A0 // do something with the se= cure result

=C2=A0 =C2= =A0 callback(err, result)

=C2=A0 } else {

=C2=A0 =C2=A0 // c'mon, I just need a= link to their public phonecam shots profile

=C2=A0 =C2=A0 webfinger.lookup('acct://bob@example.com', callbac= k)

=C2=A0 }

}

= =C2=A0

Does this make sense= ? I think it errs on the side of the HTTPS-only crowd, which I sympathise w= ith even if I can't lend 100% support to. It also errs on the side of c= lient simplicity, and mirrors HTTP behaviours (but defaults to secure inste= ad of insecure, as with HTTP).

=C2=A0

Thoughts? Happy to try to write up some copy if this works= for people.

=C2= =A0

b.


--047d7b2e110129de5004d0e384b3-- From Axel.Nennker@telekom.de Sat Dec 15 05:23:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8AD21F8634 for ; Sat, 15 Dec 2012 05:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55uaC8X2L5P8 for ; Sat, 15 Dec 2012 05:23:13 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id CB52821F85E2 for ; Sat, 15 Dec 2012 05:23:11 -0800 (PST) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 15 Dec 2012 14:23:07 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Sat, 15 Dec 2012 14:23:07 +0100 From: To: , Date: Sat, 15 Dec 2012 14:23:06 +0100 Thread-Topic: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] Thread-Index: Ac3awgZ5FPrEqQ/QTXu7XeWQoojAjwABNgSw Message-ID: References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4025238F45743HE111541eme_" MIME-Version: 1.0 Cc: jpanzer@google.com, webfinger@googlegroups.com, jasnell@gmail.com, laurentwalter.goix@telecomitalia.it, webfinger@ietf.org, bradfitz@google.com Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 13:23:15 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238F45743HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFzZWQgb24gYSBzZWN1cmUtYnktZGVmYXVsdCBydWxlIHdlIGNvdWxkIGRlY2lkZSB0aGF0IOKA nGFjY3TigJ0gdHJhbnNsYXRlcyB0byBhbiBodHRwcyByZXF1ZXN0Lg0KSSB0aGluayBpdCBpcyBn b29kIHRvIG1ha2UgaXQgZWFzeSB0byBiZSBzZWN1cmUgYW5kIGN1bWJlcnNvbWUgdG8gYmUgaW5z ZWN1cmUuDQoNCndmLmxvb2t1cCjigJxhY2N0OmJhYnNAamVuc2VuLm9yZ+KAnSkgICAgLS0+IGh0 dHBzOi8vamVuc2VuLm9yZy8uLi4uDQp3Zi5sb29rdXAo4oCcYWNjdDpiYWJzQGplbnNlbi5vcmfi gJ0sIGluc2VjdXJlLT50cnVlKSAgICAtLT4gaHR0cDovL2plbnNvbi5vcmcvLi4uDQoNCg0KQXhl bA0KDQpGcm9tOiB3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndlYmZpbmdlci1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sNClNlbnQ6IFNhdHVyZGF5 LCBEZWNlbWJlciAxNSwgMjAxMiAxOjQ1IFBNDQpUbzogUGF1bCBFLiBKb25lcw0KQ2M6IEpvaG4g UGFuemVyOyB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTsgSmFtZXMgTSBTbmVsbDsgR29peCBM YXVyZW50IFdhbHRlcjsgQnJhZCBGaXR6cGF0cmljazsgd2ViZmluZ2VyQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3dlYmZpbmdlcl0gQSB0aGlyZCAob3IgaXMgaXQgdHdlbGZ0aD8pIHdheSBbd2Fz OiBzZWN1cmUgbGlua3Mgd2l0aCBodHRwcyByZWxzXQ0KDQpJIGFncmVlIHdpdGggTGF1cmVudCdz IGNvbW1lbnRzIGhlcmUuDQoNCldoYXQgSSB0aGluayB3ZSdyZSBib3RoIHNheWluZyBpcyB0aGF0 IGl0IHNlZW1zIGNsZWFyIHRoYXQgdGhlcmUgaXMgYSBkZXNpcmUgdG8gaW5jbHVkZSBsYW5ndWFn ZSB0aGF0IHByZWZlcnMgc2VjdXJlIGxvb2t1cHMgb2Ygd2ViZmluZ2VyIGRhdGEsIGJ1dCBhbGxv d3MgbG9va3VwcyBvZiB1bnNlY3VyZWQgZGF0YS4gUmF0aGVyIHRoYW4gaW52ZW50aW5nIHNvbWUg d2F5IHRvIHNpZ25hbCB0byBjbGllbnQgZGV2ZWxvcGVycywgcHJvdmlkZXJzLCBhbmQgYXV0aG9y cyBvZiBkZXBlbmRlbnQgcHJvdG9jb2xzLCBsZXQncyBqdXN0IHVzZSB0aGUgZXhpc3RpbmcgYXBw cm9hY2ggdGhhdCBoYXMgYmVlbiByZS11c2VkIGluIG1hbnkgcGxhY2VzIGJlZm9yZS4NCg0KSFRU UCBtYWRlIHRoZSAid3JvbmciIGRlZmF1bHQgY2hvaWNlIGZyb20gYSBzZWN1cml0eSBwZXJzcGVj dGl2ZTsgd2hlbiB3ZSB0eXBlIGluIGEgVVJMIGludG8gYSBicm93c2VyLCB0aGUgZGVmYXVsdCBz Y2hlbWUgaXMgImh0dHAiLCBub3QgImh0dHBzIi4gVGhhdCdzIGZpbmUsIGZyb20gYW4gaGlzdG9y aWNhbCBwZXJzcGVjdGl2ZSwgYnV0IHRoaW5ncyBsaWtlIEhTVFMgYW5kIGRlZmF1bHQtSFRUUFMg bGlzdHMgZW1iZWRkZWQgaW4gYnJvd3NlcnMsIGFuZCBpbmRlZWQgYWxsIG9mIHRoaXMgZGlzY3Vz c2lvbiBvbiAic2VjdXJpbmcgd2ViZmluZ2VyIiBpcyBhIHJlYWN0aW9uIHRvIHRoYXQgZGVmYXVs dC4NCg0KTG9vaywgdGhlIG9ubHkgcmVhc29uIEknbSBhZHZvY2F0aW5nIGZvciBub24tU1NMIHJl cXVlc3RzIGJlaW5nIGFsbG93ZWQgaXMgcHVyZWx5IGZyb20gYSBkZXBsb3ltZW50IHBlcnNwZWN0 aXZlLiBUaGVyZSBhcmUgbG9hZHMgb2YgcHJvZ3JhbW1lcnMgKHJlOiBlYXJseSBhZG9wdGVycykg d2hvIHVzZSBnaXRodWIgcGFnZXMgdG8gaG9zdCB0aGVpciBwZXJzb25hbCBkb21haW5zIChyZTog d2ViZmluZ2VyIElEcykuIEkgcmFpc2VkIHRoaXMgYXMgYW4gaXNzdWUgaGVyZSwgYW5kIHJlY2Vp dmVkIHplcm8gY29tbWVudHMgYWNrbm93bGVkZ2luZyB0aGF0IGFzIGEgcmVhbCBkZXBsb3ltZW50 IHNjZW5hcmlvLiBUaGVyZSdzIGEgd2hvbGUgY29tbXVuaXR5IHRoYXQncyBub3QgcHJlc2VudCBo ZXJlICgiaW5keXdlYiIpIHRoYXQncyBhZHZvY2F0aW5nIGZvciBwZW9wbGUgb3duaW5nIHRoZWly IG93biBkb21haW5zIGFzIGJlaW5nIHRoZSBvbmx5IHdheSBmb3J3YXJkIChJIGRpc2FncmVlIHdp dGggdGhlaXIgYWJzb2x1dGlzbSBvbiB0aGUgcXVlc3Rpb24gb2YgaG9zdGVkIHNlcnZpY2VzLCBi dXQgc3ltcGF0aGlzZSkuIEl0J3MgZmluZSBpZiB0aGUgcGFydGljaXBhbnRzIGhlcmUgZnJvbSBH b29nbGUgYW5kIE1pY3Jvc29mdCBhbmQgdGhlIElFVEYgc2VjdXJpdHkgY29tbXVuaXR5IHdhbnQg dG8gY2xhaW0gdGhhdCB0aGV5IGNhbiBwcm92aWRlIHNlY3VyZSBzZXJ2aWNlcyB0byB0aGVpciB1 c2VyczsgdGhlIGZhY3QgaXMgdGhhdCB0aGVyZSBhcmUgcmVhbCBzY2VuYXJpb3MgdG9kYXkgYW5k IGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlIHdoZXJlIGhhdmluZyByZWFsIG5vbi1UTFMgbG9v a3VwcyBvZiB3ZWJmaW5nZXIgZGF0YSB3b3VsZCBiZSB1c2VmdWwuDQoNCkkgd2FudCB0aGlzIHRo aW5nIHRvIGJlIGRlcGxveWFibGUuIEkgd2FudCB0aGlzIGNvbW11bml0eSB0byBtYWtlIGEgY29t bWl0bWVudCB0byBzdXBwb3J0aW5nIHVzZXJzIG91dHNpZGUgdGhpcyBjb21tdW5pdHkuDQoNCkkg KnJlYWxseSogZGlzbGlrZSB0aGUgImFjY3QiIHNjaGVtZSwgYXMgSSd2ZSBtYWRlIGNsZWFyIGEg bnVtYmVyIG9mIHRpbWVzLiBUaGVyZSdzIG5vICJkbnMiIHNjaGVtZSwgYW5kIHRoZXJlIGRvZXNu J3QgbmVlZCB0byBiZS4gSSB0aGluayB0aGUgc2FtZSBpcyB0cnVlIG9mICJhY2N0Ii4gSG93ZXZl ciwgYXMgQm9iIFd5bWFuIGhhcyBleHByZXNzZWQsIHRoZXJlICpzaG91bGQgaGF2ZSBiZWVuKiBh IGRucyBzY2hlbWUuIFdlIGhhdmUgYSBjaGFuY2UgdG8gZml4IHRoYXQgZm9yIHdlYmZpbmdlciBs b29rdXBzLCBhbmQgImFjY3RzIiBjb252aW5jZXMgbWUgb2YgdGhlIG5lZWQgZm9yIGEgc2NoZW1l LWJhc2VkIGFwcHJvYWNoLiBJbmRlZWQsIGlmIHdlJ3JlIGdvaW5nIHRvIGhhdmUgc2NoZW1lcyBh dCBhbGwsIGFuZCBpZiB3ZSBjYW4gKHBsZWFzZSkgYXNzdW1lIHRoYXQgaXQncyBhdCBsZWFzdCBw b3NzaWJsZSB0byBoYXZlIGluc2VjdXJlIHdlYmZpbmdlciBsb29rdXBzLCB0aGVuIGl0IGRlbWFu ZHMgdXMgdG8gYXNrIHRoZSBxdWVzdGlvbiB3aHkgKmlzbid0KiB0aGVyZSBhbiBhY2N0cyBzY2hl bWU/DQoNClNvcnJ5IGZvciBteSBzcG9yYWRpYyBhbmQgbGVuZ3RoeSBwYXJ0aWNpcGF0aW9uLiBJ IGNhbid0IGRldm90ZSB0aGUgdGltZSBuZWNlc3NhcnkgdG8gYmUgb24gdGhlIGxpc3QgYWxsIHRo ZSB0aW1lLg0KDQpiLg0KDQoNCg0KT24gMTUgRGVjZW1iZXIgMjAxMiAwNzo0MywgUGF1bCBFLiBK b25lcyA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+ PiB3cm90ZToNCkJsYWluZSwNCg0KSG93IGRvZXMgdGhpcyBoZWxwIHVzPyAgTGV04oCZcyBzYXkg SSB2aXNpdCBCb2LigJlzIGJsb2cgYW5kIHdhbnQgdG8gbG9nIGluLiAgSSBlbnRlciBteSBlbWFp bCBhZGRyZXNzIGFuZCBCb2LigJlzIGJsb2cgc2VydmVyIHdpbGwgaXNzdWUgYSBXRiBxdWVyeS4g IEl0IGtub3dzIGl0IG5lZWQgdG8gbWFrZSBhIHNlY3VyZSBxdWVyeSwgYmVjYXVzZSBpdCBrbm93 cyBpdHMgb3duIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gIEl0IHdvdWxkIGJlIHRoYXQgY2xpZW50 IGNvZGUgdGhhdCB3b3VsZCBoYXZlIHRvIGNyZWF0ZSB0aGUg4oCcYWNjdHPigJ0gVVJJIG91dCBv ZiB3aGF0IEkgZW50ZXIuICBTbywgaWYgaXTigJlzIGdvaW5nIHRvIGRvIHRoYXQsIHdoeSBub3Qg anVzdCBpc3N1ZSB0aGUgcXVlcnkgdG8gd2hhdGV2ZXIgdW5kZXJseWluZyBsaWJyYXJ5IGlzIHVu IHVzZSBsaWtlOg0KDQp3ZWJmaW5nZXIubG9va3VwKCdhY2N0OnBhdWxlakBwYWNrZXRpemVyLmNv bTxtYWlsdG86YWNjdCUzQXBhdWxlakBwYWNrZXRpemVyLmNvbT4nLCAnc2VjdXJlOnRydWUnKTsN Cg0KT3Igc2ltaWxhci4gIElmIGEgbGlicmFyeSBpcyB1c2VkIGF0IGFsbCwgd2UgY2FuIHNpZ25h bCB0aGF0IG9ubHkgYW4gSFRUUFMgcXVlcnkgc2hhbGwgYmUgbWFkZS4NCg0KUGVyaGFwcyBJ4oCZ bSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KUGF1bA0KDQpGcm9tOiB3ZWJmaW5nZXItYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86d2ViZmlu Z2VyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEJsYWluZSBDb29rDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE0LCAyMDEy IDY6MDEgQU0NClRvOiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTxtYWlsdG86d2ViZmluZ2Vy QGdvb2dsZWdyb3Vwcy5jb20+DQoNCkNjOiBKb2huIFBhbnplcjsgd2ViZmluZ2VyQGlldGYub3Jn PG1haWx0bzp3ZWJmaW5nZXJAaWV0Zi5vcmc+OyBKYW1lcyBNIFNuZWxsOyBHb2l4IExhdXJlbnQg V2FsdGVyOyBCcmFkIEZpdHpwYXRyaWNrDQpTdWJqZWN0OiBbd2ViZmluZ2VyXSBBIHRoaXJkIChv ciBpcyBpdCB0d2VsZnRoPykgd2F5IFt3YXM6IHNlY3VyZSBsaW5rcyB3aXRoIGh0dHBzIHJlbHNd DQoNClNvLCBhbGwgdGhpcyBoYXMgbWUgdGhpbmtpbmcuIEFuZCBJJ20gZ29pbmcgdG8gcHJvcG9z ZSBzb21ldGhpbmcgdG90YWxseSBhZ2FpbnN0IG11Y2ggb2Ygd2hhdCBJJ3ZlIGJlZW4gc2F5aW5n Lg0KDQpXaHkgbm90IGludHJvZHVjZSBhIFNFQ09ORCBzY2hlbWUsICJhY2N0cyINCg0KSWYgeW91 IHdhbnQgYSBzZWN1cmUgbG9va3VwLCB5b3VyIHJlcXVlc3QgKGZyb20gYSBjbGllbnQtbGlicmFy eSBwZXJzcGVjdGl2ZSkgd2lsbCBsb29rIGxpa2U6DQoNCndlYmZpbmdlci5sb29rdXAoJ2FjY3Rz Oi8vYm9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5jb20+JykNCg0Kb3IganVzdA0K d2ViZmluZ2VyLmxvb2t1cCgnYm9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5jb20+ JykNCg0Kd2hpY2ggd2lsbCBkZWZhdWx0IHRvICJhY2N0cyIsIHNpbmNlIHRoYXQncyB0aGUgYmVz dC1tb3N0LXNlY3VyZSBvcHRpb24uDQoNCklmIHlvdSB3YW50IGFuIHVuc2VjdXJlZCBsb29rdXAs IHVzZSB0aGUgImFjY3QiIHNjaGVtZSBleHBsaWNpdGx5LCBzbyBhcyBmb2xsb3dzOg0KDQp3ZWJm aW5nZXIubG9va3VwKCdhY2N0Oi8vYm9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5j b20+JykNCg0KRm9yIGFwcGxpY2F0aW9ucyB3aGVyZSBpdCBkb2Vzbid0IG1hdHRlciwgYW5kIHlv dSB3YW50IHRvIGRvIGEgbG9va3VwIGFuZCBnZXQgRUlUSEVSIHRoZSBzZWN1cmUgb3IgdW5zZWN1 cmVkIHByb2ZpbGUsIGl0J3MgdHJpdmlhbCBmb3IgbGlicmFyeSBhdXRob3JzIHRvIHByb3ZpZGUg YW4gZXhwbGljaXQgZmxhZywgbGlrZSBzbzoNCg0Kd2ViZmluZ2VyLmxvb2t1cCgnYm9iQGV4YW1w bGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5jb20+JywgeyBhbGxvd19mYWxsYmFjazogdHJ1ZSB9 KQ0KDQpPUiBpdCdzIGVhc3kgZW5vdWdoIGZvciBkZXZlbG9wZXJzIHRvIGRvIHRoZSBsb29rdXAg ZXhwbGljaXRseSwgbGlrZSBzbzoNCg0Kd2ViZmluZ2VyLmxvb2t1cCgnYWNjdHM6Ly9ib2JAZXhh bXBsZS5jb208bWFpbHRvOmJvYkBleGFtcGxlLmNvbT4nLCBmdW5jdGlvbiAoZXJyLCByZXN1bHQp IHsNCiAgaWYgKHJlc3VsdCkgew0KICAgIC8vIGRvIHNvbWV0aGluZyB3aXRoIHRoZSBzZWN1cmUg cmVzdWx0DQogICAgY2FsbGJhY2soZXJyLCByZXN1bHQpDQogIH0gZWxzZSB7DQogICAgLy8gYydt b24sIEkganVzdCBuZWVkIGEgbGluayB0byB0aGVpciBwdWJsaWMgcGhvbmVjYW0gc2hvdHMgcHJv ZmlsZQ0KICAgIHdlYmZpbmdlci5sb29rdXAoJ2FjY3Q6Ly9ib2JAZXhhbXBsZS5jb208bWFpbHRv OmJvYkBleGFtcGxlLmNvbT4nLCBjYWxsYmFjaykNCiAgfQ0KfQ0KDQpEb2VzIHRoaXMgbWFrZSBz ZW5zZT8gSSB0aGluayBpdCBlcnJzIG9uIHRoZSBzaWRlIG9mIHRoZSBIVFRQUy1vbmx5IGNyb3dk LCB3aGljaCBJIHN5bXBhdGhpc2Ugd2l0aCBldmVuIGlmIEkgY2FuJ3QgbGVuZCAxMDAlIHN1cHBv cnQgdG8uIEl0IGFsc28gZXJycyBvbiB0aGUgc2lkZSBvZiBjbGllbnQgc2ltcGxpY2l0eSwgYW5k IG1pcnJvcnMgSFRUUCBiZWhhdmlvdXJzIChidXQgZGVmYXVsdHMgdG8gc2VjdXJlIGluc3RlYWQg b2YgaW5zZWN1cmUsIGFzIHdpdGggSFRUUCkuDQoNClRob3VnaHRzPyBIYXBweSB0byB0cnkgdG8g d3JpdGUgdXAgc29tZSBjb3B5IGlmIHRoaXMgd29ya3MgZm9yIHBlb3BsZS4NCg0KYi4NCg0K --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238F45743HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5CYXNlZCBvbiBhIHNlY3VyZS1ieS1kZWZhdWx0IHJ1bGUgd2UgY291bGQgZGVjaWRl IHRoYXQg4oCcYWNjdOKAnSB0cmFuc2xhdGVzIHRvIGFuIGh0dHBzIHJlcXVlc3QuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkg dGhpbmsgaXQgaXMgZ29vZCB0byBtYWtlIGl0IGVhc3kgdG8gYmUgc2VjdXJlIGFuZCBjdW1iZXJz b21lIHRvIGJlIGluc2VjdXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+d2YubG9va3VwKOKAnGFjY3Q6 YmFic0BqZW5zZW4ub3Jn4oCdKcKgwqDCoCA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPsOgPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+IDxhIGhyZWY9Imh0dHBzOi8vamVuc2VuLm9yZy8iPmh0dHBzOi8v amVuc2VuLm9yZy88L2E+Li4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz53Zi5sb29rdXAo4oCcYWNjdDpiYWJzQGplbnNlbi5v cmfigJ0sIGluc2VjdXJlLSZndDt0cnVlKcKgwqDCoCA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPsOgPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IDxhIGhyZWY9Imh0dHA6Ly9qZW5zb24ub3JnLyI+aHR0 cDovL2plbnNvbi5vcmcvPC9hPi4uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5B eGVsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gd2ViZmluZ2VyLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzp3ZWJmaW5nZXItYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9m IDwvYj5CbGFpbmUgQ29vazxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIERlY2VtYmVyIDE1LCAy MDEyIDE6NDUgUE08YnI+PGI+VG86PC9iPiBQYXVsIEUuIEpvbmVzPGJyPjxiPkNjOjwvYj4gSm9o biBQYW56ZXI7IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tOyBKYW1lcyBNIFNuZWxsOyBHb2l4 IExhdXJlbnQgV2FsdGVyOyBCcmFkIEZpdHpwYXRyaWNrOyB3ZWJmaW5nZXJAaWV0Zi5vcmc8YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBbd2ViZmluZ2VyXSBBIHRoaXJkIChvciBpcyBpdCB0d2VsZnRo Pykgd2F5IFt3YXM6IHNlY3VyZSBsaW5rcyB3aXRoIGh0dHBzIHJlbHNdPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+SSBhZ3JlZSB3aXRoIExhdXJlbnQncyBjb21tZW50cyBoZXJlLjxvOnA+PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoYXQgSSB0aGluayB3ZSdyZSBib3RoIHNheWluZyBpcyB0 aGF0IGl0IHNlZW1zIGNsZWFyIHRoYXQgdGhlcmUgaXMgYSBkZXNpcmUgdG8gaW5jbHVkZSBsYW5n dWFnZSB0aGF0IHByZWZlcnMgc2VjdXJlIGxvb2t1cHMgb2Ygd2ViZmluZ2VyIGRhdGEsIGJ1dCBh bGxvd3MgbG9va3VwcyBvZiB1bnNlY3VyZWQgZGF0YS4gUmF0aGVyIHRoYW4gaW52ZW50aW5nIHNv bWUgd2F5IHRvIHNpZ25hbCB0byBjbGllbnQgZGV2ZWxvcGVycywgcHJvdmlkZXJzLCBhbmQgYXV0 aG9ycyBvZiBkZXBlbmRlbnQgcHJvdG9jb2xzLCBsZXQncyBqdXN0IHVzZSB0aGUgZXhpc3Rpbmcg YXBwcm9hY2ggdGhhdCBoYXMgYmVlbiByZS11c2VkIGluIG1hbnkgcGxhY2VzIGJlZm9yZS48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IVFRQIG1hZGUgdGhlICZxdW90O3dy b25nJnF1b3Q7IGRlZmF1bHQgY2hvaWNlIGZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZTsgd2hl biB3ZSB0eXBlIGluIGEgVVJMIGludG8gYSBicm93c2VyLCB0aGUgZGVmYXVsdCBzY2hlbWUgaXMg JnF1b3Q7aHR0cCZxdW90Oywgbm90ICZxdW90O2h0dHBzJnF1b3Q7LiBUaGF0J3MgZmluZSwgZnJv bSBhbiBoaXN0b3JpY2FsIHBlcnNwZWN0aXZlLCBidXQgdGhpbmdzIGxpa2UgSFNUUyBhbmQgZGVm YXVsdC1IVFRQUyBsaXN0cyBlbWJlZGRlZCBpbiBicm93c2VycywgYW5kIGluZGVlZCBhbGwgb2Yg dGhpcyBkaXNjdXNzaW9uIG9uICZxdW90O3NlY3VyaW5nIHdlYmZpbmdlciZxdW90OyBpcyBhIHJl YWN0aW9uIHRvIHRoYXQgZGVmYXVsdC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5Mb29rLCB0aGUgb25seSByZWFzb24gSSdtIGFkdm9jYXRpbmcgZm9yIG5vbi1TU0wgcmVx dWVzdHMgYmVpbmcgYWxsb3dlZCBpcyBwdXJlbHkgZnJvbSBhIGRlcGxveW1lbnQgcGVyc3BlY3Rp dmUuIFRoZXJlIGFyZSBsb2FkcyBvZiBwcm9ncmFtbWVycyAocmU6IGVhcmx5IGFkb3B0ZXJzKSB3 aG8gdXNlIGdpdGh1YiBwYWdlcyB0byBob3N0IHRoZWlyIHBlcnNvbmFsIGRvbWFpbnMgKHJlOiB3 ZWJmaW5nZXIgSURzKS4gSSByYWlzZWQgdGhpcyBhcyBhbiBpc3N1ZSBoZXJlLCBhbmQgcmVjZWl2 ZWQgemVybyBjb21tZW50cyBhY2tub3dsZWRnaW5nIHRoYXQgYXMgYSByZWFsIGRlcGxveW1lbnQg c2NlbmFyaW8uJm5ic3A7VGhlcmUncyBhIHdob2xlIGNvbW11bml0eSB0aGF0J3Mgbm90IHByZXNl bnQgaGVyZSAoJnF1b3Q7aW5keXdlYiZxdW90OykgdGhhdCdzIGFkdm9jYXRpbmcgZm9yIHBlb3Bs ZSBvd25pbmcgdGhlaXIgb3duIGRvbWFpbnMgYXMgYmVpbmcgdGhlIG9ubHkgd2F5IGZvcndhcmQg KEkgZGlzYWdyZWUgd2l0aCB0aGVpciBhYnNvbHV0aXNtIG9uIHRoZSBxdWVzdGlvbiBvZiBob3N0 ZWQgc2VydmljZXMsIGJ1dCBzeW1wYXRoaXNlKS4gSXQncyBmaW5lIGlmIHRoZSBwYXJ0aWNpcGFu dHMgaGVyZSBmcm9tIEdvb2dsZSBhbmQgTWljcm9zb2Z0IGFuZCB0aGUgSUVURiBzZWN1cml0eSBj b21tdW5pdHkgd2FudCB0byBjbGFpbSB0aGF0IHRoZXkgY2FuIHByb3ZpZGUgc2VjdXJlIHNlcnZp Y2VzIHRvIHRoZWlyIHVzZXJzOyB0aGUgZmFjdCBpcyB0aGF0IHRoZXJlIGFyZSByZWFsIHNjZW5h cmlvcyB0b2RheSBhbmQgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUgd2hlcmUgaGF2aW5nIHJl YWwgbm9uLVRMUyBsb29rdXBzIG9mIHdlYmZpbmdlciBkYXRhIHdvdWxkIGJlIHVzZWZ1bC48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIHdhbnQgdGhpcyB0aGluZyB0byBi ZSBkZXBsb3lhYmxlLiBJIHdhbnQgdGhpcyBjb21tdW5pdHkgdG8gbWFrZSBhIGNvbW1pdG1lbnQg dG8gc3VwcG9ydGluZyB1c2VycyBvdXRzaWRlIHRoaXMgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgKnJlYWxseSogZGlzbGlrZSB0aGUgJnF1b3Q7YWNj dCZxdW90OyBzY2hlbWUsIGFzIEkndmUgbWFkZSBjbGVhciBhIG51bWJlciBvZiB0aW1lcy4gVGhl cmUncyBubyAmcXVvdDtkbnMmcXVvdDsgc2NoZW1lLCBhbmQgdGhlcmUgZG9lc24ndCBuZWVkIHRv IGJlLiBJIHRoaW5rIHRoZSBzYW1lIGlzIHRydWUgb2YgJnF1b3Q7YWNjdCZxdW90Oy4gSG93ZXZl ciwgYXMgQm9iIFd5bWFuIGhhcyBleHByZXNzZWQsIHRoZXJlICpzaG91bGQgaGF2ZSBiZWVuKiBh IGRucyBzY2hlbWUuIFdlIGhhdmUgYSBjaGFuY2UgdG8gZml4IHRoYXQgZm9yIHdlYmZpbmdlciBs b29rdXBzLCBhbmQgJnF1b3Q7YWNjdHMmcXVvdDsgY29udmluY2VzIG1lIG9mIHRoZSBuZWVkIGZv ciBhIHNjaGVtZS1iYXNlZCBhcHByb2FjaC4gSW5kZWVkLCBpZiB3ZSdyZSBnb2luZyB0byBoYXZl IHNjaGVtZXMgYXQgYWxsLCBhbmQgaWYgd2UgY2FuIChwbGVhc2UpIGFzc3VtZSB0aGF0IGl0J3Mg YXQgbGVhc3QgcG9zc2libGUgdG8gaGF2ZSBpbnNlY3VyZSB3ZWJmaW5nZXIgbG9va3VwcywgdGhl biBpdCBkZW1hbmRzIHVzIHRvIGFzayB0aGUgcXVlc3Rpb24gd2h5ICppc24ndCogdGhlcmUgYW4g YWNjdHMgc2NoZW1lPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNvcnJ5 IGZvciBteSBzcG9yYWRpYyBhbmQgbGVuZ3RoeSBwYXJ0aWNpcGF0aW9uLiBJIGNhbid0IGRldm90 ZSB0aGUgdGltZSBuZWNlc3NhcnkgdG8gYmUgb24gdGhlIGxpc3QgYWxsIHRoZSB0aW1lLjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPmIuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiAxNSBEZWNlbWJlciAyMDEyIDA3OjQzLCBQ YXVsIEUuIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cGF1bGVqQHBhY2tldGl6ZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+QmxhaW5lLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBkb2VzIHRoaXMgaGVscCB1 cz8mbmJzcDsgTGV04oCZcyBzYXkgSSB2aXNpdCBCb2LigJlzIGJsb2cgYW5kIHdhbnQgdG8gbG9n IGluLiZuYnNwOyBJIGVudGVyIG15IGVtYWlsIGFkZHJlc3MgYW5kIEJvYuKAmXMgYmxvZyBzZXJ2 ZXIgd2lsbCBpc3N1ZSBhIFdGIHF1ZXJ5LiZuYnNwOyBJdCBrbm93cyBpdCBuZWVkIHRvIG1ha2Ug YSBzZWN1cmUgcXVlcnksIGJlY2F1c2UgaXQga25vd3MgaXRzIG93biBzZWN1cml0eSByZXF1aXJl bWVudHMuJm5ic3A7IEl0IHdvdWxkIGJlIHRoYXQgY2xpZW50IGNvZGUgdGhhdCB3b3VsZCBoYXZl IHRvIGNyZWF0ZSB0aGUg4oCcYWNjdHPigJ0gVVJJIG91dCBvZiB3aGF0IEkgZW50ZXIuJm5ic3A7 IFNvLCBpZiBpdOKAmXMgZ29pbmcgdG8gZG8gdGhhdCwgd2h5IG5vdCBqdXN0IGlzc3VlIHRoZSBx dWVyeSB0byB3aGF0ZXZlciB1bmRlcmx5aW5nIGxpYnJhcnkgaXMgdW4gdXNlIGxpa2U6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1p bmRlbnQ6OS4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+d2ViZmluZ2VyLmxvb2t1cCgnPGEg aHJlZj0ibWFpbHRvOmFjY3QlM0FwYXVsZWpAcGFja2V0aXplci5jb20iIHRhcmdldD0iX2JsYW5r Ij5hY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbTwvYT4nLCAnc2VjdXJlOnRydWUnKTs8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDo5LjBwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5PciBzaW1pbGFyLiZuYnNwOyBJZiBh IGxpYnJhcnkgaXMgdXNlZCBhdCBhbGwsIHdlIGNhbiBzaWduYWwgdGhhdCBvbmx5IGFuIEhUVFBT IHF1ZXJ5IHNoYWxsIGJlIG1hZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGVyaGFwcyBJ4oCZ bSBtaXNzaW5nIHNvbWV0aGluZz88L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QYXVsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlci1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+d2ViZmluZ2VyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYg T2YgPC9iPkJsYWluZSBDb29rPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDE0LCAy MDEyIDY6MDEgQU08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86d2ViZmluZ2VyQGdvb2ds ZWdyb3Vwcy5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbTwv YT48L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxiPkNj OjwvYj4gSm9obiBQYW56ZXI7IDxhIGhyZWY9Im1haWx0bzp3ZWJmaW5nZXJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj53ZWJmaW5nZXJAaWV0Zi5vcmc8L2E+OyBKYW1lcyBNIFNuZWxsOyBHb2l4 IExhdXJlbnQgV2FsdGVyOyBCcmFkIEZpdHpwYXRyaWNrPG86cD48L286cD48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPlN1YmplY3Q6PC9iPiBbd2ViZmluZ2VyXSBBIHRoaXJkIChvciBp cyBpdCB0d2VsZnRoPykgd2F5IFt3YXM6IHNlY3VyZSBsaW5rcyB3aXRoIGh0dHBzIHJlbHNdPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlNvLCBhbGwgdGhpcyBoYXMg bWUgdGhpbmtpbmcuIEFuZCBJJ20gZ29pbmcgdG8gcHJvcG9zZSBzb21ldGhpbmcgdG90YWxseSBh Z2FpbnN0IG11Y2ggb2Ygd2hhdCBJJ3ZlIGJlZW4gc2F5aW5nLjxvOnA+PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz5XaHkgbm90IGludHJvZHVjZSBhIFNFQ09ORCBzY2hlbWUsICZxdW90 O2FjY3RzJnF1b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPklm IHlvdSB3YW50IGEgc2VjdXJlIGxvb2t1cCwgeW91ciByZXF1ZXN0IChmcm9tIGEgY2xpZW50LWxp YnJhcnkgcGVyc3BlY3RpdmUpIHdpbGwgbG9vayBsaWtlOjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz53ZWJmaW5nZXIubG9va3VwKCdhY2N0czovLzxhIGhyZWY9Im1h aWx0bzpib2JAZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ib2JAZXhhbXBsZS5jb208L2E+ Jyk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+b3IganVzdDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+d2ViZmluZ2VyLmxvb2t1 cCgnPGEgaHJlZj0ibWFpbHRvOmJvYkBleGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJvYkBl eGFtcGxlLmNvbTwvYT4nKTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz53aGljaCB3aWxsIGRlZmF1bHQgdG8gJnF1b3Q7YWNjdHMmcXVvdDssIHNpbmNlIHRoYXQncyB0 aGUgYmVzdC1tb3N0LXNlY3VyZSBvcHRpb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPklmIHlvdSB3YW50IGFuIHVuc2VjdXJlZCBsb29rdXAsIHVzZSB0aGUgJnF1 b3Q7YWNjdCZxdW90OyBzY2hlbWUgZXhwbGljaXRseSwgc28gYXMgZm9sbG93czo8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+d2ViZmluZ2VyLmxvb2t1cCgnYWNjdDov LzxhIGhyZWY9Im1haWx0bzpib2JAZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ib2JAZXhh bXBsZS5jb208L2E+Jyk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ Rm9yIGFwcGxpY2F0aW9ucyB3aGVyZSBpdCBkb2Vzbid0IG1hdHRlciwgYW5kIHlvdSB3YW50IHRv IGRvIGEgbG9va3VwIGFuZCBnZXQgRUlUSEVSIHRoZSBzZWN1cmUgb3IgdW5zZWN1cmVkIHByb2Zp bGUsIGl0J3MgdHJpdmlhbCBmb3IgbGlicmFyeSBhdXRob3JzIHRvIHByb3ZpZGUgYW4gZXhwbGlj aXQgZmxhZywgbGlrZSBzbzo8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+d2ViZmluZ2VyLmxvb2t1cCgnPGEgaHJlZj0ibWFpbHRvOmJvYkBleGFtcGxlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmJvYkBleGFtcGxlLmNvbTwvYT4nLCB7IGFsbG93X2ZhbGxiYWNrOiB0cnVl IH0pPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk9SIGl0J3MgZWFz eSBlbm91Z2ggZm9yIGRldmVsb3BlcnMgdG8gZG8gdGhlIGxvb2t1cCBleHBsaWNpdGx5LCBsaWtl IHNvOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz53ZWJmaW5nZXIu bG9va3VwKCdhY2N0czovLzxhIGhyZWY9Im1haWx0bzpib2JAZXhhbXBsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5ib2JAZXhhbXBsZS5jb208L2E+JywgZnVuY3Rpb24gKGVyciwgcmVzdWx0KSB7PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDsgaWYgKHJl c3VsdCkgezxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5i c3A7ICZuYnNwOyAvLyBkbyBzb21ldGhpbmcgd2l0aCB0aGUgc2VjdXJlIHJlc3VsdDxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7ICZuYnNwOyBjYWxs YmFjayhlcnIsIHJlc3VsdCk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPiZuYnNwOyB9IGVsc2UgezxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+Jm5ic3A7ICZuYnNwOyAvLyBjJ21vbiwgSSBqdXN0IG5lZWQgYSBsaW5rIHRv IHRoZWlyIHB1YmxpYyBwaG9uZWNhbSBzaG90cyBwcm9maWxlPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDsgJm5ic3A7IHdlYmZpbmdlci5sb29rdXAo J2FjY3Q6Ly88YSBocmVmPSJtYWlsdG86Ym9iQGV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Ym9iQGV4YW1wbGUuY29tPC9hPicsIGNhbGxiYWNrKTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPn08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IEkgdGhpbmsgaXQgZXJycyBvbiB0aGUgc2lkZSBv ZiB0aGUgSFRUUFMtb25seSBjcm93ZCwgd2hpY2ggSSBzeW1wYXRoaXNlIHdpdGggZXZlbiBpZiBJ IGNhbid0IGxlbmQgMTAwJSBzdXBwb3J0IHRvLiBJdCBhbHNvIGVycnMgb24gdGhlIHNpZGUgb2Yg Y2xpZW50IHNpbXBsaWNpdHksIGFuZCBtaXJyb3JzIEhUVFAgYmVoYXZpb3VycyAoYnV0IGRlZmF1 bHRzIHRvIHNlY3VyZSBpbnN0ZWFkIG9mIGluc2VjdXJlLCBhcyB3aXRoIEhUVFApLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5UaG91Z2h0cz8gSGFwcHkgdG8gdHJ5 IHRvIHdyaXRlIHVwIHNvbWUgY29weSBpZiB0aGlzIHdvcmtzIGZvciBwZW9wbGUuPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPmIuPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_CE8995AB5D178F44A2154F5C9A97CAF4025238F45743HE111541eme_-- From romeda@gmail.com Sat Dec 15 05:26:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5328821F8834 for ; Sat, 15 Dec 2012 05:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3+MPST5qLh7 for ; Sat, 15 Dec 2012 05:26:58 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA98321F8588 for ; Sat, 15 Dec 2012 05:26:58 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2813237pad.31 for ; Sat, 15 Dec 2012 05:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W9Sb188Vp6Wb43tuVQlBhmTH/St75XlKNjUpwfqhUgo=; b=cEKlVlOhcYBcIw+i2Ni+oyEK0SZoNOJbz8CggXRFu/h9xGxR2aQDzESyc7XhnyfEi1 jeckEpg0sRuqdQHgtB21spIwyCMwJoJJgAzv2GEHwSejlpH5S8NqpG4X0Q1akcPu166M z/tWaOS3tfgoAZw82Kd9VYUz6cVHJDDZry7UUQOLE7EbelFLamQUY3XKzyMtSZ0eZAuV ghIuISxyZng184QLC54pcln6BT7aqBP8f3k1AHjQ1O/be1jfiAEhSC+DBvYD0+pNy/dD QhKXb9C/2ndz/T4c1El19LZo8XI1+CZEhqM7dMIxP4v7uD6fwfWH5l3uyxYQQq5WUBUi g+Uw== Received: by 10.68.197.68 with SMTP id is4mr24879616pbc.30.1355578018510; Sat, 15 Dec 2012 05:26:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Sat, 15 Dec 2012 05:26:38 -0800 (PST) In-Reply-To: References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> From: Blaine Cook Date: Sat, 15 Dec 2012 13:26:38 +0000 Message-ID: To: Axel.Nennker@telekom.de Content-Type: multipart/alternative; boundary=e89a8ff1c86242364b04d0e41a9e Cc: John Panzer , webfinger@googlegroups.com, Paul Jones , James Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 13:26:59 -0000 --e89a8ff1c86242364b04d0e41a9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 December 2012 13:23, wrote: > Based on a secure-by-default rule we could decide that =E2=80=9Cacct=E2= =80=9D translates > to an https request.**** > > I think it is good to make it easy to be secure and cumbersome to be > insecure.**** > > ** ** > > wf.lookup(=E2=80=9Cacct:babs@jensen.org=E2=80=9D) =C3=A0 https://jense= n.org/....**** > > wf.lookup(=E2=80=9Cacct:babs@jensen.org=E2=80=9D, insecure->true) =C3= =A0 http://jenson.org/ > ... > I don't see how that's any different than just saying "webfinger is always secure (except when it's not, but the standards committee doesn't want to think about how this is used in the real world, so please don't tell us what you actually do with it)"? b. --e89a8ff1c86242364b04d0e41a9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 15 December 2012 1= 3:23, <Axel.Nennker@telekom.de> wrote:

Based on a secure-by-default rule we could d= ecide that =E2=80=9Cacct=E2=80=9D translates to an https request.=

I think it is good to mak= e it easy to be secure and cumbersome to be insecure.<= /p>

=C2=A0

wf.lookup(=E2=80=9C= acct:babs@jense= n.org=E2=80=9D)=C2=A0=C2=A0=C2=A0 =C3=A0 https://jensen.org/<= /a>....

wf.lookup(=E2=80=9Cacct:babs@jensen.org<= /a>=E2=80=9D, insecure->true)=C2=A0=C2=A0=C2=A0 =C3=A0 http://j= enson.org/...


I don't see how that's= any different than just saying "webfinger is always secure (except wh= en it's not, but the standards committee doesn't want to think abou= t how this is used in the real world, so please don't tell us what you = actually do with it)"?

b.=C2=A0
--e89a8ff1c86242364b04d0e41a9e-- From nick@silverbucket.net Sat Dec 15 05:32:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAF921F8864 for ; Sat, 15 Dec 2012 05:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hy2TX2bxms2 for ; Sat, 15 Dec 2012 05:32:21 -0800 (PST) Received: from mail-la0-f66.google.com (mail-la0-f66.google.com [209.85.215.66]) by ietfa.amsl.com (Postfix) with ESMTP id A57EA21F885C for ; Sat, 15 Dec 2012 05:32:20 -0800 (PST) Received: by mail-la0-f66.google.com with SMTP id e6so621395lah.1 for ; Sat, 15 Dec 2012 05:32:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=16U+HDy2qs5XPUm5NPZFyAutHMcgIhR1NbinJa3oiw8=; b=KJn52h7oPaTcBIrIKyx0p566Pkt/KKGlOzZ94lKajBPbjJo+w55gIJAy3ltSV7VETb qvg18v8q63mig5Vu0DsmMD+HoFi35Nc4S+8t72YzurGZhqY2QPZ9Zu62608vQICBYARb /bVYtdppCjn9M6Dxe6NHOiakCpxN0kJzqZlrvgjjYsm2tbVUdqG5ZZ/8VA986V3VWYLJ d9aH5WcsWUwdpQr1iqkdAAN1q7w+2kc8R+5wm2lnz+XJ1JzXi+SYGbC2HhBfazNT6bbm +pVgd3XUKU5P8HIW0wXeZaSILEnHWrzlG/iUn3XQq63Nrn3Ha80dodI7qbFSA9n0bTmC Y39Q== Received: by 10.152.108.37 with SMTP id hh5mr5561089lab.52.1355578339658; Sat, 15 Dec 2012 05:32:19 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id lr20sm2832208lab.17.2012.12.15.05.32.18 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 05:32:19 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3521419lah.31 for ; Sat, 15 Dec 2012 05:32:18 -0800 (PST) Received: by 10.112.38.66 with SMTP id e2mr3446395lbk.90.1355578338446; Sat, 15 Dec 2012 05:32:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 05:31:48 -0800 (PST) In-Reply-To: References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> From: Nick Jennings Date: Sat, 15 Dec 2012 14:31:48 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlllq4AY/ifBHgfse8GXIPVUO5AwC/Pxni7X04ndfkMNJcecovY3ilAmZUMWSzrZ+Elqxqz Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 13:32:21 -0000 On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook wrote: > > Look, the only reason I'm advocating for non-SSL requests being allowed is > purely from a deployment perspective. There are loads of programmers (re: > early adopters) who use github pages to host their personal domains (re: > webfinger IDs). I raised this as an issue here, and received zero comments > acknowledging that as a real deployment scenario. There's a whole community > that's not present here ("indyweb") that's advocating for people owning > their own domains as being the only way forward (I disagree with their > absolutism on the question of hosted services, but sympathise). On the contrary, I consider myself a part of this community and I think there are a few others wandering about. :) > It's fine if > the participants here from Google and Microsoft and the IETF security > community want to claim that they can provide secure services to their > users; the fact is that there are real scenarios today and for the > foreseeable future where having real non-TLS lookups of webfinger data would > be useful. > I want this thing to be deployable. I want this community to make a > commitment to supporting users outside this community. +1 From nick@silverbucket.net Sat Dec 15 08:05:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670D21F85ED for ; Sat, 15 Dec 2012 08:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDybmGQuMgCK for ; Sat, 15 Dec 2012 08:05:42 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79021F85C4 for ; Sat, 15 Dec 2012 08:05:41 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3583825lah.31 for ; Sat, 15 Dec 2012 08:05:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Mnv1cxrJtoZpmme5TA1qrcfVC0bpuEvA5iYqoAkWgWo=; b=Ha4JD6hBwcGLhDiAJpfMhUGldAappSWnr7Pa6GCj7r1wCErv7s4ys+YsC/5BYHxXnS I61I5Wro9bQK/q8GJ/QtR1qSdUyzHfkZZbBN94fge2gE39O+gH0mPbkS+SWSPsq32+IX AQigzQbt/AxrqBlU6vkq33PmlYgc9Dng+P6i1qBdr8dTEQr+BDt3sqiYEWL39b5CkWUM Kq3zRj81NC2ABdGS5vo2p/Ppmz9gKk+kjUp5dX7oMnTawWvjC7E4fBU1+Z2NnfmOe+r5 eX7H6ZI2ElGnbBirf5AWY1XuOoezILVHztA6WbwlKc167kRTgVAjxxgrDGsX2ttj+vmI ERBw== Received: by 10.112.10.71 with SMTP id g7mr3711393lbb.70.1355587540850; Sat, 15 Dec 2012 08:05:40 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id pw17sm2947925lab.5.2012.12.15.08.05.39 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 08:05:40 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3596576lbk.31 for ; Sat, 15 Dec 2012 08:05:39 -0800 (PST) Received: by 10.112.11.99 with SMTP id p3mr3729028lbb.73.1355587539580; Sat, 15 Dec 2012 08:05:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 08:05:09 -0800 (PST) In-Reply-To: <50CC9F00.50303@openlinksw.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> From: Nick Jennings Date: Sat, 15 Dec 2012 17:05:09 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0402dd78c2387004d0e65162 X-Gm-Message-State: ALoCoQnjX+jUg9NCc4MymIsg5e6lrT1UvKcGD/TAt+k5UGxaUIYA4UekzK4VItGJtftMxqoVICsy Cc: "Paul E. Jones" , webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:05:43 -0000 --f46d0402dd78c2387004d0e65162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are we foregoing the secure links filtering idea? On Sat, Dec 15, 2012 at 5:02 PM, Kingsley Idehen wr= ote: > On 12/15/12 2:56 AM, Paul E. Jones wrote: > > Folks,**** > > ** ** > > Here=E2=80=99s the current language. I get the feeling more people like = this than > what we had before. Now, what fine-tuning do we need to do? Or are peop= le > still of the mind that we need HTTPS only no matter what?**** > > ** ** > > Current language:**** > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, > either serially or in parallel=E2=80=9D. Let the client decide what to d= o based on > its security requirements.**** > > ** ** > > I would like to suggest we change =E2=80=9CIf a query is issued using HTT= PS=E2=80=9D to > =E2=80=9CIf a query is issued using HTTPS because it has strict security > requirements=E2=80=9D. Reasoning, again, is that if a client like a blog= server > issues a query via HTTPS looking for a user=E2=80=99s avatar and it fails= , why not > let it use HTTP? Actually, we could probably just remove this whole seco= nd > paragraph. We could just speak to the certificate checking on the securi= ty > section as it relates to secure clients.**** > > ** ** > > Thus, I propose we go with this (with or without the middle paragraph):**= * > * > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS because it has strict security > requirements and the server has an invalid certificate, the server return= s > a 4xx or 5xx status code, or the HTTPS connection cannot be established f= or > any reason, the client MUST accept that the WebFinger query has failed an= d > MUST NOT attempt to reissue the WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > Paul**** > > ** ** > > +1 > > -- > > Regards, > > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > --f46d0402dd78c2387004d0e65162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are we foregoing the secure links filtering idea?

On Sat, Dec 15, 2012 at 5:02 PM, Kingsley Idehen <kidehen@op= enlinksw.com> wrote:
=20 =20 =20
On 12/15/12 2:56 AM, Paul E. Jones wrote:
=20 =20 =20

Folks,

=C2=A0

Here=E2=80=99s the current language.=C2=A0 I= get the feeling more people like this than what we had before.=C2=A0 Now, what fine-tuning do we need to do?=C2=A0 Or are people still of t= he mind that we need HTTPS only no matter what?

=C2=A0

Current language:

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel.=C2=A0 The choice of transport protocols depends on the client=E2=80=99s security requirements, though use= of HTTPS is RECOMMENDED in most situations.

=C2=A0

If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

=C2=A0

I would like to suggest we strike =E2=80=9C,= but MUST NOT attempt to use both, either serially or in parallel=E2=80=9D.=C2=A0 Let the client decide what to do based o= n its security requirements.

=C2=A0

I would like to suggest we change =E2=80=9CI= f a query is issued using HTTPS=E2=80=9D to =E2=80=9CIf a query is is= sued using HTTPS because it has strict security requirements=E2=80=9D.=C2=A0 Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user=E2=80=99s avatar and = it fails, why not let it use HTTP?=C2=A0 Actually, we could probably just remove this whole second paragraph.=C2=A0 We could just spea= k to the certificate checking on the security section as it relates to secure clients.

=C2=A0

Thus, I propose we go with this (with or without the middle paragraph):

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP.=C2=A0 The choice of transport protocols depends on the client=E2=80= =99s security requirements, though use of HTTPS is RECOMMENDED in most situations.

=C2=A0

If a query is issued using HTTPS because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

=C2=A0

Paul

=C2=A0

+1

--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen

--f46d0402dd78c2387004d0e65162-- From dick.hardt@gmail.com Sat Dec 15 08:19:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16A121F85CF for ; Sat, 15 Dec 2012 08:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXBZq51QroXq for ; Sat, 15 Dec 2012 08:19:47 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 137FC21F84D7 for ; Sat, 15 Dec 2012 08:19:47 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1859759dae.31 for ; Sat, 15 Dec 2012 08:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=uL7Z70MrOXKNbFC8rhyHVT99zpHOwyg/iu0/gcAvRvA=; b=eKpGUKvSlJMsONfPRSP8cpS8ZylJqtTPI9vLJrxMYnisqo/MnpEAr2yxsXUh2b+JZ9 8uUn0ALKFDNX926kTnI1m7I2jLPCjgkCA7a6WnR4yp4D2K2vhF0pUpxC9oAAiyCkjCmZ 1U2oPWAs58R00DS9IBB88BqkBB6HZbS3uJhyW4LQ8u8EwhFquAOJvDjaCtzRTSHmUK9S CxuGH1jn0XD0dQGgr8IRpc0iiboUN8r9IFm8aGYhrZHuQejk5NvcBiupgs4SyDFrkOh4 tnI9/DVsTzrtg3XAQiXIOEGTVdO3JrN0XdTSHoDmflQ/q2uHR6Qx/nyvJmEq3O2rM2ON L03g== Received: by 10.68.252.135 with SMTP id zs7mr2473167pbc.45.1355588386885; Sat, 15 Dec 2012 08:19:46 -0800 (PST) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hs2sm4932156pbc.22.2012.12.15.08.19.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 08:19:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F26537F4-2B64-4FBC-9575-CF167CC27FDE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> Date: Sat, 15 Dec 2012 08:19:43 -0800 Message-Id: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:19:48 -0000 --Apple-Mail=_F26537F4-2B64-4FBC-9575-CF167CC27FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +0.5 I think the language at the bottom is better than the language at the = top. I continue to feel that HTTPS only is better, but perhaps HTTPS only = deployments will be driven by clients that will ONLY support HTTPS. = Given the strong desire by some (even though they fail to explain why = :), this may be the best that we can do to reach consensus. -- Dick On Dec 14, 2012, at 11:56 PM, "Paul E. Jones" = wrote: > Folks, > =20 > Here=92s the current language. I get the feeling more people like = this than what we had before. Now, what fine-tuning do we need to do? = Or are people still of the mind that we need HTTPS only no matter what? > =20 > Current language: > =20 > Clients MAY issue a query to the WebFinger server using either HTTPS = or HTTP, but MUST NOT attempt to use both, either serially or in = parallel. The choice of transport protocols depends on the client=92s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. > =20 > If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and MUST NOT attempt to reissue the = WebFinger request using HTTP. > =20 > WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. > =20 > I would like to suggest we strike =93, but MUST NOT attempt to use = both, either serially or in parallel=94. Let the client decide what to = do based on its security requirements. > =20 > I would like to suggest we change =93If a query is issued using HTTPS=94= to =93If a query is issued using HTTPS because it has strict security = requirements=94. Reasoning, again, is that if a client like a blog = server issues a query via HTTPS looking for a user=92s avatar and it = fails, why not let it use HTTP? Actually, we could probably just remove = this whole second paragraph. We could just speak to the certificate = checking on the security section as it relates to secure clients. > =20 > Thus, I propose we go with this (with or without the middle = paragraph): > =20 > Clients MAY issue a query to the WebFinger server using either HTTPS = or HTTP. The choice of transport protocols depends on the client=92s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. > =20 > If a query is issued using HTTPS because it has strict security = requirements and the server has an invalid certificate, the server = returns a 4xx or 5xx status code, or the HTTPS connection cannot be = established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP. > =20 > WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. > =20 > Paul --Apple-Mail=_F26537F4-2B64-4FBC-9575-CF167CC27FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +0.5

I think = the language at the bottom is better than the language at the = top.

I continue to feel that HTTPS only is better, = but perhaps HTTPS only deployments will be driven by clients that will = ONLY support HTTPS. Given the strong desire by some (even though they = fail to explain why :), this may be the best that we can do to reach = consensus.

-- Dick
On Dec 14, = 2012, at 11:56 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Folks,
Here=92s the = current language.  I get the feeling more people like this than = what we had before.  Now, what fine-tuning do we need to do?  = Or are people still of the mind that we need HTTPS only no matter = what?
 
Current language:
 
Clients MAY issue a = query to the WebFinger server using either HTTPS or HTTP, but MUST NOT = attempt to use both, either serially or in parallel.  The choice of = transport protocols depends on the client=92s security requirements, = though use of HTTPS is RECOMMENDED in most = situations.
If a query is = issued using HTTPS and the server has an invalid certificate, the server = returns a 4xx or 5xx status code, or the HTTPS connection cannot be = established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP.
WebFinger servers = operating on HTTP MAY redirect a client using an appropriate HTTP status = code to another HTTP or an HTTPS URI.  Likewise, WebFinger servers = operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST = NOT redirect a client to an HTTP URI.  Further, clients MUST NOT = follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD = automatically follow all other server = redirects.
I would like to = suggest we strike =93, but MUST NOT attempt to use both, either serially = or in parallel=94.  Let the client decide what to do based on its = security requirements.
I would like to = suggest we change =93If a query is issued using HTTPS=94 to =93If a = query is issued using HTTPS because it has strict security = requirements=94.  Reasoning, again, is that if a client like a blog = server issues a query via HTTPS looking for a user=92s avatar and it = fails, why not let it use HTTP?  Actually, we could probably just = remove this whole second paragraph.  We could just speak to the = certificate checking on the security section as it relates to secure = clients.
Thus, I propose we = go with this (with or without the middle = paragraph):
Clients MAY issue a query to the WebFinger server = using either HTTPS or HTTP.  The choice of transport protocols = depends on the client=92s security requirements, though use of HTTPS is = RECOMMENDED in most situations.
If a query is = issued using HTTPS because it has strict security requirements and the = server has an invalid certificate, the server returns a 4xx or 5xx = status code, or the HTTPS connection cannot be established for any = reason, the client MUST accept that the WebFinger query has failed and = MUST NOT attempt to reissue the WebFinger request using = HTTP.
WebFinger servers = operating on HTTP MAY redirect a client using an appropriate HTTP status = code to another HTTP or an HTTPS URI.  Likewise, WebFinger servers = operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST = NOT redirect a client to an HTTP URI.  Further, clients MUST NOT = follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD = automatically follow all other server = redirects.
> wrote: > > Folks,**** > ** ** > Here=E2=80=99s the current language. I get the feeling more people like = this than > what we had before. Now, what fine-tuning do we need to do? Or are peop= le > still of the mind that we need HTTPS only no matter what?**** > ** ** > Current language:**** > ** ** > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > ** ** > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > ** ** > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > ** ** > I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, > either serially or in parallel=E2=80=9D. Let the client decide what to d= o based on > its security requirements.**** > ** ** > I would like to suggest we change =E2=80=9CIf a query is issued using HTT= PS=E2=80=9D to > =E2=80=9CIf a query is issued using HTTPS because it has strict security > requirements=E2=80=9D. Reasoning, again, is that if a client like a blog= server > issues a query via HTTPS looking for a user=E2=80=99s avatar and it fails= , why not > let it use HTTP? Actually, we could probably just remove this whole seco= nd > paragraph. We could just speak to the certificate checking on the securi= ty > section as it relates to secure clients.**** > ** ** > Thus, I propose we go with this (with or without the middle paragraph):**= * > * > ** ** > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > ** ** > If a query is issued using HTTPS because it has strict security > requirements and the server has an invalid certificate, the server return= s > a 4xx or 5xx status code, or the HTTPS connection cannot be established f= or > any reason, the client MUST accept that the WebFinger query has failed an= d > MUST NOT attempt to reissue the WebFinger request using HTTP.**** > ** ** > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > ** ** > Paul**** > > > --bcaec54fb9d2b9420704d0e69fcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Dec 15, 2012 at 5:19 PM, Dick Ha= rdt <dick.hardt@gmail.com> wrote:
+0.5

I think the lan= guage at the bottom is better than the language at the top.

<= div>I continue to feel that HTTPS only is better, but perhaps HTTPS only de= ployments will be driven by clients that will ONLY support HTTPS. Given the= strong desire by some (even though they fail to explain why :), this may b= e the best that we can do to reach consensus.


I think I'v= e made several points as to why HTTP is a valid option.

=C2=A0

-- Dick

On Dec 14, 2012, at 11:56 PM, "Paul E. Jones" <paulej@packetizer.com>= wrote:

Folks,
=C2=A0
Here=E2=80=99s the current language.=C2=A0 I get the feeling more people li= ke this than what we had before.=C2=A0 Now, what fine-tuning do we need to = do?=C2=A0 Or are people still of the mind that we need HTTPS only no matter= what?
=C2=A0
Current language:
=C2=A0
Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P, but MUST NOT attempt to use both, either serially or in parallel.=C2=A0 = The choice of transport protocols depends on the client=E2=80=99s security = requirements, though use of HTTPS is RECOMMENDED in most situations.=
=C2=A0
If a query is issued using HT= TPS and the server has an invalid certificate, the server returns a 4xx or = 5xx status code, or the HTTPS connection cannot be established for any reas= on, the client MUST accept that the WebFinger query has failed and MUST NOT= attempt to reissue the WebFinger request using HTTP.
=C2=A0
WebFinger servers operating o= n HTTP MAY redirect a client using an appropriate HTTP status code to anoth= er HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTT= PS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a clie= nt to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection fro= m an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other se= rver redirects.
=C2=A0
I w= ould like to suggest we strike =E2=80=9C, but MUST NOT attempt to use both,= either serially or in parallel=E2=80=9D.=C2=A0 Let the client decide what = to do based on its security requirements.
=C2=A0
I would like to suggest we ch= ange =E2=80=9CIf a query is issued using HTTPS=E2=80=9D to =E2=80=9CIf a qu= ery is issued using HTTPS because it has strict security requirements=E2=80= =9D.=C2=A0 Reasoning, again, is that if a client like a blog server issues = a query via HTTPS looking for a user=E2=80=99s avatar and it fails, why not= let it use HTTP?=C2=A0 Actually, we could probably just remove this whole = second paragraph.=C2=A0 We could just speak to the certificate checking on = the security section as it relates to secure clients.
=C2=A0
Thus, I propose we go with th= is (with or without the middle paragraph):
=C2=A0
Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P.=C2=A0 The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most situation= s.
=C2=A0
If a query is issued using= HTTPS because it has strict security requirements and the server has an in= valid certificate, the server returns a 4xx or 5xx status code, or the HTTP= S connection cannot be established for any reason, the client MUST accept t= hat the WebFinger query has failed and MUST NOT attempt to reissue the WebF= inger request using HTTP.
=C2=A0
WebFinger servers operating o= n HTTP MAY redirect a client using an appropriate HTTP status code to anoth= er HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTT= PS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a clie= nt to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection fro= m an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other se= rver redirects.
=C2=A0
Pau= l



--bcaec54fb9d2b9420704d0e69fcc-- From dick.hardt@gmail.com Sat Dec 15 08:30:56 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986C21F85D8 for ; Sat, 15 Dec 2012 08:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO4zOkjwUTuw for ; Sat, 15 Dec 2012 08:30:55 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2F21F85BC for ; Sat, 15 Dec 2012 08:30:55 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2863870pad.31 for ; Sat, 15 Dec 2012 08:30:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HtE314oLGXYM1DbHZKvPQGXEcLwiGCA0W5AI8GG4k3A=; b=JibagXVEXPzJzbm1VAUxWK2yQTDdYPNzBk+kKZXXGtWLvO3d4klD3ATwd8gZs3MiTS 6AtK/uvbCGxo7JSgqUU6mXFVMk/7wS6a1Z9VMhXiwaD6qR9wbG8OJWrNOFD/h1c1fB36 AEUOj2hE43z5ZPWroXb04nndZjaiD0xr7WAfMEZ/D3SpScE2SBWV6h5TzVk3/FePOk62 Mk3uXA3dJBX3/jpesO6jUMulkLIIccoaHf5Kc03hsHSQZGE1k0eDhczyawwmrM4zQVc4 8U+xZCzZxikIq4YUudGi+VfiNxksrWZLeCammureXVAkEdBxEX27UrHC/dFN8EvB3qc3 ZRsg== Received: by 10.68.143.129 with SMTP id se1mr26698204pbb.67.1355589055443; Sat, 15 Dec 2012 08:30:55 -0800 (PST) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id nt5sm4936609pbb.59.2012.12.15.08.30.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 08:30:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sat, 15 Dec 2012 08:30:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:30:56 -0000 On Dec 15, 2012, at 5:31 AM, Nick Jennings = wrote: > On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook wrote: >>=20 >> Look, the only reason I'm advocating for non-SSL requests being = allowed is >> purely from a deployment perspective. There are loads of programmers = (re: >> early adopters) who use github pages to host their personal domains = (re: >> webfinger IDs). I raised this as an issue here, and received zero = comments >> acknowledging that as a real deployment scenario. There's a whole = community >> that's not present here ("indyweb") that's advocating for people = owning >> their own domains as being the only way forward (I disagree with = their >> absolutism on the question of hosted services, but sympathise). >=20 > On the contrary, I consider myself a part of this community and I > think there are a few others wandering about. :) I would guess that almost everyone on this list has their own personal = domain. I have several. >=20 >=20 >> It's fine if >> the participants here from Google and Microsoft and the IETF security >> community want to claim that they can provide secure services to = their >> users; the fact is that there are real scenarios today and for the >> foreseeable future where having real non-TLS lookups of webfinger = data would >> be useful. >> I want this thing to be deployable. I want this community to make a >> commitment to supporting users outside this community. >=20 > +1 On the other hand, if all the "indyweb" people want WF and HTTPS is = required, the hosting services may innovate on easily providing HTTPS. I = think this would be a Good Thing to happen. As noted previously, the cost of certs is pretty much zero, so HTTPS as = part of a standard hosting package is really a product management = decision followed by a deployment task (i.e., it is not a major = financial decision by hosting companies. Do we want to be brave and say = HTTPS only and help drive a safer, more secure web? -- Dick= From nick@silverbucket.net Sat Dec 15 08:54:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0B21F857C for ; Sat, 15 Dec 2012 08:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vz8Not7VujS for ; Sat, 15 Dec 2012 08:54:25 -0800 (PST) Received: from mail-la0-f66.google.com (mail-la0-f66.google.com [209.85.215.66]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0A21F8569 for ; Sat, 15 Dec 2012 08:54:24 -0800 (PST) Received: by mail-la0-f66.google.com with SMTP id e6so643647lah.1 for ; Sat, 15 Dec 2012 08:54:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=GIgNizvakPmDPQX4vBJSyzuCVGTwf7np+I4e3wk/Awo=; b=QhaRSgEe/Mvp4lxpRDOD2cRf8iKdQeW0VyyfAMNH78hTlHNR+ySEiw/Gcj06+2woPl jnokets7kUZ1MWhz+St1PUFagS0IcogPY1s3JGXk8qRY4BOlQrjrPiYnHOq6XbSmEPvO isRBmryhWDsEVP//ndGHpjVVTbEwDtvkMDYHkxI39CLJaN8oTXoMpqmrF320BQY8Nkoa CnG7P4xxTwytrd1S18x4/EufroCHYr4dHa0SAx+CXWegTWKJfhCPRXnKFEOnx7ckzh9Y sjXPecYpnccJ5p0OnDSliGrWt09KxKBVUaOALVc+zQ8lGdsQG0hW1/sVzmftcBjz7dSn fjpQ== Received: by 10.112.83.133 with SMTP id q5mr3760848lby.40.1355590463686; Sat, 15 Dec 2012 08:54:23 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id p5sm3039368lbh.2.2012.12.15.08.54.22 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 08:54:22 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3602130lah.31 for ; Sat, 15 Dec 2012 08:54:22 -0800 (PST) Received: by 10.112.38.66 with SMTP id e2mr3604709lbk.90.1355590461985; Sat, 15 Dec 2012 08:54:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 08:53:51 -0800 (PST) In-Reply-To: <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> From: Nick Jennings Date: Sat, 15 Dec 2012 17:53:51 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkGe8VdNlWCpqn93Lint/M6wnerlwcuEXWpE1gt/QFEPCIHKMcxSFLnB9zomx1ow5UpIbj1 Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:54:25 -0000 On Sat, Dec 15, 2012 at 5:30 PM, Dick Hardt wrote: > On Dec 15, 2012, at 5:31 AM, Nick Jennings wrote: >> On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook wrote: >>> It's fine if >>> the participants here from Google and Microsoft and the IETF security >>> community want to claim that they can provide secure services to their >>> users; the fact is that there are real scenarios today and for the >>> foreseeable future where having real non-TLS lookups of webfinger data = would >>> be useful. >>> I want this thing to be deployable. I want this community to make a >>> commitment to supporting users outside this community. >> >> +1 > > > On the other hand, if all the "indyweb" people want WF and HTTPS is requi= red, the hosting services may innovate on easily providing HTTPS. I think t= his would be a Good Thing to happen. > > As noted previously, the cost of certs is pretty much zero, so HTTPS as p= art of a standard hosting package is really a product management decision f= ollowed by a deployment task (i.e., it is not a major financial decision by= hosting companies. Do we want to be brave and say HTTPS only and help driv= e a safer, more secure web? > There are several reasons to allow HTTP, it's not *just* a cert issue. 1. Adoption. Make it easy for to add a WebFinger service to query things like avatar, name, some social media links. 2. Maintenance. Your WebFinger service does not break when you fail to go through the process of cert renewal every year. (it's not like you just make a payment, you have to have a new cert issued and update your server, this is not ideal for a lot of people). 3. High Latency Mobile Networks and Optimization. This isn't the "HTTPS is slow" argument. This is not a 1st world issue, per-say, however there are places with sub-optimal connectivity and HTTPS does not help. In these cases, it's completely unnecessary when all you want is a little bit of 'gravatar-like' functionality on your web application or website. In these cases I'm referring to client-side WF access (not servers making WF requests). 4. Cost. I know there is a free service, not everyone will know about this free service. A lot of people will think they will need to pay $50-100 per. year just to play the game. Those *same* people will likely be people that are NOT going to be serving ANY sensitive information and these factors will be taken into account when they decide if they really want to adopt WF or not. In these cases, HTTPS-only is a deterrent and detracts from #1 (Adoption), which IMO is the most important. That said, I like the idea of HTTPS only, it's nice and simple. I just don't think there's enough out there to make it easy for everyone to adopt with little effort, not just up-front, but ongoing. -Nick From dick.hardt@gmail.com Sat Dec 15 09:05:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7413321F85DF for ; Sat, 15 Dec 2012 09:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OkMK5B4Lb5p for ; Sat, 15 Dec 2012 09:05:42 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1E3A21F85D9 for ; Sat, 15 Dec 2012 09:05:42 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2872995pad.31 for ; Sat, 15 Dec 2012 09:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=D7WU/hzv+JuEVEL8SKgap+gCwVHgyZo60LCRgEpschI=; b=0nV/bBy8wkFVClNjKbvo81GCvQD+8uoR3V5qZyHy93db1rXZKY71yw5U6yAw9jKQcJ rmsaHkDG1qUQt60INpY6Tfrs+KQISqEn44qp6F7lU8ShBGbLlRAu7+VWZt4Oi9JPvfSh 9C+2p9ewtdZicaE8nyf9cn4jdgD3k4eyxt53J7Cn2uvWIRG0viqAXc30KKfjj1U2jL0s PKUCRGz2gVsm1pgxWTn9y7XeC5X7Ft1y6Ca9CEVEVe74Bpgh8WqhNUCv1dPJ62CSOWNH 9d6PQ1PvUo+uV7jlGQyCGW23tBo+hNAcw9XHdEgIYwoztMAXN6mYgYTb8n5B1Gkk4xMJ Xv5w== Received: by 10.66.73.105 with SMTP id k9mr26276298pav.37.1355591142291; Sat, 15 Dec 2012 09:05:42 -0800 (PST) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id j9sm5307321paw.2.2012.12.15.09.05.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 09:05:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Sat, 15 Dec 2012 09:05:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <23858499-9385-44C9-B3D6-20A997727C12@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:05:43 -0000 On Dec 15, 2012, at 8:53 AM, Nick Jennings = wrote: > On Sat, Dec 15, 2012 at 5:30 PM, Dick Hardt = wrote: >> On Dec 15, 2012, at 5:31 AM, Nick Jennings = wrote: >>> On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook = wrote: >>>> It's fine if >>>> the participants here from Google and Microsoft and the IETF = security >>>> community want to claim that they can provide secure services to = their >>>> users; the fact is that there are real scenarios today and for the >>>> foreseeable future where having real non-TLS lookups of webfinger = data would >>>> be useful. >>>> I want this thing to be deployable. I want this community to make a >>>> commitment to supporting users outside this community. >>>=20 >>> +1 >>=20 >>=20 >> On the other hand, if all the "indyweb" people want WF and HTTPS is = required, the hosting services may innovate on easily providing HTTPS. I = think this would be a Good Thing to happen. >>=20 >> As noted previously, the cost of certs is pretty much zero, so HTTPS = as part of a standard hosting package is really a product management = decision followed by a deployment task (i.e., it is not a major = financial decision by hosting companies. Do we want to be brave and say = HTTPS only and help drive a safer, more secure web? >>=20 >=20 > There are several reasons to allow HTTP, it's not *just* a cert issue. >=20 > 1. Adoption. Make it easy for to add a > WebFinger service to query things like avatar, name, some social media > links. >=20 > 2. Maintenance. Your WebFinger service does not break when you fail to > go through the process of cert renewal every year. (it's not like you > just make a payment, you have to have a new cert issued and update > your server, this is not ideal for a lot of people). >=20 > 3. High Latency Mobile Networks and Optimization. This isn't the > "HTTPS is slow" argument. This is not a 1st world issue, per-say, > however there are places with sub-optimal connectivity and HTTPS does > not help. In these cases, it's completely unnecessary when all you > want is a little bit of 'gravatar-like' functionality on your web > application or website. In these cases I'm referring to client-side WF > access (not servers making WF requests). >=20 > 4. Cost. I know there is a free service, not everyone will know about > this free service. A lot of people will think they will need to pay > $50-100 per. year just to play the game. Those *same* people will > likely be people that are NOT going to be serving ANY sensitive > information and these factors will be taken into account when they > decide if they really want to adopt WF or not. >=20 > In these cases, HTTPS-only is a deterrent and detracts from #1 > (Adoption), which IMO is the most important. >=20 > That said, I like the idea of HTTPS only, it's nice and simple. I just > don't think there's enough out there to make it easy for everyone to > adopt with little effort, not just up-front, but ongoing. Thanks for the reiterating your points. I think that *if* HTTPS is incorporated as part of the hosting service, = points 1,2 & 4 are non-issues.=20 I do agree that WF adoption by the indy web may be critical to WF = success, and HTTPS is a barrier to indy web adoption of WF. As for 3, HTTPS is required in secure transactions, even if they are = mobile. Just because one use case does not need it does not mean it is = not a good thing to be HTTPS only so that things that require HTTPS = 'for sure' run over HTTPS. Remember that payments drove the deployment of HTTPS to all ecommerce = sights. Intercepted credentials drove HTTPS to web mail and Twitter = etc. Perhaps WF will drive HTTPS further? Having said that, I'm ok (a +0.5) with Paul's last revision as it = allows HTTPS to be dictated by clients -- Dick From nick@silverbucket.net Sat Dec 15 09:40:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7021F8634 for ; Sat, 15 Dec 2012 09:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH8mLJhQpjSG for ; Sat, 15 Dec 2012 09:40:05 -0800 (PST) Received: from mail-lb0-f194.google.com (mail-lb0-f194.google.com [209.85.217.194]) by ietfa.amsl.com (Postfix) with ESMTP id 58DB721F85CF for ; Sat, 15 Dec 2012 09:40:05 -0800 (PST) Received: by mail-lb0-f194.google.com with SMTP id gf7so655571lbb.1 for ; Sat, 15 Dec 2012 09:40:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=8Ar6lCZDTXXXve6zVtS368nmmcLLQ0vuBkg1O0YnEZM=; b=V/AseQYhYKKAhkPwiV7p1RnGhCRPJK1D/LjXXWP8Yh5L15kHoyS16CaKW0MAk2CHqH O50IxXgqRwEySCzXg0HR8DXEfd1rsrgn78I1orwSGogXB2n9lJV6lctTr6WgO2RGiLFE QA96ouZsovSlmRHLVhlEsUxJISZdVJz/md9YBDGDEf5OBtBwJ3+qlMks8r7jJMTWEOcW MsHUx+X8Y316aLLOmmQGKdVK/OOa9c1RPwb4EDyJ5DtaQgYvepPgTf7fNHbRHYRXib59 XVPL2E1tXmPr3tYdudZSEaqswtpB3aqcLM/7C+e43jKf0zEActBRyZFBF6pCc/YbEQyS 4b7Q== Received: by 10.152.104.226 with SMTP id gh2mr5983887lab.24.1355593204062; Sat, 15 Dec 2012 09:40:04 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id hu6sm3012332lab.13.2012.12.15.09.40.02 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 09:40:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3618544lah.31 for ; Sat, 15 Dec 2012 09:40:02 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr3780430lbd.54.1355593202307; Sat, 15 Dec 2012 09:40:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 09:39:32 -0800 (PST) In-Reply-To: <23858499-9385-44C9-B3D6-20A997727C12@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> <23858499-9385-44C9-B3D6-20A997727C12@gmail.com> From: Nick Jennings Date: Sat, 15 Dec 2012 18:39:32 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnCy9+WQMiq/oQCQ0ecwdGtppjYai4FrfD3j3u4s2Uu9eNhXazh12Rdxm4gEYNLplI+cD1S Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , webfinger@ietf.org, Brad Fitzpatrick Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:40:06 -0000 On Sat, Dec 15, 2012 at 6:05 PM, Dick Hardt wrote: > > On Dec 15, 2012, at 8:53 AM, Nick Jennings wrote: > >> On Sat, Dec 15, 2012 at 5:30 PM, Dick Hardt wrote= : >>> On Dec 15, 2012, at 5:31 AM, Nick Jennings wrot= e: >>>> On Sat, Dec 15, 2012 at 1:44 PM, Blaine Cook wrote: >>>>> It's fine if >>>>> the participants here from Google and Microsoft and the IETF security >>>>> community want to claim that they can provide secure services to thei= r >>>>> users; the fact is that there are real scenarios today and for the >>>>> foreseeable future where having real non-TLS lookups of webfinger dat= a would >>>>> be useful. >>>>> I want this thing to be deployable. I want this community to make a >>>>> commitment to supporting users outside this community. >>>> >>>> +1 >>> >>> >>> On the other hand, if all the "indyweb" people want WF and HTTPS is req= uired, the hosting services may innovate on easily providing HTTPS. I think= this would be a Good Thing to happen. >>> >>> As noted previously, the cost of certs is pretty much zero, so HTTPS as= part of a standard hosting package is really a product management decision= followed by a deployment task (i.e., it is not a major financial decision = by hosting companies. Do we want to be brave and say HTTPS only and help dr= ive a safer, more secure web? >>> >> >> There are several reasons to allow HTTP, it's not *just* a cert issue. >> >> 1. Adoption. Make it easy for to add a >> WebFinger service to query things like avatar, name, some social media >> links. >> >> 2. Maintenance. Your WebFinger service does not break when you fail to >> go through the process of cert renewal every year. (it's not like you >> just make a payment, you have to have a new cert issued and update >> your server, this is not ideal for a lot of people). >> >> 3. High Latency Mobile Networks and Optimization. This isn't the >> "HTTPS is slow" argument. This is not a 1st world issue, per-say, >> however there are places with sub-optimal connectivity and HTTPS does >> not help. In these cases, it's completely unnecessary when all you >> want is a little bit of 'gravatar-like' functionality on your web >> application or website. In these cases I'm referring to client-side WF >> access (not servers making WF requests). >> >> 4. Cost. I know there is a free service, not everyone will know about >> this free service. A lot of people will think they will need to pay >> $50-100 per. year just to play the game. Those *same* people will >> likely be people that are NOT going to be serving ANY sensitive >> information and these factors will be taken into account when they >> decide if they really want to adopt WF or not. >> >> In these cases, HTTPS-only is a deterrent and detracts from #1 >> (Adoption), which IMO is the most important. >> >> That said, I like the idea of HTTPS only, it's nice and simple. I just >> don't think there's enough out there to make it easy for everyone to >> adopt with little effort, not just up-front, but ongoing. > > > Thanks for the reiterating your points. > > I think that *if* HTTPS is incorporated as part of the hosting service, p= oints 1,2 & 4 are non-issues. The hosting service would provide TLS certs for 'yourdomain.com' ? That would help, but a lot of people don't see the point in paying yearly for a TLS cert if they're not doing e-commerce. (in this case it would most definitely be a paid-addon) > I do agree that WF adoption by the indy web may be critical to WF success= , and HTTPS is a barrier to indy web adoption of WF. > > As for 3, HTTPS is required in secure transactions, even if they are mobi= le. Just because one use case does not need it does not mean it is not a go= od thing to be HTTPS only so that things that require HTTPS 'for sure' run= over HTTPS. Of course it's required for secure transactions. Every point I'm making is for the "damn I just want a picture and some social network links" situation. Again, this gives the power to the developer to decide how they will use WF. IMO the servers should provide all options (HTTPS and HTTP) when they can, and leave the use up to the client. In addition, I'd like to see any secure information filtered by both the server and client libraries, just to cover all our bases for possible misuse. In that case, a developer not understanding what he's doing, would not get a result for querying openid connect info via an HTTP request. > Remember that payments drove the deployment of HTTPS to all ecommerce sig= hts. Intercepted credentials drove HTTPS to web mail and Twitter etc. Perh= aps WF will drive HTTPS further? > > Having said that, I'm ok (a +0.5) with Paul's last revision as it allows= HTTPS to be dictated by clients > > -- Dick > > > From jasnell@gmail.com Sat Dec 15 09:45:49 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400B21F853F for ; Sat, 15 Dec 2012 09:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW8F0ijNE+gp for ; Sat, 15 Dec 2012 09:45:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D213A21F852C for ; Sat, 15 Dec 2012 09:45:47 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4202034iaz.31 for ; Sat, 15 Dec 2012 09:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dix/4m+puWt29ZvwpBNlCng1LLRln3TQSP06HZJDX1I=; b=07xW7h8CCHc7ORCGMwfFrSFpHWMgkJ+685bX5xFyOlvJmE93hUorld6Ty45dGAhaQX DuL+Ncdq24nl51dFrCfjK3+vsT+KFMMJ/JXk41S1QsB08mg/9gB4kYUVgo0YTImpfRxB h0kZAkxF+W9IHQH4wez1fl94Eh3QAJbldT3cDYleO40SdcDNv07jXob8zzD279M8+OBo QNV2KMi+jHPJx7kIdIdPEd15DbCSvkRcVXh6rcaZk7dSlyS1OkpRfB5P27txGzVuFIFt 9aUJtJ2qrhaQIpW/kWKE2caWdEwat3uazTM0dxVV9qRYRn5Ralp7JKZhdjtP3bXa0a65 FhXw== Received: by 10.50.178.106 with SMTP id cx10mr4988325igc.24.1355593547392; Sat, 15 Dec 2012 09:45:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sat, 15 Dec 2012 09:45:27 -0800 (PST) In-Reply-To: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> From: James M Snell Date: Sat, 15 Dec 2012 09:45:27 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f5036c8da25d404d0e7b768 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:45:49 -0000 --e89a8f5036c8da25d404d0e7b768 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones wrot= e: > Folks,**** > > ** ** > > Here=E2=80=99s the current language. I get the feeling more people like = this than > what we had before. Now, what fine-tuning do we need to do? Or are peop= le > still of the mind that we need HTTPS only no matter what?**** > > ** ** > > Current language:**** > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, > either serially or in parallel=E2=80=9D. Let the client decide what to d= o based on > its security requirements.**** > > ** ** > > I would like to suggest we change =E2=80=9CIf a query is issued using HTT= PS=E2=80=9D to > =E2=80=9CIf a query is issued using HTTPS because it has strict security > requirements=E2=80=9D. Reasoning, again, is that if a client like a blog= server > issues a query via HTTPS looking for a user=E2=80=99s avatar and it fails= , why not > let it use HTTP? Actually, we could probably just remove this whole seco= nd > paragraph. We could just speak to the certificate checking on the securi= ty > section as it relates to secure clients.**** > > ** > Note that there is a different between a user-agent automatically falling back to http and a user issuing a second request after failing. The former involves no user-interaction with the second step, the latter requires it. Client implementations ought to be forbidden from automatic fallbacks. Require intentional intervention to issue the secondary request. This is no different really than the issues involved in automatic redirection of unsafe HTTP methods (see [1] section 7.4). [1] http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_te= xt=3D1 So rather than removing that paragraph, try this: "If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and SHOULD NOT attempt to automatically reissue the WebFinger request using HTTP. This failure condition SHOULD be reported to the user. Following such a failure, a client MAY attempt to issue a separate subsequent query over HTTP if an application's security requirements permit." This would require that any subsequent HTTP fallbacks would occur only after human intervention (either the user reissues the request or a developer specifically handles the failure and sends a new request). In either case, fallback requires a conscious choice to accept the fallback risks. - James ** > > Thus, I propose we go with this (with or without the middle paragraph):**= * > * > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS because it has strict security > requirements and the server has an invalid certificate, the server return= s > a 4xx or 5xx status code, or the HTTPS connection cannot be established f= or > any reason, the client MUST accept that the WebFinger query has failed an= d > MUST NOT attempt to reissue the WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8f5036c8da25d404d0e7b768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Fri, Dec 14, 2012 at 11:56 PM, Paul E= . Jones <paulej@packetizer.com> wrote:
Folks,

=C2=A0

Here=E2=80=99s the current language.=C2=A0 I get the feeling more people l= ike this than what we had before.=C2=A0 Now, what fine-tuning do we need to= do?=C2=A0 Or are people still of the mind that we need HTTPS only no matte= r what?

=C2=A0

Current language:

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P, but MUST NOT attempt to use both, either serially or in parallel.=C2=A0 = The choice of transport protocols depends on the client=E2=80=99s security = requirements, though use of HTTPS is RECOMMENDED in most situations.=

=C2=A0

If a query is issued us= ing HTTPS and the server has an invalid certificate, the server returns a 4= xx or 5xx status code, or the HTTPS connection cannot be established for an= y reason, the client MUST accept that the WebFinger query has failed and MU= ST NOT attempt to reissue the WebFinger request using HTTP.

=C2=A0

WebFinger servers opera= ting on HTTP MAY redirect a client using an appropriate HTTP status code to= another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating = on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect = a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirecti= on from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all ot= her server redirects.

=C2=A0

I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use= both, either serially or in parallel=E2=80=9D.=C2=A0 Let the client decide= what to do based on its security requirements.

=C2=A0

I would like to suggest= we change =E2=80=9CIf a query is issued using HTTPS=E2=80=9D to =E2=80=9CI= f a query is issued using HTTPS because it has strict security requirements= =E2=80=9D.=C2=A0 Reasoning, again, is that if a client like a blog server i= ssues a query via HTTPS looking for a user=E2=80=99s avatar and it fails, w= hy not let it use HTTP?=C2=A0 Actually, we could probably just remove this = whole second paragraph.=C2=A0 We could just speak to the certificate checki= ng on the security section as it relates to secure clients.

=C2=A0


Note that there is a different between a user-agent automatically falling = back to http and a user issuing a second request after failing. The former = involves no user-interaction with the second step, the latter requires it. = Client implementations ought to be forbidden from automatic fallbacks. Requ= ire intentional intervention to issue the secondary request. This is no dif= ferent really than the issues involved in automatic redirection of unsafe H= TTP methods (see [1] section 7.4).=C2=A0


So rather than removing that paragraph, try this:

= "If a query is issued usi= ng HTTPS and the server has an invalid certificate, the server returns a 4x= x or 5xx status code, or the HTTPS connection cannot be established for any= reason, the client MUST accept that the WebFinger query has failed and SHO= ULD NOT attempt to automatically reissue the WebFinger request using HTTP. = This failure condition SHOULD be reported to the user. Following such a fai= lure, a client MAY attempt to issue a separate subsequent query over HTTP i= f an application's security requirements permit."
=C2=A0
This would require that any subsequent HTTP fallbacks= would occur only after human intervention (either the user reissues the re= quest or a developer specifically handles the failure and sends a new reque= st). In either case, fallback requires a conscious choice to accept the fal= lback risks.

- James

Thus, I propose we go with this= (with or without the middle paragraph):

= =C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P.=C2=A0 The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most situation= s.

=C2=A0

If a query is issued= using HTTPS because it has strict security requirements and the server has= an invalid certificate, the server returns a 4xx or 5xx status code, or th= e HTTPS connection cannot be established for any reason, the client MUST ac= cept that the WebFinger query has failed and MUST NOT attempt to reissue th= e WebFinger request using HTTP.

=C2=A0

WebFinger servers opera= ting on HTTP MAY redirect a client using an appropriate HTTP status code to= another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating = on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect = a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirecti= on from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all ot= her server redirects.

=C2=A0

Paul

=C2=A0


_______________= ________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8f5036c8da25d404d0e7b768-- From nick@silverbucket.net Sat Dec 15 09:59:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47C21F86F5 for ; Sat, 15 Dec 2012 09:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IpeVqzS48+w for ; Sat, 15 Dec 2012 09:59:22 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DE21F8509 for ; Sat, 15 Dec 2012 09:59:21 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3625165lah.31 for ; Sat, 15 Dec 2012 09:59:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=o0tOtU+7QJhAFudr/Xm8BoeFDmaHReSphYSTTATH4wc=; b=herRINCKFdjMImYfMMWRUHlEtTT62BYkKwWwPmYVxQKcmd+L7ue4SIWLifxGeej+6z 6dtWrSaTp6uYu8JoU5arMVlxQs6ASBQdBR2mZw5EW38rQIHqMu2hdbePmv1h366MxBma OyHEtTxvrYVJ2bRfyt10/U+h2fYugTj5CeLpzawJb4vxORMlDYcPql5kWq2I/uSjt+5E hcFl6SbjFJfhlyj2nONJudJGVzEbshryM54iZ3EH37SPOciUQZZphJlQ/I8o6DiZqavR UOc7VslBOb7pL7zA66ML46wVEIlW1aS5KpJ/Euc59bAzzW10f5jMDyN8kPvmAxef7pOj lx7w== Received: by 10.152.121.212 with SMTP id lm20mr5885177lab.42.1355594360387; Sat, 15 Dec 2012 09:59:20 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id hc20sm798108lab.11.2012.12.15.09.59.18 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 09:59:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3638113lbk.31 for ; Sat, 15 Dec 2012 09:59:18 -0800 (PST) Received: by 10.112.17.129 with SMTP id o1mr3795031lbd.54.1355594358454; Sat, 15 Dec 2012 09:59:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 09:58:48 -0800 (PST) In-Reply-To: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> From: Nick Jennings Date: Sat, 15 Dec 2012 18:58:48 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec554d94431f9fc04d0e7e8e4 X-Gm-Message-State: ALoCoQk0+S392o2XuXIiHOY9Br1BaKGWBIA6jUpX7hYSTH2cN/ySXYYdovoy0MN1idFvTvMn8T8g Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:59:23 -0000 --bcaec554d94431f9fc04d0e7e8e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 6:45 PM, James M Snell wrote: > > > > On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones wr= ote: > >> Folks,**** >> >> ** ** >> >> Here=E2=80=99s the current language. I get the feeling more people like= this >> than what we had before. Now, what fine-tuning do we need to do? Or ar= e >> people still of the mind that we need HTTPS only no matter what?**** >> >> ** ** >> >> Current language:**** >> >> ** ** >> >> Clients MAY issue a query to the WebFinger server using either HTTPS or >> HTTP, but MUST NOT attempt to use both, either serially or in parallel. >> The choice of transport protocols depends on the client=E2=80=99s securi= ty >> requirements, though use of HTTPS is RECOMMENDED in most situations.**** >> >> ** ** >> >> If a query is issued using HTTPS and the server has an invalid >> certificate, the server returns a 4xx or 5xx status code, or the HTTPS >> connection cannot be established for any reason, the client MUST accept >> that the WebFinger query has failed and MUST NOT attempt to reissue the >> WebFinger request using HTTP.**** >> >> ** ** >> >> WebFinger servers operating on HTTP MAY redirect a client using an >> appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, >> WebFinger servers operating on HTTPS MAY redirect a client to another HT= TPS >> URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MU= ST >> NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD >> automatically follow all other server redirects.**** >> >> ** ** >> >> I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use= both, >> either serially or in parallel=E2=80=9D. Let the client decide what to = do based on >> its security requirements.**** >> >> ** ** >> >> I would like to suggest we change =E2=80=9CIf a query is issued using HT= TPS=E2=80=9D to >> =E2=80=9CIf a query is issued using HTTPS because it has strict security >> requirements=E2=80=9D. Reasoning, again, is that if a client like a blo= g server >> issues a query via HTTPS looking for a user=E2=80=99s avatar and it fail= s, why not >> let it use HTTP? Actually, we could probably just remove this whole sec= ond >> paragraph. We could just speak to the certificate checking on the secur= ity >> section as it relates to secure clients.**** >> >> ** >> > > Note that there is a different between a user-agent automatically falling > back to http and a user issuing a second request after failing. The forme= r > involves no user-interaction with the second step, the latter requires it= . > Client implementations ought to be forbidden from automatic fallbacks. > Require intentional intervention to issue the secondary request. This is = no > different really than the issues involved in automatic redirection of > unsafe HTTP methods (see [1] section 7.4). > > [1] > http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_= text=3D1 > > So rather than removing that paragraph, try this: > > "If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and SHOULD NOT attempt to automatical= ly > reissue the WebFinger request using HTTP. This failure condition SHOULD b= e > reported to the user. Following such a failure, a client MAY attempt to > issue a separate subsequent query over HTTP if an application's security > requirements permit." > > This would require that any subsequent HTTP fallbacks would occur only > after human intervention (either the user reissues the request or a > developer specifically handles the failure and sends a new request). In > either case, fallback requires a conscious choice to accept the fallback > risks. > > If you are just querying for 'public' information (no security concerns), then this encourages an HTTP-first with automatic HTTPS fallback process from the client end. The other way around, you are saying it would be mandated that the client would need to abort on a 404 or otherwise failure to connect (maybe they don't have an HTTPS service running at all), and the user of the library would need to write in functionality to handle that case and issue the request again using HTTP. > - James > > ** >> >> Thus, I propose we go with this (with or without the middle paragraph):*= * >> ** >> >> ** ** >> >> Clients MAY issue a query to the WebFinger server using either HTTPS or >> HTTP. The choice of transport protocols depends on the client=E2=80=99s= security >> requirements, though use of HTTPS is RECOMMENDED in most situations.**** >> >> ** ** >> >> If a query is issued using HTTPS because it has strict security >> requirements and the server has an invalid certificate, the server retur= ns >> a 4xx or 5xx status code, or the HTTPS connection cannot be established = for >> any reason, the client MUST accept that the WebFinger query has failed a= nd >> MUST NOT attempt to reissue the WebFinger request using HTTP.**** >> >> ** ** >> >> WebFinger servers operating on HTTP MAY redirect a client using an >> appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, >> WebFinger servers operating on HTTPS MAY redirect a client to another HT= TPS >> URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MU= ST >> NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD >> automatically follow all other server redirects.**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > --bcaec554d94431f9fc04d0e7e8e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Dec 15, 2012 at 6:45 PM, James M= Snell <jasnell@gmail.com> wrote:

=

On Fri, Dec 14, 2012 a= t 11:56 PM, Paul E. Jones <paulej@packetizer.com> wrote:=
Folks,

=C2=A0

Here=E2=80=99s the cu= rrent language.=C2=A0 I get the feeling more people like this than what we = had before.=C2=A0 Now, what fine-tuning do we need to do?=C2=A0 Or are peop= le still of the mind that we need HTTPS only no matter what?<= /p>

=C2=A0

Current language:

= =C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P, but MUST NOT attempt to use both, either serially or in parallel.=C2=A0 = The choice of transport protocols depends on the client=E2=80=99s security = requirements, though use of HTTPS is RECOMMENDED in most situations.=

=C2=A0

If a query is issued using HTTPS and the serv= er has an invalid certificate, the server returns a 4xx or 5xx status code,= or the HTTPS connection cannot be established for any reason, the client M= UST accept that the WebFinger query has failed and MUST NOT attempt to reis= sue the WebFinger request using HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redir= ect a client using an appropriate HTTP status code to another HTTP or an HT= TPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect = a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP UR= I.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI t= o an HTTP URI, but SHOULD automatically follow all other server redirects.<= u>

=C2=A0

I would like to sug= gest we strike =E2=80=9C, but MUST NOT attempt to use both, either serially= or in parallel=E2=80=9D.=C2=A0 Let the client decide what to do based on i= ts security requirements.

=C2=A0

I would like to suggest we change =E2=80=9CIf= a query is issued using HTTPS=E2=80=9D to =E2=80=9CIf a query is issued us= ing HTTPS because it has strict security requirements=E2=80=9D.=C2=A0 Reaso= ning, again, is that if a client like a blog server issues a query via HTTP= S looking for a user=E2=80=99s avatar and it fails, why not let it use HTTP= ?=C2=A0 Actually, we could probably just remove this whole second paragraph= .=C2=A0 We could just speak to the certificate checking on the security sec= tion as it relates to secure clients.

=C2=A0


Note= that there is a different between a user-agent automatically falling back = to http and a user issuing a second request after failing. The former invol= ves no user-interaction with the second step, the latter requires it. Clien= t implementations ought to be forbidden from automatic fallbacks. Require i= ntentional intervention to issue the secondary request. This is no differen= t really than the issues involved in automatic redirection of unsafe HTTP m= ethods (see [1] section 7.4).=C2=A0


=C2=A0
This would require that any subsequent HTTP fallbacks= would occur only after human intervention (either the user reissues the re= quest or a developer specifically handles the failure and sends a new reque= st). In either case, fallback requires a conscious choice to accept the fal= lback risks.





=C2=A0
- James

Thus, I propose we go with this (with or without the = middle paragraph):

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTT= P.=C2=A0 The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most situation= s.

=C2=A0

If a query is issued using HTTPS because i= t has strict security requirements and the server has an invalid certificat= e, the server returns a 4xx or 5xx status code, or the HTTPS connection can= not be established for any reason, the client MUST accept that the WebFinge= r query has failed and MUST NOT attempt to reissue the WebFinger request us= ing HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redir= ect a client using an appropriate HTTP status code to another HTTP or an HT= TPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect = a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP UR= I.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI t= o an HTTP URI, but SHOULD automatically follow all other server redirects.<= span>

=C2=A0=

Paul

=C2=A0

<= /div>

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



--bcaec554d94431f9fc04d0e7e8e4-- From perpetual-tripper@wwelves.org Sat Dec 15 12:19:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD021F84DA for ; Sat, 15 Dec 2012 12:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb5wYIKfyEXY for ; Sat, 15 Dec 2012 12:19:06 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4242221F84D0 for ; Sat, 15 Dec 2012 12:19:06 -0800 (PST) X-Originating-IP: 217.70.178.138 Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 7870F172097; Sat, 15 Dec 2012 21:18:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YwCl6KkvwmGX; Sat, 15 Dec 2012 21:18:54 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1AE74172093; Sat, 15 Dec 2012 21:18:54 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Nick Jennings In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> Date: Sat, 15 Dec 2012 20:18:53 +0000 Message-Id: <1355602155-sup-2015@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: "webfinger@ietf.org" , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:19:07 -0000 Excerpts from Nick Jennings's message of 2012-12-15 17:58:48 +0000: > If you are just querying for 'public' information (no security concerns= ), [snip] not sure if we stay on the same page with security concerns and public/pr= ivate terminology all information we request with webfinger i would consider public since i= t doesn't use any ACL, so instead of saying (no security concers) when qu= erying for public information, i would say *quering for information that = we don't mind receiving spoofed response*... on example of OpenID, information about server which i use for that i con= sider fully public but if someone accepted it over HTTP it would open pos= sibility for impostors! From nick@silverbucket.net Sat Dec 15 12:23:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3885B21F850B for ; Sat, 15 Dec 2012 12:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR9r7uKwh685 for ; Sat, 15 Dec 2012 12:23:41 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50C21F84CE for ; Sat, 15 Dec 2012 12:23:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3682898lbk.31 for ; Sat, 15 Dec 2012 12:23:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=f1dnpQd2lN/C4ykIxsLBfaX/OBXZrXIZVARTaDu4KKc=; b=Bxx7CENih9oel9z6Dq5EVUWZ7a/eUyLOcohhxPCTA15FXYNK/waOp7rNtgyXWXPH3n rmFJKSwV4rilBhYkFVQ1YKsA7AdKn6lhZETPOQKHvz0/Fspl1dQoGpr8YzK0PwbAt+Gp fRvEmWf9lGfhKXQeOkn4fMoJZjFOqMLmOjBOrdgL+WrHQTmdV8n9Yy4mHRZxp3EOY51W FO+sCjn+9aJbjfaZ0tE8JrklUVJP34olKPyNSmq6jDOYGd1pNgdTM+iCdHPwrkJ46JFI 9k+VE1L9AUAr1zHB8GPWK0dkeKN9Du8SJytUxFpi1h76eQloZBz0di5dkVuUSQVyxMVk oNYQ== Received: by 10.152.114.66 with SMTP id je2mr6198687lab.40.1355603020369; Sat, 15 Dec 2012 12:23:40 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id lr20sm3124211lab.17.2012.12.15.12.23.39 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 12:23:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3682894lbk.31 for ; Sat, 15 Dec 2012 12:23:39 -0800 (PST) Received: by 10.152.125.136 with SMTP id mq8mr6387003lab.41.1355603019244; Sat, 15 Dec 2012 12:23:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 12:23:08 -0800 (PST) In-Reply-To: <1355602155-sup-2015@heahdk.net> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <1355602155-sup-2015@heahdk.net> From: Nick Jennings Date: Sat, 15 Dec 2012 21:23:08 +0100 Message-ID: To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYNDICU1WcmcfFS2Rkl7QMxWlXcIK+thsrPX5FeboSrfchfWQj0zVEsSS39s8elq3bZ3kz Cc: "webfinger@ietf.org" , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:23:42 -0000 On Sat, Dec 15, 2012 at 9:18 PM, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Nick Jennings's message of 2012-12-15 17:58:48 +0000: >> If you are just querying for 'public' information (no security concerns)= , > [snip] > not sure if we stay on the same page with security concerns and public/pr= ivate terminology > > all information we request with webfinger i would consider public since i= t doesn't use any ACL, so instead of saying (no security concers) when quer= ying for public information, i would say *quering for information that we d= on't mind receiving spoofed response*... > > on example of OpenID, information about server which i use for that i con= sider fully public but if someone accepted it over HTTP it would open possi= bility for impostors! Right. I realized I should have used different wording after I sent it. Thanks for clarifying. From evan@status.net Sat Dec 15 12:35:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A141A21F852D for ; Sat, 15 Dec 2012 12:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPX1iJdgTlnN for ; Sat, 15 Dec 2012 12:35:17 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1D821F8525 for ; Sat, 15 Dec 2012 12:35:17 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 63A928D423E; Sat, 15 Dec 2012 20:47:54 +0000 (UTC) Message-ID: <50CCDF02.1080007@status.net> Date: Sat, 15 Dec 2012 15:35:14 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> In-Reply-To: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020400070303040404050807" Cc: webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:35:26 -0000 This is a cryptographically signed message in MIME format. --------------ms020400070303040404050807 Content-Type: multipart/alternative; boundary="------------080909020309010904080209" This is a multi-part message in MIME format. --------------080909020309010904080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -1 Well-written implementations are going to fallback to HTTP, to HostMeta=20 + LRDD, and possibly to SWD because that's what's right for the users.=20 Very-well-written implementations will carefully choose which=20 combination of SSL and non-SSL makes sense for their application. We need to stop backseat driving. Balancing the requirements of getting=20 the information that the user has requested, versus various security=20 risks, is something that implementers do. Some will do it wrong. That is how technology works. No one will tell users that they can't have the data they need because=20 technically the spec says MUST NOT right here in section 5.1.2. =20 However, a good cluster of convoluted MUST/MUST NOT language will be=20 enough to keep people from ever implementing the spec in the first place.= I suggest the following language: Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. Servers MAY provide a /.well-known/webfinger endpoint over HTTP. Clients SHOULD request Webfinger documents via /.well-known/webfinger over HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger over HTTP. There are a class of attacks on HTTP-only requests listed in the Security Considerations. There are additional potential attacks on mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED that clients and servers use HTTPS only. Those of us who care about micromanaging the client request flow should=20 take the time to build liberally-licensed Open Source libraries for=20 Python, Perl, Java, C++, JavaScript and Ruby. Code is law. -Evan On 12-12-15 02:56 AM, Paul E. Jones wrote: > > Folks, > > Here's the current language. I get the feeling more people like this=20 > than what we had before. Now, what fine-tuning do we need to do? Or=20 > are people still of the mind that we need HTTPS only no matter what? > > Current language: > > Clients MAY issue a query to the WebFinger server using either HTTPS=20 > or HTTP, but MUST NOT attempt to use both, either serially or in=20 > parallel. The choice of transport protocols depends on the client's=20 > security requirements, though use of HTTPS is RECOMMENDED in most=20 > situations. > > If a query is issued using HTTPS and the server has an invalid=20 > certificate, the server returns a 4xx or 5xx status code, or the HTTPS = > connection cannot be established for any reason, the client MUST=20 > accept that the WebFinger query has failed and MUST NOT attempt to=20 > reissue the WebFinger request using HTTP. > > WebFinger servers operating on HTTP MAY redirect a client using an=20 > appropriate HTTP status code to another HTTP or an HTTPS URI. =20 > Likewise, WebFinger servers operating on HTTPS MAY redirect a client=20 > to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. =20 > Further, clients MUST NOT follow a redirection from an HTTPS URI to an = > HTTP URI, but SHOULD automatically follow all other server redirects. > > I would like to suggest we strike ", but MUST NOT attempt to use both, = > either serially or in parallel". Let the client decide what to do=20 > based on its security requirements. > > I would like to suggest we change "If a query is issued using HTTPS"=20 > to "If a query is issued using HTTPS because it has strict security=20 > requirements". Reasoning, again, is that if a client like a blog=20 > server issues a query via HTTPS looking for a user's avatar and it=20 > fails, why not let it use HTTP? Actually, we could probably just=20 > remove this whole second paragraph. We could just speak to the=20 > certificate checking on the security section as it relates to secure=20 > clients. > > Thus, I propose we go with this (with or without the middle paragraph):= > > Clients MAY issue a query to the WebFinger server using either HTTPS=20 > or HTTP. The choice of transport protocols depends on the client's=20 > security requirements, though use of HTTPS is RECOMMENDED in most=20 > situations. > > If a query is issued using HTTPS because it has strict security=20 > requirements and the server has an invalid certificate, the server=20 > returns a 4xx or 5xx status code, or the HTTPS connection cannot be=20 > established for any reason, the client MUST accept that the WebFinger=20 > query has failed and MUST NOT attempt to reissue the WebFinger request = > using HTTP. > > WebFinger servers operating on HTTP MAY redirect a client using an=20 > appropriate HTTP status code to another HTTP or an HTTPS URI. =20 > Likewise, WebFinger servers operating on HTTPS MAY redirect a client=20 > to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. =20 > Further, clients MUST NOT follow a redirection from an HTTPS URI to an = > HTTP URI, but SHOULD automatically follow all other server redirects. > > Paul > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------080909020309010904080209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
-1

Well-written implementations are going to fallback to HTTP, to HostMeta + LRDD, and possibly to SWD because that's what's right for the users. Very-well-written implementations will carefully choose which combination of SSL and non-SSL makes sense for their application.

We need to stop backseat driving. Balancing the requirements of getting the information that the user has requested, versus various security risks, is something that implementers do.

Some will do it wrong. That is how technology works.

No one will tell users that they can't have the data they need because technically the spec says MUST NOT right here in section 5.1.2.  However, a good cluster of convoluted MUST/MUST NOT language will be enough to keep people from ever implementing the spec in the first place.

I suggest the following language:
Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. Servers MAY provide a /.well-known/webfinger endpoint over HTTP.

Clients SHOULD request Webfinger documents via /.well-known/webfinger over HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger over HTTP.

There are a class of attacks on HTTP-only requests listed in the Security Considerations. There are additional potential attacks on mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED that clients and servers use HTTPS only.
Those of us who care about micromanaging the client request flow should take the time to build liberally-licensed Open Source libraries for Python, Perl, Java, C++, JavaScript and Ruby. Code is law.

-Evan

On 12-12-15 02:56 AM, Paul E. Jones wrote:

Folks,

 

Here’s the current language.  I= get the feeling more people like this than what we had before.  No= w, what fine-tuning do we need to do?  Or are people still of= the mind that we need HTTPS only no matter what?

 

Current language:

 

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel.  The choice of transport protocols depen= ds on the client’s security requirements, though use= of HTTPS is RECOMMENDED in most situations.

=

 

If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

 

WebFinger servers operating on HTT= P MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

 

I would like to suggest we strike “,= but MUST NOT attempt to use both, either serially or in parallel”.  Let the client decide what to do based o= n its security requirements.

 

I would like to suggest we change “I= f a query is issued using HTTPS” to “If a query is issu= ed using HTTPS because it has strict security requirements”. = Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user’s avatar and = it fails, why not let it use HTTP?  Actually, we could probab= ly just remove this whole second paragraph.  We could just sp= eak to the certificate checking on the security section as it relates to secure clients.

 

Thus, I propose we go with this (with or without the middle paragraph):

 

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP.  The choice of transport protocols depends on the clientR= 17;s security requirements, though use of HTTPS is RECOMMENDED in most situations.

 

If a query is issued using HTTP= S because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

 

WebFinger servers operating on HTT= P MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

 

Paul

 



_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--------------080909020309010904080209-- --------------ms020400070303040404050807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMTUy MDM1MTRaMCMGCSqGSIb3DQEJBDEWBBTXkX9VEw4cnn+MusFbOPGRm6VaADBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAK4c j7DEyHHGZTSAlp0zEmYeBfFaVru7YTYSqyi+SMc9ahaKdIsIoM8u19ZcjhPmOXMkh1K74V15 Nuulat/rhSpXj3GklaC//F6zuAZwspocpgHwKek9jAdiV7r+WaqfFcThQN+kWdx5DgCrIfu0 spf5XT1OB1ClX4W7sxf1FXdqcAtQ3+FDc6i1MoKGz0SX/p6RqglquYtpCOAm53Nl/Y2QioLM 2Y6CdH2COw8GR5ar3lV+fuCxAHR7qQSMvglDly7020YOw3+wq9/8tUZWY5Nwx5YKGTEWOFyl 2Fnic0ZBuW2z6wlz7HUIDscEaEL4/lEDdHSI6TuILHFKbiQUAMgAAAAAAAA= --------------ms020400070303040404050807-- From nick@silverbucket.net Sat Dec 15 12:49:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747721F85B2 for ; Sat, 15 Dec 2012 12:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ysNs5rSl0uZ for ; Sat, 15 Dec 2012 12:49:36 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 706A221F8525 for ; Sat, 15 Dec 2012 12:49:35 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3677410lah.31 for ; Sat, 15 Dec 2012 12:49:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=7yI+nGxXuB8AEzTSN9OAQSjs8Mxp8G8NAh/PdQeRSck=; b=FByi+ECAPG4GIjguE9QWbHVHQOUbInZwWwoGCitlrt5B4c1CdwjQgb0/kLaw+9tjI+ PFzPV+riepdnswsp9sAZaBy1LnJ38At9GzWveue9k6YrkiUNkCJZ2z4IwnrntAGYGHVT MDP1wj1VDH8WUlqcxVOhxI0PrZq45dUAKNQz/rO1JrmsTeUbHv/LA7HEPXHCintTs+NN qCDeKVIZ9fRZUdMBU/PVDVZySpwo37Jc66xg+nb/8qi6iFDif8UMJd+vGlYSkz56jO40 zuO+A32vQA+UftcN0MaVJhTHJlVWNIpsYzqgR6HqsYbUvpUhV6Z91oZim0ixIbzzHlEd fewg== Received: by 10.112.25.193 with SMTP id e1mr3957808lbg.94.1355604574117; Sat, 15 Dec 2012 12:49:34 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id v7sm3194254lbj.13.2012.12.15.12.49.32 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 12:49:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3677406lah.31 for ; Sat, 15 Dec 2012 12:49:32 -0800 (PST) Received: by 10.112.38.66 with SMTP id e2mr3777104lbk.90.1355604572731; Sat, 15 Dec 2012 12:49:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 12:49:02 -0800 (PST) In-Reply-To: <50CCDF02.1080007@status.net> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> From: Nick Jennings Date: Sat, 15 Dec 2012 21:49:02 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e0cb4efe300803784804d0ea498a X-Gm-Message-State: ALoCoQnQ1bvF6UGQiL1+pxHL/a3KBJO2cVc4LsJl4L5Gt+VgphGiCix7fjtetawktg5IwjTa6mTx Cc: webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 20:49:37 -0000 --e0cb4efe300803784804d0ea498a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 totally agree here. Keep things simple and flexible and let the developers worry about client implementation. The only, BUT, I have is the case where we decide there are 'secure' links that shouldn't be divulged over HTTP (Brad proposed this the other day). IF that moves forward then I think we should have server-side filtering of that data over HTTP. I otherwise completely agree with what Evan proposes below. On Sat, Dec 15, 2012 at 9:35 PM, Evan Prodromou wrote: > -1 > > Well-written implementations are going to fallback to HTTP, to HostMeta + > LRDD, and possibly to SWD because that's what's right for the users. > Very-well-written implementations will carefully choose which combination > of SSL and non-SSL makes sense for their application. > > We need to stop backseat driving. Balancing the requirements of getting > the information that the user has requested, versus various security risk= s, > is something that implementers do. > > Some will do it wrong. That is how technology works. > > No one will tell users that they can't have the data they need because > technically the spec says MUST NOT right here in section 5.1.2. However,= a > good cluster of convoluted MUST/MUST NOT language will be enough to keep > people from ever implementing the spec in the first place. > > I suggest the following language: > > Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. > Servers MAY provide a /.well-known/webfinger endpoint over HTTP. > > Clients SHOULD request Webfinger documents via /.well-known/webfinger ove= r > HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger > over HTTP. > > There are a class of attacks on HTTP-only requests listed in the Security > Considerations. There are additional potential attacks on mixed HTTPS and > HTTP requests. Where possible, it is RECOMMENDED that clients and servers > use HTTPS only. > > Those of us who care about micromanaging the client request flow should > take the time to build liberally-licensed Open Source libraries for Pytho= n, > Perl, Java, C++, JavaScript and Ruby. Code is law. > > -Evan > > On 12-12-15 02:56 AM, Paul E. Jones wrote: > > Folks,**** > > ** ** > > Here=E2=80=99s the current language. I get the feeling more people like = this than > what we had before. Now, what fine-tuning do we need to do? Or are peop= le > still of the mind that we need HTTPS only no matter what?**** > > ** ** > > Current language:**** > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, > either serially or in parallel=E2=80=9D. Let the client decide what to d= o based on > its security requirements.**** > > ** ** > > I would like to suggest we change =E2=80=9CIf a query is issued using HTT= PS=E2=80=9D to > =E2=80=9CIf a query is issued using HTTPS because it has strict security > requirements=E2=80=9D. Reasoning, again, is that if a client like a blog= server > issues a query via HTTPS looking for a user=E2=80=99s avatar and it fails= , why not > let it use HTTP? Actually, we could probably just remove this whole seco= nd > paragraph. We could just speak to the certificate checking on the securi= ty > section as it relates to secure clients.**** > > ** ** > > Thus, I propose we go with this (with or without the middle paragraph):**= * > * > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > If a query is issued using HTTPS because it has strict security > requirements and the server has an invalid certificate, the server return= s > a 4xx or 5xx status code, or the HTTPS connection cannot be established f= or > any reason, the client MUST accept that the WebFinger query has failed an= d > MUST NOT attempt to reissue the WebFinger request using HTTP.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > Paul**** > > ** ** > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > --e0cb4efe300803784804d0ea498a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 totally agree here. Keep things simple and flexible and let the develope= rs worry about client implementation.

The only, BUT, I h= ave is the case where we decide there are 'secure' links that shoul= dn't be divulged over HTTP (Brad proposed this the other day). IF that = moves forward then I think we should have server-side filtering of that dat= a over HTTP. I otherwise completely agree with what Evan proposes below.


On Sat, Dec 15, 2012 at 9:35 PM, Ev= an Prodromou <evan@status.net> wrote:
=20 =20 =20
-1

Well-written implementations are going to fallback to HTTP, to HostMeta + LRDD, and possibly to SWD because that's what's ri= ght for the users. Very-well-written implementations will carefully choose which combination of SSL and non-SSL makes sense for their application.

We need to stop backseat driving. Balancing the requirements of getting the information that the user has requested, versus various security risks, is something that implementers do.

Some will do it wrong. That is how technology works.

No one will tell users that they can't have the data they need because technically the spec says MUST NOT right here in section 5.1.2.=C2=A0 However, a good cluster of convoluted MUST/MUST NOT language will be enough to keep people from ever implementing the spec in the first place.

I suggest the following language:
Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. Servers MAY provide a /.well-known/webfinger endpoint over HTTP.

Clients SHOULD request Webfinger documents via /.well-known/webfinger over HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger over HTTP.

There are a class of attacks on HTTP-only requests listed in the Security Considerations. There are additional potential attacks on mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED that clients and servers use HTTPS only.
Those of us who care about micromanaging the client request flow should take the time to build liberally-licensed Open Source libraries for Python, Perl, Java, C++, JavaScript and Ruby. Code is law.

-Evan

On 12-12-15 02:56 AM, Paul E. Jones wrote:
=20 =20 =20

Folks,

=C2=A0

Here=E2=80=99s the current language.=C2=A0 I= get the feeling more people like this than what we had before.=C2=A0 Now, what fine-tuning do we need to do?=C2=A0 Or are people still of t= he mind that we need HTTPS only no matter what?

=C2=A0

Current language:

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel.=C2=A0 The choice of transport protocols depends on the client=E2=80=99s security requirements, though use= of HTTPS is RECOMMENDED in most situations.

=C2=A0

If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

=C2=A0

I would like to suggest we strike =E2=80=9C,= but MUST NOT attempt to use both, either serially or in parallel=E2=80=9D.=C2=A0 Let the client decide what to do based o= n its security requirements.

=C2=A0

I would like to suggest we change =E2=80=9CI= f a query is issued using HTTPS=E2=80=9D to =E2=80=9CIf a query is is= sued using HTTPS because it has strict security requirements=E2=80=9D.=C2=A0 Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user=E2=80=99s avatar and = it fails, why not let it use HTTP?=C2=A0 Actually, we could probably just remove this whole second paragraph.=C2=A0 We could just spea= k to the certificate checking on the security section as it relates to secure clients.

=C2=A0

Thus, I propose we go with this (with or without the middle paragraph):

=C2=A0

Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP.=C2=A0 The choice of transport protocols depends on the client=E2=80= =99s security requirements, though use of HTTPS is RECOMMENDED in most situations.

=C2=A0

If a query is issued using HTTPS because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.

=C2=A0

WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

=C2=A0

Paul

=C2=A0



__________________________________=
_____________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger


--e0cb4efe300803784804d0ea498a-- From perpetual-tripper@wwelves.org Sat Dec 15 13:08:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123EB21F8511 for ; Sat, 15 Dec 2012 13:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRiyVWUkGk6H for ; Sat, 15 Dec 2012 13:08:39 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 28A4B21F850B for ; Sat, 15 Dec 2012 13:08:36 -0800 (PST) X-Originating-IP: 217.70.178.135 Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4E7E217208C; Sat, 15 Dec 2012 22:08:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id C44CYbh7Tu30; Sat, 15 Dec 2012 22:08:23 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D2F5A172067; Sat, 15 Dec 2012 22:08:23 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Nick Jennings In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> Date: Sat, 15 Dec 2012 21:08:23 +0000 Message-Id: <1355605184-sup-8223@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:08:40 -0000 Excerpts from Nick Jennings's message of 2012-12-15 20:49:02 +0000: > +1 totally agree here. Keep things simple and flexible and let the > developers worry about client implementation. >=20 > The only, BUT, I have is the case where we decide there are 'secure' li= nks > that shouldn't be divulged over HTTP (Brad proposed this the other day)= . IF > that moves forward then I think we should have server-side filtering of > that data over HTTP. I otherwise completely agree with what Evan propos= es > below. Nick, again I have impression that you may talk about different scenario.= .. To my understanding Brad proposal didn't have anything to do with server = but only with client. In scenario with MITM attack, client using HTTP tal= ks to server under full control of an attacker, we can NOT expect any sup= port from server side code in this case. So client which made request ove= r HTTP needs to take into account receiving spoofed response and don't us= e it for anything serious! Maybe instead of secure/non-secure we can use terms serious/non-serious c= ontent ;D All the data we publish at our webfinger endpoints stays publicly accessi= ble so I see no need for any filtering on a server... From perpetual-tripper@wwelves.org Sat Dec 15 13:18:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FCF21F850D for ; Sat, 15 Dec 2012 13:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1teOs9VJdwX for ; Sat, 15 Dec 2012 13:18:14 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E921F84C8 for ; Sat, 15 Dec 2012 13:18:14 -0800 (PST) X-Originating-IP: 217.70.178.135 Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 9E69CA805E; Sat, 15 Dec 2012 22:18:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vZSUQefS+fLT; Sat, 15 Dec 2012 22:18:02 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3EDF5A8086; Sat, 15 Dec 2012 22:18:02 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Dick Hardt In-reply-to: <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> Date: Sat, 15 Dec 2012 21:18:01 +0000 Message-Id: <1355606019-sup-9609@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:18:14 -0000 Excerpts from Dick Hardt's message of 2012-12-15 16:30:50 +0000: [snip] > As noted previously, the cost of certs is pretty much zero, so HTTPS as= part of a standard hosting package is really a product management decisi= on followed by a deployment task (i.e., it is not a major financial decis= ion by hosting companies. Do we want to be brave and say HTTPS only and h= elp drive a safer, more secure web? Besides possible complexity of getting and installing a cert I would also= take a look on possible issues with Server Name Indication [1] which may= lead that besides domain name and cert one may also need a dedicated IP = as well :( [1] Server Name Indication From nick@silverbucket.net Sat Dec 15 13:25:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B0321F8534 for ; Sat, 15 Dec 2012 13:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-zYFPrUeyrC for ; Sat, 15 Dec 2012 13:25:35 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1921F8512 for ; Sat, 15 Dec 2012 13:25:35 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3699999lbk.31 for ; Sat, 15 Dec 2012 13:25:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=WgJKzzKr0VskQysqhJQw0F3dkoIN71LP5aU0DV6OD2k=; b=fSIz8wnjtSMAIkAWs/QspnPjAtl1rF4439MmRPAkz+0QYLXPP6f/CoiH5GHCueb+/+ 2jACJddXz+6AivYF+QA50Njr9bM39xHRhXHlqvdrJu7dXb5i7qtj7YzPHVBmRPXyRAwk lrHhrlkNftvnVNdhcBebXXMffjLToYhTPDYk+YQeHdGFquUhYZqxUvSsUu2xS86tkh6z MlNxlU2CiPtFDzr07WiJO7+fgIIoNVVO9wx3Aq5aHoKSPLta+ySqqSPqaHMoBREiaFz+ E9N3lA1k3UMrYDSJ3ug/fhQYmvB9V43GTtoKe5VM3JJTHBtbf3wv02ba9PVEZZmBWxIK UT9A== Received: by 10.112.16.207 with SMTP id i15mr4028733lbd.114.1355606734440; Sat, 15 Dec 2012 13:25:34 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id fj2sm3220339lbb.6.2012.12.15.13.25.33 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 13:25:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3687494lah.31 for ; Sat, 15 Dec 2012 13:25:33 -0800 (PST) Received: by 10.112.87.194 with SMTP id ba2mr3993518lbb.84.1355606733315; Sat, 15 Dec 2012 13:25:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 13:25:03 -0800 (PST) In-Reply-To: <1355605184-sup-8223@heahdk.net> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <1355605184-sup-8223@heahdk.net> From: Nick Jennings Date: Sat, 15 Dec 2012 22:25:03 +0100 Message-ID: To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmMGXzB2rJEd4PTxPM6jRlpczNLBOsgNqe+afx81VohmID4KydMsNLO6yV7ewvM5gjAVr7q Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:25:36 -0000 On Sat, Dec 15, 2012 at 10:08 PM, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Nick Jennings's message of 2012-12-15 20:49:02 +0000: >> +1 totally agree here. Keep things simple and flexible and let the >> developers worry about client implementation. >> >> The only, BUT, I have is the case where we decide there are 'secure' lin= ks >> that shouldn't be divulged over HTTP (Brad proposed this the other day).= IF >> that moves forward then I think we should have server-side filtering of >> that data over HTTP. I otherwise completely agree with what Evan propose= s >> below. > Nick, again I have impression that you may talk about different scenario.= .. > > To my understanding Brad proposal didn't have anything to do with server = but only with client. In scenario with MITM attack, client using HTTP talks= to server under full control of an attacker, we can NOT expect any support= from server side code in this case. So client which made request over HTTP= needs to take into account receiving spoofed response and don't use it for= anything serious! Yes I completely understand the scenario. Brads' proposal was for marking 'security related' links as 'secure' (which is why I used the word 'secure' in single quotes), then mandating that the client implement filtering of these 'security related' links if they were retrieved over HTTP. I was adding that, if we do this, the server should also filter this data when sending a response over HTTP as a precaution against a poorly written client library. We discussed this in-depth in other threads, and I was trying to keep the comment short so as not to distract / carry on about things we already hashed out. > Maybe instead of secure/non-secure we can use terms serious/non-serious c= ontent ;D Sure, that works for me. > All the data we publish at our webfinger endpoints stays publicly accessi= ble so I see no need for any filtering on a server... Because if we differentiate between 'serious' and 'non-serious' links, then we serve out 'serious' links over HTTP, inevitably lazy client code will use that to retrieve authentication related links. If we mark links as 'serious' then we should implement accordingly on both ends (IMO). I think about this in terms of my own server. If someone retrieves something 'serious' from my server and acts on it. I have the peace of mind they got that via. HTTPS because my server does not send it out for HTTP requests. From nick@silverbucket.net Sat Dec 15 13:28:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC621F8A7D for ; Sat, 15 Dec 2012 13:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzoflFK6g5Ty for ; Sat, 15 Dec 2012 13:28:44 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 036AE21F896B for ; Sat, 15 Dec 2012 13:28:43 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3700889lbk.31 for ; Sat, 15 Dec 2012 13:28:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=bIeDQ/9+7bzqZFOIXjm5CvOMqmYG9SOUy/d5OT1DCEY=; b=AoVsT/LEWyGeayFof+WyIpW0+ZAYknm/8jH1Ung+tdXzeaAJccMwK97VNP+IywTnF4 C3rI4GCkOiTbuJZDxhgCX2Z7qO7SfvtnMLEdUEhmrJaVKKw0FuSblxPiUTlIHH+5Tppi wAo+5kC1wet4lXgIQ/KLpzREH+91iJzjmYQxyloZ0P/Lgk6N7fPu36TnW2WL5ohz6Q6q To2626WplJsiaFSQ52bRtdBuKWIQUBLS+Z8ZNs3big77XbQBUOFAdo4hPLBQP0KIifJK mJDaVOjQmENtr7HoW6hip0YmRHvEO5l/ODjudbQHq59L10rEBLq6s3IinyFC1XM+3c2y JAEg== Received: by 10.112.103.202 with SMTP id fy10mr3905023lbb.13.1355606922420; Sat, 15 Dec 2012 13:28:42 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id ti4sm3172246lab.1.2012.12.15.13.28.41 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 13:28:41 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3688415lah.31 for ; Sat, 15 Dec 2012 13:28:41 -0800 (PST) Received: by 10.112.83.133 with SMTP id q5mr3967173lby.40.1355606921238; Sat, 15 Dec 2012 13:28:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 13:28:11 -0800 (PST) In-Reply-To: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <1355605184-sup-8223@heahdk.net> From: Nick Jennings Date: Sat, 15 Dec 2012 22:28:11 +0100 Message-ID: To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnXW0047kfFv0D1vyBRmgRm2qczv3CTMJQS42DUbhkvyRBGf5pw7pkoX2tzEYAfmCxRitQz Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:28:45 -0000 > On Sat, Dec 15, 2012 at 10:08 PM, =E2=98=AE elf Pavlik =E2=98=AE >> In scenario with MITM attack Don't you mean (Wo)MITM ? :) From nick@silverbucket.net Sat Dec 15 13:30:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70621F84CA for ; Sat, 15 Dec 2012 13:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCjIIxgE2l0j for ; Sat, 15 Dec 2012 13:30:21 -0800 (PST) Received: from mail-la0-f66.google.com (mail-la0-f66.google.com [209.85.215.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1319421F84C7 for ; Sat, 15 Dec 2012 13:30:20 -0800 (PST) Received: by mail-la0-f66.google.com with SMTP id e6so670378lah.1 for ; Sat, 15 Dec 2012 13:30:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ilKjpGVhOoDBLiGJo64g7BlgPsU23txpKqR8PAOJUaw=; b=HPtfuV1fMOe/bEYcKDSUSSk/26VXp2Dok0h2cKU6Ev5eIJG68tbSPF0yCjzQ1Hq0UO +8Mf6YEYyiusVkiRUszkhLeRSR+rrd4CCvHWpvygaMuHPsELS7XCD9ROi3iSc1NL9EYk l7lFUtygfi/ALocx7FVTe6U2Pkaq02MW6yNKHzU/qptz8fJRvVkexMaJ24BMjYYrrtLQ Oi2GTDOEB8wQuIDhOPm8ocotSEw6Pd1cfl9L29yxGago4lX8WdjH1F6MxPrgKcpiHtP/ UJS4ck5aSXYAqsUqso6lNTRE7O59f6xDOQIUoZk6QXfMj8eNkw3t9NCAibpYh+IXpdSZ DnBQ== Received: by 10.152.144.38 with SMTP id sj6mr6288544lab.48.1355607020046; Sat, 15 Dec 2012 13:30:20 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id pw17sm3171456lab.5.2012.12.15.13.30.19 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 13:30:19 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3701330lbk.31 for ; Sat, 15 Dec 2012 13:30:19 -0800 (PST) Received: by 10.112.24.161 with SMTP id v1mr3945545lbf.28.1355607018873; Sat, 15 Dec 2012 13:30:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.60.39 with HTTP; Sat, 15 Dec 2012 13:29:48 -0800 (PST) In-Reply-To: <1355606019-sup-9609@heahdk.net> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> <1355606019-sup-9609@heahdk.net> From: Nick Jennings Date: Sat, 15 Dec 2012 22:29:48 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnpRnsKjSoXlhLsWDcDe7EsMfzUDyifmalUASKlMy46w4zOyekXaMaVNY6jn05S6Z1PA6Bz Cc: webfinger , Dick Hardt Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:30:21 -0000 On Sat, Dec 15, 2012 at 10:18 PM, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Dick Hardt's message of 2012-12-15 16:30:50 +0000: > [snip] >> As noted previously, the cost of certs is pretty much zero, so HTTPS as = part of a standard hosting package is really a product management decision = followed by a deployment task (i.e., it is not a major financial decision b= y hosting companies. Do we want to be brave and say HTTPS only and help dri= ve a safer, more secure web? > Besides possible complexity of getting and installing a cert I would also= take a look on possible issues with Server Name Indication [1] which may l= ead that besides domain name and cert one may also need a dedicated IP as w= ell :( Good point, could be considered a 5th reason for allowing HTTP. From perpetual-tripper@wwelves.org Sat Dec 15 13:54:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164321F8467 for ; Sat, 15 Dec 2012 13:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF5YyamD01cJ for ; Sat, 15 Dec 2012 13:54:43 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id D1C4821F8462 for ; Sat, 15 Dec 2012 13:54:42 -0800 (PST) X-Originating-IP: 217.70.178.146 Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id F184E172077; Sat, 15 Dec 2012 22:54:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id jisS3HSHmlCs; Sat, 15 Dec 2012 22:54:30 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 944C7172074; Sat, 15 Dec 2012 22:54:30 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Nick Jennings In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <1355605184-sup-8223@heahdk.net> Date: Sat, 15 Dec 2012 21:54:29 +0000 Message-Id: <1355607780-sup-897@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:54:43 -0000 Excerpts from Nick Jennings's message of 2012-12-15 21:28:11 +0000: > > On Sat, Dec 15, 2012 at 10:08 PM, =E2=98=AE elf Pavlik =E2=98=AE > >> In scenario with MITM attack >=20 > Don't you mean (Wo)MITM ? :) ** Affirmative i guess we all may want to work more on gender neutrality... how about AI= TM - Attacker In The Middle ? ** Out From paulej@packetizer.com Sat Dec 15 22:33:00 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F6221F8536 for ; Sat, 15 Dec 2012 22:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohlz4WV90xtN for ; Sat, 15 Dec 2012 22:32:58 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B69DE21F8538 for ; Sat, 15 Dec 2012 22:32:58 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG6Wtwx002605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 01:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355639576; bh=8H9SzYGgo34kEE2h8nlqx5JpAqyQ3iftTatkQGOo68k=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=IDXfSV2Dvz/Q6FbduJqJB7W7x0Jvxns8VK2v3oXo2w58daq49ufZkim5Qpmc/H2a6 STjXXq+NwvTNKFrqh//KtUTNgclIPYyDK11shVG1AHb4xUq5BixFmFHBN0c1I06ASi kOpgMHHLIXCM/Fcy4F3cRnDuTOnJrmufQgQlReXo= From: "Paul E. Jones" To: "'Nick Jennings'" , References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> In-Reply-To: Date: Sun, 16 Dec 2012 01:32:54 -0500 Message-ID: <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01CDDB2D.45E63B20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gJf97KaA2wuLZeXbL224A== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:33:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01CDDB2D.45E63B20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The secure links idea is separate from the problem at hand: when does a = device use HTTPS vs HTTP and when is it acceptable to query HTTP? =20 The secure links idea (which I don=E2=80=99t particularly like) helps = the server decide what to return. At least as I understand it. Since = there is nothing secure about a link in and of itself, I don=E2=80=99t = see any reason to classify link types. But, a server is certainly free = to return whatever it likes over HTTP, and that might be different than = what it returns over HTTP. But, why bother? If we ensure proper client = behavior, it=E2=80=99s not an issue. And by =E2=80=9Cproper=E2=80=9D, = that means ensuring that clients that absolutely need to ensure that = data is not modified in flight must only use HTTPS. Any client that = does not have that restriction could do what it wants, but with some = reasonable guidance =E2=80=A6 that we=E2=80=99re trying to hammer out. =20 Paul =20 From: Nick Jennings [mailto:nick@silverbucket.net]=20 Sent: Saturday, December 15, 2012 11:05 AM To: webfinger@googlegroups.com Cc: Paul E. Jones; webfinger@ietf.org Subject: Re: Current HTTP/HTTPS Language =20 Are we foregoing the secure links filtering idea? On Sat, Dec 15, 2012 at 5:02 PM, Kingsley Idehen = wrote: On 12/15/12 2:56 AM, Paul E. Jones wrote: Folks, =20 Here=E2=80=99s the current language. I get the feeling more people like = this than what we had before. Now, what fine-tuning do we need to do? = Or are people still of the mind that we need HTTPS only no matter what? =20 Current language: =20 Clients MAY issue a query to the WebFinger server using either HTTPS or = HTTP, but MUST NOT attempt to use both, either serially or in parallel. = The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. =20 If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and MUST NOT attempt to reissue the = WebFinger request using HTTP. =20 WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. =20 I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, either serially or in parallel=E2=80=9D. Let the client decide = what to do based on its security requirements. =20 I would like to suggest we change =E2=80=9CIf a query is issued using = HTTPS=E2=80=9D to =E2=80=9CIf a query is issued using HTTPS because it = has strict security requirements=E2=80=9D. Reasoning, again, is that if = a client like a blog server issues a query via HTTPS looking for a = user=E2=80=99s avatar and it fails, why not let it use HTTP? Actually, = we could probably just remove this whole second paragraph. We could = just speak to the certificate checking on the security section as it = relates to secure clients. =20 Thus, I propose we go with this (with or without the middle paragraph): =20 Clients MAY issue a query to the WebFinger server using either HTTPS or = HTTP. The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. =20 If a query is issued using HTTPS because it has strict security = requirements and the server has an invalid certificate, the server = returns a 4xx or 5xx status code, or the HTTPS connection cannot be = established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP. =20 WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. =20 Paul =20 +1 --=20 =20 Regards, =20 Kingsley Idehen =20 Founder & CEO=20 OpenLink Software =20 Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen =20 =20 =20 =20 =20 ------=_NextPart_000_00B6_01CDDB2D.45E63B20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The secure links idea is separate from the problem at hand: when does = a device use HTTPS vs HTTP and when is it acceptable to query = HTTP?

 

The secure links idea (which I don=E2=80=99t particularly like) helps = the server decide what to return.=C2=A0 At least as I understand = it.=C2=A0 Since there is nothing secure about a link in and of itself, I = don=E2=80=99t see any reason to classify link types.=C2=A0 But, a server = is certainly free to return whatever it likes over HTTP, and that might = be different than what it returns over HTTP.=C2=A0 But, why = bother?=C2=A0 If we ensure proper client behavior, it=E2=80=99s not an = issue. And by =E2=80=9Cproper=E2=80=9D, that means ensuring that clients = that absolutely need to ensure that data is not modified in flight must = only use HTTPS.=C2=A0 Any client that does not have that restriction = could do what it wants, but with some reasonable guidance =E2=80=A6 that = we=E2=80=99re trying to hammer out.

 

Paul

 

From:= = Nick Jennings [mailto:nick@silverbucket.net]
Sent: Saturday, = December 15, 2012 11:05 AM
To: = webfinger@googlegroups.com
Cc: Paul E. Jones; = webfinger@ietf.org
Subject: Re: Current HTTP/HTTPS = Language

 

Are we foregoing the secure links = filtering idea?

On Sat, Dec 15, = 2012 at 5:02 PM, Kingsley Idehen <kidehen@openlinksw.com> = wrote:

On = 12/15/12 2:56 AM, Paul E. Jones wrote:

Folks,<= /o:p>

 <= /o:p>

Here=E2=80=99= s the current language.  I get the feeling more people like this = than what we had before.  Now, what fine-tuning do we need to = do?  Or are people still of the mind that we need HTTPS only no = matter what?

 <= /o:p>

Current = language:

 <= /o:p>

Clients MAY = issue a query to the WebFinger server using either HTTPS or HTTP, but = MUST NOT attempt to use both, either serially or in parallel.  The = choice of transport protocols depends on the client=E2=80=99s security = requirements, though use of HTTPS is RECOMMENDED in most = situations.

 <= /o:p>

If a query = is issued using HTTPS and the server has an invalid certificate, the = server returns a 4xx or 5xx status code, or the HTTPS connection cannot = be established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP.

 <= /o:p>

WebFinger = servers operating on HTTP MAY redirect a client using an appropriate = HTTP status code to another HTTP or an HTTPS URI.  Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server = redirects.

 <= /o:p>

I would = like to suggest we strike =E2=80=9C, but MUST NOT attempt to use both, = either serially or in parallel=E2=80=9D.  Let the client decide = what to do based on its security requirements.

 <= /o:p>

I would = like to suggest we change =E2=80=9CIf a query is issued using = HTTPS=E2=80=9D to =E2=80=9CIf a query is issued using HTTPS because it = has strict security requirements=E2=80=9D.  Reasoning, again, is = that if a client like a blog server issues a query via HTTPS looking for = a user=E2=80=99s avatar and it fails, why not let it use HTTP?  = Actually, we could probably just remove this whole second = paragraph.  We could just speak to the certificate checking on the = security section as it relates to secure clients.

 <= /o:p>

Thus, I = propose we go with this (with or without the middle = paragraph):

 <= /o:p>

Clients MAY = issue a query to the WebFinger server using either HTTPS or HTTP.  = The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations.

 <= /o:p>

If a = query is issued using HTTPS because it has strict security requirements = and the server has an invalid certificate, the server returns a 4xx or = 5xx status code, or the HTTPS connection cannot be established for any = reason, the client MUST accept that the WebFinger query has failed and = MUST NOT attempt to reissue the WebFinger request using = HTTP.

 <= /o:p>

WebFinger = servers operating on HTTP MAY redirect a client using an appropriate = HTTP status code to another HTTP or an HTTPS URI.  Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server = redirects.

 <= /o:p>

Paul

 <= /o:p>

+1


-- 
 
Regards,
 
Kingsley =
Idehen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
Founder & CEO =

OpenLink =
Software=C2=A0=C2=A0=C2=A0=C2=A0 
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen<= /span>
Twitter/Identi.ca handle: =
@kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn =
Profile: http://www.linkedin.com/in/kidehen
 
 
 
 

 

------=_NextPart_000_00B6_01CDDB2D.45E63B20-- From paulej@packetizer.com Sat Dec 15 22:43:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7421F8439 for ; Sat, 15 Dec 2012 22:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lQwb1UhlrWD for ; Sat, 15 Dec 2012 22:43:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF221F8436 for ; Sat, 15 Dec 2012 22:43:16 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG6hDQc003050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 01:43:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355640194; bh=+P5av9MJE0Eol//4pxQujpct4MQFqf+6Lp/+gorsF3g=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qc8gT8oL5yFKjakssWwjKFhpFSg6gb8FfJlWoHfBlWI3gP3BE2ciREZLsz6RD7SIo AVMqSVamdehg3gM4b/s504K/jKMWzvJrWzo7Ytc8Hb/y4ZJRp04ZlTf8xpKxBfbX8s LEIf8p4bwftbbiEiJt0GB6kiSE8m7GggbBB5wPYI= From: "Paul E. Jones" To: References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> In-Reply-To: <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> Date: Sun, 16 Dec 2012 01:43:12 -0500 Message-ID: <00c201cddb58$9f1b8bc0$dd52a340$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQELUdhvAhw3xu53UQOPgZBHozChcAI/PkK5AtSbhMICoQbKpwH7TRpvmVKJtTA= Content-Language: en-us Cc: 'John Panzer' , webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:43:17 -0000 Dick, > As noted previously, the cost of certs is pretty much zero, so HTTPS as > part of a standard hosting package is really a product management > decision followed by a deployment task (i.e., it is not a major > financial decision by hosting companies. Do we want to be brave and say > HTTPS only and help drive a safer, more secure web? But they're not. Few (maybe only StartCom) provides free certificates and those (last I checked) were limited to a single domain for a single year. So, users are stuck with these options: 1) Buying a certificate that costs more than the domain itself 2) Getting a free one that has to be updated annually 3) Paying for a wildcard certificate, but those are fairly expensive and only cover *.example.com, not *.foo.example.com. To cover the sub-domain, one needs another certificate or wildcard certificate And then there is administrative effort. Personally, I hate dealing with certificates. For that reason, I would LOVE to be able to completely automate use of certificates by generating them myself and putting them in DNS using procedures defined in DANE. I wish the world would go forward with DNSSEC! As it is, they're expensive in one way or another, a headache, etc. They're vital for business, but far less vital to most people who might be running a blog or whatever. All that said, I'm still OK with mandating TLS. Would casual bloggers even use an identifier like joe@myblog.example.com? Or would they use a gmail identifier or other identifier from a domain that likely supports WF securely? But, I assume serious bloggers would not be turned off by a certificate. I have no idea. Paul From paulej@packetizer.com Sat Dec 15 22:50:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70D21F853F for ; Sat, 15 Dec 2012 22:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+fItK2IHcqp for ; Sat, 15 Dec 2012 22:50:52 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3A21F8507 for ; Sat, 15 Dec 2012 22:50:52 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG6oodO003346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 01:50:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355640650; bh=kyzG9hLmG3Ek2MenOHL0VHmrQ8jgRKgJIK7OBbqwERI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=fNAD6PGH7FNvRWHb3K/+VMRjt/PIsjRajgqPP+TX0qefOhUfrCiRgKXAJQxT5rvWt 8Mm5+HYUOV9F9z/PHVGUrAf20nqEN3a2oO1t/vJWlCT2hu/bQsaRrbuM30gmyuMNnm HDAsqVVZdrqVTaCY1aL3qm4PVbn6LHLtOXYfhyVA= From: "Paul E. Jones" To: "'James M Snell'" References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 01:50:49 -0500 Message-ID: <00cf01cddb59$af1d7cd0$0d587670$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01CDDB2F.C648FB70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gHY6+Zol4xcnjA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:50:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D0_01CDDB2F.C648FB70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, =20 But the client should automatically switch to using HTTP if security is = not an issue. Again, if I=E2=80=99m running a blog and I really = don=E2=80=99t care if the avatar link I grab for you gets = =E2=80=9Chacked=E2=80=9D in flight, I might issue this query: wf.query("acct:you@example.com", WF_NON_SECURE); =20 This would query using HTTPS, but if it failed, try HTTP automatically. =20 Someone suggested the second parameter should default to SECURE, meaning = the client ONLY uses HTTP. That=E2=80=99s reasonable. So, if either of = these calls were made: =20 wf.query("acct:you@example.com"); wf.query("acct:you@example.com", WF_SECURE); =20 Then only HTTPS wouyld be queried and no attempt would be made via HTTP. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Saturday, December 15, 2012 12:45 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language =20 =20 =20 On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones = wrote: Folks, =20 Here=E2=80=99s the current language. I get the feeling more people like = this than what we had before. Now, what fine-tuning do we need to do? = Or are people still of the mind that we need HTTPS only no matter what? =20 Current language: =20 Clients MAY issue a query to the WebFinger server using either HTTPS or = HTTP, but MUST NOT attempt to use both, either serially or in parallel. = The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. =20 If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and MUST NOT attempt to reissue the = WebFinger request using HTTP. =20 WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. =20 I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, either serially or in parallel=E2=80=9D. Let the client decide = what to do based on its security requirements. =20 I would like to suggest we change =E2=80=9CIf a query is issued using = HTTPS=E2=80=9D to =E2=80=9CIf a query is issued using HTTPS because it = has strict security requirements=E2=80=9D. Reasoning, again, is that if = a client like a blog server issues a query via HTTPS looking for a = user=E2=80=99s avatar and it fails, why not let it use HTTP? Actually, = we could probably just remove this whole second paragraph. We could = just speak to the certificate checking on the security section as it = relates to secure clients. =20 =20 Note that there is a different between a user-agent automatically = falling back to http and a user issuing a second request after failing. = The former involves no user-interaction with the second step, the latter = requires it. Client implementations ought to be forbidden from automatic = fallbacks. Require intentional intervention to issue the secondary = request. This is no different really than the issues involved in = automatic redirection of unsafe HTTP methods (see [1] section 7.4).=20 =20 [1] = http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_= text=3D1 =20 So rather than removing that paragraph, try this: =20 "If a query is issued using HTTPS and the server has an invalid = certificate, the server returns a 4xx or 5xx status code, or the HTTPS = connection cannot be established for any reason, the client MUST accept = that the WebFinger query has failed and SHOULD NOT attempt to = automatically reissue the WebFinger request using HTTP. This failure = condition SHOULD be reported to the user. Following such a failure, a = client MAY attempt to issue a separate subsequent query over HTTP if an = application's security requirements permit." =20 This would require that any subsequent HTTP fallbacks would occur only = after human intervention (either the user reissues the request or a = developer specifically handles the failure and sends a new request). In = either case, fallback requires a conscious choice to accept the fallback = risks. =20 - James =20 Thus, I propose we go with this (with or without the middle paragraph): =20 Clients MAY issue a query to the WebFinger server using either HTTPS or = HTTP. The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations. =20 If a query is issued using HTTPS because it has strict security = requirements and the server has an invalid certificate, the server = returns a 4xx or 5xx status code, or the HTTPS connection cannot be = established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP. =20 WebFinger servers operating on HTTP MAY redirect a client using an = appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server redirects. =20 Paul =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 ------=_NextPart_000_00D0_01CDDB2F.C648FB70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James,

 

But the client should automatically switch to using HTTP if security = is not an issue. =C2=A0Again, if I=E2=80=99m running a blog and I really = don=E2=80=99t care if the avatar link I grab for you gets = =E2=80=9Chacked=E2=80=9D in flight, I might issue this = query:

=C2=A0=C2=A0 wf.query("acct:you@example.com", = WF_NON_SECURE);

 

This would query using HTTPS, but if it failed, try HTTP = automatically.

 

Someone suggested the second parameter should default to SECURE, = meaning the client ONLY uses HTTP. =C2=A0That=E2=80=99s = reasonable.=C2=A0 So, if either of these calls were = made:

 

=C2=A0=C2=A0 = wf.query("acct:you@example.com");

=C2=A0=C2=A0 wf.query("acct:you@example.com", = WF_SECURE);

 

Then only HTTPS wouyld be queried and no attempt would be made via = HTTP.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, = December 15, 2012 12:45 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Current HTTP/HTTPS = Language

 

 

 

On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

Here=E2=80=99= s the current language.  I get the feeling more people like this = than what we had before.  Now, what fine-tuning do we need to = do?  Or are people still of the mind that we need HTTPS only no = matter what?

 <= /o:p>

Current = language:

 <= /o:p>

Clients MAY = issue a query to the WebFinger server using either HTTPS or HTTP, but = MUST NOT attempt to use both, either serially or in parallel.  The = choice of transport protocols depends on the client=E2=80=99s security = requirements, though use of HTTPS is RECOMMENDED in most = situations.

 <= /o:p>

If a query = is issued using HTTPS and the server has an invalid certificate, the = server returns a 4xx or 5xx status code, or the HTTPS connection cannot = be established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP.

 <= /o:p>

WebFinger = servers operating on HTTP MAY redirect a client using an appropriate = HTTP status code to another HTTP or an HTTPS URI.  Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server = redirects.

 <= /o:p>

I would = like to suggest we strike =E2=80=9C, but MUST NOT attempt to use both, = either serially or in parallel=E2=80=9D.  Let the client decide = what to do based on its security requirements.

 <= /o:p>

I would = like to suggest we change =E2=80=9CIf a query is issued using = HTTPS=E2=80=9D to =E2=80=9CIf a query is issued using HTTPS because it = has strict security requirements=E2=80=9D.  Reasoning, again, is = that if a client like a blog server issues a query via HTTPS looking for = a user=E2=80=99s avatar and it fails, why not let it use HTTP?  = Actually, we could probably just remove this whole second = paragraph.  We could just speak to the certificate checking on the = security section as it relates to secure clients.

 <= /o:p>

 

Note that there is a different between a user-agent = automatically falling back to http and a user issuing a second request = after failing. The former involves no user-interaction with the second = step, the latter requires it. Client implementations ought to be = forbidden from automatic fallbacks. Require intentional intervention to = issue the secondary request. This is no different really than the issues = involved in automatic redirection of unsafe HTTP methods (see [1] = section 7.4). 

 

 

So rather than removing that paragraph, try = this:

 

"If a query is issued using = HTTPS and the server has an invalid certificate, the server returns a = 4xx or 5xx status code, or the HTTPS connection cannot be established = for any reason, the client MUST accept that the WebFinger query has = failed and SHOULD NOT attempt to automatically reissue the WebFinger = request using HTTP. This failure condition SHOULD be reported to the = user. Following such a failure, a client MAY attempt to issue a separate = subsequent query over HTTP if an application's security requirements = permit."

 

This would require that any subsequent HTTP fallbacks = would occur only after human intervention (either the user reissues the = request or a developer specifically handles the failure and sends a new = request). In either case, fallback requires a conscious choice to accept = the fallback risks.

 

- = James

 

Thus, I = propose we go with this (with or without the middle = paragraph):

 <= /o:p>

Clients MAY = issue a query to the WebFinger server using either HTTPS or HTTP.  = The choice of transport protocols depends on the client=E2=80=99s = security requirements, though use of HTTPS is RECOMMENDED in most = situations.

 <= /o:p>

If a = query is issued using HTTPS because it has strict security requirements = and the server has an invalid certificate, the server returns a 4xx or = 5xx status code, or the HTTPS connection cannot be established for any = reason, the client MUST accept that the WebFinger query has failed and = MUST NOT attempt to reissue the WebFinger request using = HTTP.

 <= /o:p>

WebFinger = servers operating on HTTP MAY redirect a client using an appropriate = HTTP status code to another HTTP or an HTTPS URI.  Likewise, = WebFinger servers operating on HTTPS MAY redirect a client to another = HTTPS URI, but MUST NOT redirect a client to an HTTP URI.  Further, = clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, = but SHOULD automatically follow all other server = redirects.

 

Paul

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_00D0_01CDDB2F.C648FB70-- From bradfitz@google.com Sat Dec 15 22:52:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5EB21F8507 for ; Sat, 15 Dec 2012 22:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ixdegpEXp8U for ; Sat, 15 Dec 2012 22:52:35 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id DFD1D21F880B for ; Sat, 15 Dec 2012 22:52:34 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2123360wgb.13 for ; Sat, 15 Dec 2012 22:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/0nQcxzeBnyZ6AVpM9kUb1GPKyJuTasH9nlvPVyDN+c=; b=d9ugL2FLhPS+vVp+jpujMpyf5lOweTfQUP+p6+l3JfYO71vZNNL9ZM2rWM7PHgYMqG tJQlIDVC7D4uz7fAHAecUQpBl7D+9WZOAAcmBHZORRKq2JR18OSx7iPqvdtRqR9g3zRp la8ROuyt9U+5ADBekit/iRZZcrD2hHgE4exIplhktEzzxtR2Az3QaHt8IIT4lEmpui5f fgrrBDyC2Ww9Rzcr70ywGmYGSa50I1DB7IoGh7g6KUaLENKcQg3RrtLP4ekWczUdjY01 5d5UmetUQj8t+SJNTNSTrFc/TNGCQzgyyug07MwVg7A8lt4jsEtZnJDwtu7rrf22DslG Gv4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/0nQcxzeBnyZ6AVpM9kUb1GPKyJuTasH9nlvPVyDN+c=; b=A+oTlQ675IFCKRBIfXNrhm/Dqhd7TRFcjfN20VdBIWtRTNtY85elV5b834hBQEdUOJ seJZu9J3t7aU96xGafoRh2Azah9wafnjtDQU8xQuNCYhmH1V/N/2voM2XOxHnv3N2/se AArokWeuyAme00L8sbsyWwe/p2ObdM8XHb3V2Kgv+dnoccfj6JQabvqsXBG4FZVMvIOn RLlC9+QjIRkVGXcm+8FBKplJfnY4FSXKR4mMfmCq7zT3MZ3E3Y2bWsLBvmunTyxw805g zuVNSsTXXso2uscPYdVdk/ZxgyptAfmy00nsmY2JlzQEEuKi5rePUi6NyikIf5RILyBx Vxkw== MIME-Version: 1.0 Received: by 10.180.99.227 with SMTP id et3mr9820491wib.6.1355640753934; Sat, 15 Dec 2012 22:52:33 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sat, 15 Dec 2012 22:52:33 -0800 (PST) In-Reply-To: <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> Date: Sat, 15 Dec 2012 22:52:33 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d041826aa94d17604d0f2b5f0 X-Gm-Message-State: ALoCoQmvrjqnwMBwiWlyK1pcQgcD0ZOdhZTMg8fN9XKDcS85fGnBwaglvdCHsnpiqYlI4WMvr++W4CUhjuf0AYXm9YH+PFD730XwlkDpVGFHE+Gbi5sToMcdh1nU+uezgSLFn3wS7U9WIELbEtfAkAXmCwAA4OEdLF81ZmxBPo7IM5iKjxhOY/y3+syHVGY1D1AGBPF8PlY2 Cc: webfinger@ietf.org, Nick Jennings , webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:52:36 -0000 --f46d041826aa94d17604d0f2b5f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones wrot= e: > > The secure links idea (which I don=E2=80=99t particularly like) helps the= server > decide what to return. At least as I understand it. > No, you misunderstand it. Maybe you don't like it because you don't understand it. I'll try to rephrase: > Since there is nothing secure about a link in and of itself, I don=E2=80= =99t see > any reason to classify link types. > The point was to encode classification (a rel type's "requires-HTTPS" property) into the rel type itself, so clients could be free of any configuration (nobody has to say "I want secure" or "sure, HTTP works I guess?") and clients can then safely failover from HTTPS to HTTP, since the *client* (again! the client, NOT the server) does the filtering. > But, a server is certainly free to return whatever it likes over HTTP, > and that might be different than what it returns over HTTP. But, why > bother? > I think your "why bother?" might be about a line of confusion that's unrelated to my bother: I'm bothered by webfinger being vulnerable to MITM, and users having to opt-in to security. > If we ensure proper client behavior, it=E2=80=99s not an issue. And by = =E2=80=9Cproper=E2=80=9D, > that means ensuring that clients that absolutely need to ensure that data > is not modified in flight must only use HTTPS. Any client that does not > have that restriction could do what it wants, but with some reasonable > guidance =E2=80=A6 that we=E2=80=99re trying to hammer out. > I'm fine with people using HTTP to fetch certain links. What I am NOT fine with is people telling their webfinger client, "Please fetch me the https://openid.net/connect/server link for foo@example.com. Oh, wait, what? I have to pick HTTPS or HTTP now? Oh, whatever, HTTP." And then it doesn't matter what your server returned, because the user's already been MITMed. HTTPS-only avoids this complication, but if we're going to permit HTTP, I was at least hoping we could make secure uses of WebFinger have a much higher likelihood of being secure but classifying rel types (NOT classifying links) and teaching clients that some rel types are HTTPS-only and the rest are whatever (since a lot of people don't seem to care about the security of their avatar or name). I'm willing to draw pictures or write such a client in the language of your choice to demonstrate this, if it's still unclear. --f46d041826aa94d17604d0f2b5f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:


The secure links idea (which I don=E2=80=99t par= ticularly like) helps the server decide what to return.=C2=A0 At least as I= understand it.=C2=A0


No, you misunderstand it.
=
Maybe you don't like it because you don't understand= it. =C2=A0I'll try to rephrase:
=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Since there is nothing secure about a link in and= of itself, I don=E2=80=99t see any reason to classify link types.


The point was to encode=C2=A0classif= ication=C2=A0(a rel type's "requires-HTTPS" property) into th= e rel type itself, so clients could be free of any configuration (nobody ha= s to say "I want secure" or "sure, HTTP works I guess?"= ) and clients can then safely failover from HTTPS to HTTP, since the *clien= t* (again! the client, NOT the server) does the filtering.
=C2=A0

= =C2=A0 But, a server is certainly free to return whatever it likes over HTT= P, and that might be different than what it returns over HTTP.=C2=A0 But, w= hy bother?=C2=A0


I think your "why bother?"= might be about a line of confusion that's unrelated to my bother: =C2= =A0I'm bothered by webfinger being vulnerable to MITM, and users having= to opt-in to security.
=C2=A0

= If we ensure proper client behavior, it=E2=80=99s not an issue. And by =E2= =80=9Cproper=E2=80=9D, that means ensuring that clients that absolutely nee= d to ensure that data is not modified in flight must only use HTTPS.=C2=A0 = Any client that does not have that restriction could do what it wants, but = with some reasonable guidance =E2=80=A6 that we=E2=80=99re trying to hammer= out.


I'm fine with people using HTTP = to fetch certain links.

What I am NOT fine with is= people telling their webfinger client, "Please fetch me the https://openid.net/connect/server link for foo@example.com. =C2=A0 O= h, wait, what? =C2=A0I have to pick HTTPS or HTTP now? =C2=A0Oh, whatever, = HTTP." =C2=A0And then it doesn't matter what your server returned,= because the user's already been MITMed.

HTTPS-only avoids this complication, but if we're g= oing to permit HTTP, I was at least hoping we could make secure uses of Web= Finger have a much higher=C2=A0likelihood=C2=A0of being secure but classify= ing rel types (NOT classifying links) and teaching clients that some rel ty= pes are HTTPS-only and the rest are whatever (since a lot of people don'= ;t seem to care about the security of their avatar or name).

I'm willing to draw pictures or write such a client= in the language of your choice to demonstrate this, if it's still uncl= ear.
--f46d041826aa94d17604d0f2b5f0-- From jasnell@gmail.com Sat Dec 15 22:58:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04B021F879A for ; Sat, 15 Dec 2012 22:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSFpCFKBdulF for ; Sat, 15 Dec 2012 22:58:19 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21F8455 for ; Sat, 15 Dec 2012 22:58:19 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7884410ieb.31 for ; Sat, 15 Dec 2012 22:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8t2NxnbqIKtT0jIYT9AQzxjsGNPR8HdRQlnxj+Ug2rA=; b=yYgEbV71vlbYu2RlsIkBjzZGLNSjtmuRVni4DevnKRMaKT6EY702oqsoCaz8aMxaO+ hqPo+bFFlvT68wp5iRh4a0V6yGMa0YOoZv3P9IBkhoqjlaqZPCqhv32n+QJv5ThlMONa L9Z6Rl6txHx08Y/BhFgDLHrN1pGPGHLj537OEp7gk2OZbaAwIDcxsnNpSpY0oyJ1BN2n qgWFZgCMtFDmgWlFBezs0WCiQhCnztEte/QQlwjEmkmPpZkmxSxIAjNdQULCoz55LcbL Ci3RlF8s5oKhbGzcOYh4wYVhlt8oSjlz1jLq/KShgDEwhoMH3EXUUiM1OiOPcxSRR0Nk eVHA== Received: by 10.50.41.200 with SMTP id h8mr6120675igl.0.1355641098812; Sat, 15 Dec 2012 22:58:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sat, 15 Dec 2012 22:57:58 -0800 (PST) In-Reply-To: <00cf01cddb59$af1d7cd0$0d587670$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <00cf01cddb59$af1d7cd0$0d587670$@packetizer.com> From: James M Snell Date: Sat, 15 Dec 2012 22:57:58 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9340ad1233e1d04d0f2cac8 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:58:20 -0000 --14dae9340ad1233e1d04d0f2cac8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 10:50 PM, Paul E. Jones wrot= e: > James,**** > > ** ** > > But the client should automatically switch to using HTTP if security is > not an issue. Again, if I=E2=80=99m running a blog and I really don=E2= =80=99t care if the > avatar link I grab for you gets =E2=80=9Chacked=E2=80=9D in flight, I mig= ht issue this > query:**** > > wf.query("acct:you@example.com", WF_NON_SECURE);**** > > ** > ** > > This would query using HTTPS, but if it failed, try HTTP automatically.**= * > * > > ** > Question... if fallback is automatic.. what happens in the following situation: 1. Client sends a request to HTTPS... server responds with a 5xx... 2. Client sends a request to HTTP automatically.. server responds with a 3xx redirect to HTTPS, because the server says HTTPS is required. 3. Client follows the redirect and sends a request to HTTPS... server responds with a 5xx... rinse, repeat Second question, if security really isn't an issue, why would I issue the request over HTTPS in the first place? Why wouldn't I just try HTTP first and hope for the best? - James > ** > > Someone suggested the second parameter should default to SECURE, meaning > the client ONLY uses HTTP. That=E2=80=99s reasonable. So, if either of = these > calls were made:**** > > ** ** > > wf.query("acct:you@example.com");**** > > wf.query("acct:you@example.com", WF_SECURE);**** > > ** ** > > Then only HTTPS wouyld be queried and no attempt would be made via HTTP.*= * > ** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Saturday, December 15, 2012 12:45 PM > *To:* Paul E. Jones > *Cc:* webfinger@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [webfinger] Current HTTP/HTTPS Language**** > > ** ** > > ** ** > > ** ** > > On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > Here=E2=80=99s the current language. I get the feeling more people like = this than > what we had before. Now, what fine-tuning do we need to do? Or are peop= le > still of the mind that we need HTTPS only no matter what?**** > > **** > > Current language:**** > > **** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP, but MUST NOT attempt to use both, either serially or in parallel. > The choice of transport protocols depends on the client=E2=80=99s securit= y > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > **** > > If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and MUST NOT attempt to reissue the > WebFinger request using HTTP.**** > > **** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > **** > > I would like to suggest we strike =E2=80=9C, but MUST NOT attempt to use = both, > either serially or in parallel=E2=80=9D. Let the client decide what to d= o based on > its security requirements.**** > > **** > > I would like to suggest we change =E2=80=9CIf a query is issued using HTT= PS=E2=80=9D to > =E2=80=9CIf a query is issued using HTTPS because it has strict security > requirements=E2=80=9D. Reasoning, again, is that if a client like a blog= server > issues a query via HTTPS looking for a user=E2=80=99s avatar and it fails= , why not > let it use HTTP? Actually, we could probably just remove this whole seco= nd > paragraph. We could just speak to the certificate checking on the securi= ty > section as it relates to secure clients.**** > > **** > > ** ** > > Note that there is a different between a user-agent automatically falling > back to http and a user issuing a second request after failing. The forme= r > involves no user-interaction with the second step, the latter requires it= . > Client implementations ought to be forbidden from automatic fallbacks. > Require intentional intervention to issue the secondary request. This is = no > different really than the issues involved in automatic redirection of > unsafe HTTP methods (see [1] section 7.4). **** > > ** ** > > [1] > http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_= text=3D1 > **** > > ** ** > > So rather than removing that paragraph, try this:**** > > ** ** > > "If a query is issued using HTTPS and the server has an invalid > certificate, the server returns a 4xx or 5xx status code, or the HTTPS > connection cannot be established for any reason, the client MUST accept > that the WebFinger query has failed and SHOULD NOT attempt to automatical= ly > reissue the WebFinger request using HTTP. This failure condition SHOULD b= e > reported to the user. Following such a failure, a client MAY attempt to > issue a separate subsequent query over HTTP if an application's security > requirements permit."**** > > **** > > This would require that any subsequent HTTP fallbacks would occur only > after human intervention (either the user reissues the request or a > developer specifically handles the failure and sends a new request). In > either case, fallback requires a conscious choice to accept the fallback > risks.**** > > ** ** > > - James**** > > ** ** > > Thus, I propose we go with this (with or without the middle paragraph):**= * > * > > **** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > **** > > If a query is issued using HTTPS because it has strict security > requirements and the server has an invalid certificate, the server return= s > a 4xx or 5xx status code, or the HTTPS connection cannot be established f= or > any reason, the client MUST accept that the WebFinger query has failed an= d > MUST NOT attempt to reissue the WebFinger request using HTTP.**** > > **** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > **** > > Paul**** > > **** > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --14dae9340ad1233e1d04d0f2cac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

On Sat, Dec 15, 2012 at 10:50 PM, Paul E= . Jones <paulej@packetizer.com> wrote:

James,=

=C2=A0

But the client shou= ld automatically switch to using HTTP if security is not an issue. =C2=A0Ag= ain, if I=E2=80=99m running a blog and I really don=E2=80=99t care if the a= vatar link I grab for you gets =E2=80=9Chacked=E2=80=9D in flight, I might = issue this query:

=C2=A0=C2=A0 wf.query(&qu= ot;acct:you@exa= mple.com", WF_NON_SECURE);

=C2=A0=C2= =A0

This would query using HTTPS, but if it failed, try= HTTP automatically.

<= /div>

Question... if fallback is automatic.= . what happens in the following situation:

1. Client sends a request to HTTPS... server responds w= ith a 5xx...
2. Client sends a request to HTTP automatically.. se= rver responds with a 3xx redirect to HTTPS, because the server says HTTPS i= s required.
3. Client follows the redirect and sends a request to HTTPS... server = responds with a 5xx... rinse, repeat

Second questi= on, if security really isn't an issue, why would I issue the request ov= er HTTPS in the first place? Why wouldn't I just try HTTP first and hop= e for the best?

- James
=C2=A0

=C2=A0

Someone suggested the sec= ond parameter should default to SECURE, meaning the client ONLY uses HTTP. = =C2=A0That=E2=80=99s reasonable.=C2=A0 So, if either of these calls were ma= de:

=C2=A0

=C2=A0=C2=A0 wf.que= ry("acct:y= ou@example.com");

=C2=A0=C2=A0 wf.query(&qu= ot;acct:you@exa= mple.com", WF_SECURE);

=C2=A0

Then only HTTPS wou= yld be queried and no attempt would be made via HTTP.<= /p>

=C2=A0

Paul<= /span>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, December 15, 2012 12:45 PM
To: Paul E. Jon= es
Cc: we= bfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: [webfinger] Current HTTP/HTTPS Language

= =C2=A0

=C2=A0

=C2=A0

On Fri, Dec 14, 2012 at= 11:56 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

Here=E2=80=99s the current language.=C2=A0 I get the fee= ling more people like this than what we had before.=C2=A0 Now, what fine-tu= ning do we need to do?=C2=A0 Or are people still of the mind that we need H= TTPS only no matter what?

=C2=A0

Curre= nt language:

=C2=A0

Clients MAY i= ssue a query to the WebFinger server using either HTTPS or HTTP, but MUST N= OT attempt to use both, either serially or in parallel.=C2=A0 The choice of= transport protocols depends on the client=E2=80=99s security requirements,= though use of HTTPS is RECOMMENDED in most situations.

=C2=A0

If a = query is issued using HTTPS and the server has an invalid certificate, the = server returns a 4xx or 5xx status code, or the HTTPS connection cannot be = established for any reason, the client MUST accept that the WebFinger query= has failed and MUST NOT attempt to reissue the WebFinger request using HTT= P.

=C2=A0

WebFi= nger servers operating on HTTP MAY redirect a client using an appropriate H= TTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger = servers operating on HTTPS MAY redirect a client to another HTTPS URI, but = MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT = follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatic= ally follow all other server redirects.

=C2=A0

I would like to suggest we strike =E2=80=9C, but MUST = NOT attempt to use both, either serially or in parallel=E2=80=9D.=C2=A0 Let= the client decide what to do based on its security requirements.=

=C2=A0

I wou= ld like to suggest we change =E2=80=9CIf a query is issued using HTTPS=E2= =80=9D to =E2=80=9CIf a query is issued using HTTPS because it has strict s= ecurity requirements=E2=80=9D.=C2=A0 Reasoning, again, is that if a client = like a blog server issues a query via HTTPS looking for a user=E2=80=99s av= atar and it fails, why not let it use HTTP?=C2=A0 Actually, we could probab= ly just remove this whole second paragraph.=C2=A0 We could just speak to th= e certificate checking on the security section as it relates to secure clie= nts.

=C2=A0

=C2=A0

Note = that there is a different between a user-agent automatically falling back t= o http and a user issuing a second request after failing. The former involv= es no user-interaction with the second step, the latter requires it. Client= implementations ought to be forbidden from automatic fallbacks. Require in= tentional intervention to issue the secondary request. This is no different= really than the issues involved in automatic redirection of unsafe HTTP me= thods (see [1] section 7.4).=C2=A0

=C2=A0

=C2=A0

So rather than removing that paragraph, try this:

=C2=A0

"= If a query is issued using HTTPS and the server has an invalid certificate,= the server returns a 4xx or 5xx status code, or the HTTPS connection canno= t be established for any reason, the client MUST accept that the WebFinger = query has failed and SHOULD NOT attempt to automatically reissue the WebFin= ger request using HTTP. This failure condition SHOULD be reported to the us= er. Following such a failure, a client MAY attempt to issue a separate subs= equent query over HTTP if an application's security requirements permit= ."

=C2=A0

This would require that any subsequent HTTP fallbacks woul= d occur only after human intervention (either the user reissues the request= or a developer specifically handles the failure and sends a new request). = In either case, fallback requires a conscious choice to accept the fallback= risks.

=C2=A0

- James

=C2=A0

Thus, I propose we go with this (with or w= ithout the middle paragraph):

=C2= =A0

Clients MAY i= ssue a query to the WebFinger server using either HTTPS or HTTP.=C2=A0 The = choice of transport protocols depends on the client=E2=80=99s security requ= irements, though use of HTTPS is RECOMMENDED in most situations.<= /u>

=C2=A0

If= a query is issued using HTTPS because it has strict security requirements = and the server has an invalid certificate, the server returns a 4xx or 5xx = status code, or the HTTPS connection cannot be established for any reason, = the client MUST accept that the WebFinger query has failed and MUST NOT att= empt to reissue the WebFinger request using HTTP.

=C2=A0

WebFi= nger servers operating on HTTP MAY redirect a client using an appropriate H= TTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger = servers operating on HTTPS MAY redirect a client to another HTTPS URI, but = MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT = follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatic= ally follow all other server redirects.

=C2=A0

Paul

=C2=A0


_____= __________________________________________
webfinger mailing list
webfinger@ietf.org=
https://www.ietf.org/mailman/listinfo/webfinger

=C2=A0

=

--14dae9340ad1233e1d04d0f2cac8-- From paulej@packetizer.com Sat Dec 15 23:12:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2621F8653 for ; Sat, 15 Dec 2012 23:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFhhqpJNcG-y for ; Sat, 15 Dec 2012 23:12:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3721F86F5 for ; Sat, 15 Dec 2012 23:12:16 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG7CFwB004257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 02:12:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355641935; bh=xlTfmmGz1NxX2oZr/bh0jzf9R2bpezh3FYyc3frZPmU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=d9dh4JV9LNqgxlDNczI3yQ5BDDW6GC3E+G8YpEfShckY/SbMdmRfggC+X9sQmPjI0 YVm6+pQe7MjgJvWxZgT+D+G3KpVK6snFW9gPOO3ItNbExFn+99TvN/ZkY2LkPe07Hh itDvIdGymD4ljpaAYoqZ//7HiMZluSrXpboaP/+Q= From: "Paul E. Jones" To: "'Evan Prodromou'" , References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> In-Reply-To: <50CCDF02.1080007@status.net> Date: Sun, 16 Dec 2012 02:12:14 -0500 Message-ID: <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01CDDB32.C3FCE130" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gNYyICol4BgQJA= Content-Language: en-us Cc: webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:12:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DD_01CDDB32.C3FCE130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Evan, Maybe I'm confused a bit, but I thought we were saying the same thing, really. What I proposed was the we simplify the text to this: Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. We still seem to be stuck at the "do we require TLS only" or "do we not". If we do not mandate TLS, then I think the above rules are OK. Separate from this, we need to have that bit of text that explains that a client that needs to guarantee that data is not modified while being transmitted from the server to the client MUST only use HTTPS. Perhaps give an example of where a client's security requirements might vary from another client. And we need to explain a bit about how client libraries should support such clients (having a "secure" request being the default). Dare I suggest it again, but we could just explain that there are two types of clients: those that need security and those that do not. In all cases, HTTPS should be queried first. If an HTTPS query fails and the client can accept a non-secure reply, then the client may issue an HTTP query. So, just write the procedures explicitly leaving no room for alternate possible ways of issuing a query. We want predictable results, after all. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Evan Prodromou Sent: Saturday, December 15, 2012 3:35 PM To: webfinger@ietf.org Cc: webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language -1 Well-written implementations are going to fallback to HTTP, to HostMeta + LRDD, and possibly to SWD because that's what's right for the users. Very-well-written implementations will carefully choose which combination of SSL and non-SSL makes sense for their application. We need to stop backseat driving. Balancing the requirements of getting the information that the user has requested, versus various security risks, is something that implementers do. Some will do it wrong. That is how technology works. No one will tell users that they can't have the data they need because technically the spec says MUST NOT right here in section 5.1.2. However, a good cluster of convoluted MUST/MUST NOT language will be enough to keep people from ever implementing the spec in the first place. I suggest the following language: Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. Servers MAY provide a /.well-known/webfinger endpoint over HTTP. Clients SHOULD request Webfinger documents via /.well-known/webfinger over HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger over HTTP. There are a class of attacks on HTTP-only requests listed in the Security Considerations. There are additional potential attacks on mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED that clients and servers use HTTPS only. Those of us who care about micromanaging the client request flow should take the time to build liberally-licensed Open Source libraries for Python, Perl, Java, C++, JavaScript and Ruby. Code is law. -Evan On 12-12-15 02:56 AM, Paul E. Jones wrote: Folks, Here's the current language. I get the feeling more people like this than what we had before. Now, what fine-tuning do we need to do? Or are people still of the mind that we need HTTPS only no matter what? Current language: Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP, but MUST NOT attempt to use both, either serially or in parallel. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. I would like to suggest we strike ", but MUST NOT attempt to use both, either serially or in parallel". Let the client decide what to do based on its security requirements. I would like to suggest we change "If a query is issued using HTTPS" to "If a query is issued using HTTPS because it has strict security requirements". Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user's avatar and it fails, why not let it use HTTP? Actually, we could probably just remove this whole second paragraph. We could just speak to the certificate checking on the security section as it relates to secure clients. Thus, I propose we go with this (with or without the middle paragraph): Clients MAY issue a query to the WebFinger server using either HTTPS or HTTP. The choice of transport protocols depends on the client's security requirements, though use of HTTPS is RECOMMENDED in most situations. If a query is issued using HTTPS because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP. WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects. Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_00DD_01CDDB32.C3FCE130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Evan,

 

Maybe I’m confused = a bit, but I thought we were saying the same thing, really.  What I = proposed was the we simplify the text to this:

 

Clients MAY issue a = query to the WebFinger server using either HTTPS or HTTP.  The = choice of transport protocols depends on the client’s security = requirements, though use of HTTPS is RECOMMENDED in most = situations.

 

WebFinger servers = operating on HTTP MAY redirect a client using an appropriate HTTP status = code to another HTTP or an HTTPS URI.  Likewise, WebFinger servers = operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST = NOT redirect a client to an HTTP URI.  Further, clients MUST NOT = follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD = automatically follow all other server = redirects.

 

 

We still seem to be = stuck at the “do we require TLS only” or “do we = not”.  If we do not mandate TLS, then I think the above rules = are OK.

 

Separate from this, we = need to have that bit of text that explains that a client that needs to = guarantee that data is not modified while being transmitted from the = server to the client MUST only use HTTPS.  Perhaps give an example = of where a client’s security requirements might vary from another = client.  And we need to explain a bit about how client libraries = should support such clients (having a “secure” request being = the default).

 

Dare I suggest it again, = but we could just explain that there are two types of clients: those = that need security and those that do not.  In all cases, HTTPS = should be queried first.  If an HTTPS query fails and the client = can accept a non-secure reply, then the client may issue an HTTP = query.  So, just write the procedures explicitly leaving no room = for alternate possible ways of issuing a query.  We want = predictable results, after all.

 

Paul

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Evan Prodromou
Sent: Saturday, December = 15, 2012 3:35 PM
To: webfinger@ietf.org
Cc: = webfinger@googlegroups.com
Subject: Re: [webfinger] Current = HTTP/HTTPS Language

 

-1

Well-written implementations are going to = fallback to HTTP, to HostMeta + LRDD, and possibly to SWD because that's = what's right for the users. Very-well-written implementations will = carefully choose which combination of SSL and non-SSL makes sense for = their application.

We need to stop backseat driving. Balancing = the requirements of getting the information that the user has requested, = versus various security risks, is something that implementers = do.

Some will do it wrong. That is how technology = works.

No one will tell users that they can't have the data they = need because technically the spec says MUST NOT right here in section = 5.1.2.  However, a good cluster of convoluted MUST/MUST NOT = language will be enough to keep people from ever implementing the spec = in the first place.

I suggest the following = language:

Servers SHOULD provide a = /.well-known/webfinger endpoint over HTTPS. Servers MAY provide a = /.well-known/webfinger endpoint over HTTP.

Clients SHOULD request = Webfinger documents via /.well-known/webfinger over HTTPS. Clients MAY = request Webfinger documents via /.well-known/webfinger over = HTTP.

There are a class of attacks on HTTP-only requests listed = in the Security Considerations. There are additional potential attacks = on mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED that = clients and servers use HTTPS only.

Those of us who care about micromanaging the client = request flow should take the time to build liberally-licensed Open = Source libraries for Python, Perl, Java, C++, JavaScript and Ruby. Code = is law.

-Evan

On 12-12-15 02:56 AM, Paul E. Jones = wrote:

Folks,

 

Here’s = the current language.  I get the feeling more people like this than = what we had before.  Now, what fine-tuning do we need to do?  = Or are people still of the mind that we need HTTPS only no matter = what?

 

Current language:

 

Clients MAY issue a query to the WebFinger server = using either HTTPS or HTTP, but MUST NOT attempt to use both, either = serially or in parallel.  The choice of transport protocols depends = on the client’s security requirements, though use of HTTPS is = RECOMMENDED in most situations.

 

If a query = is issued using HTTPS and the server has an invalid certificate, the = server returns a 4xx or 5xx status code, or the HTTPS connection cannot = be established for any reason, the client MUST accept that the WebFinger = query has failed and MUST NOT attempt to reissue the WebFinger request = using HTTP.

 

WebFinger servers operating on HTTP MAY redirect a = client using an appropriate HTTP status code to another HTTP or an HTTPS = URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a = client to another HTTPS URI, but MUST NOT redirect a client to an HTTP = URI.  Further, clients MUST NOT follow a redirection from an HTTPS = URI to an HTTP URI, but SHOULD automatically follow all other server = redirects.

 

I would like = to suggest we strike “, but MUST NOT attempt to use both, either = serially or in parallel”.  Let the client decide what to do = based on its security requirements.

 

I would like = to suggest we change “If a query is issued using HTTPS” to = “If a query is issued using HTTPS because it has strict security = requirements”.  Reasoning, again, is that if a client like a = blog server issues a query via HTTPS looking for a user’s avatar = and it fails, why not let it use HTTP?  Actually, we could probably = just remove this whole second paragraph.  We could just speak to = the certificate checking on the security section as it relates to secure = clients.

 

Thus, I propose we go with this (with or without the = middle paragraph):

 

Clients MAY issue a query to the WebFinger server = using either HTTPS or HTTP.  The choice of transport protocols = depends on the client’s security requirements, though use of HTTPS = is RECOMMENDED in most situations.

 

If a = query is issued using HTTPS because it has strict security requirements = and the server has an invalid certificate, the server returns a 4xx or = 5xx status code, or the HTTPS connection cannot be established for any = reason, the client MUST accept that the WebFinger query has failed and = MUST NOT attempt to reissue the WebFinger request using = HTTP.

 

WebFinger servers operating on HTTP MAY redirect a = client using an appropriate HTTP status code to another HTTP or an HTTPS = URI.  Likewise, WebFinger servers operating on HTTPS MAY redirect a = client to another HTTPS URI, but MUST NOT redirect a client to an HTTP = URI.  Further, clients MUST NOT follow a redirection from an HTTPS = URI to an HTTP URI, but SHOULD automatically follow all other server = redirects.

 

Paul

 




__________________=
_____________________________
webfinger mailing =
list
webfinger@ietf.org
https://www.ietf=
.org/mailman/listinfo/webfinger

 

------=_NextPart_000_00DD_01CDDB32.C3FCE130-- From bradfitz@google.com Sat Dec 15 23:16:55 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F8D21F8654 for ; Sat, 15 Dec 2012 23:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhMMP8nqaWIH for ; Sat, 15 Dec 2012 23:16:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5B21F8512 for ; Sat, 15 Dec 2012 23:16:53 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2300350wey.31 for ; Sat, 15 Dec 2012 23:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iBX5vkbjk4wDCQiF9dLVV3ZLvPxw5An7hUjvIhPDMm0=; b=WOAlNlnu9vLZs/XmuIvRVuiFBENXhXNtJzR5Xm5mwbdBdv4se6/d3U+Iu3D8Zg/K6C X+g4n5vS/H0Pj2ctrP8vFnJvnU8uwjdq5Xv08xWvtliy26xbEXqzJqX+wE/xf+65JTSp /EJveM3DQAe/JA9rWVxcBONIYrvZyG77lMZHklzfWoTd+oDLKksxbboQrXMfDVxYtedn y22jxEro3DjRAMbze767+lSLL3PIq2xRufJazsbUKIqkAfb2qNp5qMR0zbhyP+fxD42f vxYD/iIhjZ0M70ckm3mkDCuf2RsqxiLBfbN9pwgj/iRBJvXAcKD69cpt0PmJGsyakCQ8 ThTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=iBX5vkbjk4wDCQiF9dLVV3ZLvPxw5An7hUjvIhPDMm0=; b=XQRzcKb9a3aRkCmxwfHpDKLgcPTfa8ykbk2mGfy4RG4i9BwkFTyr6Tpfk16bNDRmTX DlZ0/6FbSUzCjt6ZgFMGVMlpTUjB4z4SmlBgEoSrHeGUxg3JS23F4rB3OifS5ScnrcpT AGPP/ohqKCo2JWvwPkTw7ttHTPAV+WCjIeioLQOugD2Hc6vc86aCQj7Oobd2amzaU48k VzulbbL7U08HU2qL7HJo9hyFUo5v/KEEb/Nuss5msAZuG7keHoraQGvdoSrkavyarVoi x9YBJ27gMA1wZ1SRr0BaV75dxn6COQDANIb8M0mjhL5ZxySxXGEzCfVgSRb3L7tVM9Xn B7aQ== MIME-Version: 1.0 Received: by 10.180.107.130 with SMTP id hc2mr9876065wib.12.1355642213147; Sat, 15 Dec 2012 23:16:53 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sat, 15 Dec 2012 23:16:53 -0800 (PST) In-Reply-To: <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> Date: Sat, 15 Dec 2012 23:16:53 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3baa6f8ea46f04d0f30cfa X-Gm-Message-State: ALoCoQmvWlJmXtOJZYC1fWPdX8GGEQnDRPIjOXhaKXluqAXg38UGJ5+CvVVRvZC2u53DhqtApxmWHxB8JFpWP+bYEkqLeBFixVNQ0qN1lfpfwRq6cKEo7T8weCEVVlleaSpObb3755m+GdSTXafnb/Evprn9jBDW+tEkqQIdw3CnwuvEMpYtKAnr4ZJSZ0cZRDQZc/bQvGQj Cc: webfinger@ietf.org, Evan Prodromou Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:16:55 -0000 --e89a8f3baa6f8ea46f04d0f30cfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 11:12 PM, Paul E. Jones wrot= e: > Evan,**** > > ** ** > > Maybe I=E2=80=99m confused a bit, but I thought we were saying the same t= hing, > really. What I proposed was the we simplify the text to this:**** > > ** ** > > Clients MAY issue a query to the WebFinger server using either HTTPS or > HTTP. The choice of transport protocols depends on the client=E2=80=99s = security > requirements, though use of HTTPS is RECOMMENDED in most situations.**** > > ** ** > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise, > WebFinger servers operating on HTTPS MAY redirect a client to another HTT= PS > URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUS= T > NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD > automatically follow all other server redirects.**** > > ** ** > > ** ** > > We still seem to be stuck at the =E2=80=9Cdo we require TLS only=E2=80=9D= or =E2=80=9Cdo we not=E2=80=9D. > If we do not mandate TLS, then I think the above rules are OK.**** > > ** ** > > Separate from this, we need to have that bit of text that explains that a > client that needs to guarantee that data is not modified while being > transmitted from the server to the client MUST only use HTTPS. Perhaps > give an example of where a client=E2=80=99s security requirements might v= ary from > another client. And we need to explain a bit about how client libraries > should support such clients (having a =E2=80=9Csecure=E2=80=9D request be= ing the default). > **** > > ** ** > > Dare I suggest it again, but we could just explain that there are two > types of clients: those that need security and those that do not. In all > cases, HTTPS should be queried first. If an HTTPS query fails and the > client can accept a non-secure reply, then the client may issue an HTTP > query. So, just write the procedures explicitly leaving no room for > alternate possible ways of issuing a query. We want predictable results, > after all.**** > > ** > If HTTPS queries are first and HTTP fallback happens if and only if the user has opted-in to an insecure mode, I could live with that. It's not my ideal, but I recognize that a lot of people want to use HTTP. --e89a8f3baa6f8ea46f04d0f30cfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Sat, Dec 15, 2012 at 11:12 PM, Paul E.= Jones <paulej@packetizer.com> wrote:

Evan,

=C2=A0

Maybe I=E2=80= =99m confused a bit, but I thought we were saying the same thing, really.= =C2=A0 What I proposed was the we simplify the text to this:<= /span>

=C2=A0

<= div class=3D"im">

Clien= ts MAY issue a query to the WebFinger server using either HTTPS or HTTP.=C2= =A0 The choice of transport protocols depends on the client=E2=80=99s secur= ity requirements, though use of HTTPS is RECOMMENDED in most situations.=

=C2=A0

WebFing= er servers operating on HTTP MAY redirect a client using an appropriate HTT= P status code to another HTTP or an HTTPS URI.=C2=A0 Likewise, WebFinger se= rvers operating on HTTPS MAY redirect a client to another HTTPS URI, but MU= ST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST NOT fo= llow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatical= ly follow all other server redirects.

=C2=A0

=C2=A0

We still seem to be stuck at the =E2=80=9Cdo = we require TLS only=E2=80=9D or =E2=80=9Cdo we not=E2=80=9D.=C2=A0 If we do= not mandate TLS, then I think the above rules are OK.=

=C2=A0

Separate from this, we= need to have that bit of text that explains that a client that needs to gu= arantee that data is not modified while being transmitted from the server t= o the client MUST only use HTTPS.=C2=A0 Perhaps give an example of where a = client=E2=80=99s security requirements might vary from another client. =C2= =A0And we need to explain a bit about how client libraries should support s= uch clients (having a =E2=80=9Csecure=E2=80=9D request being the default).<= u>

=C2=A0

Dare I sugges= t it again, but we could just explain that there are two types of clients: = those that need security and those that do not.=C2=A0 In all cases, HTTPS s= hould be queried first.=C2=A0 If an HTTPS query fails and the client can ac= cept a non-secure reply, then the client may issue an HTTP query.=C2=A0 So,= just write the procedures explicitly leaving no room for alternate possibl= e ways of issuing a query.=C2=A0 We want predictable results, after all.=


If HTTPS queries are first a= nd HTTP fallback happens if and only if the user has opted-in to an insecur= e mode, I could live with that. =C2=A0It's not my ideal, but I recogniz= e that a lot of people want to use HTTP.


--e89a8f3baa6f8ea46f04d0f30cfa-- From paulej@packetizer.com Sat Dec 15 23:44:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9221F863C for ; Sat, 15 Dec 2012 23:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM8Pg6YEvlqb for ; Sat, 15 Dec 2012 23:44:42 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF9021F8651 for ; Sat, 15 Dec 2012 23:44:42 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG7idAA005535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 02:44:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355643880; bh=9YVUSHN4WkWJIcO80YcLmvIPBCnQgEcf5ktorz3faNA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=toU8mzxvsEDsf8hisiboX+hjrVsz1FL7LZVgF3inhrJvwc2hZELrYpn3F5fvmoylA fZVexe0Bfjhm9inrRUbkLBeCNIo2CwP3rR0qI8yN0AXGsu0zd1Fhh+zy6UtKtRb9xO gq48yTRgcXvQu58pYmgbxYlaiZo4juRRNvTuK3Bk= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 02:44:38 -0500 Message-ID: <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01CDDB37.4B35E580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gJf97KaA2wuLZcB+QAw/wFuEMI5l1GT86A= Content-Language: en-us Cc: webfinger@ietf.org, 'Nick Jennings' , webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:44:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0106_01CDDB37.4B35E580 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 I really thought I understood this. I think I still do, but = I=E2=80=99ll admit that I might be missing something. =20 Let me explain how I expected the WF client to work. First, I would = never expect the end user ever selects a transport on a case-by-case = basis. Rather, the WF client would be integrated in software like my = email client, my blog (for fetching visitor=E2=80=99s avatars), or = perhaps on my web forums where users log into the system. =20 In my email client, I would expect a configuration option where WF = queries are secure or they are not. By default, I=E2=80=99d expect = those to not be secure, since most users that would use WF from an email = client don=E2=80=99t care. If I get the right picture for you, good. If = not, no big deal. Some users would care, though: they would not want to = fetch a vcard and get the wrong telephone number. So, the email client = would operate in either =E2=80=9Csecure=E2=80=9D or = =E2=80=9Cnon-secure=E2=80=9D mode. =20 Behavior for =E2=80=9Csecure mode=E2=80=9D: =C2=B7 TLS query =C2=B7 Fail for any reason? Stop. =20 Behavior for =E2=80=9Cnon-secure mode=E2=80=9D: =C2=B7 TLS query =C2=B7 Failure? Try HTTP. =20 My blog where you might post comments and I want to grab your avatar = might operate in =E2=80=9Cnon-secure=E2=80=9D mode. Security is not so = important. This would be provisioned by the blog admin. =20 The web forums where users log in would use =E2=80=9Csecure = mode=E2=80=9D. That client would not want to be directed to the wrong = IdP. =20 Now, some would argue that =E2=80=9Cnon-secure=E2=80=9D mode should = start with HTTP and the server could re-direct the client to HTTPS or = just reply. That=E2=80=99s reasonable, IMO. Either way, the = =E2=80=9Cnon-secure=E2=80=9D mode is susceptible to MITM attacks, and = leading with HTTP could result in a fast response. =20 If we allow the non-secure mode, then it=E2=80=99s truly non-secure. = And, it could introduce some serious problems if users blindly trust it. = Let=E2=80=99s say I get an email from my bank. My email client = (operating in non-secure mode) automatically grabs the contact info for = customerservice@mybank.com. Somebody (not my bank) actually served the = reply (blocking port 443 and providing a bogus answer on 80). I see = their phone number and call, getting some very professional-sounding = person who collects information from me and then cleans out my bank = account. =20 Without mandating HTTPS, WF might never be adopted for anything except = casual stuff. My bank would never support it, yet they would still be = subject to a MITM attack! That=E2=80=99s really scary. So, there is a = lot of value in the HTTPS only approach. =20 However, what I don=E2=80=99t understand in your proposal is how you = would prevent this MITM attack. If it does, I=E2=80=99m missing that = and perhaps a pretty picture is needed. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Sunday, December 16, 2012 1:53 AM To: Paul E. Jones Cc: Nick Jennings; webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language =20 On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones = wrote: =20 The secure links idea (which I don=E2=80=99t particularly like) helps = the server decide what to return. At least as I understand it.=20 =20 No, you misunderstand it. =20 Maybe you don't like it because you don't understand it. I'll try to = rephrase: =20 Since there is nothing secure about a link in and of itself, I = don=E2=80=99t see any reason to classify link types. =20 The point was to encode classification (a rel type's "requires-HTTPS" = property) into the rel type itself, so clients could be free of any = configuration (nobody has to say "I want secure" or "sure, HTTP works I = guess?") and clients can then safely failover from HTTPS to HTTP, since = the *client* (again! the client, NOT the server) does the filtering. =20 But, a server is certainly free to return whatever it likes over HTTP, = and that might be different than what it returns over HTTP. But, why = bother?=20 =20 I think your "why bother?" might be about a line of confusion that's = unrelated to my bother: I'm bothered by webfinger being vulnerable to = MITM, and users having to opt-in to security. =20 If we ensure proper client behavior, it=E2=80=99s not an issue. And by = =E2=80=9Cproper=E2=80=9D, that means ensuring that clients that = absolutely need to ensure that data is not modified in flight must only = use HTTPS. Any client that does not have that restriction could do what = it wants, but with some reasonable guidance =E2=80=A6 that we=E2=80=99re = trying to hammer out. =20 I'm fine with people using HTTP to fetch certain links. =20 What I am NOT fine with is people telling their webfinger client, = "Please fetch me the https://openid.net/connect/server link for = foo@example.com. Oh, wait, what? I have to pick HTTPS or HTTP now? = Oh, whatever, HTTP." And then it doesn't matter what your server = returned, because the user's already been MITMed. =20 HTTPS-only avoids this complication, but if we're going to permit HTTP, = I was at least hoping we could make secure uses of WebFinger have a much = higher likelihood of being secure but classifying rel types (NOT = classifying links) and teaching clients that some rel types are = HTTPS-only and the rest are whatever (since a lot of people don't seem = to care about the security of their avatar or name). =20 I'm willing to draw pictures or write such a client in the language of = your choice to demonstrate this, if it's still unclear. ------=_NextPart_000_0106_01CDDB37.4B35E580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

I really thought I understood this.=C2=A0 I think I still do, but = I=E2=80=99ll admit that I might be missing = something.

 

Let me explain how I expected the WF client to work.=C2=A0 First, I = would never expect the end user ever selects a transport on a = case-by-case basis.=C2=A0 Rather, the WF client would be integrated in = software like my email client, my blog (for fetching visitor=E2=80=99s = avatars), or perhaps on my web forums where users log into the = system.

 

In my email client, I would expect a configuration option where WF = queries are secure or they are not.=C2=A0 By default, I=E2=80=99d expect = those to not be secure, since most users that would use WF from an email = client don=E2=80=99t care.=C2=A0 If I get the right picture for you, = good. If not, no big deal.=C2=A0 Some users would care, though: they = would not want to fetch a vcard and get the wrong telephone = number.=C2=A0 So, the email client would operate in either = =E2=80=9Csecure=E2=80=9D or =E2=80=9Cnon-secure=E2=80=9D = mode.

 

Behavior for =E2=80=9Csecure mode=E2=80=9D:

=C2=B7         = TLS query

=C2=B7         = Fail for any reason? Stop.

 

Behavior for =E2=80=9Cnon-secure = mode=E2=80=9D:

=C2=B7         = TLS query

=C2=B7         = Failure?=C2=A0 Try HTTP.

 

My blog where you might post comments and I want to grab your avatar = might operate in =E2=80=9Cnon-secure=E2=80=9D mode.=C2=A0 Security is = not so important.=C2=A0 This would be provisioned by the blog = admin.

 

The web forums where users log in would use =E2=80=9Csecure = mode=E2=80=9D.=C2=A0 That client would not want to be directed to the = wrong IdP.

 

Now, some would argue that =E2=80=9Cnon-secure=E2=80=9D mode should = start with HTTP and the server could re-direct the client to HTTPS or = just reply.=C2=A0 That=E2=80=99s reasonable, IMO.=C2=A0 Either way, the = =E2=80=9Cnon-secure=E2=80=9D mode is susceptible to MITM attacks, and = leading with HTTP could result in a fast = response.

 

If we allow the non-secure mode, then it=E2=80=99s truly = non-secure.=C2=A0 And, it could introduce some serious problems if users = blindly trust it. =C2=A0Let=E2=80=99s say I get an email from my = bank.=C2=A0 My email client (operating in non-secure mode) automatically = grabs the contact info for customerservice@mybank.com.=C2=A0 Somebody = (not my bank) actually served the reply (blocking port 443 and providing = a bogus answer on 80).=C2=A0 I see their phone number and call, getting = some very professional-sounding person who collects information from me = and then cleans out my bank account.

 

Without mandating HTTPS, WF might never be adopted for anything = except casual stuff.=C2=A0 My bank would never support it, yet they = would still be subject to a MITM attack!=C2=A0 That=E2=80=99s really = scary.=C2=A0 So, there is a lot of value in the HTTPS only = approach.

 

However, what I don=E2=80=99t understand in your proposal is how you = would prevent this MITM attack.=C2=A0 If it does, I=E2=80=99m missing = that and perhaps a pretty picture is needed.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Sunday, = December 16, 2012 1:53 AM
To: Paul E. Jones
Cc: Nick = Jennings; webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Current HTTP/HTTPS = Language

 

On Sat, Dec = 15, 2012 at 10:32 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

 <= /o:p>

The secure links idea (which I don=E2=80=99t particularly like) helps = the server decide what to return.  At least as I understand = it. 

 

No, you = misunderstand it.

 

Maybe you = don't like it because you don't understand it.  I'll try to = rephrase:

 

Since there is nothing secure about a link in and of itself, I = don=E2=80=99t see any reason to classify link = types.

 

The point = was to encode classification (a rel type's = "requires-HTTPS" property) into the rel type itself, so = clients could be free of any configuration (nobody has to say "I = want secure" or "sure, HTTP works I guess?") and clients = can then safely failover from HTTPS to HTTP, since the *client* (again! = the client, NOT the server) does the = filtering.

 

  But, a server is certainly free to return whatever it likes = over HTTP, and that might be different than what it returns over = HTTP.  But, why = bother? 

 

I think your = "why bother?" might be about a line of confusion that's = unrelated to my bother:  I'm bothered by webfinger being vulnerable = to MITM, and users having to opt-in to = security.

 

If we ensure proper client behavior, it=E2=80=99s not an issue. And = by =E2=80=9Cproper=E2=80=9D, that means ensuring that clients that = absolutely need to ensure that data is not modified in flight must only = use HTTPS.  Any client that does not have that restriction could do = what it wants, but with some reasonable guidance =E2=80=A6 that = we=E2=80=99re trying to hammer = out.

 

I'm fine = with people using HTTP to fetch certain = links.

 

What I am = NOT fine with is people telling their webfinger client, "Please = fetch me the https://openid.net/connect/ser= ver link for foo@example.com. =   Oh, wait, what?  I have to pick HTTPS or HTTP now?  Oh, = whatever, HTTP."  And then it doesn't matter what your server = returned, because the user's already been = MITMed.

 

HTTPS-only = avoids this complication, but if we're going to permit HTTP, I was at = least hoping we could make secure uses of WebFinger have a much = higher likelihood of being secure but classifying rel types = (NOT classifying links) and teaching clients that some rel types are = HTTPS-only and the rest are whatever (since a lot of people don't seem = to care about the security of their avatar or = name).

 

I'm willing = to draw pictures or write such a client in the language of your choice = to demonstrate this, if it's still = unclear.

------=_NextPart_000_0106_01CDDB37.4B35E580-- From paulej@packetizer.com Sat Dec 15 23:47:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8521F8645 for ; Sat, 15 Dec 2012 23:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVL7eYgbMOZU for ; Sat, 15 Dec 2012 23:47:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ABACD21F863C for ; Sat, 15 Dec 2012 23:47:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG7l8ko005673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 02:47:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355644028; bh=tfolKvdE1ozKuqATAPTGnIT+GEnoNFB5u5HQzWLdYyM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=HcPa4Yb5rzXfIbYvBLh7x1NtrKAsSJTs4QF0L3n78JFs16YPYABKiLmApNJS/EhE6 xoMmy7krq4vcp83DcobnAxBPDrvy0vDqZfmFHqq1TlNtbDIp7W4fhidqlOQ69B+19H 3QNY/8Lu7D26mXBGrHJ4ntzNW0p5I0ZWhIPkoETM= From: "Paul E. Jones" To: "'James M Snell'" References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <00cf01cddb59$af1d7cd0$0d587670$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 02:47:07 -0500 Message-ID: <012701cddb61$8c51bc90$a4f535b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01CDDB37.A37C77E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gHY6+ZoAeYMBqwBkpvmBpdwp7cQ Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:47:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0128_01CDDB37.A37C77E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, =20 This happens even today for various web services and could happen with = just HTTPS as the transport, where server A points to B who points to C = who points to A. Clients always have to watch for loops. I always put = loop detection logic into client code I write. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Sunday, December 16, 2012 1:58 AM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language =20 =20 =20 On Sat, Dec 15, 2012 at 10:50 PM, Paul E. Jones = wrote: James, =20 But the client should automatically switch to using HTTP if security is = not an issue. Again, if I=E2=80=99m running a blog and I really = don=E2=80=99t care if the avatar link I grab for you gets = =E2=80=9Chacked=E2=80=9D in flight, I might issue this query: wf.query("acct:you@example.com ", = WF_NON_SECURE); =20 This would query using HTTPS, but if it failed, try HTTP automatically. =20 Question... if fallback is automatic.. what happens in the following = situation: =20 1. Client sends a request to HTTPS... server responds with a 5xx... 2. Client sends a request to HTTP automatically.. server responds with a = 3xx redirect to HTTPS, because the server says HTTPS is required. 3. Client follows the redirect and sends a request to HTTPS... server = responds with a 5xx... rinse, repeat =20 Second question, if security really isn't an issue, why would I issue = the request over HTTPS in the first place? Why wouldn't I just try HTTP = first and hope for the best? =20 - James ------=_NextPart_000_0128_01CDDB37.A37C77E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

James,

 

This happens even today for various web services and could happen = with just HTTPS as the transport, where server A points to B who points = to C who points to A.=C2=A0 Clients always have to watch for = loops.=C2=A0 I always put loop detection logic into client code I = write.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Sunday, = December 16, 2012 1:58 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Current HTTP/HTTPS = Language

 

 

 

On Sat, Dec 15, 2012 at 10:50 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

James,

 

But the client should automatically switch to using HTTP if security = is not an issue.  Again, if I=E2=80=99m running a blog and I really = don=E2=80=99t care if the avatar link I grab for you gets = =E2=80=9Chacked=E2=80=9D in flight, I might issue this = query:

   wf.query("acct:you@example.com", = WF_NON_SECURE);

  

This would query using HTTPS, but if it failed, try HTTP = automatically.

 

Question... if fallback is automatic.. what happens in = the following situation:

 

1. Client sends a request to HTTPS... server responds = with a 5xx...

2. Client = sends a request to HTTP automatically.. server responds with a 3xx = redirect to HTTPS, because the server says HTTPS is = required.

3. Client = follows the redirect and sends a request to HTTPS... server responds = with a 5xx... rinse, repeat

 

Second question, if security really isn't an issue, = why would I issue the request over HTTPS in the first place? Why = wouldn't I just try HTTP first and hope for the = best?

 

- James

------=_NextPart_000_0128_01CDDB37.A37C77E0-- From paulej@packetizer.com Sat Dec 15 23:50:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9EE21F863C for ; Sat, 15 Dec 2012 23:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wrmPZEOs8sS for ; Sat, 15 Dec 2012 23:50:45 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A07FF21F84E8 for ; Sat, 15 Dec 2012 23:50:45 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG7ohSH005823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 02:50:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355644244; bh=tEx5oaneEIqaMxZPc55b/H3f/JZR7oPrETaGON/Lc3U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=U/dgLhwdEZmowMNCNRUeV1DNUKUYXa9f5wQ0V/jVsHlotsLaGKpOrtYgLd3vflL3Q 5jR2JjfbK55flqlO6ayAcFnHgE143l+gf1O0m4QFh/OYB3Fy65raCtsk7P85k2scob IrV6bE5YN5PDnIGFTIDCOR3HvKFUMrh4y7v+gEQs= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 02:50:42 -0500 Message-ID: <013401cddb62$0ce8e540$26baafc0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01CDDB38.24135270" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gNYyICoAaOMA58BNFmz9Jdpr5yg Content-Language: en-us Cc: webfinger@ietf.org, 'Evan Prodromou' Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:50:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0135_01CDDB38.24135270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Braid, =20 I=E2=80=99d expect that, but do note (as I mentioned in my last message) = that a hacker can hack that, too. They block port 443 and then rob you = blind through port 80. Non-secure really means non-secure, unless the = user is explicitly told =E2=80=9Cthis data is protected with = HTTPS=E2=80=9D =E2=80=93 like a lock icon visible in my email client so = I don=E2=80=99t call the scammers who want to rob my bank account. =20 Paul Brad said=E2=80=A6 =20 If HTTPS queries are first and HTTP fallback happens if and only if the = user has opted-in to an insecure mode, I could live with that. It's not = my ideal, but I recognize that a lot of people want to use HTTP. =20 =20 ------=_NextPart_000_0135_01CDDB38.24135270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Braid,

 

I=E2=80=99d expect that, but do note (as I mentioned in my last = message) that a hacker can hack that, too.=C2=A0 They block port 443 and = then rob you blind through port 80.=C2=A0 Non-secure really means = non-secure, unless the user is explicitly told =E2=80=9Cthis data is = protected with HTTPS=E2=80=9D =E2=80=93 like a lock icon visible in my = email client so I don=E2=80=99t call the scammers who want to rob my = bank account.

 

Paul

Brad = said=E2=80=A6

 

If HTTPS = queries are first and HTTP fallback happens if and only if the user has = opted-in to an insecure mode, I could live with that.  It's not my = ideal, but I recognize that a lot of people want to use = HTTP.

 

 

------=_NextPart_000_0135_01CDDB38.24135270-- From paulej@packetizer.com Sat Dec 15 23:53:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481F121F8468 for ; Sat, 15 Dec 2012 23:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N01Fk9gv3-Ck for ; Sat, 15 Dec 2012 23:53:17 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 760D021F87C1 for ; Sat, 15 Dec 2012 23:53:17 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBG7rFIH005950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 02:53:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355644396; bh=6iqAuHRLCPDGxM0cJD6Wznq1PgNtoId1tDqhhZow+nA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=M3CYUnqnUrSAaobePnzuVLwCZu5Q48GaRhBQ/XijJ9R5tGnaYVFTg8h5LvwsSeWBP 41a/7P3zTUTc3Ret8LsIgeQRoSpRJ6554gaEiiZT50efPYmlLOfZfTYlbxH6cbBndp X7TTKZkc1BjRzwHLPZndzZb1Hzc+x9Bv9Tr/w9EI= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" , References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 02:53:14 -0500 Message-ID: <015301cddb62$676d32a0$364797e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0154_01CDDB38.7E97C6E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gNYyICoAaOMA58BNFmz9AFQ2J7Ml18p/ZA= Content-Language: en-us Cc: webfinger@ietf.org, 'Evan Prodromou' Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 07:53:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0154_01CDDB38.7E97C6E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Damn typos=E2=80=A6 don=E2=80=99t be offended. I don=E2=80=99t know if = you wear braids or not ;-) =20 =20 From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Sunday, December 16, 2012 2:51 AM To: 'Brad Fitzpatrick'; 'webfinger@googlegroups.com' Cc: 'webfinger@ietf.org'; 'Evan Prodromou' Subject: RE: [webfinger] Current HTTP/HTTPS Language =20 Braid, =20 I=E2=80=99d expect that, but do note (as I mentioned in my last message) = that a hacker can hack that, too. They block port 443 and then rob you = blind through port 80. Non-secure really means non-secure, unless the = user is explicitly told =E2=80=9Cthis data is protected with = HTTPS=E2=80=9D =E2=80=93 like a lock icon visible in my email client so = I don=E2=80=99t call the scammers who want to rob my bank account. =20 Paul Brad said=E2=80=A6 =20 If HTTPS queries are first and HTTP fallback happens if and only if the = user has opted-in to an insecure mode, I could live with that. It's not = my ideal, but I recognize that a lot of people want to use HTTP. =20 =20 ------=_NextPart_000_0154_01CDDB38.7E97C6E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Damn typos=E2=80=A6=C2=A0 don=E2=80=99t be offended.=C2=A0 I = don=E2=80=99t know if you wear braids or not ;-)

 

 

From:= = Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Sunday, = December 16, 2012 2:51 AM
To: 'Brad Fitzpatrick'; = 'webfinger@googlegroups.com'
Cc: 'webfinger@ietf.org'; 'Evan = Prodromou'
Subject: RE: [webfinger] Current HTTP/HTTPS = Language

 

Braid,

 

I=E2=80=99d expect that, but do note (as I mentioned in my last = message) that a hacker can hack that, too.  They block port 443 and = then rob you blind through port 80.  Non-secure really means = non-secure, unless the user is explicitly told =E2=80=9Cthis data is = protected with HTTPS=E2=80=9D =E2=80=93 like a lock icon visible in my = email client so I don=E2=80=99t call the scammers who want to rob my = bank account.

 

Paul

Brad = said=E2=80=A6

 

If HTTPS = queries are first and HTTP fallback happens if and only if the user has = opted-in to an insecure mode, I could live with that.  It's not my = ideal, but I recognize that a lot of people want to use = HTTP.

 

 

------=_NextPart_000_0154_01CDDB38.7E97C6E0-- From perpetual-tripper@wwelves.org Sun Dec 16 02:51:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2DE21F858A for ; Sun, 16 Dec 2012 02:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkoIhHL10WCN for ; Sun, 16 Dec 2012 02:51:08 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 86E8C21F857D for ; Sun, 16 Dec 2012 02:51:08 -0800 (PST) X-Originating-IP: 217.70.178.151 Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B70A4A808C; Sun, 16 Dec 2012 11:50:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Y2wAish04SuY; Sun, 16 Dec 2012 11:50:52 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5A7E9A807C; Sun, 16 Dec 2012 11:50:52 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Brad Fitzpatrick In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> Date: Sun, 16 Dec 2012 10:50:50 +0000 Message-Id: <1355654929-sup-2982@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , Nick Jennings , webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 10:51:09 -0000 Excerpts from Brad Fitzpatrick's message of 2012-12-16 06:52:33 +0000: [snip] > I'm willing to draw pictures or write such a client in the language of = your > choice to demonstrate this, if it's still unclear. +1 for drawing pictures! +1 for writing a .js implementation of client which one can use both in b= rowser and in node.js From perpetual-tripper@wwelves.org Sun Dec 16 03:13:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80C21F84CE for ; Sun, 16 Dec 2012 03:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdjmpZArgOAu for ; Sun, 16 Dec 2012 03:13:58 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21621F84F3 for ; Sun, 16 Dec 2012 03:13:56 -0800 (PST) X-Originating-IP: 217.70.178.148 Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 80C37A8077; Sun, 16 Dec 2012 12:13:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 1NXiNqxt1v9l; Sun, 16 Dec 2012 12:13:44 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id F2571A8086; Sun, 16 Dec 2012 12:13:43 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Paul E. Jones In-reply-to: <00c201cddb58$9f1b8bc0$dd52a340$@packetizer.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> <00c201cddb58$9f1b8bc0$dd52a340$@packetizer.com> Date: Sun, 16 Dec 2012 11:13:43 +0000 Message-Id: <1355656119-sup-119@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 11:13:59 -0000 Excerpts from Paul E. Jones's message of 2012-12-16 06:43:12 +0000: > Dick, >=20 > > As noted previously, the cost of certs is pretty much zero, so HTTPS = as > > part of a standard hosting package is really a product management > > decision followed by a deployment task (i.e., it is not a major > > financial decision by hosting companies. Do we want to be brave and s= ay > > HTTPS only and help drive a safer, more secure web? >=20 > But they're not. Few (maybe only StartCom) provides free certificates = and > those (last I checked) were limited to a single domain for a single yea= r. >=20 > So, users are stuck with these options: > 1) Buying a certificate that costs more than the domain itself > 2) Getting a free one that has to be updated annually > 3) Paying for a wildcard certificate, but those are fairly expensive an= d > only cover *.example.com, not *.foo.example.com. To cover the sub-doma= in, > one needs another certificate or wildcard certificate >=20 > And then there is administrative effort. Personally, I hate dealing wi= th > certificates. For that reason, I would LOVE to be able to completely > automate use of certificates by generating them myself and putting them= in > DNS using procedures defined in DANE. I wish the world would go forwar= d > with DNSSEC! >=20 > As it is, they're expensive in one way or another, a headache, etc. Th= ey're > vital for business, but far less vital to most people who might be runn= ing a > blog or whatever. >=20 > All that said, I'm still OK with mandating TLS. Would casual bloggers = even > use an identifier like joe@myblog.example.com? Or would they use a gma= il > identifier or other identifier from a domain that likely supports WF > securely? But, I assume serious bloggers would not be turned off by a > certificate. I have no idea. if someone runs a blog on personal domain and authenticates to it with us= ername/password pair, this person already better use HTTPS! just in such = case even self-signed can keep us safe... From evan@status.net Sun Dec 16 08:35:07 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336C321F87DD for ; Sun, 16 Dec 2012 08:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAJghJ5jpfgp for ; Sun, 16 Dec 2012 08:35:06 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25B21F87D2 for ; Sun, 16 Dec 2012 08:35:06 -0800 (PST) Received: from [192.168.0.109] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 1F4358D4247; Sun, 16 Dec 2012 16:47:44 +0000 (UTC) Message-ID: <50CDF835.2090102@status.net> Date: Sun, 16 Dec 2012 11:35:01 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@googlegroups.com References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CCDF02.1080007@status.net> <00dc01cddb5c$acd189a0$06749ce0$@packetizer.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020809050406040806000401" Cc: webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 16:35:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020809050406040806000401 Content-Type: multipart/alternative; boundary="------------080800040104040402080208" This is a multi-part message in MIME format. --------------080800040104040402080208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable +1 I like the wording and the spirit. -Evan On 12-12-16 02:16 AM, Brad Fitzpatrick wrote: > > > On Sat, Dec 15, 2012 at 11:12 PM, Paul E. Jones > wrote: > > Evan, > > Maybe I=E2=80=99m confused a bit, but I thought we were saying the = same > thing, really. What I proposed was the we simplify the text to thi= s: > > Clients MAY issue a query to the WebFinger server using either > HTTPS or HTTP. The choice of transport protocols depends on the > client=E2=80=99s security requirements, though use of HTTPS is RECO= MMENDED > in most situations. > > WebFinger servers operating on HTTP MAY redirect a client using an > appropriate HTTP status code to another HTTP or an HTTPS URI.=20 > Likewise, WebFinger servers operating on HTTPS MAY redirect a > client to another HTTPS URI, but MUST NOT redirect a client to an > HTTP URI. Further, clients MUST NOT follow a redirection from an > HTTPS URI to an HTTP URI, but SHOULD automatically follow all > other server redirects. > > We still seem to be stuck at the =E2=80=9Cdo we require TLS only=E2= =80=9D or =E2=80=9Cdo > we not=E2=80=9D. If we do not mandate TLS, then I think the above = rules > are OK. > > Separate from this, we need to have that bit of text that explains > that a client that needs to guarantee that data is not modified > while being transmitted from the server to the client MUST only > use HTTPS. Perhaps give an example of where a client=E2=80=99s secu= rity > requirements might vary from another client. And we need to > explain a bit about how client libraries should support such > clients (having a =E2=80=9Csecure=E2=80=9D request being the defaul= t). > > Dare I suggest it again, but we could just explain that there are > two types of clients: those that need security and those that do > not. In all cases, HTTPS should be queried first. If an HTTPS > query fails and the client can accept a non-secure reply, then the > client may issue an HTTP query. So, just write the procedures > explicitly leaving no room for alternate possible ways of issuing > a query. We want predictable results, after all. > > > If HTTPS queries are first and HTTP fallback happens if and only if=20 > the user has opted-in to an insecure mode, I could live with that.=20 > It's not my ideal, but I recognize that a lot of people want to use HT= TP. > > --------------080800040104040402080208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I like the wording and the spirit.

-Evan

On 12-12-16 02:16 AM, Brad Fitzpatrick wrote:


On Sat, Dec 15, 2012 at 11:12 PM, Paul= E. Jones <pau= lej@packetizer.com> wrote:

Evan= ,

=C2=A0=

Mayb= e I=E2=80=99m confused a bit, but I thought we were say= ing the same thing, really.=C2=A0 What I proposed was the we simplify the text to this:

=C2=A0=

Clients MAY issue a= query to the WebFinger server using either HTTPS or HTTP.=C2=A0 The choice of transpor= t protocols depends on the client=E2=80=99s s= ecurity requirements, though use of HTTPS is RECOMMENDED in most situations.

=C2=A0

WebFinger servers operating on HTTP MAY redirect a client using an appropriate HTTP status code to another HTTP or an HTTPS URI.=C2=A0 Likewi= se, WebFinger servers operating on HTTPS MAY redirect a client to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI.=C2= =A0 Further, clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI, but SHOULD automatically follow all other server redirects.

=C2=A0

=C2=A0=

We still seem to be stuck= at the =E2=80=9Cdo we require TLS only=E2=80=9D or =E2= =80=9Cdo we not=E2=80=9D.=C2=A0 If we do not mandate TLS, then I think the above rules are OK.

=C2=A0=

Sepa= rate from this, we need to have that bit of text that explains that a client that needs to guarantee that data is not modified while being transmitted from the server to the client MUST only use HTTPS.=C2=A0 Perhaps give an example of where a client=E2=80=99s s= ecurity requirements might vary from another client. =C2=A0An= d we need to explain a bit about how client libraries should support such clients (having a =E2=80=9Csecure= =E2=80=9D request being the default).

=C2=A0=

Dare= I suggest it again, but we could just explain that there are two types of clients: those that need security and those that do not.=C2=A0 In all cases, H= TTPS should be queried first.=C2=A0 If an HTTPS query fail= s and the client can accept a non-secure reply, then the client may issue an HTTP query.=C2=A0 So, just wr= ite the procedures explicitly leaving no room for alternate possible ways of issuing a query.=C2=A0 We = want predictable results, after all.


If HTTPS queries are first and HTTP fallback happens if and only if the user has opted-in to an insecure mode, I could live with that. =C2=A0It's not my ideal, but I recognize that a= lot of people want to use HTTP.



--------------080800040104040402080208-- --------------ms020809050406040806000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMTYx NjM1MDFaMCMGCSqGSIb3DQEJBDEWBBRZ3t0vioUmNpYlBhMTriNeo/gaxzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBANb3 p3ZfkLJPhMv5wbKHhGyk9LUOu8KxQsrRu8ncxrtoDd4GsGyfenHO00erAkEggmeoUbbngekS r9gZsTHLdfvpOvUhZvlduZAjiwZ6ppuGtsBCwU/O78Ie2rlEwBH0zPRqhBI6E+xJLEkSO9ku B0c4bKvq7rcQOT3wn72QthZk1HUHr4ocuyFGadE9Sz55CVPaXW0CZztAiXxqw/d6VCbnxtoJ qAmDiVnmRcQbtITPv/25Nlfy+QgUMIZeW3vOwkFpnrn7Pbs5qa4zIIydtcm3L+IYo7QYrf21 Ox5iKw+bv2zN0BndSIKEZyj5gu+ElNrgrl8RPVGFsk09PC0UY/oAAAAAAAA= --------------ms020809050406040806000401-- From dick.hardt@gmail.com Sun Dec 16 08:53:00 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98CB21F8821 for ; Sun, 16 Dec 2012 08:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn3XzQrbwBNY for ; Sun, 16 Dec 2012 08:53:00 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA021F881C for ; Sun, 16 Dec 2012 08:53:00 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3128894pbc.31 for ; Sun, 16 Dec 2012 08:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=e5N6IdLRTA1yiG/7Mnt2y7j5rsQaVpuuPubULuousJ4=; b=AcO9wjOwjG93KzyojlXN7LD/14Js6XGInwVoA6OkSFZUTuZHmQJzIhLb/NRFbJxLh2 M43xGA17er8a78hqcgM5DveSGz0/BvTeAbPU5pVjqZrB7UQ4BQklYs3JzMQo4foExOcQ e0eDfVdw5B2CmlXd2AB7wUaimxgAHWvZW3Lxu/nHLiC3+DRkMM0B5Us5FVY564/S8tY9 Y2G1ZHru1nDYGCZYDZPGYZn/Bvokw5mKiKixlvDx/02/BWsJKDdY9KGvxaOdfKJ+BITK DHi6URikVZoW71ZnBnxjIaZ5P221HP96c9iUtx4WVX96hDJP+qhKFp9rIh0uUSQtZ36d LoRw== Received: by 10.68.235.40 with SMTP id uj8mr35012455pbc.98.1355676780223; Sun, 16 Dec 2012 08:53:00 -0800 (PST) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id se4sm6613632pbb.13.2012.12.16.08.52.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 08:52:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <00c201cddb58$9f1b8bc0$dd52a340$@packetizer.com> Date: Sun, 16 Dec 2012 08:52:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <673B1E72-51CB-4377-A781-8A8E2FD09A03@gmail.com> References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> <00c201cddb58$9f1b8bc0$dd52a340$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: 'John Panzer' , webfinger@ietf.org, 'James M Snell' , 'Goix Laurent Walter' , 'Brad Fitzpatrick' Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 16:53:01 -0000 On Dec 15, 2012, at 10:43 PM, "Paul E. Jones" = wrote: > Dick, >=20 >> As noted previously, the cost of certs is pretty much zero, so HTTPS = as >> part of a standard hosting package is really a product management >> decision followed by a deployment task (i.e., it is not a major >> financial decision by hosting companies. Do we want to be brave and = say >> HTTPS only and help drive a safer, more secure web? >=20 > But they're not. Few (maybe only StartCom) provides free certificates = and > those (last I checked) were limited to a single domain for a single = year. I'm talking about a future where having TLS is just another part of what = is automagically deployed at a hosting service. No, it does not exist today. If there was more demand, it *could* exist = in the future. -- Dick= From paulej@packetizer.com Sun Dec 16 12:23:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBC21F888B for ; Sun, 16 Dec 2012 12:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5RN+xJl3acO for ; Sun, 16 Dec 2012 12:23:37 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2F94F21F8872 for ; Sun, 16 Dec 2012 12:23:37 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBGKNZJx006731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 15:23:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355689415; bh=wDTgBdpQaJZuS9+/D+XF1hSclnNASMnn+BfbmxYE2zM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Incz6OchbXDzh7giHqgMucxDabPBwf8t2mgCsJ7v0Lm1715HRujsyTyQ/KXjew4IB ak2V7Q/79iTYxZtP0W2rvNB+j+4uK34Fw7P6OaUQpTEUvDXoAF0S/eqnVpskRgHGmS fbp0klbEyafaW5IPf2lD7KElsJ6tmLjh4LV5ZZlY= From: "Paul E. Jones" To: References: In-Reply-To: Date: Sun, 16 Dec 2012 15:23:35 -0500 Message-ID: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01CDDBA1.512B4420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkJkI0EcA Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 20:23:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0043_01CDDBA1.512B4420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Going this route is not going to address the issues people have. The draft is oh-so-very-close to completion. I think that folks are largely OK with the text, the procedures, and the data format. There are still editorial matters, but nothing controversial. The only sticky issue is use of TLS or not. But it's a big one and we ought to get this right. Without requiring use of TLS, there exists the possibility that a person queries for "customerservice@somebank.com" and a thief intercepts that request and provides bogus information. The user might trust that information, call a discovered phone number, and provide the thief with information that the thief can use to empty the user's bank accounts. Requiring TLS, though, is viewed as a roadblock to deployment. For sites where security simply is not that important, it is a valid question as to why TLS must be mandated. Some clients are in the unfortunate position of not knowing whether security is or is not important for any given query. Some clients know, though. If I had software on my server that facilitates an OpenID login, it would know to use TLS only. My email client, though, does not know how important security is. The current text that's proposed allows the client to select the transport. I think that's OK, but we just need to provide some additional guidance to client writers. Perhaps we even suggest that an indicator should be provided to the user so they will know if HTTPS was used to retrieve the data. But it would have to be ONLY HTTPS was used, as a promotion from HTTP to HTTPS cannot be trusted. The "visible trust" element is presently missing. Anyway, I think working through that language might be a good compromise. Clients that need security will get it. Clients that do not care may or may not. Providing a visual indicator to the user, where appropriate, might help address the MITM attack concerns. We just need to decide: . HTTPS only . Either HTTPS or HTTP (or both) There are those firmly sitting on both sides and that's the problem. We need to just pick a direction and go with it. Ironing out the wording is far less difficult than reaching agreement on the two choices. Now to your plea to just get it done. Here's what I suggest: how about we just say HTTPS only and publish it. Then, we could later introduce an HTTP fallback option via a separate or updated RFC. The issue with introducing HTTP as an option now is the security complexity. That's really holding us up. So, if we table that issue and just go with HTTPS for the moment, we at least have a working solution that starts out as a secure solution. We could form a WG to hammer out how to soften the security requirements once we get the HTTPS-only version out the door. (There are other things I believe we probably need to tackle as a part of that WG, such as definition of properties, new "rel" values, etc.) Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Melvin Carvalho Sent: Sunday, December 16, 2012 10:08 AM To: webfinger@googlegroups.com Subject: Possibly speeding up the RFC process Webfinger is now in it's 4th year and I think everyone would agree that we are keen to see it shipped It seems to me that there are two value added use cases that have remained constant from the start. 1) Lookup of a string of type user@host to produce a HTTP URL 2) Lookup of a string of type mailto:user@host to produce a HTTP URL These are two things that would really be very useful, irrespective of all the other benefits that webfinger has to offer. We're perhaps at a point where both of these two cases have a solution. So maybe it may be an idea to tidy up the current RFC in the WG and mark it as informational in line with the following: http://www.ietf.org/iesg/informational-vs-experimental.html [[ An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process ]] I'm speculating here that this would get webfinger shipped more quickly. Getting webfinger to IETF to recommendation level would appear to be a greater task. Perhaps adding months to the time line, and if i have understood correctly there's no guarantee that an RFC will make it to recommendation status. Part of me wants webfinger to be the best spec it can be, and for quality to be really high, yet another part would like to see webfinger actually shipped asap, and to start using a stable form to complete the loop in discovering more information from email via HTTP. So, just putting the idea out there. ------=_NextPart_000_0043_01CDDBA1.512B4420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Going this route is not going to address the issues people = have.  The draft is oh-so-very-close to completion. I think that = folks are largely OK with the text, the procedures, and the data = format.  There are still editorial matters, but nothing = controversial.

 

The only sticky issue is use of TLS or not.  But it’s a = big one and we ought to get this right.

 

Without requiring use of TLS, there exists the possibility that a = person queries for “customerservice@somebank.com” and a = thief intercepts that request and provides bogus information.  The = user might trust that information, call a discovered phone number, and = provide the thief with information that the thief can use to empty the = user’s bank accounts.

 

Requiring TLS, though, is viewed as a roadblock to deployment.  = For sites where security simply is not that important, it is a valid = question as to why TLS must be mandated.

 

Some clients are in the unfortunate position of not knowing whether = security is or is not important for any given query.  Some clients = know, though.  If I had software on my server that facilitates an = OpenID login, it would know to use TLS only.  My email client, = though, does not know how important security is.

 

The current text that’s proposed allows the client to select = the transport.   I think that’s OK, but we just need to = provide some additional guidance to client writers.  Perhaps we = even suggest that an indicator should be provided to  the user so = they will know if HTTPS was used to retrieve the data.  But it = would have to be ONLY HTTPS was used, as a promotion from HTTP to HTTPS = cannot be trusted.  The “visible trust” element is = presently missing.

 

Anyway, I think working through that language might be a good = compromise.  Clients that need security will get it.  Clients = that do not care may or may not.  Providing a visual indicator to = the user, where appropriate, might help address the MITM attack = concerns.

 

We just need to decide:

·         = HTTPS only

·         = Either HTTPS or HTTP (or both)

 

There are those firmly sitting on both sides and that’s the = problem.  We need to just pick a direction and go with it.  = Ironing out  the wording is far less difficult than reaching = agreement on the two choices.

 

Now to your plea to just get it done.  Here’s what I = suggest: how about we just say HTTPS only and publish it.  = Then, we could later introduce an HTTP fallback option via a separate or = updated RFC.  The issue with introducing HTTP as an option now is = the security complexity.  That’s really holding us up.  = So, if we table that issue and just go with HTTPS for the moment, we at = least have a working solution that starts out as a secure = solution.  We could form a WG to hammer out how to soften the = security requirements once we get the HTTPS-only version out the = door.  (There are other things I believe we probably need to tackle = as a part of that WG, such as definition of properties, new = “rel” values, etc.)

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 = 10:08 AM
To: webfinger@googlegroups.com
Subject: = Possibly speeding up the RFC process

 

Webfinger is = now in it's 4th year and I think everyone would agree that we are keen = to see it shipped

It seems to me that there are two value added = use cases that have remained constant from the start.

1) Lookup = of a string of type user@host to produce a HTTP URL
2) Lookup of a = string of type mailto:user@host to = produce a HTTP URL

These are two things that would really be very = useful, irrespective of all the other benefits that webfinger has to = offer.

We're perhaps at a point where both of these two cases = have a solution.

So maybe it may be an idea to tidy up the = current RFC in the WG and mark it as informational in line with the = following:

http= ://www.ietf.org/iesg/informational-vs-experimental.html

[[
= An "Informational" specification is published for the general = information of the Internet community, and does not represent an = Internet community consensus or recommendation. The Informational = designation is intended to provide for the timely publication of a very = broad range of responsible informational documents from many sources, = subject only to editorial considerations and to verification that there = has been adequate coordination with the standards = process
]]

I'm speculating here that this would get webfinger = shipped more quickly.  Getting webfinger to IETF to recommendation = level would appear to be a greater task.  Perhaps adding months to = the time line, and if i have understood correctly there's no guarantee = that an RFC will make it to recommendation status.

Part of me = wants webfinger to be the best spec it can be, and for quality to be = really high, yet another part would like to see webfinger actually = shipped asap, and to start using a stable form to complete the loop in = discovering more information from email via HTTP.  So, just putting = the idea out there.

------=_NextPart_000_0043_01CDDBA1.512B4420-- From melvincarvalho@gmail.com Sun Dec 16 13:00:52 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C2121F8832 for ; Sun, 16 Dec 2012 13:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilVhNWNMJWck for ; Sun, 16 Dec 2012 13:00:51 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5074221F87C3 for ; Sun, 16 Dec 2012 13:00:51 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4827501iaz.31 for ; Sun, 16 Dec 2012 13:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9cFt0UwQ1Yb2qGPLFS5PlDAyOqLlpzKaV9gqCetLclo=; b=pMPOvCJszWbqQcEtOqx35+qkOZ7/gj2K4CalGAP3htPoBnsGeznm5Hgpnwy5zz/Ypz jhM+0n1akdw/IbwjiMiUd2o373t3Bib8cXTYPxOYyD6OfKIJojWJbnrbERUPX3fbI319 ZFN8IUB72z6XDV9IEO6FlK4qkEoyLPKwMa3RwrV3L6CQy+N/IZ7NKC10BSFPb+PumOt1 2VAAMvNDkNHzi04TqQh5hYIxEtJyk3yqvO0xYIsZvjnnAOcrA3gx7WjhxHGHXfh75GqC UOJaxoQWTLhNrkz/XveIefEIc1AHXl13ui8tX6gMM0FqXdQt/Le4TxrH4VTptONGmQw/ wxcQ== MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr7324141igb.20.1355691650955; Sun, 16 Dec 2012 13:00:50 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 13:00:50 -0800 (PST) In-Reply-To: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> Date: Sun, 16 Dec 2012 22:00:50 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3b9d3d47b8c304d0fe8f26 Cc: webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:00:52 -0000 --e89a8f3b9d3d47b8c304d0fe8f26 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16 December 2012 21:23, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Going this route is not going to address the issues people have. The > draft is oh-so-very-close to completion. I think that folks are largely O= K > with the text, the procedures, and the data format. There are still > editorial matters, but nothing controversial.**** > > ** ** > > The only sticky issue is use of TLS or not. But it=92s a big one and we > ought to get this right.**** > > ** ** > > Without requiring use of TLS, there exists the possibility that a person > queries for =93customerservice@somebank.com=94 and a thief intercepts tha= t > request and provides bogus information. The user might trust that > information, call a discovered phone number, and provide the thief with > information that the thief can use to empty the user=92s bank accounts.**= ** > > ** ** > > Requiring TLS, though, is viewed as a roadblock to deployment. For sites > where security simply is not that important, it is a valid question as to > why TLS must be mandated.**** > > ** ** > > Some clients are in the unfortunate position of not knowing whether > security is or is not important for any given query. Some clients know, > though. If I had software on my server that facilitates an OpenID login, > it would know to use TLS only. My email client, though, does not know ho= w > important security is.**** > > ** ** > > The current text that=92s proposed allows the client to select the > transport. I think that=92s OK, but we just need to provide some additi= onal > guidance to client writers. Perhaps we even suggest that an indicator > should be provided to the user so they will know if HTTPS was used to > retrieve the data. But it would have to be ONLY HTTPS was used, as a > promotion from HTTP to HTTPS cannot be trusted. The =93visible trust=94 > element is presently missing.**** > > ** ** > > Anyway, I think working through that language might be a good compromise. > Clients that need security will get it. Clients that do not care may or > may not. Providing a visual indicator to the user, where appropriate, > might help address the MITM attack concerns.**** > > ** ** > > We just need to decide:**** > > **=B7 **HTTPS only**** > > **=B7 **Either HTTPS or HTTP (or both)**** > > ** ** > > There are those firmly sitting on both sides and that=92s the problem. W= e > need to just pick a direction and go with it. Ironing out the wording i= s > far less difficult than reaching agreement on the two choices.**** > > ** ** > > Now to your plea to just get it done. *Here=92s what I suggest*: how abo= ut > we just say HTTPS only and publish it. Then, we could later introduce an > HTTP fallback option via a separate or updated RFC. The issue with > introducing HTTP as an option now is the security complexity. That=92s > really holding us up. So, if we table that issue and just go with HTTPS > for the moment, we at least have a working solution that starts out as a > secure solution. We could form a WG to hammer out how to soften the > security requirements once we get the HTTPS-only version out the door. > (There are other things I believe we probably need to tackle as a part of > that WG, such as definition of properties, new =93rel=94 values, etc.) > Paul, thanks for the detailed response. Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow consensus to be reached fastest. Today I ordered my StartSSL certificate, so hopefully I can do my little bit too :) However, that is not the greatest of the concerns that I have seen. The most serious critique I've seen to date is the thread form Mark Nottingham, "Looking at Webfinger" http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html In particular: [[ Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here). * What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space. ]] Mark Nottingham has a stellar reputation at the IETF, and these are some of the more serious concerns raised to date, imho, and have yet to be fully addressed. And that may take some time to work through. If perhaps going the "informational" route could save a significant amount of time, say, 6 months or a year, do you think would it be worth considering? > **** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Sunday, December 16, 2012 10:08 AM > *To:* webfinger@googlegroups.com > *Subject:* Possibly speeding up the RFC process**** > > ** ** > > Webfinger is now in it's 4th year and I think everyone would agree that w= e > are keen to see it shipped > > It seems to me that there are two value added use cases that have remaine= d > constant from the start. > > 1) Lookup of a string of type user@host to produce a HTTP URL > 2) Lookup of a string of type mailto:user@host to produce a HTTP URL > > These are two things that would really be very useful, irrespective of al= l > the other benefits that webfinger has to offer. > > We're perhaps at a point where both of these two cases have a solution. > > So maybe it may be an idea to tidy up the current RFC in the WG and mark > it as informational in line with the following: > > http://www.ietf.org/iesg/informational-vs-experimental.html > > [[ > An "Informational" specification is published for the general information > of the Internet community, and does not represent an Internet community > consensus or recommendation. The Informational designation is intended to > provide for the timely publication of a very broad range of responsible > informational documents from many sources, subject only to editorial > considerations and to verification that there has been adequate > coordination with the standards process > ]] > > I'm speculating here that this would get webfinger shipped more quickly. > Getting webfinger to IETF to recommendation level would appear to be a > greater task. Perhaps adding months to the time line, and if i have > understood correctly there's no guarantee that an RFC will make it to > recommendation status. > > Part of me wants webfinger to be the best spec it can be, and for quality > to be really high, yet another part would like to see webfinger actually > shipped asap, and to start using a stable form to complete the loop in > discovering more information from email via HTTP. So, just putting the > idea out there.**** > --e89a8f3b9d3d47b8c304d0fe8f26 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 16 December 2012 21:23, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Going this route is not going to address the = issues people have.=A0 The draft is oh-so-very-close to completion. I think= that folks are largely OK with the text, the procedures, and the data form= at.=A0 There are still editorial matters, but nothing controversial.=

=A0<= /p>

The only sticky issue = is use of TLS or not.=A0 But it=92s a big one and we ought to get this righ= t.

=A0<= /p>

Without requiring use = of TLS, there exists the possibility that a person queries for =93customerservice@= somebank.com=94 and a thief intercepts that request and provides bogus = information.=A0 The user might trust that information, call a discovered ph= one number, and provide the thief with information that the thief can use t= o empty the user=92s bank accounts.

=A0<= /p>

Requiring TLS, though,= is viewed as a roadblock to deployment.=A0 For sites where security simply= is not that important, it is a valid question as to why TLS must be mandat= ed.

=A0<= /p>

Some clients are in th= e unfortunate position of not knowing whether security is or is not importa= nt for any given query.=A0 Some clients know, though.=A0 If I had software = on my server that facilitates an OpenID login, it would know to use TLS onl= y.=A0 My email client, though, does not know how important security is.<= /u>

=A0<= /p>

The current text that= =92s proposed allows the client to select the transport.=A0=A0 I think that= =92s OK, but we just need to provide some additional guidance to client wri= ters.=A0 Perhaps we even suggest that an indicator should be provided to=A0= the user so they will know if HTTPS was used to retrieve the data.=A0 But = it would have to be ONLY HTTPS was used, as a promotion from HTTP to HTTPS = cannot be trusted.=A0 The =93visible trust=94 element is presently missing.=

=A0<= /p>

Anyway, I think workin= g through that language might be a good compromise.=A0 Clients that need se= curity will get it.=A0 Clients that do not care may or may not.=A0 Providin= g a visual indicator to the user, where appropriate, might help address the= MITM attack concerns.

=A0<= /p>

We just need to decide= :

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 HTTP= S only

=B7=A0=A0=A0= =A0=A0=A0=A0=A0 Eith= er HTTPS or HTTP (or both)

=A0<= /p>

There are those firmly= sitting on both sides and that=92s the problem.=A0 We need to just pick a = direction and go with it.=A0 Ironing out=A0 the wording is far less difficu= lt than reaching agreement on the two choices.

=A0<= /p>

Now to your plea to ju= st get it done.=A0 Here=92s what I suggest: how about we just say HT= TPS only and publish it.=A0 Then, we could later introduce an HTTP fallback= option via a separate or updated RFC.=A0 The issue with introducing HTTP a= s an option now is the security complexity.=A0 That=92s really holding us u= p.=A0 So, if we table that issue and just go with HTTPS for the moment, we = at least have a working solution that starts out as a secure solution.=A0 W= e could form a WG to hammer out how to soften the security requirements onc= e we get the HTTPS-only version out the door.=A0 (There are other things I = believe we probably need to tackle as a part of that WG, such as definition= of properties, new =93rel=94 values, etc.)


Paul, thanks for the detailed response.
Re: the HTTP/HTTPS debate, I'm really supportive of whatever will= allow consensus to be reached fastest.=A0 Today I ordered my StartSSL cert= ificate, so hopefully I can do my little bit too :)

However, that is not the greatest of the concerns that I have seen.=A0 = The most serious critique I've seen to date is the thread form Mark Not= tingham, "Looking at Webfinger"

http://www.ietf.o= rg/mail-archive/web/apps-discuss/current/msg06487.html

In particular:

[[

Astute observers will notice that this = approach removes the need for an ACCT URI scheme (at least here).

*= What's the fascination with XRD and JRD? These specifications seem to = be creeping into IETF architecture; first it was in a pure security context= , but now folks are talking about using them in a much more generic way, as= a cornerstone of what we do. As such, I think they deserve a MUCH closer l= ook, especially since we're defining things with "Web" in the= ir name when the W3C has already defined solutions in this space.

]]

Mark Nottingham has a stellar reputation at the IETF, and the= se are some of the more serious concerns raised to date, imho, and have yet= to be fully addressed.=A0 And that may take some time to work through.

If perhaps going the "informational" route could save a signi= ficant amount of time, say, 6 months or a year, do you think would it be wo= rth considering?
=A0

=A0

Paul=

=A0

From:= webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf = Of Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 AM
To: webfinger@googlegroups.c= om
Subject: Possibly speeding up the RFC process

=A0=

Webfinger is now in it's 4th year and I thin= k everyone would agree that we are keen to see it shipped

It seems t= o me that there are two value added use cases that have remained constant f= rom the start.

1) Lookup of a string of type user@host to produce a HTTP URL
2) Loo= kup of a string of type mailto:user@host to produce a HTTP URL

These are two things that wou= ld really be very useful, irrespective of all the other benefits that webfi= nger has to offer.

We're perhaps at a point where both of these two cases have a solut= ion.

So maybe it may be an idea to tidy up the current RFC in the WG= and mark it as informational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.html

[[
An "Informational" specification is published for the g= eneral information of the Internet community, and does not represent an Int= ernet community consensus or recommendation. The Informational designation = is intended to provide for the timely publication of a very broad range of = responsible informational documents from many sources, subject only to edit= orial considerations and to verification that there has been adequate coord= ination with the standards process
]]

I'm speculating here that this would get webfinger shipped mo= re quickly.=A0 Getting webfinger to IETF to recommendation level would appe= ar to be a greater task.=A0 Perhaps adding months to the time line, and if = i have understood correctly there's no guarantee that an RFC will make = it to recommendation status.

Part of me wants webfinger to be the best spec it can be, and for quali= ty to be really high, yet another part would like to see webfinger actually= shipped asap, and to start using a stable form to complete the loop in dis= covering more information from email via HTTP.=A0 So, just putting the idea= out there.


--e89a8f3b9d3d47b8c304d0fe8f26-- From bradfitz@google.com Sun Dec 16 13:04:44 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3121F893C for ; Sun, 16 Dec 2012 13:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Xm4mjYXxSx for ; Sun, 16 Dec 2012 13:04:42 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 96BD321F88C3 for ; Sun, 16 Dec 2012 13:04:41 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1537171wib.13 for ; Sun, 16 Dec 2012 13:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8P76k48Ne/jmlV/7ZzrTIg2ahD2Icb5yJPPi7mw4dHY=; b=EZK5FEpGnldd0F/c5FS1cBOr+idqir7IiQX4oETaYg+MPOcYjVtBPpM8Zi8Dm8FNYk JAeErd66B72tyXqJHn52+clS53kQC1SbaJCMZIvXWNsEhgj/UcNNZz7inoUgIsN0OH8Y 86h2N71NW8c7BP/ds2IWKcpKIl/bFGf3crguqU7A/LewkmEoR6Y2meukA/mxp/jgJSSM 66V9oDkZxdgeB2uqsnhMeN+XlGVPokD0gnPReNfekZMSKEYKlEQETFCIUdzN010xIH1w ZGUNGQNOZIj7bvzgq+yTrna+7O6IYoFLwiRgKBYFHHVQljfZpGxrSzxX4c8dcdNszcLg S3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8P76k48Ne/jmlV/7ZzrTIg2ahD2Icb5yJPPi7mw4dHY=; b=OhoeBIvGyqUsC9WxPbPkbHVObJxbzmXO75EN7JMJI91SZsLIJrD2HqmQ2oQAxiQyMh WWn4ZwgXpBDAj0c5So2SOGniYvOzfq1LNNSJ7UC4xqF4R2Q/R97EdK7a5Io/FyPyN8fz uu+l32dv2vFikj08cTgFlnXnUPpGWvdIMpsRf7dz2L3YXiB0CBmyZa28n84qhy1JzwQT S6UMh9fgN8wxMnEa6XHYiX6r6DZ+PZKXekXcfuZyddvqi3e529nH7W5r90qRsDFw6891 nDcWvrLN1VkBT1KeU5sNxoOsHwNtScF8dDeOB9lHMM0J0MqIeyuPzDnohf8ZMpxkZvT6 EHoA== MIME-Version: 1.0 Received: by 10.194.58.175 with SMTP id s15mr13467462wjq.31.1355691880527; Sun, 16 Dec 2012 13:04:40 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sun, 16 Dec 2012 13:04:40 -0800 (PST) In-Reply-To: <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> Date: Sun, 16 Dec 2012 13:04:40 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/mixed; boundary=047d7ba97924f6b5f504d0fe9cfa X-Gm-Message-State: ALoCoQmmi+NN0peoJbP7jtRoMdqOjAewyzH4Qdi1CnphFSaDTjSy2Wjd+n5r3wskNbgAW34iKbmHqeK+TylU+hIWfjZ7APdsSMRlUtqgpmM9GJN3Sc32ZObqpoHQmef2YqlotNF9rLww4S9jS/eNYdKdxnNtHzW2O3tEn3IFPjibf9yOI3X0uqOeGw8Aa4wlrSKNKFTi5YJj Cc: webfinger@ietf.org, Nick Jennings , webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:04:44 -0000 --047d7ba97924f6b5f504d0fe9cfa Content-Type: multipart/alternative; boundary=047d7ba97924f6b5ed04d0fe9cf8 --047d7ba97924f6b5ed04d0fe9cf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My proposal doesn't prevent MITM on HTTP fallback (because you can't); rather, it neuters it: In my secure rel proposal, after the client tries HTTPS and it fails, the client then tries HTTP, but the client knows it's using HTTP. It doesn't know who the remote party is anymore (since it's just using HTTP), but the client knows that it's speaking HTTP and not speaking HTTPS. So, when the client receives the HTTP response, it treats it suspiciously. Any link rel that's security-related MUST NOT be present. If it's present, the server is dumb or somebody's fucking with us. Either way, discard that link or abort. But if the rel is for something "unimportant" (this mailing list seems to have concluded that names and pictures are insecure, so let's use that example), then it can happily report: rel "avatar" =3D> href "http://evil.example.com/goatse.jpg", or whatever. But how does the client know which link rels are security-related (ala "HTTPS-only")? Not a database, because that's hard to keep all clients updated over time, as new link rels go into use and/or get registered with the IANA. Rather, we encode the HTTPS-only property into the rel type itself: if the "rel" value begins with "https:" or begins with "secure-", clients must never respect it when seen over an HTTP connection. That's the neutering. So a MITM can stop webfinger, but can't inject fake results. And if you want extra security for "avatar" (which isn't "secure-avatar"), you tell your WebFinger client to go into HTTPS-only mode. But even with no configuration, all WebFinger clients must neuter (filter) secure rels when seen in HTTP responses. Here's a picture: http://i.imgur.com/rvMtk.png (also attached) On Sat, Dec 15, 2012 at 11:44 PM, Paul E. Jones wrot= e: > Brad,**** > > ** ** > > I really thought I understood this. I think I still do, but I=E2=80=99ll= admit > that I might be missing something.**** > > ** ** > > Let me explain how I expected the WF client to work. First, I would neve= r > expect the end user ever selects a transport on a case-by-case basis. > Rather, the WF client would be integrated in software like my email clien= t, > my blog (for fetching visitor=E2=80=99s avatars), or perhaps on my web fo= rums where > users log into the system.**** > > ** ** > > In my email client, I would expect a configuration option where WF querie= s > are secure or they are not. By default, I=E2=80=99d expect those to not = be secure, > since most users that would use WF from an email client don=E2=80=99t car= e. If I > get the right picture for you, good. If not, no big deal. Some users wou= ld > care, though: they would not want to fetch a vcard and get the wrong > telephone number. So, the email client would operate in either =E2=80=9C= secure=E2=80=9D or > =E2=80=9Cnon-secure=E2=80=9D mode.**** > > ** ** > > Behavior for =E2=80=9Csecure mode=E2=80=9D:**** > > **=C2=B7 **TLS query**** > > **=C2=B7 **Fail for *any* reason? Stop.**** > > ** ** > > Behavior for =E2=80=9Cnon-secure mode=E2=80=9D:**** > > **=C2=B7 **TLS query**** > > **=C2=B7 **Failure? Try HTTP.**** > > ** ** > > My blog where you might post comments and I want to grab your avatar migh= t > operate in =E2=80=9Cnon-secure=E2=80=9D mode. Security is not so importa= nt. This would be > provisioned by the blog admin.**** > > ** ** > > The web forums where users log in would use =E2=80=9Csecure mode=E2=80=9D= . That client > would not want to be directed to the wrong IdP.**** > > ** ** > > Now, some would argue that =E2=80=9Cnon-secure=E2=80=9D mode should start= with HTTP and > the server could re-direct the client to HTTPS or just reply. That=E2=80= =99s > reasonable, IMO. Either way, the =E2=80=9Cnon-secure=E2=80=9D mode is su= sceptible to MITM > attacks, and leading with HTTP could result in a fast response.**** > > ** ** > > If we allow the non-secure mode, then it=E2=80=99s truly non-secure. And= , it > could introduce some serious problems if users blindly trust it. Let=E2= =80=99s say > I get an email from my bank. My email client (operating in non-secure > mode) automatically grabs the contact info for customerservice@mybank.com= . > Somebody (not my bank) actually served the reply (blocking port 443 and > providing a bogus answer on 80). I see their phone number and call, > getting some very professional-sounding person who collects information > from me and then cleans out my bank account.**** > > ** ** > > Without mandating HTTPS, WF might never be adopted for anything except > casual stuff. My bank would never support it, yet they would still be > subject to a MITM attack! That=E2=80=99s really scary. So, there is a l= ot of > value in the HTTPS only approach.**** > > ** ** > > However, what I don=E2=80=99t understand in your proposal is how you woul= d prevent > this MITM attack. If it does, I=E2=80=99m missing that and perhaps a pre= tty > picture is needed.**** > > ** ** > > Paul**** > > ** ** > > *From:* Brad Fitzpatrick [mailto:bradfitz@google.com] > *Sent:* Sunday, December 16, 2012 1:53 AM > *To:* Paul E. Jones > *Cc:* Nick Jennings; webfinger@googlegroups.com; webfinger@ietf.org > > *Subject:* Re: [webfinger] Current HTTP/HTTPS Language**** > > ** ** > > On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones > wrote:**** > > ** ** > > The secure links idea (which I don=E2=80=99t particularly like) helps the= server > decide what to return. At least as I understand it. **** > > ** ** > > No, you misunderstand it.**** > > ** ** > > Maybe you don't like it because you don't understand it. I'll try to > rephrase:**** > > **** > > Since there is nothing secure about a link in and of itself, I don=E2=80= =99t see > any reason to classify link types.**** > > ** ** > > The point was to encode classification (a rel type's "requires-HTTPS" > property) into the rel type itself, so clients could be free of any > configuration (nobody has to say "I want secure" or "sure, HTTP works I > guess?") and clients can then safely failover from HTTPS to HTTP, since t= he > *client* (again! the client, NOT the server) does the filtering.**** > > **** > > But, a server is certainly free to return whatever it likes over HTTP, > and that might be different than what it returns over HTTP. But, why > bother? **** > > ** ** > > I think your "why bother?" might be about a line of confusion that's > unrelated to my bother: I'm bothered by webfinger being vulnerable to > MITM, and users having to opt-in to security.**** > > **** > > If we ensure proper client behavior, it=E2=80=99s not an issue. And by = =E2=80=9Cproper=E2=80=9D, > that means ensuring that clients that absolutely need to ensure that data > is not modified in flight must only use HTTPS. Any client that does not > have that restriction could do what it wants, but with some reasonable > guidance =E2=80=A6 that we=E2=80=99re trying to hammer out.**** > > ** ** > > I'm fine with people using HTTP to fetch certain links.**** > > ** ** > > What I am NOT fine with is people telling their webfinger client, "Please > fetch me the https://openid.net/connect/server link for foo@example.com. > Oh, wait, what? I have to pick HTTPS or HTTP now? Oh, whatever, HTTP.= " > And then it doesn't matter what your server returned, because the user's > already been MITMed.**** > > ** ** > > HTTPS-only avoids this complication, but if we're going to permit HTTP, I > was at least hoping we could make secure uses of WebFinger have a much > higher likelihood of being secure but classifying rel types (NOT > classifying links) and teaching clients that some rel types are HTTPS-onl= y > and the rest are whatever (since a lot of people don't seem to care about > the security of their avatar or name).**** > > ** ** > > I'm willing to draw pictures or write such a client in the language of > your choice to demonstrate this, if it's still unclear.**** > --047d7ba97924f6b5ed04d0fe9cf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
M= y proposal doesn't prevent MITM on HTTP fallback (because you can't= ); rather, it neuters it:

In my secure rel proposal, aft= er the client tries HTTPS and it fails, the client then tries HTTP, but the= client knows it's using HTTP. =C2=A0It doesn't know who the remote= party is anymore (since it's just using HTTP), but the client knows th= at it's speaking HTTP and not speaking HTTPS.

So, when the client receives the HTTP response, it trea= ts it suspiciously. =C2=A0Any link rel that's security-related MUST NOT= be present. =C2=A0If it's present, the server is dumb or somebody'= s fucking with us. =C2=A0Either way, discard that link or abort. =C2=A0But = if the rel is for something "unimportant" (this mailing list seem= s to have concluded that names and pictures are insecure, so let's use = that example), then it can happily report: rel "avatar" =3D> h= ref "http://evil.exampl= e.com/goatse.jpg", or whatever.

But how does the client know which link rels are securi= ty-related (ala "HTTPS-only")? =C2=A0Not a database, because that= 's hard to keep all clients updated over time, as new link rels go into= use and/or get registered with the IANA. =C2=A0Rather, we encode the HTTPS= -only property into the rel type itself: if the "rel" value begin= s with "https:" or begins with "secure-", clients must = never respect it when seen over an HTTP connection. =C2=A0That's the ne= utering.

So a MITM can stop webfinger, but can't inject fake= results.

And if you want extra security for "= ;avatar" (which isn't "secure-avatar"), you tell your We= bFinger client to go into HTTPS-only mode. =C2=A0But even with no configura= tion, all WebFinger clients must neuter (filter) secure rels when seen in H= TTP responses.

Here's a picture:=C2=A0http://i.imgur.com/rvMtk.png (also attached)


On Sat, Dec 15, 2012 at 11= :44 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Brad,<= u>

=C2=A0

I really thought I = understood this.=C2=A0 I think I still do, but I=E2=80=99ll admit that I mi= ght be missing something.

=C2=A0

Let me explain how = I expected the WF client to work.=C2=A0 First, I would never expect the end= user ever selects a transport on a case-by-case basis.=C2=A0 Rather, the W= F client would be integrated in software like my email client, my blog (for= fetching visitor=E2=80=99s avatars), or perhaps on my web forums where use= rs log into the system.

=C2=A0

In my email client,= I would expect a configuration option where WF queries are secure or they = are not.=C2=A0 By default, I=E2=80=99d expect those to not be secure, since= most users that would use WF from an email client don=E2=80=99t care.=C2= =A0 If I get the right picture for you, good. If not, no big deal.=C2=A0 So= me users would care, though: they would not want to fetch a vcard and get t= he wrong telephone number.=C2=A0 So, the email client would operate in eith= er =E2=80=9Csecure=E2=80=9D or =E2=80=9Cnon-secure=E2=80=9D mode.=

=C2=A0

Behavior for =E2=80= =9Csecure mode=E2=80=9D:

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS query

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fail for any reason? Stop.

=C2=A0

Behavior for =E2=80= =9Cnon-secure mode=E2=80=9D:

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS query

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Failure?=C2=A0 Try HTTP.

=C2=A0

My blog where you m= ight post comments and I want to grab your avatar might operate in =E2=80= =9Cnon-secure=E2=80=9D mode.=C2=A0 Security is not so important.=C2=A0 This= would be provisioned by the blog admin.

=C2=A0

The web forums wher= e users log in would use =E2=80=9Csecure mode=E2=80=9D.=C2=A0 That client w= ould not want to be directed to the wrong IdP.

=C2=A0

Now, some would arg= ue that =E2=80=9Cnon-secure=E2=80=9D mode should start with HTTP and the se= rver could re-direct the client to HTTPS or just reply.=C2=A0 That=E2=80=99= s reasonable, IMO.=C2=A0 Either way, the =E2=80=9Cnon-secure=E2=80=9D mode = is susceptible to MITM attacks, and leading with HTTP could result in a fas= t response.

=C2=A0

If we allow the non= -secure mode, then it=E2=80=99s truly non-secure.=C2=A0 And, it could intro= duce some serious problems if users blindly trust it. =C2=A0Let=E2=80=99s s= ay I get an email from my bank.=C2=A0 My email client (operating in non-sec= ure mode) automatically grabs the contact info for customerservice@mybank.com.=C2= =A0 Somebody (not my bank) actually served the reply (blocking port 443 and= providing a bogus answer on 80).=C2=A0 I see their phone number and call, = getting some very professional-sounding person who collects information fro= m me and then cleans out my bank account.

=C2=A0

Without mandating H= TTPS, WF might never be adopted for anything except casual stuff.=C2=A0 My = bank would never support it, yet they would still be subject to a MITM atta= ck!=C2=A0 That=E2=80=99s really scary.=C2=A0 So, there is a lot of value in= the HTTPS only approach.

=C2=A0

However, what I don= =E2=80=99t understand in your proposal is how you would prevent this MITM a= ttack.=C2=A0 If it does, I=E2=80=99m missing that and perhaps a pretty pict= ure is needed.

=C2=A0

Paul<= /span>

=C2=A0

From: Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Sunday, December 16, 2012 1:53 AM
To: Paul E. Jones<= br>Cc: Nick Jennings; webfinger@googlegroups.com; webfinger@ietf.org


Subject: Re: [webfinger] Current HTTP/HTTPS La= nguage

= =C2=A0

On Sat, Dec 15, 201= 2 at 10:32 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= /p>

=C2=A0

The secure links idea (which I don=E2=80=99= t particularly like) helps the server decide what to return.=C2=A0 At least= as I understand it.=C2=A0

=C2=A0<= /u>

No, you misunder= stand it.

=C2=A0

Maybe you don't like it b= ecause you don't understand it. =C2=A0I'll try to rephrase:<= u>

=C2=A0

Since there is nothi= ng secure about a link in and of itself, I don=E2=80=99t see any reason to = classify link types.

=C2=A0<= /u>

The point was to= encode=C2=A0classification=C2=A0(a rel type's "requires-HTTPS&quo= t; property) into the rel type itself, so clients could be free of any conf= iguration (nobody has to say "I want secure" or "sure, HTTP = works I guess?") and clients can then safely failover from HTTPS to HT= TP, since the *client* (again! the client, NOT the server) does the filteri= ng.

=C2=A0

=C2=A0 But, a server= is certainly free to return whatever it likes over HTTP, and that might be= different than what it returns over HTTP.=C2=A0 But, why bother?=C2=A0

=C2=A0<= /u>

I think your &qu= ot;why bother?" might be about a line of confusion that's unrelate= d to my bother: =C2=A0I'm bothered by webfinger being vulnerable to MIT= M, and users having to opt-in to security.

=C2=A0

If we ensure proper = client behavior, it=E2=80=99s not an issue. And by =E2=80=9Cproper=E2=80=9D= , that means ensuring that clients that absolutely need to ensure that data= is not modified in flight must only use HTTPS.=C2=A0 Any client that does = not have that restriction could do what it wants, but with some reasonable = guidance =E2=80=A6 that we=E2=80=99re trying to hammer out.

=C2=A0<= /u>

I'm fine wit= h people using HTTP to fetch certain links.

=C2=A0

What I am NOT fine with is pe= ople telling their webfinger client, "Please fetch me the https://openid.net/conn= ect/server link for foo@example.com. =C2=A0 Oh, wait, what? =C2=A0I have to pick HTTPS or= HTTP now? =C2=A0Oh, whatever, HTTP." =C2=A0And then it doesn't ma= tter what your server returned, because the user's already been MITMed.=

=C2=A0

HTTPS-only avoids this compli= cation, but if we're going to permit HTTP, I was at least hoping we cou= ld make secure uses of WebFinger have a much higher=C2=A0likelihood=C2=A0of= being secure but classifying rel types (NOT classifying links) and teachin= g clients that some rel types are HTTPS-only and the rest are whatever (sin= ce a lot of people don't seem to care about the security of their avata= r or name).

=C2=A0

I'm willing to draw pictu= res or write such a client in the language of your choice to demonstrate th= is, if it's still unclear.


--047d7ba97924f6b5ed04d0fe9cf8-- --047d7ba97924f6b5f504d0fe9cfa Content-Type: image/png; name="secure-mitm-neuter.png" Content-Disposition: attachment; filename="secure-mitm-neuter.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hasnxud80 iVBORw0KGgoAAAANSUhEUgAAA8AAAALQCAIAAADQFY7jAACAAElEQVR42uydD1hc1Zn/byv9lacd K62jJZZETDHBBJOJwWQSJgkmYFDZiO2kZRW7VFGxxcoq67IuVtqylbZosdIWt7RLFVfajhW7WNGi 1GJFpYoW21ExUiU6GqITM0kHM1Z+X+7LnNzMPwbCDP++n2cecufMueeee2cYPvfkPe/RRgkhhBBC CCFRo/ESEEIIIYQQQoEmhBBCCCGEAk0IIYQQQggFmhBCCCGEEAo0IYQQQgghFGhCCCGEEEIo0LwE hBBCCCGEUKAJIYQQQgihQBNCCCGEEEKBJoQQQgghhAJNCCGEEEIIBZoQQgghhBAKNC8BIYQQQggh FGhCCCGEEEIo0IQQQgghhFCgCSGEEEIIoUATQgghhBBCgSaEEEIIIYQCzUtACCGEEEIIBZoQQggh hBAKNCGEkIXHB2RG4SeQEAo0IYQQCjShQBNCgSaEEEKBJhRoQijQhBBCCAWaAk0IBZoQQgihQFOg CaFAE0IIIRRoCjQhFGhCCCGEAk34CSSEAk0IIYQCTSjQhFCgCSGEUKAJBZoQCjQhhBBCgaZAE0KB JoQQQijQFGhCKNCEEEIIBZoCTQgFmhBCCKFATyP/+Mc/KNCEUKAJIYSQBSfQ77//vtLKt99+u7u7 +5ZbbsnPzzebzUlJSatWrdq8efNZZ521VSdb56wjyfYjdVCCXdavX7906dJPfvKTaMdqtV5yySVo 9je/+c2f//znvXv3Hjp0KOCyvPnmm0899dSTTz65b98+CjQhFGhCCCFkVgi0jBnv2bPnhz/8ocVi 2agjyps9m0B/bDZbjEa4+QkkhAJNCCGEAj2BNLe3t+/YsWP16tXbtm2bgsvm6GRlZS1fvnzp0qVr 164977zzdu7ceeGFF1555ZXXXnvtj3/84zvuuMPhcHR0dPzBAJ62tbW1tLT86Ec/uuGGG7761a9i l89//vPnnnsurB3uvmrVqlNOOWWpDow5Nzc34OhXXXUVBZoQCjQhhBAKdMyN+f333//BD36waNEi iO+Efgyr3rRpE/QaleG1t9xyS29vrzGO4h9+gkv+/ve/u93uvXv3vvPOOwcOHAioNtluy76PPvro GWecoXq4cuXK6R2K5ieQEAo0IYQQCvQ4Bw8e3LFjx/bt28Pp8ubNm/Hz5JNPhiW/9tpr0h/YdjhD fV/n7bff/tWvfrVz585jjz0WLeTm5i5ZsuTqq69+8MEH0QgOKpW9Xu+uXbsaGhrw6oYNG1DtxRdf nLL7joyMqJBrbEyjQ/MTSAgFmhBCyEIXaLR51VVXBcQ/QDph0qeddtqHdI477rgzzzzzpJNOcjgc brc7uFcw1N27d//iF7/Iy8s75phjcnJy8vPzU1NT169f//DDD0OjRbUnNTcRbNu27bzzzquvr5/C iaNLp556qjqdSR2dAk0IBZoQQggFOgSHDh2yWq3GeAyz2dzV1RVhUFkFS/h8Po/H89Zbb7388ssv vPDC4OAgtlEi+05v1MTBgweXLFmSlZW1b9++ybYMoZezg9NPS6/4CSSEAk0IIWQhCvTIyIgxUDgz M/Pxxx+PdfoO/Ny1a9evfvWryy677Nxzz8VxYbewdvy86KKL7r77brwaIUU0Cr/2ta9t2LDh1Vdf ndTRJfIEnH766RRoQijQhBBCKNCTdtk1a9YodV67du3+/fuVsGLj1ltvXb169dKlS08++eSNGzeW lpY+++yzyoCjmckn49MvvPDC17/+dcjxypUrIegw5q6uLoh7hH0h0P/1X/+FmjabbcWKFXV1dYcO HQqudsEFFyxfvjxCU8G7qHjooqKiOAt0cCh5QUFBc3MzLtHRfAzQTm1tLX8dCAWaEEIIia1A33vv vcaAjVdeecX46osvvnjmmWeKAauI4ZdffrmhoQHOvXnz5nXr1n3sYx8rLCysqqr67ne/e/PNN9fU 1Fx99dVf+MIXFi1aZDabJXIaP7ds2YL6F1100bvvvjvlEWuXy4Xjnn322WgwuB2r1XrOOedEGZXh 9XrVib/22mvxFGhN05KSkuTQuDFITU1NTExEIW4tjsah0UJxcTF/HQgFmhBCCImVQEM0ly1bpiTy +OOPD1bP4eHh6PPchVNJmf83jTHQIvSLFy+Gmt91113GuYB79uyBXu/duzeadlR2kdzc3KPp3hRM Fwc1lrjd7vz8fJS3trZSoAkFmhBCCJmlAm1cLPDFF1+cweUMcQr9/f2VlZUnnXSS2Wz+xCc+8fGP f3z58uWbNm3auHHjiSeeeNFFFz344IMyOhuQPfraa6/dunXrf/7nfyqNRuG2bduWLFkyYZINVFBX 4LLLLptBgQbd3d0or6ioMBZ6vd6enp6urq7e3t7gwWmU9PX14VWPxxONQEtlNBXyVafTGfwqDjE4 OIj20RO86nK5hnQC9sUNAKoZe4g3FPXxM2RrqI9XQyZvIRRoQgghZDYKNDzGmBH5vffem1QcBXj3 3XdfeOGFJ5988rnnnnvrrbeijIeOpuVwcw1HRkbgf9DcZcuW5eTk3H///cEaDV1Thfv378/NzZ0w Kvp///d/5TrAuafc/2kR6La2NpRLej5xTci0hHYISUlJxvFpCHdaWpq8hGrNzc0RBBqV09PTVVPJ yck4nFGdLRaLehXNor68BN9FSV1dneyekJBgtVrxM8ChbTYb7nwg2diG8RuPlZGRoaRcWquurkYH sGEymUT9CQWaEEIIme0CvWLFikmtJ4I6UJ8vfOEL69evb2hoeOWVV6BKKnfHq6+++rOf/WzHjh1Z WVmw2/PPP/+NN96YbJdWrVrV0dERfX34cWFhIeSss7NTSfZGHeP0x0suueS2226LfGpqEPqpp56K m0BDQwcNtLe3QzpTU1PVoGxVVRWqlZaW4q5gYGCgqakJhgpRlgoulws+DQ3Fjtgdb4qodkiBhoun pKSg/a6uLlTGFYMio/7w8DBehQqjZTTlcDjwKuqgJl6VwWNRXlTIzMyE+JaVleFtMoq+qoOXxMWh xTgRCDrKURnHQlexrWqicdwCobXKykr+8lKgCSGEkLkh0Keddlr09vyv//qvNpsN6hNNwg38fPjh h1F/UqO53/nOd6YWQ4KjvPPOO5s2bYJByhH37NkDOYNlGuusXr06mkFotBM3gQ4GlmkMn8BZQLKN e0E3UU3Gho3bQl1dXTiBFm012iocGmoO2cU2xBevGg8NpYbj2u12o0CroWLRcYvFourX1NSoFoqK irAtLQt9fX1yJ6Bag14fZb4RQoEmhBBC4i3QEr8xYYgw1BMa99Of/nR610AJ4N133120aNHRr/+y fft2aJlabvDBBx80Vnj++efDna/ETItDj04poHwKAg2JrPZTVVUFW4Wzmkym9vb24PoS6ww5xo5d XV0ogb8mJycb6wwPD4cTaK/XCztH4+Xl5dg9QF7T09NlhNgI2kd9pbwFBQXBKq/im9PS0pRPoyk0 GNCajH+r1kSmCQWaEEIImUsCLdknJtRiSN7Q0NCkxoPPOuusyXbmmmuuma7UHPDmPXv2yNO//vWv AcEbEc73pptuEoGG281UDLTT6ZSoDIkkhua2tLTAXFU8sQRpiEDjrQluAcobLga6s7MTFivtmM3m oqIiaWc0zHC44PF4RHkDmkVXUQjvH9UjnlVEB+pHaG3UEAPN31kKNCGEEDKXBFpF/UYW6Pfff//G G2+crEo+8MAD3/rWtya1y5e//OUJx8Kj5+c//7maE4lmv/vd70a5owxCT20q4bQINLDb7Xipr68P 24WFhTIDr7y8HCbd39/f2NhoFOjMzMzoBVqA7MJ61dTDjo4OFCYkJFgslq5QQOVDCvSoPmsQRj6q R4CgBQmnRn05tZCtUaAp0IQQQshcFejOzs5oBBoaOrXIjcsuu2xSOz722GPTKNDghhtuMM4jbGtr i2avb37zm3JZnnzyyZkSaEkF3a+DDTw1viqBE2KiOTk50GUZqxZcLle4EA63293e3o4KqkQmAkpg BuzZbDYHxHXgQwLbVsob3GxTU5N0BvtKtLSQnJwMQQ+ojLdAIqQp0BRoQgghZO4JNIRyw4YNsLft 27dH1tzGxsap+atxGfCjXy3l+eefv/766wsLC2022+LFi5cvX37OOefA0aFuwWt6K6a2sqAMQk9h UZWjF2gJ2EhISBD7lJzQktdCGB4eTk1NRSGqKX9taGgI0OuQAg0bDsgwLSJbVFSEbeisJKpTr0Lf 0RNc8AgC7fF4YPBWqxWvGuO2ZUpic3NzgKwbpyRSoCnQhBBCyFwSaKfTKeOsSUlJU0vMPCHPPPPM USaE7u3tPf7443NycrInAnVOOumkN998c1o673A4pNmdO3fGWqATExNTDZjNZimUsAroaUpKCp7W 1ta2tbXBbqUa6kCdRbjRT2huaWkpbBUqjDc0Qhq7zMxMVEY17I420RSeyhgzjpWRkSE+jaZgt+gM 5Ng4ZhyyWZnUmJycbBy9hujjHkB1DNZu0hkYGKBAU6AJIYSQuSfQ0Mrc3FxxxL///e8xyqpx3XXX Tc1fZRZggCKfddZZK1eunNCk8/Ly9u3bd/SdV4t7P/3007ET6JD9r6qqEssU+vv7US4TBy0WS0ND g8vlQokaKob4lpeXy9RAq9UK38WrkOOQR4TXwmjV8iW48TCmwJOmRNDxan5+vsRhj+qRIeGahX8b +xPyWNB6u92uzktaM45PEwo0IYQQMnsFGnq6atUq0bUtW7ZM1iyffPLJz3zmM1t0Nm/evGnTpiVL ljz00EOjR66tDX7wgx9MVqBR//zzzzcuLQ7Rv+CCCw4ePChZorOjIy0t7SgF2ri49969e2Mk0IRQ oAkhhJA5INBnn322GtOdbJYMo9oGI69OOWwDO65fv161tmzZsjfffNPYmtvtjuzNKoszWLNmzVE6 dGVlpTovlRSPAk0IBZoQQsjCEujzzjtPKeak1tmGjyqvXbFiRVpa2rnnnltQULBly5ZgkV2+fLla 4jt6e5ZVXURYww36qjrBWCwWqXP//feLyn//+9+fbCT0yMjIoUOHZNoinmZlZan2n332WQo0IRRo QgghC0ugzznnHKWDxhxtwX6JkoMHD6pyVFY7Wq3WJ5544sUXX7z77rtvvPHG8vLycMPSk5qBp4Ke g9cVl2W6b7755q9+9as4eoQR6CVLllx55ZWvvPKKnCmaUo2gkzjEN77xjYGBgZdeeim4A8PDw8an u3btKiwszMzMNLYfsCALBZoQCjQhhJD5LNB2u12J4GOPPSaFHo8nLS0tNzf3ox/9aFJS0sqVKx98 8MGXdZ555pmf/vSna9euRbVNmzZlTwmJo5AB3Qg5ntWSLuDVV181vvS73/1OzXeMHuX099xzj7Rz UCcvLy84cOXAgQPV1dXQZdRftGjRCSecsGrVqmOOOebnP/+5pJXYvn27anDHjh0UaEIo0IQQQua/ QKvFQcBDDz0kzvrpT39a0j5EuXxJf39/SkoKZFplqIgGKKmyT3hqyJYPHTqk6svwswyBB6szjr5l yxbcALz33nuq26g8MjLywx/+8LOf/awxxgPbfX194rWoc0gn+nAOtO/1ehcvXvzuu+9i+yMf+Yg0 e+qpp4ZrhJ9AQijQhBBC5oNAw0SVU375y19WIQ1FRUVHM+FPBpUhly+99NJPfvKTf/7nf4ZeRx4t PnDgQLgGlyxZohTZZrMZQ6vR5nnnnff2228bexsuIllE+Y033njrrbdU/aamJtwnBNR855134Nyb N29es2bNV7/6VYlpCXlBcAHPOeccbDQ3N0uX1q5dG7ImP4GEUKAJIYTMB4FWccMqemHbtm3GNUca GhqmZclAEVCfz1dcXGxMiIHtr33ta5EPgVdTU1MDhBslf/vb30LuePbZZ2/duvVf/uVfouy5qgYR P+OMM8LFbaP8kksuCbm7pPxT4eCwfAo0IRRoQggh81CgjeHFEsCQlZUli6e8//772DbOtJtGVFYN +Gj0dv7yyy/LXhOm2LvvvvvkpHAKUbZ/4MCB4KVYVupkZGQYlRrbP/vZz4JbeOeddyS/tVSrr6+n QBNCgSaEEDLfBPqmm24S21u/fj2e3nrrrU888QQ2fvvb327evDkg08UvfvGL22+/HRVg2Ec5Jg07 FxWelnUBQwq6WuIbvut0OiNU9vl8n/nMZwLU2WazGc8R27iA3d3dKJcKJ554YkA7N998s2wsW7ZM 3ZNQoAmhQBNCCJlXAq3yN3/lK19RcQiSEFpNwuvo6AiZX/m000574YUXopxiGGeBDhhcB+vWrfvb 3/6Gi/C+H9R5+OGHN27cGHBe6Njjjz8eoeVf/vKXUvPTn/50wEkFHDojI4MCTQgFmhBCyLwSaDWe CpF9++23d+/eLeVKDXft2jVhSrj//M//DBiQnnCIWgl0QH7l6QVHOfbYY4M7LIRc4vu5555TPT9w 4ACqvf7668Etv/HGG7KLWo1FpdWTjZ07d0qF9957jwJNCAWaEELI/BFotZaeyLRKEme1WlWkMiQS L33uc5/r6ekZGRmRHd966621a9ca7VMip++8804xYwkFiRA1EQeBVuPB99xzj4RV5ObmijrjJ7a3 bdu2aNGiyy67bHBwMNj46+rqUBM/I6x5HhAjfsUVVyh3l8ty1VVXUaAJoUATQgiZPwKt8sFhe926 dco4zz///JBJKgJYvny50aGNSh1hBBr2rLJwxC6EI1xyvXBPg/n+978v0xDDVZB7gOuuu06VGGM2 JB82xJ0CTQgFmhBCyPwR6PT0dCXQZ599tjLLCCvqPfzww8XFxaKe+/fvDxnU8W//9m/hdu/r6zNW 9ng8H8w+JBxchXkELH+o2Lx5s1pPUcWUq+0Pf/jDMuatNJ2fQEIo0IQQQua8QN97771KoI2LifzT P/1TOLnMzMw0rgh4vM6ndD772c/+4Q9/GA2/5OFFF11k9OyDBw9ONqbZ5XKNjIxMV17qYLxer8lk Cr4r2Lt3b7irt3XrVjV90GKxqFfLysoCMu7xE0gIBZoQQsicF2gggrh79+4tW7YoLVaxzuGGXV96 6aXJjumuXr1a+WhTU9Nk1RaCbpRv/JS8y5WVlT6f7+iHnF977bXgmYUS6BwysZ0Egktn1LXFLYR6 9Vvf+pa6OaFAE0KBJoQQMk8EWiVcu+KKKz760Y+q8tNPPz3cGLBY5p133jkpQ1XB1th9CuPHauGV ACwWy/PPP//uu+8ejT1/85vfNK4NjgPt3LnT4/HgoO+9915AdMqDDz6odnzhhRcC5hFu3LhRbV98 8cUUaEIo0IQQQuabQINzzz0Xkgfz6+joUGnsDhw4sGnTpuDKX/nKV0QKy8vLo9TTrq4uo4Ae5Tix rLbtcDg2bNiABvPy8lB42223nXDCCVarde3atUuXLl22bBleRYmK6g4J5FhW/DZ272tf+5qxTsgs fqtWrZKeiHarWwL8vP322wNioLdt20aBJoQCTQghZF4JtIrigDQfd9xxxqWt169fPzQ0FHJpkp07 d052KROwevXqKRhzyDQgL774ooRYRMiqES7Pxu9+9zuJ5A5YejC45he/+EXVc0i5mlm4ZMkStCzb aslGlDz77LNqW7JwQKA5iZAQCjQhhJD5JtCSI3nr1q1wxF27doVcXU+SHCvdPPPMMyO77549e3Jz c1esWBHgqY8++mg06rx3795PfepTuX4gyscee+ytt96qZPT1119XI9DRTxDcuHFjcCgI1DlkzDda xqEDxpjVlZQOqATYalRbpeqTV0855RSOQBNCgSaEEDLfBPrdd98V22toaFi8eDE0+qWXXgoWU6N6 GgdWgzn55JOrqqog36iTk5OD+pBXyf2MRiZU3l//+tfhFj50u93GkOjMzMxo1Pn222+X8eAAli9f blwpMAC1muBvf/vbcKugG2cNynLoKo2J7KvGpCnQhFCgCSGEzB+BlvQRagEUWbpv8+bNWVlZyggf f/zxAPs844wzAlQYh1ixYsWmTZuM49bYUbJkqIgOCHpkhzabzfDds88+G879yU9+Ejp+7LHHigGr JM3S1M033xyhnSeffBJnEXLVbrkHMPYzgKGhIVUz+NJJ/AbuDQKmOaqB6pC3GfwEEkKBJoQQMn8E et++fWqGXMDItGynpaVJhYyMDKhzhLjhaJJprFmzJvKigP/wYyx54IEHsPH73/8+8ij4U089ZbVa g0M1UD8vL+/pp5/eu3dvwPS+AB599FHjjuECx43BG//93/+NyyLbK1eulB1//OMfB9xgEEIo0IQQ QuaJQAOos2jfc889FzCNT0UDyxC1cUwX2z09PZNyaAnqAMPDw3gKDYXLnnvuuVG2sGfPnu3btxsT ekgn77vvvlNOOSXAm/F0+fLld9xxh3Em4l133RXOjFFn06ZNAeYdMoTD6O44BfRHVlVsbm6WvXCa wSP0hBAKNCGEkPkj0LBAMT+r1Ro8sqtsEq8Gh0MsXbo0+mUFjUmdVWjy//3f/00hsd3+/fuvvfZa m80WvJz4hg0bXnvttZB7ZWVlBQi0rB2jbhKM/OY3v4nch2eeeeacc86RK+ZyuSKMW/MTSAgFmhBC yLwSaCDz/ELKX7ChosHgOXkHDhyIJi0G9g0ITY5evn0+3913371o0aKQQRp2uz1k2jvjodXg9KFD h/r7+xcvXmxccdDIxRdfHKEznZ2dJ510knr69ttvqx3feustCjQhFGhCCCHzX6DVTMEAcZQ1q41I dG/I1QFRKLPrIkzRE8f94he/uH379pSUlAg18RJ6vmfPnh07dqg0zMH8+c9/jlLBs6MG9wMR2pEc I+qpitwAvb294dx9luB0OmVyZARwRuXl5caSjo4OKamtrQ2+XHjJeBEUhYWFAbsUFBSUlZXh1oW/ koQCTQghZM4LtAquWLFiRUA6C6MSqewTUhkGPDg4qEavjSZts9lKSkrUaiwhJwsGTxl87bXXbrnl loyMjMzMzHDGjMZxxBNOOEFZWjRnp4I3Ajj77LOvvfZaGT6XI+bm5kaZYRrVNm/erJrq7OyMMPg9 G/D5fLiwmjaBt1RXVwdItvgxNrq7u5t1oMLp6emyDb3u6+uTbbzpZrNZth0OB3YpLi7Gh0FKGhsb 7Xa7yWTCB4O/lYQCTQghZG4LNJApdAEp3n75y18adVNWUVHJ2iSVMp5+5zvfUQk6wo1Mb9myBXWW LVu23M+qVaugVtt0IowH41XU/PznP/+HP/xB+ibOLb47YULo2267LWT72P0Xv/iFcmU1wXHfvn3R XK6ysjKcvmrtwQcfjBy4MhuoqqrKz88/GoGOUEfVTE1NNZYU6xglPjk5uaGhwVjH6/VCqV0uFwQd 21LSrSNPBY/H09XVZSwcHh5G4cDAAMrdbrexTSnET1WCQ2BHp9OJcuwY0GxPTw/6ZuxScAdwu2h8 SijQhBBCFrpAf+Mb3wgOSoZ9GqXzd7/7nXGxPaNqq3wdIsrZk8c45CwxG7CxCIPBkhNaLRYYvKLh eeedF0HNw60UE2VAyKFDh9RpPvLIIxNGfs84EMSMjAzo44wLdEpKSn19vbEO/BVWjR3NZnN7ezs6 iTryPx7YwFPU6evrQx273S6FcNlR//A2zgvl2Be+K4coKipCnYKCAuyCWx05CtpHmxaLxWq1mkym 3t5eFHZ2dmLHwsJCtIMKkHg5VnAHxoRP09BVfp9QoAkhhFCgx3nnnXdEB6GGqjAg5vXll19G4WOP PaYS2xkjg6Xw97//vSgjFNbhcFx99dXLly9fuXKlMWPGpk2bsrKy8DM9Pf3GG2+UVQaBRETU1dVF E0QBMQpY7gR7Pfjgg/ChcOEfytSN7eDo0SyyaOTgwYOqtbvvvjuaqZMzi8fjSUtLgzLCO6MR6MTE xFQDuKRHI9B5eXldOq2trVBVyKt4qlGg0Suo86g/zqSqqkpekk8gNsrLy0tKSqQQr0plNA4hlpHj pqYmfJyw0dLSAuuVAWkcKCkpqa2tTQRatSDR2NICzkUKcQjxY7RZU1MjhdiARss2R6Ap0IQQQijQ oafZGdegrq+vN6rnaaedZox2GBkZUTU/8YlPSKGsPhiSj33sY8HmbUQEurGxMZreqgmOb7zxxgMP PKB6FY5jjjlGNoyZp1U4SvRjz7hVUAPbuAeIZpcZ/wBAE8UIoxRoGGSXgcrKyqMR6OTkZHWR8TR4 EqEItGwPDw9jG72VsGls4Ck+VLgZS0hIsNvtEGUVgIHWcLulbhJQc2hoCJZcWlqqGi8qKpKn6BgM Xim4jIs3NDTgbgF1oN1oQZwb7UDcpQM4UxyX3yEUaEIIIRTo0JInkQx33XWXKlQrjxizQSt9vP/+ +4M1NMIgrrQfYSFAEejbb799UsYfebxZZkYaw6aNs/2mELwB/5b669ati3KXmX334ZQwQvkfALx9 2MZGX19fBIGOXQhHSIwCLYpfXl5ebUCGk9FniG9aWhqMFr4rjcOnZUdINnbE7iiE8avGy8rKpAPo mArAQJuqVz09PThcSkoKTLq9vV06UFFRYeyAuDWhQBNCCKFABw6syiDuDTfcEJzeLiRLliyR8WYl 0DJEHQ4Jkq6rq4ss0BEqqCUJr7jiigmHnFHh0ksvVUKPExSB/vrXvy4lDz30kNTcsGFDlMEbqpEI twGzTaAhf81+cG1hh9gICKKYPQKNT5TJZJIIDdDf3y8hFjBmpb81NTVydLSsBpvhwdjR6/UG9A13 DjJKHVKgGxsbJRgalJSU2O12tACT7ujoUB2ora3ldwgFmhBCCAU6tBrKcOzll1+uCo0L7EUIKV69 evXGjRtFK7dv3/70008HJ6oDeXl5qPP666//Iwwi0N/73veCs93t2rXrS1/6UoT0dkYsFgsEKNxi 3egtti+88ELV/8iJq428+eabstc999wzVwTaSEAIh6RwnlUCLY2npKQ4HA68iXgrRZEbGhrS0tLa 2to6OzutVmtFRYU0DtnFSxDujIwMCVMZGhpKSkqqrKxEszjB5ORkCfkIKdBVVVXyaQFoQdKD4FVU lg6kp6eraYiRR+4JBZoQQsiCE2g4peS1MAq0MTZjCuTm5m43oAaGsZ0ThKoAo4XpQmvWrVsHpw+5 znZIj4dXXXXVVRHOUaVtNlr4Aw88EL0KS6g3ehvliPVsE2iopFFna2trZYKdEZQEjLl2d3cHlATX UTVFbRVNOpF75XQ6AyQbIp6fn19QUFBfX6+yy6HQbrejXBViLxwOho1C41EGBgZQiLcJr6qc09hW +TTQf6mPdtAaDhTQQsgO4HCqBUKBJoQQQoE+LNDXXXfd1Bbwm0E+9KEPRXmaAYntLrjggug9WN1O RDnNkUt5xxpjDg1CgSaEEEJmQKDFDuvr64OzO882cnJy0DGfzyfJfT/84Q9H6bJer1c1cuyxx07K g//whz9MOFGSAk2BJhRoQgghC0WgVXa2++67z1h+yimnzB5vPuussxYvXvy3v/1NxUbLaiZJSUnR 3CGoKBGwZs2aSXmwSuJx/PHHfzBJ+AmMEcPDwwELEBIKNCGEEBJXgZa8Fn/961+N5ZdeeqkYZ0lJ yUx5M8w+Nzf3L3/5S7DyLlq0SFYLj2zDe/fuNWbtWLVq1WRHkR9++GHZ9+2336ZAE0KBJoQQQoE+ nBTZ4/EYC3ft2iXi+M4770STAWMaB5svu+yyl156SeXiCMnXv/71yOtpY98vfOELxpZ37NjxweSR 4XlY+BT25SeQEAo0IYSQ+SnQIdcTUbHRxx133PPPP6/s9igTdIQ05k2bNl155ZV79uzB0y1btkQz SKy6ETIzxqFDh4zSj+3g9HbRkJGRIS0MDQ1RoAmhQBNCCKFARxJosGzZMnkJPpqenq4E+tlnn1Ur Wj/zzDMf/vCHA5x4+/btn/rUp4455piARU/OPPPMm2+++eqrr77pppseeuih/fv3SwyJHM7tdkcv 0KC0tFSavfbaa43lt9xyi/GgeXl5kw3bCLDnk08++YMpwU8gIRRoQggh81Cgd+/eLdHGwZb5xBNP iEEuXrz4wIEDsu1wOPCSZL5T2o19IdkS7QDtNjbi8/nUYDCEO4LLvvTSS5PKtawGoXNzc2UXHGvD hg1Ge/7yl788NffNysqa7GqFFGhCKNCEEEIWhED/7Gc/U0PLwYaq0iergeqzzz7bKK/wS1V/xYoV IVf4U+1s3bo1Qk86Ojomu1b2mjVrVII55fSC1Wo9ePDg1MRXpfALeV9BgSaEAk0IIWRBC7TFYoEp nn766SFf/dGPfiQqefHFF8NQZYFAeUkSyRnTd9TW1krJT37yk4B2+vr6JkylLCofMphkwviTgNwd jY2NUxNfo4gfpT1ToAmhQBNCCJmfAi2+mJWVFU4oJUeH8Prrr6vR5ddee00FGQekTA4Ow8Be0s4T TzwRrid33HFHlAKNxr1e7w033LBu3bqA+Yi4HwhpvSh86qmnAkbH9+7de/nll9fU1Kg6GzduVE19 cNTwE0gIBZoQQsg8FGhx0O3bt0ewQGNGC9RctWrV7t27VajDOeecoypfeOGFUu1Pf/pTQDsSnXz+ +eeHO9DQ0FBkgYb7joyMnHTSSQFzE4WMjIyQuzzyyCOof/fddyuxxsY111yDwvT0dFXzrbfeUrcK eCkgCoUCTQgFmhBCCAX6iIHhhoaGCNXee++9CCt7Q68hqTgcxBSCK4XBMSGS02PlypURdNMo0O/r oBA/b7755o0bN4ZMR42Ofe973wsedcaOq1ev3rZt22uvvWYch4biox3sNTw8rA4kC4OrGZNHGblB gSaEAk0IIWTeCvSof3TZ6XROGDXxk5/8JOTQr9Gk1aw+Uds33nhDtXDDDTdEyFK3f//+a665Ru27 VQf6G24NF5SffPLJu3fvDjn3MSsra9WqVa+//rpx1Pn666+XGO4//vGPqhwtGGNU7rjjjg+mD34C CaFAE0IImYcCrTI9RznHDjUvvfTS1atXG70zmtVSJlUejs2bN+/YsePFF18M2b2RkZG0tLQVK1a8 +eabRnWuqqqSNCD33nuvUbitVqtqOTMzM8qLQIEmhAJNCCFk4Qr0/v37p5D4wrjg35133rlGZ8uW LSrn3bQsT4jWNm3ahJahuT/+8Y9lpfFwwRU4kVNOOQUSbFyQHJWvu+66nJycjRs3Pv7448Z9r7nm GuXu2LjxxhunK2yDAk0IBZoQQsh8FuiHHnooyowTzz333ISD00COC53905/+1NTUdMUVV6xfv37R okUnnnji8ccff+qpp4ptn3766dg+4YQTkpOTU1NTd+7cWVtbe//99+/atcvn80kj77//fjRSC2PO yMjIysoaGRkxxnafeeaZMmIt6x2qTt5zzz3GsXM49wcxg59AQijQhBBC5ptAX3nllSGzzr3yyivB Q7wfzCbQ4d27d+fm5h577LEqY4bMYly7di1uCZYtW2Y8KWzD6Y1j5Dhr43A1BZoQCjQhhBAysUAf d9xxIdc3+exnPxssrOvXr3/vvfemRRyljvxUQ87Ri+k3vvENqPCll15qLPyP//iPLVu2ZGVldXZ2 BqjzY489tmnTJmMmvieffDIOls9PICEUaEIIIfNNoE888UQIpcViCShPTU0NDp+A6W7duvXaa6+N MlzY7XYPDAw8++yzjz766G9/+1v8fOqpp/r7+3ft2vXmm2/u27fP6/UeOnRI0tWh8QMHDkQecn79 9dfhwcuWLevp6VHlzz///BlnnAGfvuyyywI6hqctLS3GgI2cnJxf//rXsQh3pkATQoEmhBCyIARa Ft47+eSTA8rDRUXDdDds2AAN/eUvfxkHDZW4aqfTuWXLFlj+bbfdpl5644030En0ZPv27SMjI8Hq /K1vfcuYdA8t3HfffXFT50kJtMfjGdRRg/EKlOBuAXca0bTjcrnQVLhXh4eHUQF3Nfg5Sz6fODuc dXD50NBQlKccEuyLFmb57ybehWE/FGhCCCFkLgm0jM4GCzRE8+DBg+Gktr+/PysrC/sef/zxjz32 mGjudBkzfu7bt++ee+4544wzbDbb8uXLd+3apV599dVX0dvNmzd/6UtfGtWXbglu4ZJLLjFmx7Na rc8991yc1XlSAt3c3JyYmJiamhqsfeh8WlpalMqLk0VT4V4tLi5GherqavycJZ9P2LOmhbApXIqu rq7Jttbe3t7R0YEN7IsWRNArKytn5+8m3oViPxRoQgghZO4JdMhMFD09PZDjyLv//e9///a3v/2R j3xk/fr127dv/+hHP3rjjTc+++yzKJccGgqoDNy3t7f3vvvuq6+vv/baa6+//vo77rjD4XD8z//8 z8UXX7xz587Pfe5zVVVVjzzyCHYf1bNwKKVuamrasGEDDvTXv/41Qn/QAWMuPPi31+udwZmO0Qt0 SKmFT5vN5uBh6akJdFlZWUFBQW1t7ewRaLw7IUV5agKtTt/tduPTG0HQZwN5eXnl5eWlpaUUaEII IWROCnRWVlbIV//yl79s3rw5/mO3os533XUXjv6pT33q97//feSUdjjTjIwMozonJyfPrDpPi0A7 nU4ZSQVtbW2dnZ24wZAhVZxdQ0MD3AtP1bi1Msi+vj7cpQS0hvqojHbE2Dwej7RQUVHR39+vqrW0 tKAQtm0sxDaqwfZwwyMlaF9FX7TpjOpDv6hQU1MDNUT7UH/c+cghBgYGgk8QpltdXS3bw8PDOLuS kpLu7m6jQLe3t5fqoFxKcHY4HMpRGS1LN1CCvXCHgB1RIqePxiHQ+Ik7N/xUYSG4sDj3gM5Ib9Em Oo9DqHK0jEJckIAO1NXVoSbOV85dQAs4ljodnDvuWFRcDXoFs0dr2As9b2xsRIm6AhRoQgghZG4I tKR12759ewSXXbx4cWZm5uOPPx67QGfZ+OMf/7hly5bjjz8eBiZLCU7o7ujeGWecYVx+5dxzz1VZ 7ea6QKtQhFE9ACMpKQk/IW1QPdTPy8trbW2Fh6WkpEiMhxLojo6OwsLCYFuFaku8NZ6iAnRTTM5k MkkkLtzOYrHAofEW4CZEXBDOhwooQXl6ejqMcPTIQWIVhwAXRCfRLHxXDoFPDjqJfVEObQ3okhoh Rt9wFpBUVLbZbImJidI4JBXlsFK4JvqDV+VyYTs/Px8b+JmWloZC2C36hv7DbtV1w15oH9VwfVAi u4/qg/G4jAGdwXXIycmBDaO36ID0FtvYER2AcOOgsHbpAE4Hh8bhUB89VFcYO+KkcDFRGRcBR7Tb 7Tgj+W8ENIVO4tAoV/HosycknQJNCCGERCXQ4p1LliyJXG1kZOS8887Lzc1dunTpV77ylTfeeEPU dlKD02oXCO6rr7561113wbROO+20yy677E9/+pMxYCMaYCRr165V6ow7gS996UsfzDKOUqBFEJWk qjrwYxlil6dQtKqqqtGJQjgCUCo8qg+yQuZEZ9W4MmwYLUv7KpIYMg2pjSDQorOj+jBtQkKCmiEH Zw2OVVACDdOFakshhBI7onG8xfBUCWsGkM6MjAy5LCqyZWBgAC3IEK86fSXQxhAO9E0uJnbE7sYx ZkFiKqRZHFRmZEKI1cCz6iSOom5sUB8CLZcCni3vkTHQHBVwTcS8sRca4fcSBZoQQsjcFug1a9aI fUZvwI899tiWLVu2bt26bt26rKysk046CX6wc+fOyy+//Lrrrrv++ushc/iJp5///Oc3btwI54bp QsLuvPNOp9OpMklPOTIEO9psNqXO6AkU/INZydEItPiijAEbJXXUP9CrroCELkxWoCHN8Ei0U1RU JHqHnzBX1SwMWzQRG2rsVhFOoKUno/6ZkcbW8K5JJwVUUIIbEAosjcurVqtVrRkplbGjNDVuY37p jyzQ2Bahx4lbLBaxZNUZ6DL2wm2JyWTCZ1XOFxcfu6sPG/ZSHTC+X7i7KCkpwQZqSgfQAqxaNY6L LHEaU4vtpkATQgghs0ugYRXyN/5Xv/rV0WSaC5gyGLvY6GuuuUZl2MAG1Hn2BGxMr0D39PRAoJW5 GgW6trYWWjloICCEI0p8Pl9nZyfkD2bpcDgglFA9Y7MSXQ33Vc16vV6JZg4n0KqTLS0tuLMKbq3a j1JkFJaXl4cT6L6+PmMjwZcrSoEGOTk5jY2NUHyJkEbLqjNut1vqdHd3ozPQ6IaGhv7+fuyOn5E7 gNtC3IrgsmAvGQsvLCzEVTXuJe1ToCnQhBBC5oNAAxnh27Zt24wkeotenW+66SbjNMH8/PzZrM7T EsLR3t6OdydYoOHWEmsrT6FrYoSTEujMzEwVnICLWVNTMzw8jGZVyERlZWVZWdmoPjxcVFSkuirD t7DqpqYmsXCIfrBAi7yqEXQ0EpxRTgkuzjQ5OVnsU8Z9RTRRqGb74XAw4MgCLV0KEGglx3B6m82G m4SQqZdxEdQUSegvOizBHuqSoicyvh78fqFZ9E3GoaUmbh7kdPATV0xOhwJNgSaEEDJPBPq9994T JV27du2MG2fweij4CbMxriaYl5c3m10/dpMIjWO05eXlcDtIHtQN/ipGqATaGKQbjrq6OrQgue1S UlLEQWF+8EuIIArVtL+hoSG0BkFEB2C0nZ2do/rsOgn/gIjD8oMFelQfKUcddBJvGQ4RnIjDOEJs t9txIqgMNcdeIpoQa2zjDgHNmkwmNYcvpECj2zgKzsuYBxq7o1mJePZ6vWhEBZkE0NraiguCRnBS Kki6ra0NuxTpYENuOYLfL4g7uqFuSHAgiVrB6eDo+ACrSYQUaAo0IYSQ+SDQ4Nvf/ra4aW5u7oy4 KQ66e/duaJZRlM866yxJEqKe7ty5c66o87QINLxQebBTx/gqDA87dnR0qETRKJFYDvyURMiRQYMt LS0Oh8O4fiEOikKZVqgKYYSoJrkjVCEOgQ6gEewifVMbxkOgDloLubJgQB5oqDkOLZ1XR8dTHBdH V4fGhnEKIFqQxvETho0jqjzQYv8oVPtaLBax8JCg/606xnOfsAOjYRJaowTnrqxarpixZQo0IYQQ MocFWgVygIyMjLhJqqx3aLfbIe7ZEbnyyis/mINEL9AS0xywZgpELTExcQGmOYsFuLxNTU24IYl+ YRpCgSaEEEKBnoDly5crYf3ud78bO41Gy263+8ILL9y+fXs4Y966devGjRsvuOCCyEuozA+Bdjgc qTrBS3mXlpbKxD5+mI+S4uLilJQUiT8hFGhCCCFkegQafO973zOGTCxduvRo8s0ZpwCiM++8886O HTs2b94c0pjz8vI++clPwhfffPPNUf863nMdfgIJoUATQgiZ5wItcwrXrVtnVFuY9Nq1a2+55ZaD Bw+qlVCCZ/tJuRJHp9P57//+76eeeqrNZlOJ54xs377dZDLde++9Xq937o4xU6AJoUATQghZ6AIt NvzCCy/IGivBbNPZvHnzmWeeebqfjRs3ykvGWYABQKOzsrIKCgqefvrpaRnYpkATQoEmhBBCZoVA G0MvCgsL169fnz0lcnJy4NbnnXfeXXfdNTIyskCkOaRAd3R0lJeXT+1NbG9vT09Pl1Wsg5Hl9Pr6 +mQ5PTzFWxZcze12q5TMkqci+g6UlpbKvj6fT+WljhJ0RhJWSPdmwy8F+hPyEsWBzs7OysrK2tpa fBiam5sDulFfX493OUKSEAo0IYQQMgcE2piMed++fbfeeuvq1atlUWVgs9k2bdq0ceNGeSprHRcX Fz/yyCMLU5cjCHS4RHXRgKtaVVUVnERZaG1tlQzEkg45XAbovLw8WU0aJCQkTGpWIhqUPHE4it1u n1TnKyoqJLGdytY84xiza8eZsrIyvF8lJSX4MODtSEtLC7jJaWxsDHenRIEmhBBC5pJAk+kSaBhS R0eHMYUwnNLj8XR2dsqQsM/n6+npwVO1VN7Q0FBKSopkJsarwanu0Bp0UBYRHPUvoSJtqlzI2Ndq tZaXl6MaGhThhhO7dVCCXhnt1uVyqSFqNJKfny/b8HhZ6g+gKeyFV6U/aM3YAp5KRhH8FPkOJ9DQ a7Sjbg/Qc2M17K5yVPf39xuPKP1E4yhXF1DqqM6jk9gdh1AVggVadg93fwLwEioY81sHv00oQVfx E43LZTduK9LT09GN+vr60tJSh8OhLqzx8zBTck+BJoQQQijQs06g4cFpaWl5eXmyON+4SWhaTk4O XqqtrYUOZmRkWCyWgoICs9ks/5VfWFgIM0YhWpB1+wI0FKImqw82NjbKgWTtPchZcnKyKJoUwsxw FDSIRuDTMO/q6mpswOpk7T1pYVQPt1DD1dhQ5ZKselTPu4cG7XY7Omaz2Tw6JpNJ3RtgLxmrVmvv hRRoWTsQXcLPiooKUV5sy/LdsjSgiKn6/w00iLMTKZdIoczMTLyEk0UL6CGeyi3EqJ66Dt1DCQ6B pkRnjesUyqHRVeyO24Pg3yC0iR1RDRVkKXLj24RTRidFfFEBx5LLjvqy2jy2ZTl0qSMBMHBx9EFW eAkWaLRJgSaEEEIo0BToMYWFGEkQcHd3d0JCghLo+vp6kTnYpAqKhVrBvUQTlYOGHIEOAAdC4zJc OjAwgPbloEYnVi6LEniwDKP29vbC1MU7jSPQcD4ZnUU1qLZsoKZKqAxNFPeFrcoGwK2C2GEEgYaF Q17lQDgizlcW7UPLsmg2+tbR0SF9QzfUULdaUhsnJZqOl0RzpWU0JTuiSzBd2bGpqUn6rwS6paVF qTY6gMOpMHEBwo1CuYDwXTSL3hbqSAUcBZcCF0TubXBGshe229ra5FhoQSrjPkS9BeFA+9h33i/1 QoEmhBBCgSaTi4EW2RItw4aKDYBNFhQUVPvBS+JzykGjISAGWmlrOIGGYqrK6IB4p9HnRDpFN2Ue JNQQ1qj6CYHOzMyUGwO0oDbEAiMIdGlpaUZGhmoHzl1TUyMv4UA4hIz4ChI1AQmWl6RNnJQKKcG2 jMQDm80m2zg7uT8R70cf4MFKoHHHAr1WHZARemMP0Z+8vLyAK4xqxpFjWDUuiLyn4uLB21ITb65x We9wFBUVoWPze/lJCjQhhBAKNJmKQItNGrXSZDJB+KoNyEsxFWhjbhDsKOOmitbWVhWBgL6JXktA iLGfSlIhwZ2dnTBj5b4RBBoNWq1WYzvqNOvq6lBfxVRIZDA0Hb2Fx8NZlUAraQ65jUOoQq/XK31Q Ag2jhWqH7ICAkuB8HWaz2VgNTTkcDqMoh9zGDYC6qYgM3gLUNAbKU6AJIYQQCjQFOrRAwybVEKzb 7a6oqJDwhpgKNAxSCl0uV2JiYsBcOgioGm1VuTjgdgkJCWr+HPQRUivbtbW12AWKqYbVIwi08eij ehI3iVFG+7iXgKxD02XIFjqek5Mj1TweD44evUCrcHOYPTomc/vkEhmbHdXHmwNCONCIGoAHMHhc H7xNaqAabxA609/fP6FA46DR5M5D9xbCyu0UaEIIIRRoMj0CDROFODY0NED18vPzVX3loHDcCbMp hxNomU4n7eAoZWVlcFwoLPyvqqpKkkkXFRXJXpKleFQfUZZQBJilMZgB3gmPhFu3trZC+GQi3age KAwLN+aKDhboWp1Rf9wzBBcV4LLYlqwacNa6ujpUwKWQGOXGxka8isuCfuLKqKl70Qg0+gM1b2tr Q7NyXCXQMmMPJ2vsgPRQBuZxaNSUHuInBBqCK28TuoTTx5nKZZlQoNG+ijaJAOqr+Pho3m4KNCGE EELmLd3d3WrYcnh4GGInI7hqQ4CowWILCgpqampU+jaVStm4Y4QDqZl8xvbRAhRQYi1gkyhHTQg0 DodjwUrhrCrAAF1FHdiwGr41DjOLWaIO9sLuAakk0KaxRHVe9aRJR/kiKsBBIawy+C0rzqie4FX0 BE/RPVyWkpISdBvyKgKNPqio4pDbMq8RdwvYV+k1+qMuETqAw0kH1J0MuqfeLPgrKuNMYcBqYiVU Xt4mddHkrTG+vwHbuJKS129CgVb3P9jXYrHMy9FoCjQhhBBC5ioBkwjnHxJTPoc63NfXp1ZX8Xq9 cHR1H0WBJoQQQgihQFOgj0DCb9S0Tp/P19/fPy/fFwr0DCPrHhmZlzdqhBBCSCxwu92RA0LmOjg7 FXcx+4HGBKxcOF+hQMdWjvv6+lpbWxsaGqqqqnATmZOTI0sNadFhNpszMjKys7Oxb2VlZX19fUtL S29vLyWbEEKmkXm/6AMhhAI9e79/ocvNzc0Sqp+amhqVIydqWuqRD1NU+8HCZcZAY2Mj7vYkLw8h hJDJ4nA4gpcjJoQQCnSs8Hg8HR0d1dXVOTk5JlOQ+SZoWoam2TWtTNOqNa1Z0zo0rVfThjRtNLqH S9P6NK1T37dG08o1rVDTLLp2B3h4YqLNZqusrGxra5tD/9dDCCEzbs8JCQkBqXPJfEJyYkT/eYiQ cw1N9fX1detMS998Pl/041/Nzc0DAwPoYUCia0KBnjPg96empiYzMzNQY9N0wa3VtDZN69c0X9Si PIXHgKa1a1qdphXrSn0k6enpkOnp+g0nhJB5SUNDA+xZLUlN5h+SJlmt7TIhkRd8kZVcinWOvm+y xnj0Kd7wQZUpeiqZHaFAzwFwmyhre6akpBwRgGHVtArdmF2x1OUJH259eLtK07KPCAIxm834PccN K8OmCSHESH19/fh/FvoXfSDzj7a2NrWYy9ELdEFBQW1tbZnOtMh98NKGEZD1ty0Wi1rzhVCgZzX9 /f3l5eX44B7WUih0iT4A7J1RaQ738Glalx7vkXa4y7gFLykpWSBzYwkhJEp7BsZF78g8o7m5Wa10 XVhYiPc9KSkpPz8fT9vb2zMyMvABgJJ2dnYGCHRFRUXwstV1dXUdHR0tLS0yBux0OvPy8hITE3EP ZrPZJLICG6o1VEhPT/d6vS6Xy263S6in1WqVzG7YGBOKlBT8afZ4PPgbjb6hBL2S/0AeGhpCa8XF xdgRvS0qKkI7EJL5mhiOAj1PcLvdjY2NR8RpZOhDvL2zUprDPZx6SIntiOgO3EDz/ysJIQsWKIgx 5m1SI5RkboG/4yrcAm90Wloa7La3txcOCvGFDYtJw1xljT0l0G1tbRNGSkDNZcVBKDJMWpY8rKys VMuJSwIubMCesSE14eVi8MYRaFlKEK+iDrbh0KqCLNPN2U0U6DmA3OHhV2v8yzVJnwU4t7w5pElX 6mPn/v+yxC+zrE1KCCEL1p5B8EAjmR/AR6GqDQ0NSqBht7JdUVEB/VUrMNhsNlkhPHIIRwADAwMS Hok/pkqLUWgymaQ8JSVFWoOdiwHjVXwC5Z7NKNAuHalZW1sr/ysiFajOFOg5AD7Z0EqZUzJGjqa1 ztY4jSlHd7TriUH8p1hQUMDp54SQhYCM7QVnBYVL8eLMS/AHPTMzUyX5hraqQWW8lJSUlGpgCgLd 3t5utVqhy5k66r8yoOMtLS1oR0UH9fT0oCaOaLFYIO7BAg0FRzkqZGRkSCZcVYHvIwV6tqszVPJw +rkiPX/c6Px9DOjD6omH/weTGk0Imd/2bLfbQ6bVF3Mi8w+XywUrbWxsDBZo3Erh86Bq9vX1yXKG 0Qu0x+NJTExsamoSQa+srFQCjUIYRUlJiVqC22w219TUSMa6hoaGYIGGN6NLMm4NL6dAU6DnAG63 u6KiYnzUGUJZqsvl6MJ4uPS4jqTxvyK4I2dsNCFkXtLd3R1uFViHw8HrM1+BPasQHaNA4/OAv/sy 20/iocWblUCjgkRIhwPCjQ+PVB4YGMCOSqDhwWYdkWMYNo7V1tY2qkdowJXT0tLGJUzT0AeIdUpK ioSawElkVHtCgUb3mKyWAj1jAxL41RpPr5GgJ9ZwLRh1DkiBVzk+Gi35MrmuISFk/oFvtvr6+hNP PDFAoJmeaB4DY1ZeC5M23izhJWhrso4apbbZbPJ5CJmFI4Da2lqJA8Fe0F/8VC+Vl5cbd29qapKa kGMcCw4t49byX99Q4fb2dtgIKlgsFkn2DEGHbUdIEYP2pyUdNaFATw6n04mPqT+CYb4HbEQZ1GE/ nNSJ97WEkHkJxAjfcv/v//0/JdCSfoHMS+Cm8zXLSl9fn5oTSSjQcaK+vn48yUaqpjmme5aeQzfR NE0z6+3b9WVWYuq+zdN3D9ClZ+vT03Tgz4yae0EIIfMAl8slX/5PPvkk/hBIUAcvyzzG6XQmJSWp Aeb5RFNTE6MuKdDxY2hoCDej48MOJZrmme6QYqs/851dX2Tb7l8X0B7Llb2r9UN0Td89QNV4mg6L xYJ7XP6eEELmB8XFxca8dV6vt6WlhZdlfuNwOBjqQCjQR0VXV5cs8zM2NtwegwxxsuhK5ZGZ79z+ 0IiaOSLQ8ugZX8gwMTGRf2AIIfOAvr6+hIQEfKfJinGEEEKBnpimpqbxVBv5mjYcA4tt0C22NNRL Xj2Wwxw0CD2sr28SrjNe/dXB8L4+4J/1GAuBHtWH50vGB+urqqr420IImdPIfz8y6zMhhAIdFT6f T2aNjA8Px2gYWGYkhsvj0akLrhLoviOW1x7b7j/SXMsPJ2keM++mI1tr1AvVai+lsRFodayE8cW6 JEUlIYTMOdrb28fC65KSuK7b3AXvnWRrnhqygnfIl/DXbWhoyOv1SuK5mQLdmEJYsyxziB1xcfAz 5DnKqQFm2aJAT8Kex5PnJ+iT7WKXCU7TQziiXFXbpGnJupt26T+T9RKVfzpHb61M1+52/9Naw5RB kKdpHfrDH9EdK4EW+9cjuW02Gx2aEDIX/xCkp6dzzZS5TnV19ZSjmbGjyWSyWq0hX5XMcV1dXTM7 qdSYdC960HNcGeyIc+zo6MDT0tLSgDo9PT0oT0hIiH6dRbKgBfqwPZs1rTuWeTB6dIUtjK6yhEQb k2b0ybLa+na7vl0eFF2d6B/eTtGjk72GSI+0GAu0SH8aHZoQMidpbGzE11daWhozCy1YgU5OTo6w MEpra6vkb51ZgXa5XFOYuG+xWOrq6vLz88vLy0f1xCPhskdPaqFysnAF+rA9mzStN8aJ5Lp0hS0K yi4XgAyBm/SYjYAWbLoij+oDz1rQaohNemGrX7UrYz+JMGSOkRQ6NCFkjuF2u2XBLFkKjsx1gW5p acHPyspKCefA+4tyeCEKZQUD/CwrK5OaakdZbRfVBgcH8TQgkqe/v99qtaJQqSdK0EhpaSlaq6+v l/qy/hrawUvGSIn29nbURDlaVkEmqhvYRd25DQwMQHNR2NDQEHw7B3uWtRKxgY8rtlGzpqZG/c3F Rm1tLQrRpc7OTrHhoqIidKCiokKy9eEEExMTKdAU6KmDDy5+YT5k+lBsx57lMeQPZR49cly52v8o 8Au0S1bNDmqhWC8f1GMztDCCXq3HbGhBsSjNcRFoGYfWl8LNycnhQA4hZE4A0xpbL2uerqax0ATa ZDLBFyXUQVb+k/WuMzMz8UbDDqGSSUlJdXV1DocjIyMDu4zqoRFjQ0+VlX062Dc41NjpdIq5jvqz R2Pf1tZWNAIfldhou92OA6FlSC16IjKKOikpKTgElBddwt9HaSc5OVkK09PTpRtwbmkWLaBa8EqH KoQDG6hZUFDQ0dGBg6o1DvN0sHtJSQk6IM2ibxIDLZaPn+HG0SnQFOiJwc1Z/Ox51B9ZkRg+sXRz dALt1pOEhBPoej0cWQuaUxg3gTY4NO5P+PtDCJnlyGgcvrJ6e3t5NeaBQENnZRuGKpooAq1Wz4Xg qkh3CCvefRm+HfsjGbU7lugYD4SjSGtq6LqqqkpkF4qsWsaGjGHDqtPS0mSRS+i4fPyg/qpZtIPW Aib8GQUa/i0T/vDTbDaj5Z6eHkiz6oDVahWBDgb15X6AAk2Bnhz4kI1nrGuL41LYVZLvbSKBHtWX WbGESuJh0jfKgyKkR3V11vQ1Dp3++YXGV2vjKNCjejyMniEEXxD8FSKEzGYKCwvHwuuKingp5odA q1Fb8Wa1obJnyBJg2X7G/pzqg8qTEmjs2NTUpJ7CKNA+pDY9PV0VynS9UT2uA5WLi4thtDBXKYS1 5+fny9B4TU2NxHWk66i+BS+zYBTogoICY38aGhpQaJwEWVZWFk6g4fTQ9+B0HBRoCnQk8DFNSdFj dSviaM+SiCPVny7DF3p97HGBlsHmziPTXMhqhSHDqT2alq47q2SMTtfnRLriO4kwOLcdhN9kCnmP Swghs2QwRVaDkoFAMg8EWk0iDCfQeLtbW1sHDcg47qQEOi8vr66uTrbhx9K+TDQ0Sqo8xe0ZLBl2 C2FVI9ACPnj19fUZGRmoMKrP9oNMG/sWMKHIKNDogyqHN6MEHTAaPI4bTqArKiqg78FhKhRoCvQE n/vxcGRffAXakKpiTHAL9dHoEn+JDBt7/QHTkrdOYppr/FnthvztFPmTcrTpzp15ZNhGl56SL01/ qVV/1RR3gfZ3Et8LDIYmhMxObDYb14FaaAINB1BJ3CCLaWlpASEckhE58l8uWC9kV3aUFC7YBTac kJCgYoGKdMRKZeafmKv0CiV2u10Ku7u7ZVZfeXm5mkGE1rCjLIopKZxHg2KgpRB1ZPlMVMOGBKtg W8KpQ/bfGGpCgaZAR4XD4Rj316G427MaD673K6+Qoi904jyy2oDux7JUSqJu20NH5q2rHg81Hk8v 3RY0pG3xv2rXx4NT9VR68TxTGRfXtNraWv4iEUJm55+D5ORkrpyyoATa6XSmpKTAU1HTbDY3NDSM 645foCXZc+QFUyDZaAHtZGZmShyI1IdYQ1vRMu7NVIgzpBliKoO+ErYB84b7ohA2X1JSgg0Zz0Zh RkaG1WpFC/hkqkUxJYXzaFAMNCpjd5yF+jvb1NSEDqAF9A2KH1Kg0StOIqRATw584vHhGHO6xhmy 5wCTHjRka46QGy5yWIg3osJ6Z/Qc9ciT45KOm8LKSYQQEtM/B/Cbsf+6M0SykrkOLFbFDeItViPK 2DAusIfttrY2CeRQhaijklQE1A/poKg2MDDQ19cngq5uwyQYuqOjwziG3dPTg0IJtu7u7pbKOASq odwY64i9UNjS0mIsxI7y1CjQ2JBjqZqyXCIax+GwbYwzCbhKFGgK9OSoqakZEzrLTARvLNiHnp5v ypntCSEkFkAsGGNGjubzI2mhIcFlZWXh1i+cXnC4qqoqCX0OuSTh8PBwQkKChHBIRo6Qq3Y7HA7c PQbfUkKsU1JSKNAU6EBcLhc+TDMQCrzAHwPjgShTWDyJEEJiJCJJSUn4Xoqw8hwhEfB4PPBm6GZy crLdbo/PJNTi4mIcUT60+CnLCgbQ2tpqsVjw8c7MzAyZCAvmjUaCX5Ls14B/rCnQgcg6Q+OrYfMR z4eedy84ITwhhMwIMA9Z74mXghBCgY6EpBkf87huGm3cH0NjWUESEhKYKIoQMuMMDAwk6IT8321C CKFAH6atrW08+pk6OyMPO9NxEEJmBQUFYzMz1HpvhBBCgZ7gG3MsfxxddkYe7Zos/sTfKELIDCIZ ykwmE1MDEUIo0BPg9XrHpw/GJ/fzoD5P0RVmIZUuPbWcV9+I8HD6K0d4ePU0dsHl4bLjDetrfdfq NxLtepK7uAm0b3wxl8iZNQkhJKbgNh5fRDU1NbwUhBAKdFRDDmNrZcdHFqsNi3IHPGSN7kH9EZli f+UIDPqX9Q5GVjH0HdmrxCPrJBkWL4xXFAdTrhJCZormZnwva6mpqZFT/BJCCAV6DMn3OZYLYvYI tEevoB42vbzOUNKtP9TTSm18+XHjXh6/QBccWV6rrzuo6WuAy3Eb9KdWfeB5UB/bbvUvId4er8tS rzHukBAyU3g8nuTkseVbW1paeDUIIRToibHb9cHPltkk0FGWG5fmlmHpkOXVoRJfJOorlsvTTH1M 2hOUoTlBl/L4XJZuhkETQmYMyWQanwUvCCFkPgi0BL1pvQtJoEWaNX8odqqmJYeqU6lpZfG6LG5N 5u7wl4oQEmeGhoYSE8eC2GSRNkIIoUBPjKw4NTaFbkEJdJo+wCxh0IX+3QdnNBeHvA/Dw/y9IoTE k+LiYi7nRAihQE/yHITR+Aq0zT8R0PhIi4tAe/19UMsuuvQ5lEK6ppXqMdCeuAt0KhNxEELiTW9v L755EhMTBwYGeDUIIRToqPB4PONZKeIs0GbdFwMeptgINFrO9j/S/Nk2ko9sEFbdqFdI8Jt0oj6x Mp4abR07bE9PD3+vCCFxIzsbX3xaZWUlLwUhhAIdLS6Xa1xnR+dvCIdRoLP1gee68CErHj3zRplu 2CAvjldm7K+Y1tXVxd8rQkh8cDgcY+MJyclut5tXgxBCgZ7MOcxICMeMx0AbFzEJubSKxz/RsC+u IRz8X1RCSHzwer1paWORc42NjbwahBAK9ORISNCjFrwLVaBb9TqNoV5qDt/VWDxSGANNCIkfsghA RkaGz+fj1SCEUKAnh4xAjK0esjAFelCPe84IFe5cFscRaJ//fwIIIST2DA8PSwqmjo4OXg1CCAV6 0uTl5cV1yb3ZJtCjetoNWcy8RT+KW8+KLfacE6/L0j92NNzM8JeKEBIHysrGvuPw/c9LQQihQE+F ioqKI9a1XoAC7dMTbqj8G4q8OKbHbtET6xUU8JeKEBJrnE5ngk5/fz+vBiGEAj0VZBZ2/NJN9On2 PBBmOevmUKEU4cpHDYmcm/VqIcujjMEY0ivDtqs0rTaOcwcNo+A1NTX8pSKExBr5j8fS0lJeCkII BXqKDA8Pj6c99s7oOnwL/JHKJNCEkHjQ2dmJb5ukpCSue0oIoUAfFVarvoZHG0V2hh56ALTZbOZv FCEkpvh8voyMsZVXa2treTUIIRToo6K+vv6Ipa35iPNDj0Lnf6cSQmJNU1OTzFf2er28GoQQCvRR 4XK5xrJBJ+hBw9TZOD+846seMn6DEBJT3G53cvLY101rayuvBiGEAj0N2O32MYmrpNHG/TE2HqRZ LBb+OhFCYkpVVRW+bWw2Gy8FIYQCPT309vaOeZyJg9BxH37Wpw9yQIgQElMGBwcTExPxbYNve14N QggFetoYH4QuptfG8VEzPvzMpXQJITGluHgso35RUREvBSGEAj2dDAwMyPiE1kO1jctjSM8eqGnd 3d38XSKExI6+vr6xbKWJiYODg7wahBAK9DQjEXKaVV+cj4Ib64c+4l9YWMhfJEJITMnOzsa3TUVF BS8FIYQCPf14PJ6UlBTOJozHo1mPOTeZhoaG+ItECIkdHR0dsnKK2+3m1SCEUKBjQldX11hKO9AR L5X06Ktwd2naYKhXfXpISfCrHr3Ep//E7m59YzhUmMTQkZP25FhDR1Zz+9t36oeL9aKMfePBG83N zfwtIoTEDp/PZ7FY8G1TX1/Pq0EIoUDHkNra2jG5SwpjtNP7aNAPpMjUFdY4TGt8NceQJEQfwdUa NS3BvyNq2o5s3KW/WuR/Wn9ka3bdwuWlar2k2f9SfoxvGNLGDlJSUsJfIUJITMFdOldOIYRQoONE fn7+mOJlGBQzFo9u3VYLdWke9Ntwjv/VVv3VbE3r1V9t0rPsWfzDwyK7Jj1tSJX+tFQvGTC0ry+w ODberLbz/a3VH3ksEWiz3kilfugYnbJP74OeeYN/zwghMQVfMrJySktLC68GIYQCHXPcbnd6evqY 6Nli6dD6SPeY0aqSOkP4dar+8ASuOaK1GAS6yPBqj15SbSix6C1I5EaS/tQXmEJuPFJFBLo8xsPt vvGJg/iTNjAwwN8fQkhMqakZ+5rLzMzkpSCEUKDjhMvlirlDd+jamqqbtDMoSlj8eNDw6DVIc7M/ 6MK4V7oeHSHb/Qaf7tK3y45srcMgzSLQ7fGwZ7PZ7HQ6+ctDCIn1d3hS0ljUWldXF68GIYQCHT8G Bwflv/9i6NDVehiGAPet8E/v69TCkm0Q6K4jW6vTDuexrtS3Bw2VQ1JsEOi+mNuzyWRi1mdCSBwo KysbC1vLz+elIIRQoOON0+kcd+iMmM0p9OpDvyV6CPJYfIOeE0ONGXcFPfrCC7TMGpRB5RRDiLNU rgzVmtMg0DE6Qbcu/Zr2cdPHac+EkDgwMDCQoNPf38+rQQihQM/MF/F4LEeyPu1vGs0S8uo4cpi2 wh/lPKiFWFccqt3mnyYYUqBH9Sl6Kf7piS1HhkdXHFlz2NBa7ATaqQeW6HHPvb29/J0hhMQBu93O VD+EEAr0DOPxePLy8sY0MNFgpUf/KNO1tTsob4bDPwUwUQ9lHj0yV0ZdRIFu08YXUzQZ0jn79Ejr pCPTPxcbJDtGAt05njjPYrFwwRRCSHzAvbos3O1yuXg1CCEU6JnE5/OVlpYezqDsnqbRWZMeuSF5 6Mr1p+l+8e3VnybpoRdN+txBiSTxRhRonz8UpCRowmKC/lKNni+vwB9O7YuNQHv109EpKCjAHQh/ Wwgh8UEW7q6qquKlIIRQoGcFzc3NJpM+6S9lmpYqhCXn+dc3SdHTMBtXE+zXs0SrV8sNcxk7dP0N Oe2vzp89OvhY+f7WUnVr9xiCpLMNq7Qc/UKDethGQkJCTU0N7j34q0IIiQ9dXV1cuJsQQoGedQwO DtpstvHB1bJpGoqeNw+vPpitL46Ynp7e19fHXxJCSDyRhbtra2t5KQghFOjZhc/nq6urS0hIGF+9 r/HIBUoW7KNVH9iW7NLl5VxokBASZ9ra2mTKMr9/CCEU6FlKf3+/RNqNhyZ3LmB17tVTZWvj8wWZ q44QMiNDG2lpafgWampq4tUghFCgZzUOh0O+ssfICTWrb34/+vQobW08UR3+bjHimRAyIzQ3j82t xhcyv4UIIRToOYDX662trZU1Y8dTyLUtAHXu0qck6iQmJlZWVnLKDiFkBr+HZdGr1tZWXg1CCAV6 zgB9rK6uHl+2UII6GmO2APjMThNsPRywYTKZysvLmWyVEDKz1NfXSwgZLwUhhAI9J0dB8D2emuqf TGfS1yvpmi/RGmX+JNP412zGDQNHnQkhs2H8Qv4PsKOjg1eDEEKBnqv4fL6WlpbDUwzH4vL0FUyc c9CbB/X1ES2HTyUzM7OhoYGT3AkhswTczI8tDJWdzUtBCKFAzwcGBwerqqpSUlKOMOlyPWXHLM98 16OvtJJxuONms7m8vJypnQkhswqXy5WYmIjvqJ6eHl4NQggFev7g8/k6OjpKSkrgoIeFNElfErxe zwHnmzVBGo36muHJh7tpMpkKCwsdDgeHnAkhsxDc2OObqqCggJeCEEKBnrd0d3dXVVVlZBiGdiVU Olsf8W2Lb5jHoL4keI1hOXE/qamp+LPU2dnJhFCEkFmLGn7mf44RQijQC4KBgYHm5uaSkpL09HQt gEQ95tiuL4vdqs9BHDy6hB5evYVuTXNoWq0+xpypW7sWKM2FhYUNDQ39/f18gwghsx8OPxNCKNAL F7fb3dbWVllZmZeXdziDRzAmfa3sbH3FlmL/o0T3bHmUGsrz9JrpgUPLRpKTk7Ozs/EXqLW1dWho iG8EIWQOweFnQggFmhzG4/H09vY2NzdDqe12OxwXVi1/J6ZGQkICWrBarQUFBdDlxsbGnp4eZqAj hMxpZPgZX5K8FIQQCjQJC5R3YGCgq6urs7Oz2U9TU1O1n4aGBlXe0dGBmk6nc3h4mJeOEDLPkOHn hIQEfCvyahBCKNCEEELIBBQXF2uahp+8FIQQCjQhhBAyAQMDAwk6HH4mhFCgCSGEkInh8DMhhAJN CCGERAuHnwkhFGhCCCFkEnD4mRBCgSaEEEKihcPPhBAKNCGEEDIJOPxMCKFAE0IIIdHC4WdCCAWa EEIImQSy9CCHnwkhFGhCCCFkYmTpQQi00+nk1SCEUKAJIYSQCaioqIA9FxQU8FIQQijQhBBCyAS4 3e6kpCQIdF9fH68GIYQCTQghhExAdXU17Dk7O5uXghBCgSaEEEImwOv1JicnQ6C7urp4NQghFGhC CCFkAurr62HPVquVl4IQQoEmhBBCJsDn88nwc1tbG68GIYQCTQghhExAc3Mz7NlisfBSEEIo0IQQ QsgE+Hy+tLQ0CHRLSwuvBiGEAk0IIYRMgMPhgD3DoWHSvBqEEAo0IYQQMgGZmZkQ6KamJl4KQggF mhBCCJmAnp4e2LPZbPZ6vbwahBAKNCGEEDIBdrsdAl1VVcVLQQihQBNCCCETMDQ0lKDjcrl4NQgh FGhCCCFkAioqKjRNKyoq4qUghFCgCSGEkAnwer1JSUkQ6N7eXl4NQggFmhBCCJmAhoYGrt1NCKFA E0IIIdGSnp4OgXY4HLwUhBAKNCGEEDIB7e3tsOeUlBQunkIIoUATQgghE5OXlweBrqur46UghFCg CSGEkAlwOp2w58TERLfbzatBCKFAE0IIIRNQWloKgS4rK+OlIIRQoAkhhJAJcLvdiYmJEGin08mr QQihQBNCCCETINnr8vLyeCkIIRRoQgghZGIyMjKYvY4QQoEmhBBCoqK7uxv2nJyczOx1hBAKNCGE EDIxhYWFEOjKykpeCkIIBZoQQgiZgOHhYZk+ODg4yKtBCKFAE0IIIRNQV1cHe87Pz+elIIRQoAkh hJCJkemDbW1tvBSEEAo0IYQQMgG9vb2wZ7PZzOmDhBAKNCGEEDIxZWVlEOjy8nJeCkIIBZoQQgiZ AK/XazabIdB9fX28GoQQCjQhhBAyAQ6HA/ZssVh4KQghFGhCCCFkYgoKCiDQ9fX1vBSEEAo0IYSQ WY/HMzo4OJ2PSTI8PJygg40ZOP0ZOSghhFCgCSFkDttzcvKopk3nY5LrCDY1NWmalpOTMwPnbreP JiSMOhz8IBBCKNCEEEKiY3AQyvvBMdrIoml4HDpeF2hY6WSAOkOgodHxtmebbdz44dCdnfwsEEIo 0IQQQqIVaLhvb+80PF5o1H00Ozv647tcroSEhMTERA+MNv72nKyNFut9Nn18tLubHwdCCAWaEEJI FCqpaf/42IwJdH19vaZpBQUF8Ttll2vUah3rZ4o26tTG/oSV0aEJIRRoQgghk/gKH9PHmRJom80G gW5paYmfPaenj3UyXRt16faMh08btes9T0oadTr5iSCEUKAJIYTMUoF2uVyw5/jFb4S05wCHTk6m QxNCKNCEEEJmqUBL/o04xW9Ai9PSxrpnCbJn5dD5dGhCCAWaEELILBbovLy8OOXfgBBLtj6bNuoJ Zc/y8OgVUA2q7XLxo0EIoUATQgiJi0DbbNEc1uPxJCYmxmP9lCjtOcCh09Pp0IQQCjQhhJDYCvSf f6OrZ2pqNId1OByaptmis+2p0909ajaP9SovCntWDm2hQxNCKNCEEELCYTJBFp9+NN4CXVRUBIGu q6uLrT3rZzc2QdAXnT3Lw6VPNJTR9HgmqCaEUKAJIYTMAeC72pj7xlmgzWYzBNoZu+l6Y/b88anY Mx2aEEKBJoQQEh+BfrbDn8ViIvr6+mDPqdGp9lRwOEYTE8c6UzIle5bHkL5UoTi0z8dPCiGEAk0I IUQnMxOO+Nc7picMWiKqJzxmbW0tBLqkpCRW9pyQMNaN8qmqs3o4/Q5tt9OhCSEUaEIIITrZ2RDE FxrjKtA5OTkQ6NbW1uk/HbQ5XfZMhyaEUKAJIYSEIC8PdvjiD6ZHoA8dr7vm0FCEA3q93sTERAi0 2+2e5nOprx83+Nppsmd54MbApDdbVMTPCyGEAk0IIQue4mKo4Ss3To9AjyzSRXNwMMIBOzo6YM9W qzVW9lw/rfYsj2449If0ge1yfmQIIRRoQgihQE+bQP/9s7rC9vdHOGB1dTUEuqKiYjrPorY2hvZM hyaEUKAJIYQcprISUrj7yukR6P1rdYvt6opwQAmAbmtrm7ZTgNHioAnaaGvM7FkebfpRcKzqan5w CCEUaEIIWajABTXt9cvjJ9AmkwkC7ZquRf6UPTtibM/ycPgdur6enx1CCAWaEEIWJHV10EFX0fQI 9N5zdLlsbg53NMkAnZaWNg099/lGS0vjas90aEImj9frHRwc7Orqcjgczc3NNTU11X6KDVRUVKjy xsZG1MQu/f39w8PDFGhCCCGzDMiupg3nT49Ao50xs2xqCne0hoYGCHTR0aezgD3b7WPHMn1oLDp5 NL6Pen/CvpYWfoIIUUB2Yb34NS8vL8/Ly8OtsvyP01GSkJCQmppqtVrh2XV1dW1tbTFcxJQCTQgh ZGI6OiCC+zZMj0C/fvkEIcL4+4c/h/j7Ooft2ejQCQlj67YQslBxu93Q2crKyuzsbLPZHMZ/NS1V 02yaZtc0fAFUaVq1/9Gkac3+R62hvBT32ZqWrWnpmpYUutXExESLxVJSUtLc3DxHfZoCTQghc5ae HojggdOmR6BfvU7XytLScEfLzMzEX74eHHTKeDyj+fljR0nSZsye5VFLhyYLEdf/Z+/9Q5trzzvP 8xJNKlqValkR1EUz+A9RtKABQcWiggqGNR0XVBCMKC6YqSGmeEEQQf2HBgRjGLG44GXc4i0icYtp FWoatRWpQ7WtG3WqBoUqidqoqZqobzWNkiobJ6sQJaiJ8kb7PfdlnedYvx7ZPpIl6/vh8KDnnKPz 49aRz+fcuu7rarfhrDBXn883arWQ3ZCy5DNNu9G0uqZ1tOHvNc+Y+prW1LSSpmU0LaFpu5rmGduz 0xmNRk9PTyuVCgWaEELIgmk2cXv615+0RqD/6b+q+93e3rS9PbeECuw5HNZ34VY1AgcvPSXU+drt g1KJlxJ53dRqtXQ6HQqFHvYDq37ipNLlthWuPP/U1bSKpp2rjm33g4PyeDxHR0eFQqHX61GgCSGE LIB+H3eiH77PGoH+h4y6tW1vT7sB4962tbX1XHvGlNQGV9OnonWKXJ+5I0w+dTyOH6NDk1dJtVpN JBL42j6Q5ogy14rqGx6sxtTUtKyK/TB1Tjscjlgslsvl+vhDR4EmhBBiJQ4H7j6f+6QFAl37mLqX TUmygdsYbmnRaPSJxykZ6+acKhYJtGvuPfp8vJTIq6HT6VxcXEjM1T1uTTvUtLym9VZGmqdNFRVI bTp2l8t1fHxcm1njiQJNCCHkMWxt4Y7z+Y9bINB/U1D3L5dr4n7S6TTuZMlk8onHWS7rdRPfOqnn gUHNCnvuDiM05tnvM0dGErIalMvlvb09ibZS7qlpcU0rr7w0T5xaqqfc/8ak8UhwdXW1IqEdFGhC CFlntrdxo/mHjDVRHPd3rklICo6r6VmirUEEumOFQDdmdagT8sooFArb29tvUmfsatr1OvQ3z9kn HX+T0MPtdp+fn3e7XQo0IYSQpxKN4v7yj79mjUB/7wPqhtVsThJ1/d58e3u7wHPpdFREskXxG8VZ Id2EvA76/X4ulwsEAm8yaaRU3+3g1U09FScdeJO44+Tk5OljminQhBCy0Rwe4s7yP/6zNQL93Z9S t6pqdXw/Mg6p0Wgs8FxqNRWObJFAX6lzeX7ZF0JWlWKx+Ead3Sr9XOc1qvPIlFfJQ4YafXZ29iKj DCnQhBCyzqTTejXvA2sE+ls/o+5QNzcT7haKxd6oVF2YwY6lmZ6fHLRNyAqDR9lYLHZvkVsqxXJv A9TZPBVVmIrC6/XeTPqrRYEmhBAyhWwWt5Jv/Lw1Av31/6juTWMj6lqtloQeLvZcLi/1vR9YJNBx dS7n57xGyGui1+slk8n7YYIOTUtvnjqbp4Kqd6jY2dlZZlFDCjQhhKwzxaJelCBgjUC3RDqPj0d2 IkmgfYvO9XZyomqJWyTQMXUuLDRIXhHVavVNBcEDq6uf9FS9QCnNnVe1Thatv2VNq1pR6fDifogh nisulpVRhwJNCCHrjCpG+L0PWCPQ7/6f6pYUi41ZehE3p+1FD8g7OND3fmmRQIfUubBCCnkV9Pv9 dDpts9l0T/SpxBTWqvPJmzQXb1J5HC1Yo7dUNLMlm+qoJ4phV3Sr1aJAE0IImf2HXL99fObTFgj0 3/+2uhkFgy8j0Ds7+t4LFgm0W53L4u+jhCz+Mbn5pgp3wuqYjb6mhdWWwyrNRV3VBbwZRhhvr4lA G+MLXfeDC3ML/vWJAk0IIWuO1FL5wwXWUrm6utJ/MT44WOyJ+HzWV1EhZM0plUput1u3Qo8aOWe5 xSaVKB9OquwtfbrX6yPQmO5UrXLFyckJBZoQQsgUVC2VL/6mNVEc771f3YYeFilYkkBbWEWlqs7C 7+fVQdaabDZ7H7axu5gUdV1Ns6sUeBN7tduqQ/f0YbDHpbLtAzV/PAi7pPrID9S/pbGldeXrBypi pLMYgZbpXIWgaNre3t6CKhdSoAkhZM1RocPNlDUC3dtSN6BabdkCfXdnZRWVnDqLaJRXB1lfUqnU fVdqfFL3sCXTtdr+8XwrN5Ty6jW1VbyHXaUBMXeK72v3PeXb6l85cmNpTkmtY7h0S9n59iITdDj0 QwiFQu12mwJNCCHkISp5xb98cIGpoJch0OWyCr+2SKDP1FkkErw6yJqSSCTuR/JlFhmFfKw0Nz/f ykElzbfD/zaVBDuH/dAXalNHQ9fvq45qbXj8baWzARViIT3Z0cXHWNfvjd/n81nu0BRoQghZc1Qq 6G/+nKWpoB+mT16GQGcyViaBPpqc0JqQNbPnmwUnkpMo55HQ6isVYmGeJOXceF91Ts2UGA+fCgXp P4z3cKn5hl4XHubNsC9YoEXcffcOfXd3R4EmhBAypFLBbeK7P2WNQH/5V9V95+jIvIfr62uJJlyo Muj7PbVIoHfUWRQKvDrI2pFOp+/tObf4TMxHk3qgt7VRDAO+GUsep/9pULHUIDa2felm7g1NvTvW pb29+HMcOnQ4HO4+HN1BgSaEkA0GtwRNH/xniUB/8TfUTSccNu9hGWnsIhF9v3mLBFoiuRsNXh1k vchkMsuzZ0OL02PG2RxOoaFAn0zqqx5I4mW1ptR2mdjD3RomxRuMmfr2Uk5z6ND4I9bv9ynQhBBC FCqTXe1ji8pkV6/Xce/xer2LPoVB3bocdjbbwKI7JSHLoVKp3OfcuF5WKWwRX//0FbaH4ns+vQf6 YPhiWg+0YdIjiURCyxJocWg1rjFh0dAICjQhhKw/qvu2cWZNJ/QPflzdcUzxgr1eT+8Ug5IuCNWJ PrBZ1P1cUccfCPC6IGvE3d2dx+O5L5UyWOK0JzmTpyS58w8NuDyWVWOgCq+YY6BdD9PhddUQQ4mB vlRr5h7Kt2OJAi2noB5P8vk8BZoQQsh9AHErbo1Af+ffq9tNsWjeg5RyWEQ2KJ1qVaVttkigr9Tx LzRimxCr2d3dvS8H2F+uQA/DG/T6I4VhJ3FN087UoEBNpc4wOoxtpoDpmlrBNczCoWJP9Ex2veEI wpiacznUZZfKidEc5ujYX3wWjon5oeHtDkfj2fFdFGhCCFl/VAqLb/y8pYk4HqawCAaDuPGUSqWF HP/1tb7HmEUCnVDHf3rK64KszzdY6adLhQsPlj61h/3QI7hUeLQh9K1hh7R/KNOuh1HRieG7tu9L aj/I2lFSXc529ZAgeaD9SxfoYY97+OEwDwo0IYRsJCqJ8nf+V0sTccTj5j0cHuo5Xc8fprezjGRS 32PKIoHeVcdvxa+0hCyBTqfjcrlGIxyWPzVUB+2RildOqXDn8fKEfRW2EVdTZlJxxIp674Ey79ok Uz9T+aFPVULowsPEdsuZOvc969d4bqdAE0LIht+B9UQcP2qNQH/pv6kbzcOcG5IKOrqg2n6xmL7H a4sE2q2Ov9nkdUHWgng8fp/LYsBpKZMKyPZ4PM+p8k2BJoSQV4HbjfvC5//QAoH+209MSMTRaDT0 32YfzrQMv1/fY9UKe+6og3c4eEWQtaBWq+mZN2yT+ms5LW7SQ9K0VCpFgSaEkM0mGsVN4R9/zZpO 6L5zQieujCOs1+sWH7nqPh/YtUHfCoEuqiMPBnlFkLUgFovdV8Cm1A6Wm5FDjSbs4O8PBZoQQjaX dBo3ha/9kjUC/a2fVXeZXM68h/19fdj8qeWD825v9X2FLIrfOJsQwE3IatJsNu+7n9uU2qVPKuvJ k/+gUaAJIeRVcHOj510NWCPQ//JBdYs5PjbvIZ/P6ymtLM+vrNRfT51hiUDH1JFfXvKKIKtPKpW6 T/1GnV3+dKu3/dbWFgWaEEI2mEWMI9zZMe+h1+s5HA7cchrWlshWwSeDrKVFvGs1XhFk9bmvnFKi zr7QpJq/+DDnPQWaEEI2DK8Xd4QvfNQCga7+2eSheJLMLp1OW3nYavjjoGGFPd9xBCFZG8plFYe7 RZF9uUn9ABB/UsQXBZoQQl4LKhlcM2VNJ/T3PjChK/f29lZ+9Oz3+9Ycc6ul78VpUffzzYQEfISs JicnJxOKYy9zOlV1TCaGXyeGJU6q6sWM6UqVJpmxwp7aztXY/KhKF305Kdv0cocSer1eCjQhhGww Z2e4I/y/v2iNQP9//7u6xWSzIzvx+XzPr0HwhlxO30vEIoFOTQjdJmQ1CYfDur7dvJw+Hqhigc1J i7bVIlHMLdNk1+57zY3pXFUWNP7rGhYjNOaE1XZOxuZ7hvUOfZMKsixtcuqH0MKTPAWaEEI2lFLJ ynqEH5qczuLy8tLKoYSQXezlxNIahA+ThxCymsiIAr0g3yoL9JzzjelKrXA1Nv9k0vyupsXGKn4v eYro+88/vnApBZoQQl4L3e7AZvvh+7TP/ncLBPofMur+MibKvV5PEkI/beTNeC+cvpcbK+y5rw0c 6pjbbV4LZMWRykR6TenBBgu0FNbWoyherhGS2tPGdVCgCSHkFREK4Y7wxd+wQKA/+yntvferW8xY oQHcbHDL2X5+qHG/rw/401T5wOcLdFkdrc/Hq4CsPjKc4D7OeJMFeqDCQl5wJKUq631wcECBJoSQ DSaVwh2hvW9NFMe3f3pyRESn03G5XE/73fMB5bJSXoviN07V0R4d8Sogq8/VlTLNgxUQ6JJy6JEp tCyBLqr5Oy+cDfoJ3QEUaEIIeUUUi7gjfPenrBHoVnyqkmYyGRm9/qx0HKenavuWBkBbNbqRkEUi 36AXruB9oL0FywU6qYxZpqyaqcbw6Rb7Uo1QpEATQgjp9QZ2O24Kn/ukBQL99789NSgC3izpOM7P z59+tDs7SnkZAE02jvscdicrINAJdRgj09ZiBHoc95S4jqVN9SdmsqNAE0LI62J7GzeFxpkFAv2Z T+ulDadZ6c3NDW48TqfzCRmgzK6vVz9hADTZMM7Ozl44+8SLxEAfqkUy3aok0/2XrqVS0o8rFApR oAkhZNO7tnBT+NovWRPF8a2fmRUXEYnoKaDw71OOU0WbDAIMgCabyArFQL/4IMKXnRjCQQghREdl g+5tWRoGPWWIeqvVcjr1GEbYwKOPM5lURU8sEugwM0CTdSKfz+viFqFAv/R0rR9XLBajQBNCyGYz zA33t5+wQKD/7lrdZTye2R1pLpfr7u7uccfp9+tbLlphz3fawKbpASHdLj9/shZUq1Vd3PwU6Jee TlUozePLl1KgCSHk1bG3h/vCl3/Vmk7o731A3WjK5Wl7k0CO3d3dRxxhs6lv06EG/z1foLPqCHd2 +MmTdaHb7eriZtO0HgX6Rad9/bguLy8p0IQQsvFks7gvfPunrRHor/2SutGkUtP21mq1JC30ycnJ vEeYyejbjFkUv7GvjvDigp88WSP8fr/ubpWXc8djlW2jNWnR3pTiJntvK3qSUyvkxuafT5n/4pOe TEirVqsUaEIIYe9Wd2C3//B9WvXPLBDoL/6mutHMTPNUKBRsitvb27mOUBLYXVmUwM6pjrDRmGfP 9Xo9mUzu7e0dHR3hsOdvVLzxQJHF88kk8PyApaenp/LfUqmE/0qtGfx7MBNs/O7uTl5Pywx4cXGB pU/4rdlypClwguaHKH7tHsvh4aHubqer55SbM7X0T8DhcDwhnz0FmhBCXiPKUP/pv1iTzK4/h6FK Xlu3291+ayZm+L3NpkctW5LArviIBHYQWVi+0+nc2dmRPNaQmDlbtFiUmmmTU8ZCf7Fl83B+iQ6X Xvn7pL/Twcabzaa8xu281+uNbB9zpJt/a2vrxS8uaQpj5CjO7glpdEkul3v5at4bPl0+cQQhBZoQ Ql4pl5e4O3S2rYniuIuo2006PWOH/X4fVioZVcf97wEqwmSwY1H8RvwtESYGnU4H6gwBNcY7Hh0d zV+QXKwRdjvxB9+Liwu73T5NoEdvvZPSZolAy/bHD0mSNmAXqyDQaEm0hvGktKXgd+6xdLtduWYm B1FwWsK088QAaAo0IYS8Ulot3B3ee7/22U9ZINCNM3W7CYdn7xNGBZHCDWlvb2/WetGovrVLi+I3 XOrY5ghhlDiTC1OodL2uVyGLx+PzC/T+vj7mKDXm6+FwOBqNPl+gY7EYpAp7GVmKOYFAYB5VxdNL dywbSavV6j47RQm2DHUenz/tqLDytJ8j8LiF8+1ufNYUfFMYxfGy8Rv4uj3tOqRAE0LIKwW+a1FJ Qlg4XFy/6bwt1BVKKn2oUwcUqvhsywoQ3j6uACG8zdw7XsG5aVoymZxfoHFeENmRiAXoKRbJL/LP FOiDgwOI+EgUB15jzvn5+QyBPj4+hsTn83lpf1F8mAEeD2QO2NnZwSnLBnEKR6a6M3i6wJYTiYQx J5vNYk61WpX9lkolyfl9eHhYLpcxB+eLE8cLCX/HCyN6+/r6WiJkgMfjMT+0jBwSGvPm5mZjv6NS zlPzrEBBvg2cEpo8Ej/ts6NAE0LIKwU2o2nf+llroji++XNvj+IwVEyigScPtlOxJZbFb+zPe1Tj wAL9fj9MDub6KIGGJo5EcWCOKK8lAi0ibo7ikDliq9MEGm90KXZ3dyORCPaOpwUoNT4LaPHt7S3m 4L04zlqtNtCD5HcgxMbYKYlmMW88Fotha4NhADc8GG/BlmHDRgw0bBj/yn7xQtrk8vJSInlw2BBE 6WQ1+uzhKzgk/BfXCd4Cj8d/n5AD4dVwn4vjika73Kmjac4n5t+gQBNCyKvm7m5gs/3wfdrfFKzI xfEbb8/FYQDH0lPc2mwTwotVv7g1+Td6KpP03Pk3DGCQEnv6iLQhJoGW/mZzFEcwGJR+LEsEWvqb zR1j0Wg0rOJnZgv0SDhKJpPBHHPvL44cJy4Zu+UzKg/Te0NkZZCiPE7IMcgISxFoc1jOyCBC81F1 Oh28MRAImNMaQLvR1LJlLDXXfoe+oPVyG1xC8r6mt0fTuvTaJU7x+99knvzBUaAJIeT1EovpkX5x a3Jx3FdUKRbn2XMymZQhceZkZ2/qp3StEOicOp5Q6LGtApODXMIg/X4/xG7OIUSGQKungLARxdFo NDBfMuJZItDSTWtEcchQMxzwPAJtbm2IMuaMxHfCxXHKmCm7k8OT19KzLlqM5wq8luAKEWhzoMUM gZbBjiOZ+GSmnALcGqeTTqcbj3zsecWEQiHd5lL02mVNNb2EDb4I8msMBZoQQshDID2a1tuyJorj Xz6o7j7K8OYhHo+LQ7/5kRS6pqm4C0viN3afWz8FHgkPdjqd84wiMgu0OYoDLuhyuaTD1SqBFuOU /vtsNos7vWQOeatAm8NRJDp56yESfCyrwWWlYxtqK1btdrul51vClMXgRaDNqjFDoNEaUtrdvFNs 1uizh+JLV7ckBMTMTY7fEMrlshrONqUoIKfFJN+Yc/QwBZoQQjYPWJ3Hg/tF/SMWCPTnP67uPnb7 YL5B63DKWCwmyaHr9bpxMHrm5ufbc314MJPyQsyP9JQ/6CafQ6DNURzQUCOZtFUCbY7iiEQixg/N jxVoPBucTEKSaeD4xZvxMYlJ7+3t4cMaqIgOIzmuCLR5yzMEWlbGwYzv1OjDxtlJZRnDpI1NbSyS 3UXb5WjCJeV+xrXXed6fDgo0IYS8apJJ3DLuotZ0Qn/7p9U9aO60qWaHbl1cqIwZFnU/H6sjMeWR eCvZbDYUCo30dz5NoAfDKA6J3ygOw1qsEujBMIoDpg7HNYZjPkqgsQu73T6SkxsbNNJgSxKSXC4n nm0cs/R/Gzt9lEDjXeNCDFMx3t5ut42yhbg8sC8cpG/uPCqvFTSL9NNrJ3TcxQZvvON4Z+oQZwo0 IYSQexoNPSH0j2qf+6QFAv1P/1XdhgKB+fdvOPQnf+RH9PeeWzR8UIojqqRscyK5LMyZ2p4cwjEY DtHDqXk8nolm/EyBFouVtNDG4T1KoM/OzkYGEUqQhhFwAnDwEoArzwByDJIZw+ife6tAS4JqQwRx wCODCCWY5/r6WrY/kibcq+A39fb2Vk9fY9O026WoZFXTDlUdxF1l7e2HS/FgeDxceqpyVhiLrtRU Vov2cIWptzfGgoxP1L/Gvo6GW8NV2TOteY4ntuHWDsa2Y+3UxcWtmb9lFGhCCCHT2d3FveOrv2JN Qujv/8+PGEpoOPSH/sN/UBEX2qBjhUBfPWX4IA4D2orb5/HxcalUgqEGg0FjcJvhhdNuriMCbdTu Nhu5hQKNo5UIh2g0aqzzKIGGLvt8PskZh4M3ztc8aFKy1zkcDsN3JX+zOTvBWwV6d3dXkuXJSEpZ Hyd4c3ODNcWesWvZhZSbwcyiQg779PSUX1Oj6TTX4msT3uij6LQt5awR9dpt2mlezXEqP46p4Owt U3w2vkN+dZBCWv2beLj9fbWFu6Fwy/b3h/vyDRcN1JaxQcdwa5VFnnXsPvX4W0qlUqAJIYSI7+De AfG1pCrhV/4PdTMa87/ZvPef/pOKuLAofiOgjuHxP8J2Oh0Ym4iv5Da+vr4e8cI5BXqgUinrd3xT L7iFAg0ODw9HEkI/SqAHqj9Y+rDlfN1u90hwBZRXj7xVie3MSm3ut36rQEOUR1wfb78PSFC5Avf3 943+bGi9pIKWpU6nE35v7q7e+KddPXeKrpjtRapkUJmrEW9dUB9GUr1uK531mxy3phx62yTQmuq9 7imrxkYCyo/7po5ebCE67MnGRx0yJekrqTl7JoGWXfcX3P2syqbgWdGq9C8UaEII2QCCQdxBvvyr Fgj05z6p/eDH562ebXicPtrPpg0aVthzXu3d4xk81brgcPV6vfW2qoqvBklat+jzHR+S1VRMDI/p 9XqylOo8/mEFAoGFO7RfKW/NNKc+NOALZbS5h+sfqplNk0Cbj03eYkSeZNV/b9TrpHpderi1qHLo 7lCg7Q+DOhZmzz/m+LF5RjtQoAmxEvyVPz8/t+R3H0JegHweN5F//bd6OufnO3Rb6v+ZQgveQiKh rx+ztPv5YaZhQl4N7Xb7vhC6f2HVVa6GIRN+lX+6bFp0oOZH1QtjCqqZ+aFAux9u7U5J8L4pSZzR Ia360/X+ZvPWAiar3lJxyYu358l1nSjQhCyBg4ODra2tTa6YRdYbrxe3kn/6LxYI9N8UtPferw1s trlKALbbA4dD9Vhb1/3sdg/4NEs2xKEXFA99q5TXCGX2Do02qv67PWkqDAV6a1J4sUPpfkv1Lh+b 4j1sU7ZWNcVAL0id+2/s2fJ7NwWakHmR0lwyvEZPakvIenF1JUVVLOmEvouqO5Sp3PRUpPs5alH3 c5jdz2TDHNr9sIfYcsW8HfY6+0zRGjOsfaJASxR1VmXV0EzBIdIDPSNCY3EC3b3f+yLsmQJNyCPo 9/sej8cYFpNIJJ6chv373e67udwP2IVGlnsFSye0JZHQn/+46oTGfapcnrXTRkPvqLZpg5oV9nzN 7meyQXS7XRmoqgdIXFttlscPZ4bVvW1YZ0T3YPPSlNLc5nSBhoh7VKhGWMV7GPMlR8f1WET1znCQ 4oIEuqk679XAWQvjninQhDwRSLNmwuVyXc5dUcLgvX7/TyKRjKZ9nr1oZMkUCriz/ODHteqfWVfZ e3Yuuf19Vf3botzPW48r40LIK+i4kbwo96nirBpsF1BSXhj+t6ICMMJDvfao/xZMAdM2pcX96QIt 4wUlG13GNLOt0uGZO9Ez8kvuInug8/ehKT6fbyQvDQWakJehWq1qYwSDwfLsTriH/FU8nlF/Q74w zD5LyPJQOaG//h+tyAn937XvfUDdsKbVYVbp8/Tcz00rBPpkWMOFeRvIhnFxcXGf+M8/DB1+5lRX liw5p+XFlppp5K2Tme5hkLTPtHSaQDe0+87yzsP5JbUd89YCpiQe1gp0dxiOopIzzlMgiQJNyJK4 D0obY39/v91uv/Xtf3dxIfaM6V2ORyTLp14f2Gw/fJ/2hY9aV5jQ7R6MhzNBc30+fWnaCntuKRHH 1t72a6zkRzOqVZuRbG5yT221Ws3pYKmsPAPZzsRFG3txTWv51dngWnff3N99bKo0YN8K17xW9QJP VNK6kb7tnpopS/MPl1anx2SXp1RC6Q33lVYd2/2Hb6laZM/F+6zSdrvdnMicAk3ISpBOpycKtM1m u5rWD2fcDPL5D9tsUOffcugC/dXH1HIjxDKOj3Gv+c6/t2Y0Ibaj37ywzbGvij7fp0Ivni/Qu2ov D0tAT2RGMRSpbCLf062tLW06WCorz0C2M3GRw+E4PDxcaO/Xguj3+6enp5XHFEh/oBQWFUle3AbX GjwcvgkjDIwlV97kqa3iqm33vwkvZ5Q/BZqQQe/u7k8ikfLx8bfn6DqSamEj/PKP/Mjv/cIvvDfz l+WvVyq/5fgxePNn09pHt3SB/vYG91SRl6TT0auQaNqXP2SBQH/ho9oP3zdW3Lta1ccO6jOtsOcL tX2XazBHKZA5BTqXy10NkYJ/+NeYg6WNRuPKhIx5MM+RemYSZ2nMvLi4ODk58fv14UuxWGxNOwiK T322p0Avgdvb2zePf3umCtubOfX0/vh3nO9INxa+fUsrzUOBJmTwjWpVYio+bLMVotGv3N7OXj8c Dpvt+X/5N/9G3v6nsdg0h/5Oq/U7bjfWKarRVB+x6+szCwd5MdRowvfe/44lgRxf/RV1L9vaug/k wIUtwRsJK+y5NgzemK8IwpwCPc/8EZObWEN7YlHubrfr9XqxyKqiwUtDqnZToFe906fXw6POfYV2 u0qR0dlIe86p9NWKSCSy5K8bBZoQnS9lsxJcIdPv+/31y8tpgpvJZAx7/omf+ImfH74L018eHY2v //1uFxvE0o9va+/1te93NRXF4WCzk5ckHpfahJ/75HMF+jOfHgZy7O7qW4bx4LXfiuCN7rDu4OHh nKe1CgI90MNkjvVyyFPGOfT7/Ww2e3R0dHh4WCgUOp0OzLWqSqM3m03jtdlrzYcnb8d7cZoQKfPo C5w+VobBJ5NJbB+r4b/jh3F6eopFIzPz+TzORVrv3JQj6ObmJh6PYyZOqjqzfru8t16vY83xYxPz w4ngwLBUDm+kvGulUkkkElh6cXGBRRToGbRarf39/ftbkVPl6Ghvhjf3VWKQ4XAkv99/+7ZuLwo0 IQvk3VzuI3Z7xmTDVy7Xp5PJ74z9anx3dycDovGHHn/C0sq8P3MCJ34HLz6VSJhXfq/f/+OdHcy/ 9unqjC/dtxr6xj866WZMyDJ7sQbBIG5G3/oZC4KhP/9xre8cZrXDv453LEj83FfVv7E1r3cwdzzx igi0pB6beF+H3cqvWHhjJBKx2+2iQXIAcvwjB2PeC/7+BAIB8QZsx6EwMt1KF/Le3p64BdrB6/W6 3W7z79rlchmLzs7OxqXf6XRK6lxsWUxdNuXxeHAALpeeQwG7mNFKODYcj8/nwxZwatigEVGNZwMZ BhcMBrE12Ze59WDtEiojS6WVKNCzwae5u7t775J2FQrceNUBG+fDDCGahms7k8n0XygtDwWakDe0 SyUJU/5tp/b7fs2I6/jTWKz9cOx/LBaTDNAS/nHl0ruWv3KLlTUV5Zw21vyLw0PM+R239u1hJq+v FjXVGz3hpgvb/mat1sznq6enX3/qOB5C5qXZ1BNoaHpZwecHcnzxN4fB0JoquP384I24vqlvvfPO //Prvz7/OYmA4s56MIYI2RIEGjoLiYQCThxHmEwmzbur1WpYeX6Bxh8fPMBfX18b3ZA4WUin1HUS gcYceFW9Xm80GqenpyMqH4/HsYWJWYNGQjjkv4lEQhwFpxON6oWe81PCaURrDMPGqaERIM3yX4k1 N46k1+uJ+YlhS5JQPFFInzROJxQKUaDnBK0nF8Z9mo7dSaU73BgAAF/OSURBVIk11nqqaFpcdbTL EMpAAN+R/otmtKRAEzLq0BKsnA/rQny7d+/EmD4WCHwpm5W4DuNnx79OpVTkxv0t/93c/fpSJAUe rKI13vla+Y0W/OP1fcD0d9vtrxaLX8hkPpVI/Ekkcu3zmfu//3hnhx8HWTh4MnT8GG5PX/slCxz6 f/xndbOzaYPcs+35TN/U99/3PhlwkEql5rxZioC+NXuGhQINR9w2IQO8ZqTlcbvduP1PU+rZAi2D mPceZiOBTGOmPNKL8ppzeMGwcTD7w6LraEbYNjx14rGNCDTWhIubWx5ea7fbJ3a6D4ZDKqdtECc1 0u2NY8bSm5sb0Xq8NudPEKWmQM8PnpfwlHIfGy05nuPWJYl7kelOdTkH3nx/8Ricn284BAWakGXT qdfFof8gqH23rU9/ndK7kMVrsQjS/N1h581Ht7Yws116c+P/4tWbeGjVga1btdkM/u5CM4vyyCQZ 7j5ss325UOBnQZYB7kYqYwYc+vmxHPcDCuHQV8+I3EgMb6C5nFFCYnd3tzOebXqKQC8zhAO+smUC cgyJmVZcSQz46OFgidvb2zkFOpfL6UXcdnZOTIh6yjYnjgJE0zkcDukOh3zMCM42v10OFRsfWScU CuGUp7VS4mEMW6FQGAkXwYeIxoE6Hx8fy1BLOVmIER4tRjaIhxMK9GO5u7vDtyYYDL6xTr8aaLhG ae9a6na4o4JShnV/cWnVarXVaWcKNCET+HazKf3B1z5doPFN+UFPN+OPBd7Eddzu7X1BDSf8Xc+o AXz+/I0Q/+3Z6NL6pRFjrf1RSM/LUT3VmnntmzWtU9ejR0aCQAhZONAp1Q/9rZ+xYEzhlz80vA8e Kxt+7KjBqCi4bTCMUoDPSfQtfOutd9AViYGe0Uc4HkYsM+cRaDlUiObWGMcqFbcY8EgxF+millGD sVgMjdmbMkLaLNDSATwe8SwDDae10sj6cjoyE6cJ9TcS58Pw5L9GZu7xFsYcCvSTwSeI5x/57rzp kz5UhVE6Kzk0sKxEP/CgwEIkEsHzXn/16o9SoAmZzHfbbUmdAT+G1xo3+HZJ+9PYm7gONWpwggd8 5kQzh3aMTN+oar270Znf794L+p9M+XWVkAVSKumJljXtX39Sj2Z+fizHfTx0SBvU57bnsiq8gnc5 f2Kk4iCMUEbOORyO2T/grrhAt9vt8cMzS7O8xrP5xL2ICo8sHTfgEYGGLjudzmg02u127Xb7eKfy RIFutVrTeqDhZNNa6fBhvhTpgZacHj6fDz6UTqchduJD5paXQYojG8SjAgX6maCpb29vE4mE9Pe/ Ad+nIzxXvWgm6Y4qTJhS1bwdD0oR4UkPj3yrXIeSAk3IVL7f7ebDYRkCCOU13+m/09I+ndR7i2HS 35ySbQDrPKrv7c/3NdXn7fv+GhYwI68BWFcgcH9f235ure9/yGjf+4C6S9pVSEZ75vXf0AYHKvBD L17oG0wqJAb5M5J2zUgEseICDTwez0hgsZQvMQu0+QRrtdpIDPRIiZZSqQQ5lueKiQI9UFlBoM5y pjMKDY4UUoHR4qzNhwqhwXYkR8fE1pgY3o09ylmMRG9Lsj85cXlt/oWhXq8zBtpa0Lz4iHEtvYmT Ftxq3GFC9QmVF9Y/3cMHPKwQHnvQ0yzgEQsPbND93joUSaBAE/IWh/7E7q6EJpsDnWX6Qe9Nbo1n Tl/IaEY1lvrl5VeLxe/MUXSNEMt7qwZnZwO7Xe533YAej/H3v6NV/+wpDv25T2p3keHd06ZiMy5V YZTuMFoDz6UZbbBjrGODcA1m3jvPzs4kJDoSiUzMcbH6An1xcWFObSGpKowDgKFKijoJ+MZ/jZx3 8nacuLkTutVqSc+uZGieJtBQWAkkxZZnHJvRFGIw4tPjWTimhVCLBhk5pPFZGLYtXe/BYNDQcXiS aJycOHQZ/w2FQtLpiH0ZSan5vbQcfL7lchnfJnygD2I8zMEeYaW5R8p3cV3cKLduDqeRnNNd06Iq HsLUW840DY9FB6qD2TdhJ/KJ49kJj3+r3NlMgSZkLn7Q632jWn03l/vMyQl01kiOAYeWRM6LmP4q PmFA4Ufs9t/3+wvR6KcSib+7uPhyodBbtz8xZC1ptweJxMDhWN5vuVD2w8PBfIXEIF5yy4c41sf6 qldfoIF0pXu9XtgD3FeyIxsHIL22DocDK8AwYMxwUGMvMFGJZpG3YwVswXDWaQINpMD4ePrncc8W sxmM5YGG6EsMxoxWkgGLODYZxIZTMw4GH4o0I84Ip4BdyJka3e3X19fYPt4u4RzYAkM4lkOj0YDC np6eorXR7JJXcRHgeoCy43PPZrO42HrrXI6XAk2Insv5i1dX5ePj8VxyxvTRrfsq3Aua3utrX6/o Ge4+m9ZjOfLhN3k/zNNvO538vMjSOqkG2azutX7/ABfeIqQZW97bg8AOHvlkaA6JliRoJvlvw0RL D0OoDUvAovF6v9Pmj0j2xG5XzC88KWEO3hVX4MW4wUvxv6OjIzglLLagMJZiDg5GqgNCZ0dSv2E7 E/vmZ6R/NlMul2G0cCljI2hMqSyImfVJ0TXm1sABoCVhSFj/8vJyxJBwOlKGEMYvRwKRMn+CeC/2 LpUIcQA4zYkfJVk0rVYLz6I5lQYnlUrhE8GjER7YjEGreLYxmzG+icYiPKrhEQhPibhscM3gqsCm arXaWusyBZqQCfY8IqkftunJNwpRPcoZRguvXVzH8+wJ+/1yQfs975tju30YQUjIxjJnSPRaME8X +DOBc3s8npHgaUIIBZqQJ/K9TuePQiHR09/16ML6Xv9ldHlk+m5bz+/xEfu9Ohei0W+oGEdCiMFb Q6Ip0PV6vVgsSmlx9uYSQoEmxDLe6/f/7uLitxwOKeL9hQzVmZC1YXZINAX6/Pxc+umNYoSEEAo0 IZbxnVYLqirO+kehB7mflza919fKx1RnQh7HjJDotaDdbheLxbdGJz9549fX1wVWNiWEAk3I4ng3 l/tdj0ciof86pSeqW6ZAt0tvwp2/ML1WAiFkhNcUEk0IoUATsn58r9P5q3hcLPbap321uNQe6Orp fTVv9kAT8liMkOhYLNZlQSJCCAWakCXztXJZSnlj+vz5Uvuhv9fRK4H/luNeo4sHB9+aLz8uIaRQ KEhdkkAg0GI1IkIIBZqQZfKV21sjJ3T19IWHEn7YZvvLo6PvLiZEkpBXRr1el9Ikbre7XC6zQQgh FGhCFs63Gg1jNOHvefXEdsvpdf7LI71Wy6eTevfz58+1L15pX8rqk5EH+iN2+6cSie+pAr+EkBl0 Op2dnR2pqJfNZtkghBAKNCGL4vvd7l+nUvBUlc/unerp8nJC//ONNrEC4sRihAyMJuSt9Pt9SX4M kskk/ss2IYRQoAmxmC9ls5J/Q4Ud6xEUsOdvN/VKhF8u6P3Bn03rOeaw6EtZ6wX6B737oOe/PDr6 zMnJpxKJ4sHB7d7ex7e3MX10awuTZKr+sM32Nf4qTch8XF5ermCllbu7u0ql0mw2Jy7FcVar1RkB 3LVa7W7u4uedTgf7mrY1PFfU6/UOf9cihAJNyGP5RrWaD4eNLt7fcWsf3XqTCmN8+n3/s1z5H6/1 OI3vdUbn//m+vvG/PTvjJ0KIhRSLRam04vf72y89kAAHEI1GtSEej8dcP0WS8YnxA6/Xa05rvbW1 haWxWAyLsE4oFBovLphIJDCzoYYdj+zL5/OZI8KlY357e1sCXda0Bg0hFGhCXgxjsOD49NGtrT8I Bv94Z6d4cPDpZFLycvx16u3Z6D6V0DutJy79Xc992fB/vnkwv5nX538sEOAnQoi1QCiNYYUva4q7 u7sOh+Py8rJSqeTzeTg9jqqqgrL6/X4wGIQZn5ycYA7UWf57e3trCLTT6cQpwJIjkQi2gPceHR0Z G8cW8KgQDofFxXHK2NfZ2Rm2hn0FAgFsDe8yBBorY5vYGqScIS6EUKAJeRxfymb/4vDwMycnX8hk 3s3lvlosfqvRmDhWT2I8vlF9MPjva+VRRX43J6kztK/cji7q3T0Q9OLBm65oI4qDSesIsZxOpwOz hDXCQUd6bZd601U5qo3/1mq1aDQqZQKz2SyWnpl+g4IEQ5cDw4dqyC5WMD8A4IwgwYb7wrmxAux8 oFJi4/X19bWxcrvdxrnv7OwYR2K325npjxAKNCGLpV0qSV4Oc7ZmifQYydTxid030SDfbU8YLJgP h//27OzDP/J+WQfCbY7i+Gw6zdYmxHJ6vZ7EP0Acc7ncixyD3++32WzJZHJc4iXcYiS4+fDw0JgJ gfZ6vealcGUszefz8t+9vT2HwyGh3nBrnCZO2bx+JBLB3mUm3hgMBnlVEEKBJmSxfCqRkPgNszqP J4ru1O9Tzn18exsv/njnQSqPz6b1pdjUQOXL++1hrZY/jemd06LXjOIgZEH0+/14PC4xxBcXF8s/ gHK57PF4JCjZ5XLBj40IDeisNgWxbQj09va2eWtwZRizdGnjNYz54OBAFkl39URk8CJeQLh5SRBC gSZksUj8BkzXUGcoshT9vt17o8jl4/tkGt9tt3/H7R6JmS5E9aVfMiWm/b9+4Rd+XW3tyqWPL8S/ jOIgZKGcnp6KSqZSqRc5AAhxMpn0er1yGDKOEALtdDqvJiFjH8cFGsCY4c2wZ+mNLhaLhkC73e6J W5Muaqxs2DYhhAJNyEKQ+A1jgjp/Vd2ovl6pqD7jN3HMotdfVyN1vnJ7+2GbzRzjISMIv1mrmTf+ wWj0Q8Mtf9imKedOsc0JWRzwSEl2AYlc2vi5Xq9XrVbN2evK5bLD4fD5fIMpIRz1er1Wq8kRThRo GDPelc1md3Z2sIIxH2uOh3BgU9igbI0CTQgFmpCF89l0ekSdhe93u2K9EqfxxSt9nT8KhYwVqqen 0rv8ndb9CMLfcjhGNt7tdoPB4M9o2m8o21aR1l62OSEL5ebmBvIqo/qW49CNRmMkcELyZsgwQRlE eHx8bCztdDput9vpdIoHTxRoY76k7zBmnp+fY2vmOTKI0JBsCjQhFGhCFk6nXv+Lw0OzOhtIFrxv 1nSB/oOgrr9fNCV2BZ/Y3VUDB/V+aBlBOL4R3Ntwp/yfNO3X/t2/E4f+DkfHE7JgyuUyvndQyWg0 upwyK9LNDHO9vr6WbmMjbwZkWv4Lw87lcplMRpLcydIZAp1OpyUUxJxSA84NL8fMw8PDfD4Pn/Z6 vZBsY8QhBZoQCjQhL0khGoXvvpvTaxaqzmbXDx7+bNq7u5P4aYnfkBGE41QqFekP+79/+Zc/Y+o3 IoQsjnq9Lg4dDoeX4NDYRTwedzqdRqkUw4/Feo+Pj+V4pPKLOQ8djnDisD94M9x6fBH2lUgkjH0F g0HJl2fouLm3mxBCgSZkqXw6mYQWfzqp/cWh7sflSfekr1cqHx6GZ5hHEI6Am6XkBzAG5hNCXplD C51OZ0bcCA5jJHx5cfsihFCgCXkB3s3lVGy09hH7rAQanz8/F4H+hqo6No1UKiW1HlhZl5DlO/TO zg5dkxBCgSZk4XyzVjOyc3xid3fGmn9xePgnkch7b7s9S5Skz+frTKqGSAhZqEOzrjUhhAJNyMKB EBvhGf98c/P8DXa7XRn9s7u7yxs5Ict0aIkYZoURQggFmpCF87FAQI0R9Lxnke+2Wi3pDEtMGXFI CFkEpVJJxvJygB0hhAJNyGL58/19VdD71NobuRR6MA/SJ4QswaHlq5fJZNgahBAKNCGLolOvfzad /r7V4/evrq4kKUdxUv5pQsiCkJom+OqZ874RQggFmpD1IJlM4kbudrvN5X8JIYvm5OQEXz2Hw1Gr 1dgahBAK9MrR6XQqlQr+Rj9quFiv14NR3d3djS/qdrtYJAkc2u12cyay8uwVsJ3x+djytGPDuVxf X19dXRWLRQtTmW4muCp2d3elpMLSMtQSQsD+/r7UOmE+HEIIBXqFgIPGYjFtiNPpPDs7m/O9cNNp hVjld/8TVcpue3tbm4msPHuFgSr6Oo7D4YjH42arK5fLUnvWwG63p9NpftbPAS3s8/nQmJFIhEk5 CFkaeP4PBoNS6JutQQihQK8EMCG4ps1mgzTXarVCobCzs4O/1HM69JwCjc1eDTk8PJQ7wZWJRqNh /q9LMbKCCDQczpiJg8T2xZVhdbLfVqvlUJyenuLwSqUS1pTbzwkLUz8PfAr4XNCSyWSSrUHI0mg2 m5LY7vz8nK1BCKFAvzz5fH5El7vd7tbWFjzJQoGeZ76ZLcWEC0XTtre3R2bigL1eLxZJzTwJGczl cuPr2O12hh88E3zikhkgO70SOCFkQX+r8e0rl8tsDUIIBfqFuby89Pv91YdVnaUE3TyuuQoCPRgO cROlw8EYMm0mk8ngva1Wa9pOG41GOp3G2/E40el0CgpZhBcjRo4Ww4mYI7DxdpwU3h6Px0eyVWBN rH97e3t4eIiN40aIOSPhjLVaDTMnRpOvGmhJiYrhjZyQZXJ8fCy/wnFQByGEAr1y9Pv99eqBBnBW o9dZ9G5nZ0eiPuYE77XZbDjrSCSCXXu9XjxXGPvCi5HjkX5uQ5QvLi7wdofDgTWlO3x/f98IFJaQ Fem4lXMfT6uMA8be1yW2+OjoSJJyzHggIYRYC7xZxiEwhooQQoFeOc7Pz+cvfyUCDWU8GCMcDi9H oKvVqtPptNvt0qcLBzXGLEKCE4lEPp+f3ZvebrexhUAgYGxB+uDnFOhyuQw5xvkancqyFFZtHDZI pVLNZrNUKuFgcLTmE4GGYgtrVO0PTSSx8mg0RsUQsjTkrw0Y+dmQEEKBJi+JdMTOn6pMBHoGlgs0 THfbhPTHjBTrgt5dXl7CaI1OXwgrnH5agIQ8M5hLFWBNs+POFmhJMjXS4Y2HCuMtWOrxeMxLJc7E 6L49OzvDf9frjoinBWn8vb09fnEIWRoSyBEMBtkUhBAK9EoAB4VxwopmJFeeKNDLDOGA126ZwNHC X6dVyIPkXV9fHx0dud1uiR2cmEhVdHZkEe5Pcwo0NoujOnmIyKUouzlJiLndToc1t/HEEggE1u6C qdfrDoeD6U0IWSa9Xk/+oHEgLyGEAv3yyDi8UCg0vz0PViYGevwGMz5H0udNTM8nJUJGZkoP9zwC jUUjWm8gfcwTmwhLRZqr1er6ZqcqFArSzY8HFX6JCFkO8lcUf0M4mpAQCjR5Mfr9/t7engx0e2w8 66oJNOx/WlBBo9GYdqji1iM90OFweE6BNkdrTL6+J+1XtlCr1fDoAgddi/wbE5EAGIfDwaBMQpb2 RxuP3/Mn7CeEUKCJ9UgAw9HR0RNSQKxgD7T0B49nh7i9vZ02el0Sd5gT1fV6PUmpYQg0tml+SyQS MQRa6jiOxEDHFTMEutlsYn46nYZ/r3uBMXkC8Xg8j/r5ghDyZAqFgmTCYSc0IRRo8gLc3NyIlTbH EJ+uVquQ3WlBxiso0MaPm3ghHer4F3KMOw2ceGJuu06n43K5jIgLnLikaTP2Jc8YUk4cXF9fS9yC NEupVMJrcxYOGRQIsZ4h0OLlkE4szefza30VocUk6UooFOLtnJDlIJ3Qxt8lQggFmiwPI+PbOHDo t/ruasZAn56e2u32kdOBIpvzbIwACZZceBBB7Bq2Lek+ZGmtVpPRcl6vF8qL16lUypwH+vz8fCQP tN/vN6IypjVRNpuVA1uX9M8zaLfbaDdJgM2vFSFLQP6WruP4Y0IIBXrtyeVyV1OQ7ttGoyGF9KZp E5bCPscXTXvj7A0aRzVS+c+4YcyQYDOtViuTyRwdHcFc8e/l5eXE/Bsj5yKVCCH3cF/o4EiqZik0 CHXGKciJmyMWINmyAnaHRWYnntZEErG9RumfZ2M8ZhjZRQghi8NIxzHxzwshhAJNyAswItCL4OLi YmLV8fVFIoJsNhte8BIiZNFI9qTDw0M2BSEUaEJev0Df3t7m83m32727u/vK2i2dTktSjlqtxquI kIUiSTBH6jQRQijQhLxOgZYQ7dea+k1KM6IBmZSDkCX8pWIUByEUaEJWhXK5vDi7LRQKIyHUr4le rxcKhWTE5ysYH0nIKpNIJKYl6CSEUKAJIesEng1keBOjMwlZKDLwIBwOsykIoUATQtaeSqUiSTnW tEo5IWvB3d0dvmVOp5NNQQgFmhDyGri+vpakHHMmHySEPAH5tWdilShCCAWaLI+rq6vt7e2JEcDt dhuLjNpXeG0k/d3b23tOSmPzpkbAZrFxS04Nm9pWGFVOzFQqFVlqnDv2ay7oPQM5d5yC/HdiDopW qyVLN0coT05OpHvsNWXrI2SliEQi+JZNzJ1PCKFAk2VLz8Ty3c1m01xH0Fxj75lpK6aV6xNznViY 8GmaLoUJLy8vx5fG43FZapy7jHA3XhvACDHf7XYbc0Txpeg3SKVS49uHXsvSjaq+G4vFcMo+n++t tWwIIU/g6OgIX7GLiws2BSEUaLKiAt3r9TBfqnyvr0C7XK6dnZ2RRf1+H/MlwdxEgZ6niUSgsR2v 1zv+rkAgINvfKIHudrs4cZw12pxJOQhZ0F9so1+DEEKBJisn0DOsd6JAt9vtRqMxresRS+HiIlXz CDRUDFubGH3xKIE+PDy02Wwj27m9vcWiaDT6fIHG9vHvSAwMjhwzpTt2owR6oGJXJEwzHo/z+0WI tZydneHLdXx8zKYghAJNVkigc7kcdDMcDsNf5w/hKJVKfr9fIhbw9r29PbNG1+t1bFCWulwuycQ0 W6AzmYxkdRDNlSTK2A7+u7+/b15fZk7sjxGBxqmNR3HAegOBwMi5P02gxcVHojjS6TTOFDvdQIEe qLza0vs+MXiGEPJk8Pdkxt9PQggFmryAQJvteTB3DDTsGe/yer3X19fYztnZGdwXeiqdzTBpt9uN OXBiLIVZilrNEGhsDetfXFxgy1gf/zW2FgqFsKjX6xnrw1yxNSPOZFyg8cLj8ZijOPB22C22bIlA Y9c4qpEoDp/PB0eXW90GCrRxm8dnN8+PG4QQCjQhhAK9lgI9Ys/zC3QwGHQ6neZKe2ZxhKfidT6f N5bK6LoZAo2lcPGR9WXUOSwcr7PZrLEUcjytrIAh0IlEwhzFgYORPFBWCfT5+bk5igMvZP1NFmiQ TCblNwem3CLEKuSvzXOSIBFCKNDEMoGWjl6/32/Y85wCLYn9Y7GYeZvYiIReDFSfMRTKvBSqPVug Z6yPLdvt9kgkIosmhmeMC3SpVDKvtr+/L85tlUC3Wi1zFAdeQOtHHiQ2kH6/Lym3Rq4rQsgz/2Jz ECEhFGiyEn+OgV1hzuA7j0CLm04E6ixrygszTqdzhkCPD0/E1oyZ0F+jO/nw8BDHPE3ODIEemKI4 er2ew+GQgnlWCTRew8iNKA68kP6hDRdoeeCR4HiYNJNyEPJ85IeddDrNpiCEAk1eXqBjsZiEMkN2 DdGZR6ClDzgajV6NIWEbWDMYDI7s1OVyzRDo8fUlLZq8lkF7FxcXosIjYwqnCbQRxZHL5TCz1WpZ K9BGFEe5XMYL/EuBFhqNBj5utANu/Py6EfJM9vb2RsLYCCEUaPJiAi12eHx8jNdnZ2fzC7SEcIzU DoSCwyAlKhriC8019z52Op1HhXDIYZhj/jweD1aTUGb49DwCLV57eXkJ1zdc3EKBNqI4cJxGVzQF WkDT4emFTUHI8wkGg8YjOiGEAk1WQqB7vR4k0gjkmH8Q4Ujshwz1k0ylFxcXeI05xtJ5BhGaBx1C SUdEGZ4KIYMKS6jxPAI9UJEV4XAYh2oEQ1so0LI7v9+PQzKCoSnQBpLRD58ab/yEPAfJ78lKn4RQ oMkKCfRgGJIhgRxzCnSlUoGVulyus7OzQqEAfcR/3W63hCljO9BKmBPmY2kymZQbwAyBdijg2Vhf 6taOxGnIgU2roT1NoCXhnTkdh7UCLY4IarUaBXocqZ2OC0PiZwghj0VGVI/8RkcIoUCTF+D8/Bzi aO4XTCQSmJPNZiE6eCHj7cQvjfJX4XDYHLYBh97Z2ZGf6WHP0WjUnLms0+nANWWpx+O5ubkxb2qE PQVkVAJnYdJw7vHxZyLHs/OjYTvmquDVahX/NYv7yLnjpCZWER9vIgGngPmGDsLL8V9zwulcLoc5 koCP4ENE4+BTCwQCTMpByBMoFAr4Bk1L3EkIoUCTdTUko1j3RMy5oudhxvp+v388WQdZcfAo5fP5 jBSHhJBHIT+jsY43IRRoQp6CdMOwZ3cdqdfrTqeTiWwJeQLjQ0QIIRRoQt4OrEsGAvp8PuYVXlNu b28lnsdcb5IQMhv8xcOfPo4gJIQCTcijubq6gjpHIhFj6B5ZRyRttsPhqFQqbA1C5kFyceIPIJuC EAo0IWRDOTw8lKQcj42MJ2QzkQDoeDzOpiCEAk0I2VD6/b4EdIZCoV6vxwYhZDZ+v3926ShCCAWa EPL6kcR/43m+CSEjNBoNfFOcTifHfhBCgSaEbDq1Wk0K66TTabYGIdM4OzvjoyYhFGhCCLnn5uZG knLgBVuDkImEQiEmriGEAk0IIW84PT2VpBxGFXRCiEG9XpcvCEcLEEKBJoSQN+zv70MRtra2mJSD kBGSySS+HYeHh2wKQijQhBDyhl6vJz9Sh8NhDpMixABfB4/Hg69GqVRiaxBCgSaEkAe0220RhYOD A7YGIUKhUGD9FEIIBZoQMpVqtSpJOc7Pz9kahIBIJIJvxOnpKZuCEAo0IYRMJpfLQRdsNluhUGBr kA1H0j/b7fa7uzu2BiEUaEIImcrJyYnkHKjX62wNsskkEgkOHySEUKAJIXOxt7cHb/B6vZ1Oh61B NhNc/BLRxPSOhBAKNCHk7XS73WAwCHXY2dlhUg6ymZyfn8tXgE1BCKFAE0LmotVqud1uCMTR0RFb g2wavV5Prv98Ps/WIIRQoAkh81Iul+12Oxwik8mwNchGcXFxgSs/EAiwKQghFGhCyOPIZrOSlKNY LLI1yIbQ7/e9Xi+7nwkhFGhCyBNJpVIwCZfL1Wg02BpkE7i6usI17/f72RSEEAo0IeQp9Pt9qSXh 8/m63S4bhLz6C166n6HRbA1CCAWaEPJE4M1+vx9Ksbu7y6Qc5HVzeXkpORx5qRNCKNCEkGfRbDYl KcHx8TFbg7xWjOQbuVyOrUEIoUATQp5LsVi02Wz8aZu8YtLpNK7wYDDIpiCEUKAJIdYgv25Do0ul EluDvDI6nY7T6cQVzpwzhBAKNCHEShKJBAzD7XY3m022BnlNHB8fs/QgIYQCTQixnn6/v7u7KzUm mJSDvBoajYZEKFWrVbYGIYQCTQixGHizz+eDakSjUbYGeR1IrsbDw0M2BSGEAk0IWQj1el2iRVOp FFuDrDu3t7e4mHFJt9tttgYhhAJNCFmgc8hP3tlslq1B1pd+vy+/qJyenrI1CCEUaELIYslkMtAO h8NRqVTYGmRNOT8/Z+UUQggFmhCyPA4PDyUpB3/7JusIrlsJRrq5uWFrEEIo0ISQZdDv97e3t6X2 BJNykLVjb2+Pw2EJIRRoQsiyubu783q9sJD9/X22BlkjZOygw+FgUnNCCAWaELJs6vU6LAQukk6n 2RpkLej1evLgx7GDhBAKNCHkZbi5uZGkHPl8nq1BVp+TkxNcrn6/n2MHCSEUaELIi3F6eio/iLOW G1lxcInK816pVGJrEEIo0ISQl+Tg4ABS4vF4mJSDrCz9fj8QCOBCjcfjbA1CCAWaEPLyahIKhaAm 4XCYv4yT1USCN7a2tpg3hhBCgSaErATtdtvj8UBQDg4O2Bpk1TCCN4rFIluDEEKBJoSskKNIUg7m NyArBYM3CCEUaELI6pLP56EpNputUCiwNciKwOANQggFmhCy0qTTaUnKUa/X2RrkxWHwBiGEAk0I WQOkTrLX6727u2NrkBeEwRuEEAo0IWQ96Ha7wWAQ1rK9vc2kHOQFYfAGIYQCTQhZG9rtttvthrsc HR2xNciLwOANQggFmhCyZlQqFbvdDn3JZDJsDbJker0egzcIIRRoQsj6kc1mJSnH7e0tW4Msk0Qi IYH4DN4ghFCgCSFrRiqVgsc4nc5Go8HWIMvh5uZGntyq1SpbgxBCgSaErB/RaBQ24/P52BdIlkC7 3Xa5XLjkzs7O2BqEEAo0IWQtgTf7/X4Ize7uLpNykEWzs7MjFxubghBCgSaErDHNZlOSciQSCbYG WRxnZ2e4zFwuV7vdZmsQQijQhJD1plQqSU6xy8tLtgZZBJVKRa4xVpInhFCgCSGvhKurKxnaBZlm axBr6Xa7Xq+Xv3IQQijQhJDXhiQXc7vdzWaTrUEsZH9/H5dWIBDo9XpsDUIIBZoQ8nro9/u7u7sQ Hb/fz6QcxCqur69xUTkcjnq9ztYghFCgCSGvDXizz+eD7kQiEbYGeT6NRgPqzJqXhBAKNCHklRuP ZOpNpVJsDfIcjJLde3t7bA1CCAWaEPKaub29lYQJ2WyWrUGezMHBAUt2E0Io0ISQTSGTyUB97HZ7 uVxma5AnIHldHA5HrVZjaxBCKNCEkI3g6OhIknKw7AV5LNVqFU9fuH6g0WwNQggFmhCyKfT7fSm8 HAwG+RM8mZ9OpyNZn/EMxtYghFCgCSGbxd3dnZgQB4GR+YlGo/LcxazPhBAKNCFkE6nX65KG7OTk hK1B3srp6SmuFqfTyXI8hBAKNCFkcykUCpKUI5/PszXIDIrFolwqNzc3bA1CCAWaELLRnJ2dSUaF arXK1iATabfbbrcb10kymWRrEEIo0IQQcp/T1+PxMCkHGccYcop/8ZoNQgihQBNCiG5I4XAYhhQK hTg4jIwQj8eZ9JAQQoEmhJBR4EZbW1vwpIODA7YGMZCaKTabjWV3CCEUaEIIGaVarUpSjtPTU7YG AZVKRWqmXF5esjUIIRRoQgiZQD6fl+5GZlog7Xbb4/Hgejg8PGRrEEIo0IQQMpV0Oi1JOWq1Gltj Y+n3+9vb27gS8C8HDhJCKNCEEPIW9vf3YU5er/fu7o6tsZnIwEEmZiGEUKAJIWQuer1eMBhk7+PG cnl5iU/fbrdXKhW2BiGEAk0IIXNhFM5g/OumUS6XpeLg1dUVW4MQQoEmhJBHUKlUJCnHxcUFW2PT Hpzi8ThbgxBCgSaEkEdzfX0tSTlub2/ZGq+efr8fCoUYukMIoUATQsizSKVSMCqn01mv19karxup 6L61tcWBg4QQCjQhhDyLaDQKr/L5fJ1Oh63xWjk9PZX0hdVqla1BCKFAE0LIs+h2u4FAAHa1u7vL X/ZfJTc3NzJwMJ/PszUIIRRoQgixgFarJWPLEokEW+OVUavVZLRoOp1maxBCKNCEEGIZpVJJOikv Ly/ZGq+Gdru9tbWFj3V/f5+tQQihQBNCiMVcXV1JUo5iscjWeAX0+/1wOIzPNBQK9Xo9NgghhAJN CCHWk0wm4Vsul6vZbLI11h1Ju8F63YQQCjQhhCyQfr+/u7sL6/L7/d1ulw2yvpydnTHtBiGEAk0I IcsA3uzz+eBekUiESTnWlEKhwLQbhBAKNCGELI9Go+FyuaBfyWSSrbF2GGk3Tk5O2BqEEAo0IYQs iWKxKF2Y2WyWrbFGGGk39vb22BqEEAo0IYQslcvLS3iY3W4vl8tsjbWg2+2GQiF8auFwmGk3CCEU aEIIeQGOjo5gY263u9VqsTVWn1gshs/L6/Uy7QYhhAJNCCEvQ7/f39nZgZMFAgEm5VhxJAWhw+Go 1+tsDUIIBZoQQl6MTqcjSTkYU7vKGEVwbm9v2RqEEAo0IYS8MPV6nVkdVhljxCfLsBNCKNCEELIq GHmFr6+v2Rqr9njjdDqZc5AQQoEmhJCV4/z8nJXtVo12u+31evG5RKNRtgYhhAJNCCErx+HhIVzN 4/EwycMq0O/3w+EwPpFgMMghnoQQCjQhhKy0sYVCIaYZfnH29/f5PEMIoUATQsiqYxS6g72xNV6Q k5MTiaip1WpsDUIIBZoQYiXlcrlUKs2/frfbvbq6mvgWuCMWSQRwoVC4mkmj0XjrCgOVfcxMLpcr FouyaPzAstkstCmVSp2dnb1gIDKMTZJypNNpXmAvAq4ESVqH65CtQQihQBNCrEQSFBwcHMz/lmaz CTWZ+BaorZHKbXt7W5uJ5OWdvYL+F2QKwWDQXA4jn89LpgUzkUjkpSJfb25ubAq84GW2ZPB0JxlR MpkMW4MQQoEmhFhJtVp1u93TbPiZAo2NF4dIegq8pWii3W6b/+tWjKwgAj0yP5vN7u3tYb7f7+/3 +1in0WhAmLBaoVDAu3q9Xq1Ww+6wTiwWe6nmTafTDCFYPrgYXC4XWj4ej7M1CCEUaEKIZUAxoXdw u8UJ9DzzzWwpJvwF0bSJ83d3d7FIqspJtOv4j/Uynq/Var1UO8sgNhw/B7EtB6MqZCQSkYcrQgih QBNCrEHCJ6LRKORyTQVapFnCPBKJBF6Ph2Xn8/lkMokDfsEHlVAohGPb3t6mzy0atLAEDgUCASat I4RQoAkhFlOpVIwxdmsq0EdHR1iUy+UGKuAYr71eL/67aubUbrc9Hg8O7/DwkBfeQpGgHbfbzf5+ QggFmhCy4K/okwQamrI9RiAQWIJA9/t9iLLdbnc6nYYuJ5NJGTiI+TgS7AsPCavzuCJJOc7Pz3m9 LQgj4nx1PndCCKFAE0KBfiDQMJWtMSSi2nKBttlsxi6kN1dEOZ/Pm9esVqvxeFxyMAsQ+hXRqevr a2ZVWxx4oJLmHbkkCCGEAk0IWSGBXmYIh3QqG2DX6XR6RmRzo9HIZDIyyhCiPzFp9PKRoG2n02nO vkeej9HBf3p6ytYghFCgCSEU6Kkx0Ab9fr+uGF90dnaGtycSiRVp6lgshuPx+XydTocXniW0Wi35 3YMh5oQQCjQhhAI9r0D3ej1JczG+6O7uDov29vZWpKm73a6Eie/s7DAph4XtySQnhBAKNCGEAv0I gR4M8z1jLyPzJTQ2lUqtTmsbPaZHR0e89p4DjDkSibBHnxBCgSaErIRAl0olzLm8vFwXgZbSzXa7 /fj4GPvCEVYqFXizVIpZtaRm5XIZh4rzmtbCZB7wWaMNXS4XY8oJIRRoQsjLC7SUWZnWLb2CAg0K hYI5/4aRhcNId71SSAtD+sd7zck84NmDDUgIoUATQl4MKMhIH1673R6fadDr9aYt7XQ60gE853wz ZcXEw5s4f9pG4KYw9UwmM16YcKWQxNUul2tFkoSsEbe3t1Bnow4lIYRQoAkhZCMwh/Cy7vT84MnN 6XSi3fAEwtYghFCgCSFks4A3+/1+uCBMmkkk5uHu7s7r9aLFotEoW4MQQoEmhJBNpNlsulwu9qfO A54xJN1KMBhknz0hhAJNCCGbS7FYZETvPBwcHKCVVjCtCiGEUKAJIWTZGDkl5h8uuWmk02kpzL6a aVUIIYQCTQghyyaRSEj3aqvVYmuMkM/n5QEDL6zdcrfbhZqHQqGtra1wOIzX8weHXF1dbW9vTxT6 09NTLGortmeCNfHRz15noLI0js/f3d1NpVIz+uP7/f7R0ZEkHd/f3599OrILOR38i9eYI4vkOBfx yWLLOH1e4YRQoAkh5CnAdXZ2diR3NQN8zdRqNYfDgZax3OE6nY7P54OXx2IxmCh89FEB1icnJxPr Xw6G0SbNZnNEoKUIJXx9mkBLZXLY/IhAS+Jw83y/3y9bc7lcaKKJRyiVOLEmDvWtzx6yCzkdSdxu xBQ9tljpI/xAlWHnRU4IBZoQQp7lc0wxMdImknZjEQInBmwOPZdAkTlNfR6BnnO+wbSSQ2K34/Pl gKH+M45wzrggCjQhFGhCCFlLjCTHs6s2bgj9ft/oFe71epZvPxAIoLXNc7rd7gwfXUGBRhO5XC6b zTa+KexF4oJKpRJeG3kS0ZKYI/WJzK06j0DXajUsmhhlhE1hg+ObNcC7xpeOCDTaX7rtefETQoEm hJBHYJTZu76+3vCmSKVSC40Lx2ZHIpihbvP/ArAKAg2kh37Crfch4tDHx8cSEi3g+cG4zGYLdCQS gekabzw8PDSMfOJmLy8vjSNpNBoSniTgA725uRkXaDS+z+dzOBwrXkOUEAo0IeTR3N3d4eaXz+c7 nQ5unLgrS8Bor9fDa8wcEZSRziR5ezabHYnaxBvFKsrlMjaO1fBf/DtuPJswxu78/FwyTlQqlY29 0iR+F88SEw11QUh99TnzCYpA48MqjiEd50sQaHyPJMp54qZkd1BkvMY3VM4ukUjU63VILbbpcrkg vvIVni3QErqNCxLvPTo6wn/j8bi5HaDUOBicGnYHRcYHJ99f7HdrawsXM5QaS7FlWDJ2KhXsDYGm PRNCgSbk1XJxcWH0M+FWh/8ad9mJN34Z82QWDnM3VTgcNvRa7sGSzU3uqbgHe73eEfnGXRn36U1o apzmknMeQ24KhcKVIp1OnyhOT09lDj7fZf6wbgwcPDs7W6ay4wILBoNzVoWUi3YGlgt0NBq9GpLJ ZI6PjyXgZ9qPFXKExu52dnbwpRt/YJAg6dkCDdU2Px5HIhG0lVwSeI1GM29WIrNlUzhOvMYzs/kc 8V48eBgCLSU5ac+EUKAJeYVIKjHcwiGyMAxDpucUaJiQ5NJqtVp4O2QF98tAICCyInd63KRTqRS2 jH1BDiR806zvI3NeMWgW+cV8QeG/A9Wdj88OSoddiK2+FehaKBSKx+P4+EZ+bbAQnK9UOH9r5jUL gYPC6nw+3/zPCXLRwkGvxpCKiZYL9Dh4xJrRXz4i0CONXK1W5XjEdGcL9MiDK4QYM3EZvHWz+IuB 1yPXsPGIIle4NJflOQoJoUATQl4e3OTgT+YMX9JLOo9A4/aJ9xq6LEh/s3SeyZ3e+FF4oIbTjcyB uo30Sb9u8KCCBrTcIyuVCh5OxFAfupim7WjagZpS+CzVdDycE4I+P1gduolPJJ1Oz9DBpyERAjjC paXzOz09xR4fZc+Dl4iBxtvNgSJvbfkRgca3L5PJRCIRua7kd6Q5BXrkkGQFSVeCzcKnIcqSQ2Zk s/gLgN1N9QPT+rFYjH9mCaFAE/KqgAGPD666vb2dU6DL5bJ0YjVNlEolzIQtGXd6Y2iRYcwul0uc u9FoYAXo2kY1uxHJ8PwTh4xCnoLB4BsFxoYjmnahafhwOpo2mGNqQ4vgTZq2rWlvgnH0tBW5XG7O yIfZyA8ddrt9ORUHpdSIBBQ91tdXZBDh/AINQ5Ue30QigQdXPKNKtP0TBFq++7ii8BoPeJK/HJuV 4Q3mTUk41gyBxnccRyIbGe/SJoQCTQhZY3APHs8FKzPnEWj5wXcikUhkmotI9KRYtSRk2MAqfTh9 Scrx5B+4O50OmleCZXVcmpZQHtyfT5qnTV18Npq2/8ak4UkQsudoND5f6JSMzFtO84q3wSyfcNjr JdAy3HDkGVgCpeYR6JHuYYnIgkbLk+1I4j/5tkrcs7SweUCwhCdJdLsxiBAruBTjQ4cJoUATQtYV mM24QMu9c4ZA43Yod0fJqIC79Xi+AulonOgiMD+73S4BDHDxnZ2dzWx8CTBwOBzTCs5No9vtPlDn bU271rTe87x5fOqobuxhSIjX68Ul8TSNlmRnc6Zhfj7S/zqjREi73YZ9TotBXy+Blh98zDFRODuP x2P0+84WaFx+xmHjusL3Ec9L+JTlxyVzG+JrKyEi8nb5SQFKbaxwfX1tDA81p7GT+QzkIIQCTcir AvfLkWxZosVym4QHj9zgpSaF3B0loHlkHBLu35eXlyKF01xkb28Pd265SZsH8m8aIl7wkvmDdG9u bkSP7tW5bLU3j08wpcD9DgOBwBNiMGC0OObl9EFCi6W3G3vcegiuOllHxnFOy6O3XgKN7yPOFE+k 6XQaqoqnMpyp5JCWnM2zBdqtgPVeXFxI/XP5aQjNiM3iv1Bk/EHACsZmJcBjoNJ0SCg/NphIJHAM 2IIEzIwUUpE1GchBCAWakNeD/NprJMzq9/uhUMi4y0oFCnMnsdy8jbsjjGoksFVkQrR4motIqGU4 HIZGLygZxVqAc0droxHmSYoMAYUC3ptsSEVrDJY4QcO27kcZQqoe+6kt7VNuNBrbU4DkyTp4gf9O exLAlT9tKfQUi8afdqbNN8DWsMJ4Yo1CoTBx/mzkCI3d4WEV31B8DSVbH5biUjGiKWQXcjpyGJhj PEhAsvFpSoJnfB/N1yEej3d3d2Wz+JrDsDudDt5iVETH3wp8wWWIodPpxIO08Yxkbu2B+qULR/i0 iBpCKNCEkFWk2+1KzxPuf7gdSt5WczeVFI/AzTWZTOIuKImcDYGuVCoORTwex9ulbw+rmdPYTbRD 6Uad8Tv7hgANmqdPF48c0rGqjxG8eHag85PDoxMwaE2SaUCw+PUhhBAKNCGb69CQY2j01tbW0dGR OYRDliYSCVkai8WazWZCYbwdc/AuWDVWCAQCZ2dnRj/TjM488zgnMhs0qYw41GM2mi+hzuaprGm+ +yRlI/lVCCGEUKAJ2VBGAiUXxO7uLqScrf3WZxtJd6Bz8tLqbO6KNg7qkfG7hBBCgSaEUKCfvouL iwu29mx7llpuetjGzcrYszGl78M5zD9HEEIIoUATQoG2mEwmIzHWW1tbmzx88BH27Na02urZs0wF 7R3HOzjGvb09jg8jhBAKNCGbS7PZPDk5WVDFuFqtBtlKJBKPqq680fZcX1V7lql079DMsUAIIRRo Qgh5GaSim27PPlVke7Dy09ChzeU8CCGEUKAJIWRJHB4e3vc9r4U9Dx1aSn8bVTYIIYRQoAkhZBlI fW+9Q7eyPvYsU/a+zIpRp4MQQggFmhBCFkuxWLzP95xbN3uWKaVJUbpWq8VPkxBCKNCEELJYOp2O VGdcoXzPT5iimrnSOyGEEAo0IYQsivuCKaEXKtNt1XSnorc17ezsjJ/pQNW639vbCwaDkUikUCjk 83mjfP3l5SVe393dGSvX63XMKZVKxpxyuYwLIxAIhMPhZDJpzl1zfHyMLdzc3IRCod3d3XQ6PfJe UK1Wx2cSQijQhBDyGpDy6Xroc2Od7VmmG12g7XY7dHDDP1bYrc1m29ragvseHh7iNUwajSNLobZ4 3Ww2jfVHUrBnMhl5ezweh0Y7HA63291oNGQp5m9vb2Om0+nEu66vryWZoPkAjo6OsAWzoxNCKNCE EPIa6PV698EbF+tvzzKpPCI7Ozsb/rHCd6G53W5X5ojjzinQmA/3DYVCxtvxQAJdNsJjsGWsnEql 8Fp6ptHgeG4x1scBuFyuaDTKrxghFGhCCHltpNNp3aoCr8WeMXU0Te8V1W5ubjb2Yy0UCuOhLFIf Zx6BlqtiJKXJ0dGR8RYRaEOXDUG/vLyU/+bzefwX//IrRggFmhBCXhXtdltqm2vFVyTQmM5VKRif b2PLE0Kd9U+1WDTPPD4+nlOg9/b2JCTjwIREgIhVbynMG+/1ek6n0+j4j0ajLpeL5SEJoUATQshr 475sSux12fNADYX0bnRplZOTk3GBlpnzCLRUo9yexDSBHgy7qFut1t3dnd1uTyQS/IoRQoEmhJBX RbvdhuVoNu01jB0cn/QIAs3r9W5mJ+jl5eV4BAWM1hBoeXYyC7TEYIhAy1Jz2o0RJgp0uVzGu87P z2XvlUqF3zJCKNCEEPKqkP5IPXfy4DVOw07ozQzDbTTwVKTt7+8bc/Ag4fP5DIGWT79arY7otQi0 GPBICHU8Hg8EAkYM9LhAA+wiHA5HIhG/38+vGCEUaEIIeVVIkgRdMEvP7ujd07RtJeJXz04j3VHh yxG1wSNNK1sQCQ2f28yPWHJ7ZzIZqHO325X4CkOgpb85Go22221cDFhNouFFoDEHfow5uVyur5Cg aiPEeZpAYzWbzWa325mKmxAKNCGEvDaki1ELPkNPu/ApbZSAprWfusGKpnnGNph4hpR379NxbGYs AaR5d3dXsmJDaj0ejzkLB5xYlgpOpxMObc4DXa/Xpcda3q6X2QmFjKCOaQKNFWyKGeEfhBAKNCGE rCU7O0p+s8+tm60b6oc0DeqV0rSf1O6l/AnK274vIqj9e037NbXBD2ra+9Wc9DMOMqEkfINHs5VK pYuLi1wu1+v1ZODg+NJsNnt3d4cVisWiWXwh2ZiTUYwUFCwrxneHt7hcrkgkwq8YIRRoQgh5VcCW 9D5Fu+qjfZqYlpTa/rimfUz1HMtUGDp09ommq/1vmvZp0wZ/U820P6NXWx2nx+Phhz4YZt5Y6C5u bm7GE0gTQijQhBCy9pyfnz93+KDE037QJLsypdT83cdvULqfr8c2+LNqfuYZh6rCQkY6UCnQlnN1 dXVxceF2uzl8kBAKNCGEvEIkFvZZ8Rsx5bW/Oea7f6jmbz1yaz0VCvKjY1vDFFcbPGYUx6oLtAQF OZ3OiaEdhBAKNCGErDHdbleP37A9I35jMBw++N/GfPdjar738QIN3vcwfkOmD6pFqWccalkNbgwE +NEvlE6nU6lUzMW9CSEUaEIIeSVIwTk9XcZzMsQlldf+4pjvfkjN33v8Br1TurQDw9COJx9qT0VR axoMj58+IYQCTQgh5NHc109JPE+gG5reh/0+TfsNk+x+VIVhgNvHb1AdlPZv1UjEER13Kwl+ztFu b25FFUIIoUATQshzuU9gl392qb/UMO7i5zTtV9SQRMk6t//UfuLAMLPHL6oNBoY5iq+tOdRkMslP nxBCgSaEEPJonE5VXKRtRbnsE9UPbeboGXVP2ip9hxnn80Y6GpOeWu1NFT1CCKFAE0IImZe7u7t7 MR1YNLU07UKZ9JmK63j+Bkuqcgo2eKkqe1tykA1mgyaEEAo0IYQ8iXK5bMEIwnWcVE95r9fjNUAI oUATQgh5BNlsVhfJ2OYJtE8/71qtxmuAEEKBJoQQ8gjS6bQaT7d5Ar3LRByEEEKBJoSQx3N8fKyL 5NnmCbReg0+7urriNUAIoUATQgh5BFLMWbuiQBNCCAWaEEIIBfptqaDT6TSvAUIIBZoQQsgj2N1V scA3myfQqtLhyckJrwFCCAWaEELII9jeVlWtixRoQgihQBNCCJmDWCxmTXFsCjQhhFCgCSFkE9jc GOiEft7n5+e8BgghFGhCCCEUaGbhIIQQCjQhhCyGkxMJZdg8gd6nQBNCCAWaEEIez/n5uS6S8c0T 6JB+3qVSidcAIYQCTQgh5BHc3NzoIrm7eQLt0s+71WrxGiCEUKAJIYQ8gnq9roukd8PsuaOftN1u 5wVACKFAE0IIeRz9fl8T+psk0FX9jP1+Py8AQggFmhBCyKPx+Xy6TlY3SaCv9DOO/v/tnS1QHEvb hvetQqTqQyAQCEQEAoFARKyIiFiBQCAQCEREBCICgUAgIhAIxAoEIiICgUAgEAiqEAgEAoFAICIQ CAQiAoHgu5h7eU6nZ3dYfkPCfdWp1DI/Pd09vWeu7n2me2LCd98YY4E2xhhzb6aniwkpVt6SQH/x JNDGGGOBNsaYh7K6unqjk1NvSaCLMfeDgwPffWOMBdoYY8y9ab1HOPBm7Pnspri9vb1XV1e++8YY C7QxxpiH0N9fTOp28jYEeq2YuG9szPfdGGMs0MYY80C+fCmCghffhkBPOADaGGMs0MYY8zh2dnZu pHL0Ddjzr1rtnZdQMcYYC7QxxjyOq6urVhTH0ZuI3/j06ZNvujHGWKCNMeZRtKI45v91gR6/KeX3 79+fqRovLi5+lri8vLzzxLOzs93d3ePjY1JIP3B6duTh4SHbT05O2m6/81q6EP8+X1siD21z/gqh nruptOe7tP/P8wf5ixqqBdoYY14p+/v7N2rZV6td/rv2fNRawRs3faZqnJycrJXoxpN+/LhZ3OXz 588crA8819uu9vL+/fu2g+hs7+/v7/JC/Ks/9/b2ZmZmnrYSlPNv3769/mZPPZPVZ1Koo6Oj6enp +PP09HRqaiqupUv7/zx/kL+ooVqgjTHm9VKv1++3ogpHzv1R4T4tRpQP77d+ytevX5+vDkdGRhDZ b7/TjZ+VBZqNQ0NDmRNrzsHBwcGenp5fv36lcsb2VNc6gTGTOP+Gdj95QIsFWlCxVG+na33//l13 2VigLdDGGPMXs7GxcSOYQ93J6EUxXA0jf2gZ8I3bDHzsevrn4vXBcvDDU4HRPljQDw4OOHdpaUmK PDs7y8aZmRk+syUOW15eVggK/3K/Yvv6+no6rtw9Fug/JdDGAm2BNsaYf4Grq6uhoaEbx1zvTkkP Wkv61XowvkKpX0adf7amorthvDDjbs6ar7WNiHhCFAbzsABrybecuLe3V4moS5Mm2Gg0RkZGOLin p+fLly+xXaodkc18QAs4GIcbGxvDy2O4Okagz8/P+cC1BgYG+LC5uVmdQxLJgj34M+0t0H5IZ21t LbxkZ2dncnKSPExNTcWYt0Zes1lQuHp5YyRLmqTwqYCLpktIzs3NkSB9DE5nL5fTXu6FTpmenq7o Mt0pteziEqpGeimqvbRLQ85VxvHxcTowsToPh1GxVC8fyCG1py8XB/P5+vcRaBX/8vKSXbprCwsL 3KA0J9vb21EiMsDpZKxTttUAyDPHk2A5tZSLi4vFxUVdl0tkLYFcNZtNJcWly/FI3GVVPjWwsrKS 1kD2XaB0kWfln4LwleTESLZTfXZDN2nSliLNOwWamiHPKrt+HYpdagnUKpnUAXwfn69zboE2xphX jYY2a++7DszgsK+FQN8EFtRqP2q1q+dUZy73rTWQfDP8vNr1iSetsw4PD5+v9rCHm97H+rqUqxsr TUFTZJCkI6Xj+R3hHJLsd+/eSUFIf3BwMM4dHh5GrPUZg8Tb+vr6kCHOZReJfPjwQXsjBhrHIhES 5Eg+3Dl6jWfcTNNydKQ/+aAuTNinJkMMgea6WL6shavwGQWMXkE2D3e9Xk8Ha1Owk5ufGT5+pCx8 7ilIQ1AoGuUdHR3lQtpLBXJFCffNIpsDA52i3qsFmpqkckicmsTASFmVGSKlfgs1TzoIKJ/5V37G pTlX2UDCZmdnyQYHUFL9vJDGQKtuOZJjkD8SVAXG2406AAXnrChvpxpD40iHS5PnaABpalnPjV0c rNYiy8enwyCVGcoVSaX3jtYYNcA9Ug+hpWVJ0xXpkLw6GAroh9XVVTbSH+tUn92QpSl91+vRaZq0 E6VZLdDsVawUx3Munzl4eXk5/R7RIKk6/lXZuS9/4y8MFmhjjHmCQWgezDcPn6X7eO0BXnA7JMwT dvN51LlZrDcuprseeNZ/U7Xy4/zJkU7pac0Dlacpnx/5ih62hLXo89bWFgniqRrMi+gOVJjPMbbH pXmox4Oce4qThftmLxF2H8IRQSb6E5PgKmlSZIAtCJm8JNVcnavhfzSuv7+fZpYKXyePkW0vLCzE FlVC1KpsKbRGoSxcOhwXF8zCXboXaDKJBMd4M8Uh5RBo5S29v+p/RmaqQzjaCnSIvrRP2abXJ40L lZRodhJoVDjrKyq1uB0pdHjYFT09LkHrjYXulcmoPTaql6LE1WXicpEx+gZs4R51I9ByWdoDpabZ 3Fmf3Qh0pHl+fs6/ag/p7yRKU32AaoEmt2lDIjX15VSN+h5RnPjZRP3n6HtYoI0x5m2hl9j+1/e/ +xnqdTH8PJRodPOJgjp+FtEX/bcpf+IJds8U9lqTbzz34ikajpI9aPRO41IPCE0O5udvQk/0+zse gNloHFFKKrfAfkKs9Wc28o0uhPY9WKBhcHCw0WhEYUHhH9oyNDSkvfKSGImMC8UYufwvxBQ/7mSx bMR4svADSVski+PGLvUl6vV61p47SViFQOOImbuHiaomKWz2KqfyEx2e+wp03MHrImAjxlBlpWl4 AG2AUncSaNJBHNMtuum4cvlg7aKYMT5NbatQihTKmodi9NVbU22kXys+Y5DS624Een9/P/beWZ9d CnQa4SMJzobeoylWCLR2ZflX2bVR9Za2K7W9v/HFUAu0McY8DePjxWzJE/eX3atCo9/fyu67Yqh4 o1j/775JnaMPtVrjNj7kJgqhVtt+0NB1Eaj9R14V0hOX+nxwChrkkxBjqDhr7Orv79efCBbinlrC 1dUVGsEzHv+emJhAtp5EoGdmZnQh4ANejiVLiTSKLOFr6yXvC9q66Z15QE3oliArEUUQx3Nuqstl b5NAd7r7FQKtilLYSTZ+qZqk/hXinKI4jYcJdJqNNNuKBsmyR9+sk0BHJaPRVDL3SA2gbUeObp6C EygLR3JMdFcU00+FZ2WM+icPlLejlnUh0Gmjra5PMpbObNM2FktppiEfvQWd0qwQaHVKFViSQiYV DaXmkfVULdDGGPOmOT091RP3xoavH6TRPH3GkpmQ3xUjx/O12lYxGfNlh0W2D4v3F78Wi4rXfrfw /YcOYH9txVT8kcUy9MStFp1qpKpzc3My1JWVldg1PT2tn9pHR0dTsd7b25MSyX6mpqY48kkEWjaP U+oDEoNhaHBU04NoMPJOgb4uoiP0J7mtePPy169fMbW2YrUj2qFT/p9KoFWi7J051Z42RpbK6G3O pxLotq6cJZ6pc+tt4CJsmgpUUEenX0Iw5sXFRf1aogAYDTArD6rhDIVxZ/f0AQKdHV9RnwpnD9qW 5V5pRqxR27aRfU3SZqwR8bQlWKCNMca0UGRkrbeIoHhM9EWzmGauzGAxUD1cRH28TyI0Um+eKAz+ /BEZ2GkJwbO+Oximu76+Xp6jAP1N430fQKPRQG6kqun8D3qES0Djp2S0AGPA2re2tuLXcAVMP16g KSPKjl3Nz89r6FFaT96USR3WjUArqkTLuChyuu0V9Y6a+g+ppryAQJenQMmsmhqovrNPJdD6RSjr AXZ6iZAOFdu5TXyFI6K6kw6We87cF8k33SSFCVXM9cEdLw+N07lSP6psk+mromXZpddXUZ9aaDNo u5RmOc0YMG5LhUAr1D571fW6GNJWe7NAG2OMaU9r5K/+FEulXBRjz/PFsPRQEpWRGfNIIc3I3u5T XPSs9dJhvPf23AKNCOIH6S/IGqlFNx+TMvnXRBCZMCnmUqPLMTmGxCu7om6lgrMfI9BKanh4GBNK o5A1OUa8PtWNQJ+fn3MK+USbKtZ/0RQQaZWqgC8g0ORQEyykboqNhTapVlOz5wCcMqZKzGZKUeT3 AwRab6elEcwKDWor0Kr8rEp16bYCTevihqazlKjnQKeI4uDH+HRa/4gsN0XfKXVv0phjzc2i8WlN UhG7NIdMhUDfWZ93Uk5Tr8+W01TrrRBoKoT2GX3C1KrVo7BAG2OMaQ8C0ZoQaup55nL+WYRznBQf zp46/V+tOBAk5l5TyT4GzcLBv/Ge38DAAAoSo2U8eh/wfFUoKvJRntADleExn8ahakh4dHRUSqSp hdNfvTOBRp7IIVnVqKEmJ247XYPQTxNcNFLQm2Tp6Hg3Ai250UQl6ctzGRp8jUBk8qnx0RcQ6BBE CkjRtC53ujY790UT28nPqGp5avReNGkDByt9WTI1rD+7F2hSjkFljqE2VAltBVrmxy41ABo/V9Tk IeXx1LihFE3H86/qXD/aKGNkVXspqWLQ1UL4k2YZNUA7xzi5lrpzmh1P945dctkKgb6zPh8g0Jo4 JdKkFDpGFVs9C4e+zlw9/TrHRHUWaGOMMR3hQSjFuZl9+frv+e+qtdJKNrT23Pz69UvygTcoCpl/ UxlVh+QBKSskvTwXm+boyJ7Z0j5unOQY2VK8hEaIM4HWDA8x1Zf0ouK3fo0cp7anmcK4SjYIeqdA azwvHaMto5mYdSs1KS+lq9frqIz6Rc8q0FyCalF51S2RQ8eYK2VX9pQ3mWh02FTt8RYpOdExKnL3 Aq0hZw1+C9yORNI6T9HMfWoA/f391JXefey0RmZ0DNQ+NZF21IA8Mpo0H9JA/M3NTdWAzmVvNB7u ryY6bE2fUyxzUyHQd9bnAwRaDV7/EyunWS3QeLMS5PT4OocxW6CNMcZUsb293RKIlb9HoGdb75yl EcMvxv7+/tLSEk9lfDeLW2VXOUi6GxQAWn4P8uzsjO3l6fmUB0QKiZErcJjGFHVKGkLKLcYGtJca azQa1eu/ZKWg28CfaVWTzxh2Tc9K5yy7LiJuu5kdhayurq5yWIzdnpycRG2QZhbgnmWGHlQ5MwFH tq3YrM/AMZJm9VjS1Ni7trZG9paXl8uh9nSfqNvoRNEj5U91hHTp6HJk2WibbU6P210de0NuyQ+5 4lYqWfKQxlqUGxi6r0ouNyeyijRrbzn4mKyqBrhN2V7dO9ohbYx2SDrRBtLiZ7VdUZ/V3JkmZUzT bNtQ29YM36aoyfSrl/XPs7ZngTbGmDeNQjBvaP419pyugGC6BxvGzF5mRWKkhNv03JNzPxgMaXR0 NHuJUIvUvFhQkMBBceXUzBSo8zcOdhoLtDHGvCHix+jX7tCFPf9f7/9VhNWaCpYLXsAIuYrejHzN tTE8PEwmcWiE9fDwUD/oP/KV0Aeg2TDq9bqGS7e2trRMesWIsjEWaGOMeWUOvVAEGb82df7VinvG nivegTOvAcW5Dg0NvdrhZ3F8fNxa2b7WWsxybm7uhYefo8vRmpr9Nlg5W+HFGAu0Mca8UlZWVlrx 0OMPWlzw+f47KabAK173sT2/fk5OTrhNf2ppmwfkdnd3d39/v9Nk1S8D1XVwcEBOYspCYyzQxhjz d7Czs9PfX6x6MlxMQvca7Hm7tQ7L8PDw3/gGjzHGWKCNMeYf5+fPn63ftXuK6e3+YDjHRa32uRYz hf3ZAUJjjLFAG2OM6QiqqjUOitlxa7WDP2HPW8V64EVk6gu892bM03J1ddV2PeoKLi4u/kgEtrFA G2OMeTJ2d3dbSxXeLE5QBCK/jDrv1mqfWpet1+tvPGyj2WxyF7IplsXc3By7TgveV8KRWiq8guti keds48jIyKdPnzj9ZWa+e0loVzFDsCr5qV555ItDu1UD7u3t/fz5c7VJHx0dxaqNWs5jdnb2JVcI 6p509ptYMfvBdP8+g1pm23n9tKvtF+ROouVTlrbrPlqgjTHGPITLy8v5+fnWemM9RUDF8XOq836t NtZS576+vtXVVd8CLWLXdtLrWGYPP/uUMDAwoL5HbFlaWsLJ4k+F6GipjuD6dvW1bLtSQ+/uu+zF a2Z9fT2dSry8UuBjpJCU+/v7qXPcjmrXWtOdhBjzo275ik1OTi4sLHA8MqeI//Pz81dVaV++fEkt s3qplzsZHx/v/nS1zLardbZdMrBbsyy4fsQaohZoY4wxHcHPeHbGisc3w8Prtdrl03nzebEO4sh/ 6ozQvM4RuNcp0F1uDzotfy0XKW9fXl5m+9jY2Fuo1Uci/U1n0lDtaaH1Mkgk9px1TpBvTkGmX1Wl kdUnFOh7nR4CTc8k61c8RqD7Cq6LGcH5/5sF2hhjzNNzcnIyMzMTPzTX+oq4Dh5eZ4+YnG6lmDLv XSvJgYGBhYWFf0OdtVbz2tra3t5e+vojn1HbqwJ2bWxsVEdHvAaBBm5NtWGgNTs7O5ubm+XiXF5e 7u/vr6+vHxwcpDG+bCeTmu2OXVRFNoPb6empbIkPpNxpUW7OJXEu0XavliaBEC8+4KaUlLMUtsHN 0k2Js/jcKVmOVBMlt+Q5LRRHDg4O1uv1rGYqlhXkC/Xhw4dsIwkidiMjI1k1qsGkth3NScVM5VJb tre3042UN4sn0S8Y6aWjgNlhlIvSxd4wYO44uSJv5QBu5ZlqpG3EVXQJVVTba3USaDXsycnJOwX6 +PiYBpOVvW2XQDdrYmIiq20LtDHGmKeEB/bq6iqP/FrKSBHdsVy8+XfSYQ7pi2JevI1iZo/JWu39 f2djZmNjYzyD/403qKii3wbsi/cgIxxFz3vEGoGIAzCDTmV/JQI9PDzc6Tducv7169dWnE+pOKTZ mhixYGhoKCJflQ0OSFczaTQa0d9Q2KtkNwYg08BZ7JYEYy+WjzKmfRhkK21mdM+ifmLJkutSCAcZ y5JNIwfYMjc3Rz7TQlX0gsiwTmm7F2+j6spzP2da+f3797Qa+QLKR3XLaF1qb+RELTAr+Pz8vO4I yoiax91BNBV1neU2W+H8+jbaQaiFUHUfP36kqcd20kljkTksbRVkQ5VAPZdT60aguS/j4+NZIEcm 0FRLemvSspehac3MzCirmZdboI0xxjwLGMPKygrPs//GpDN6C0t+/98AcwZCMDU1xfPvvpMVvHIk fDySqSKKtrm5SUl5kEuJ9Lyn0niuHx4eHhwc6Ed/lLpCoJvN5m4Jeh0vI9BaaxrNbZsaVsReRIQr np+fa/4WLYhN2RWNjZaxC7tFRim7XgxVNrTiN5dgIx9ulsIsNFeKxl6kEGEicawOIQvbYwt7+XN7 extlJAUulK6ATePkz+XlZS7NvZiYmFA9cyFVEbUq4UsFGpclWa0FyInkXN3FeH9OWoalsYtkKWl5 WDSgAWjB8E63g/xEH5IvVNtXZqk3jqGdUDRKym3ieA2dRnOi/imOxJe8RcFPT091g1SrWnA0NJcr 6ssY1+Uwzi0P3HKzaADcPq03fn0bN8xGaoZ6IGVOjEaijFEtpEwlcEV1kzSiTyIkxZZIrUuBpjh0 APhCxRufqUAjynRIyAaZ4aJxo19bMIwF2hhjTOsH+tXVVZ5SSACP1XTYKeCxh0kgMQgHz7x/6Y20 DCoBdUu3ICXUgMROz/vp6enYi7Gx5cuXLxUCXcGTCzT36MctS0tLCLH6SNhwOSl8jtudBbMiRtI7 bIb7ntqYXFyzNygbacADbSlNTYqWOmVaNJQxajVsldPJf1yIzKeJkxmFUmTj+qlAS+LTZMl/Gmih Mel0UJOG3XYOB3Iue66eboLugQb4Y8CbxpAOaVNFKGM6Js13jcOQSN2ydDYMdDbthAhFWpMCyaa3 noYqr41fSLhlmHrbfJZjoFHVdOoSdVEU8YK1U6g0+kW9KTIcp983Blr3S5/jK5buov/A52zWS66S 5dMCbYwx5vWi6MwIcn2b4F4xVJw+/rOfyCtiZOV26nVkaOj6yQW6DCa0vr7eNqnt7W0OWFlZaVv2 tkOzGJve3FI2NFadalkq0GhiuTZUNHKFVv78HRJHWK9v38PrZK4VAk3eymPtiohQT6BcKCladgqG 3Y09p/0ozI+mov4n/ypQge9RxQi3blla/xpv1ph9oC6c4ltQZHVayCHZo6IGBwel4AquaDabXQp0 FjesS5cbnn4f0C8zXO6RAi3vDxdPd9Ev5XP2i5asulMDtkAbY4wxrwI6DJgQchBBqxrBTQU6DdXt RqBfMgaa0yNK5Pj4uPo1rLbFEYeHh22vQs0onLptNjKBzkZ2U9OtGJXH2DrJ3J0CrTH47HjFacQB 2c2KEqUoNqOTjFa3n9XVVdoMKq+3G8vdjKz+Y1j3+vcI7wwdpiANveTKRm4Tp6ijwnXZ0ime+85Z OLJQcmqA/oCmQdRvUOntfoxAK5ADYgxeu9reCBUzxN0CbYwxxrxG9A4Tz3JcAbM8OztLda3tpAGv SqC7eakrO6VtALeiBcovzymc4PECTSIKoi2Dg2rMtdMqPNUCzR3Mjle4yL0EWmlWT7Gyvb3NtTqt ksPpHCCBTmNRuhHojY2NcrVoaFavCXIAVaSfApQIJo3vdop0v69Aq/5HRkYoCNfiRmS3+zECfZ0E cqS79NUrV3Lb1yIt0MYYY8xrIY3xzWTonxRo5K98CvKEypyfn5fDo9MJ2h4p0AoFyQKENHnZ9e0P 99m6G9wXxUIsLi52Eujh4eEsxPm6iEKmLNrYpUDjo9RnOoNhGYUFt33FTVnS3HDlauREskTllwVa Rct+E9AsgfFjgsKsSUENFbHWTNVcKAuefphAK8/UZFqN6+vrTyjQ17eBHKp87VKUSBq/HhWiVmGB NsYYY14jGt5LxwuxE8VyyGn+MYHGkAYL0lmW8TMpskKH0/WfFZosS3ukQCupdIESJajxY71Q+PHj x3A4jLanp0cCrZJGxtJkY9qTSFav5UUUcpcCTT3c+QKAao9crayspK6JAtJmwuPR3HR2kevbqGvK WBbok5MTdn348CHcnQ9DQ0PURgQHY8+6brw7qIByjUNXCHQakl4h0BcXF9nroeRBy5vH7eaK6fR5 Clbp1N9o+61RIIfiQ7RL3TnEOipT3z7QjdDU469tiUcLtDHGmLeOltLQ7LM89TFFHt6a6EA/Iv9j An1d/EROedEpCsu5mpxBboriUBuoG8a2vLysCS6QWtnMIwWaRPQaJcJE4rOzs70FMaey5mij8lFt bgeyhf/pXE0MR960vGKaLA6neevILclqSm+yEfbZpUDrLty5Qh5aLAuknVAQLqrWkr59SMY0/R9l pCwqtXoOZYG+vh1zxVC/FWhO6/RFQxU/bSQau02NtoxuH5WjeOLqEA69ODs9PU3eqMaRgjSkR+PH WLUypnOzglQL9HXy2mvs0q89yiQ3nXqj+cXws5pcp++aBdoYY4z5Y2jK4YECDGNzc/P8/JwP0g6e 5XzOxvlib1t1KB8vOIVd5Vm0O20PSI0DyrKivHWSmAr29/cpMvpFkRGjNKhXy/4pLgKFIm/pkHD5 clhahDRMFZRrI4qG7CKLiuVAE9G1LOgZU9S4qSaaCF8kD5iW5qO4uLhomyx7kVpyjoelU8iVbxYZ Lkcj6C50M10jVUTfA+cjk1gyVyTBbNo1cj4zM0MZyRJ5jqBz3bJyfAIFbzQauiNqhFk3j43pu5KY JVuyCeAyyAOn4M26QemdKt8dCkXfgwxzayhas9mkzicnJ2O6Ru4Uks0B6kHp3E6BFm2/NYJqyXZp ghoqiqzSJNJFatTk3toLhRZoY4wxxhhjLNDGGGOMMcZYoI0xxhhjjLFAG2OMMcYYY4E2xhhjjDHG Am2MMcYYY4yxQBtjjDHGGGOBNsYYY4wxxgJtjDHGGGOMBdoYY/5Kzs/PDw4Ojo+Pf/365dowxhgL tDHGmI7s7Ox8+PChdsu7d+8mJiZOTk5eMg9crtPyvNW8f/8+lkf+/Pkz+X+qLJEfOhVuHsYYC7Qx xpjcnnt6egYGBubm5r5//95sNqenp7Xl58+fL5OHw8NDrP3bt2+PFGiKwJ9PkqWVlRVc/MVqwBhj LNDGGPPXUK/Xe3t7s/HmHz9+oI9fvnx5mTzs7u5yuccL9BNCZizQxhgLtDHGmDZgz6Ojo+Xtw8PD jUZDn4+Pj/f39/lwcHDQbDbR67Ozs3Df5eXltbW1i4uL9PTLy8vt7e2VlRX2bm5upnHVhwVsWV1d 5UQSJ01s9fPnz6TGiZ2yurOzw5GkeXR01FagSYoU0lPOz8/X19eXlpb4N80hV+FISkE2NjY2OIB/ 49JkT9EgnKWCG2OMBdoYY0yLer3e09ODPlYcg03iqXNzcxEnjXZjmVNTU7FlYGDg9PRUx29tbfGn DtPe/v5+5Ft7P90Su2oJbQd9MWOEnr19fX3klg9kpizQWQw0oq8MKDOcG8XkKmyZn58fHByMS/NZ V4+8wVPFhBhjjAXaGGP+Eba3t6WkGOrs7Cx/lmfhkJhyABJ8dXWlAI93794hmqgtWxTwsLCwcF0M +qKqQ0ND7OJP9iqeeHJyMgSaK5IaOsuus7Oz6hCOy8tLDkaF8XL+JHsS97W1tQqBVpofP36U1vMv n7ku3h8CLYcmw1yCzPPnzMyMTncIhzHGAm2MMaYjOOX4+Lg0GvjQaDR2dnYygZa/Cg3cRiAHAhqK jGRPTEykB0tzR0ZGQqA5OA2NqBbozc1N9jabzdiCQ5Pa4uJihUCPjY2h+Ok0GuSWoiHfIdAodXoh vD+2WKCNMRZoY4wxd3BxcbGxsTEzM4OSyqRXVlZSMU1lFGft7+//7X++tVr5Zb7T01NEfGlpqbe3 N2IhJNBXV1ddCrRCRzSeXaaTQGPPQ0NDu7/zvuA6CeHIkopMWqCNMRZoY4wx9wDrxY9xUI0xl+dX xlmz4OBUoPf29hqNRl9fX4QRk1Qq0IODg+m51QKtq3d6ubCtQOP6tc6EQGdXtEAbYyzQxhhj7mBj YwNlTKM1gsXFRQxSi5vcS6D39/d7enrYu7CwsLW1JQVP3bR8bjcCHW8odiPQV1dXfBgbG/vZDgu0 McZYoI0x5oGgzpo/rrxLgROKVL6XQM/MzGQhzuhsFsJxL4HWJHfZOoUjIyPj4+PXnUM42D44OJgG isDS0pJePexSoF94OUZjjLFAG2PMX8Do6KhmhUtDnDc2NlDeoaEhCegDBDqdj1kTXETMdPnco6Oj dGa6jNPT056ennq9HtODkL2Y9KOTQMuAU0XWZCBaHeZOgUa1s/cmjTHGAm2MMeZaKqkpljW1HJ6q 2OXBwcF4b+9eAr23t0dS6DJCjOOS4MDAgDRdcczlcy8uLnoK2J4ukhKsrq4qlho7n5iYUFa1MEon gUb99bYiGeCssbExzcSnfsKdAo06a+rotqvMGGOMBdoYY940eO33798nJyc/fvw4MjKCazabzXTd PvZmYR5LS0vZgDEHsFGfd3d3Se3Dhw+NRmNxcZGktre3OUByXD73upiOmlOQ41hvJQMvn56ejjRj NJqk4rpZPnFotoyPjyPBnMVhcRYazZGbm5vpJeYK4k8qgXOnpqYqFkc0xhgLtDHGGGOMMRZoY4wx xhhjjAXaGGOMMcYYC7QxxhhjjDEWaGOMMcYYYyzQxhhjjDHGWKCNMcYYY4yxQBtjjDHGGGMs0MYY Y4wxxligjTHGGGOMsUAbY4wxxhhjgTbGGGOMMcYCbYwxxhhjjAXaGGOMMcYYY4E2xhhjjDHGAm2M McYYY4wF2hhjjDHGGAu0McYYY4wxFmhjjDHGGGMs0MYYY4wxxhgLtDHGGGOMMRZoY4wxxhhjLNDG GGOMMcZYoI0xxhhjjLFAG2OMMcYYY4E2xhhjjDHGWKCNMcYYY4yxQBtjjDHGGGOBNsYYY4wx5hXz /2Hxybo3zxbmAAAAAElFTkSuQmCC --047d7ba97924f6b5f504d0fe9cfa-- From paulej@packetizer.com Sun Dec 16 13:21:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C021F894D for ; Sun, 16 Dec 2012 13:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow1+K6NJHO4x for ; Sun, 16 Dec 2012 13:21:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 35A6321F894C for ; Sun, 16 Dec 2012 13:21:10 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBGLL8eI009153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 16:21:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355692868; bh=1ZIa27qz8nlesauGPjdVXwGtAEgbpadlbuhgGjSoVGM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=jR1UU117lOIkElMOrOoNiORgn0w32nQD7BdNwjYWm3fSWsLhbJZeAHuhoPu5C+5hy nsBvY9/TjhI8i0Sv1/dfP85DHOGOzYjKlmHCMitmg8qvbzKkE3ChNGsAzLwVNFqvOj O/TirIvXkuvbopLYh6IlIMYWIeOpfcS10BGRfjeY= From: "Paul E. Jones" To: "'Brad Fitzpatrick'" References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 16:21:08 -0500 Message-ID: <007d01cddbd3$44228db0$cc67a910$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01CDDBA9.5B4D7010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gJf97KaA2wuLZcB+QAw/wFuEMI5AgW/GFMBsCR8Opc0y+1A Content-Language: en-us Cc: webfinger@ietf.org, 'Nick Jennings' , webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:21:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007E_01CDDBA9.5B4D7010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brad, =20 Yep, I did understand that correctly. It would certainly address issues = of certain rel types, but this approach still worries me. =20 Let=E2=80=99s say I operate that bank to which I referred in my last = examples. I want to provide contact information to my customers, but I = will only provide the contact information via HTTPS. A client looking = for contact information must now look for either = =E2=80=9Csecure-vcard=E2=80=9D or =E2=80=9Cvcard=E2=80=9D. The client = may not know which one it should use. It gets =E2=80=9Cvcard=E2=80=9D = the =E2=80=9Cbad server=E2=80=9D and offers that to the user. User = volunteers his personal information to some person who then robs the = person blind. =20 So, we end up possibly creating more names (vcard vs. secure-vcard), = clients do not always know exactly which form should be accepted, etc. =20 Given all of the complexity, I think we should go with HTTPS only for = now and then work on an HTTP fallback in a WF working group. Somebody = suggested something like that earlier this week (sorry, forgot who), and = I=E2=80=99m now of the mind that that is the way to go forward. Start = secure, introduce non-secure modes later. =20 Paul =20 From: Brad Fitzpatrick [mailto:bradfitz@google.com]=20 Sent: Sunday, December 16, 2012 4:05 PM To: Paul E. Jones Cc: Nick Jennings; webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language =20 My proposal doesn't prevent MITM on HTTP fallback (because you can't); = rather, it neuters it: =20 In my secure rel proposal, after the client tries HTTPS and it fails, = the client then tries HTTP, but the client knows it's using HTTP. It = doesn't know who the remote party is anymore (since it's just using = HTTP), but the client knows that it's speaking HTTP and not speaking = HTTPS. =20 So, when the client receives the HTTP response, it treats it = suspiciously. Any link rel that's security-related MUST NOT be present. = If it's present, the server is dumb or somebody's fucking with us. = Either way, discard that link or abort. But if the rel is for something = "unimportant" (this mailing list seems to have concluded that names and = pictures are insecure, so let's use that example), then it can happily = report: rel "avatar" =3D> href "http://evil.example.com/goatse.jpg", or = whatever. =20 But how does the client know which link rels are security-related (ala = "HTTPS-only")? Not a database, because that's hard to keep all clients = updated over time, as new link rels go into use and/or get registered = with the IANA. Rather, we encode the HTTPS-only property into the rel = type itself: if the "rel" value begins with "https:" or begins with = "secure-", clients must never respect it when seen over an HTTP = connection. That's the neutering. =20 So a MITM can stop webfinger, but can't inject fake results. =20 And if you want extra security for "avatar" (which isn't = "secure-avatar"), you tell your WebFinger client to go into HTTPS-only = mode. But even with no configuration, all WebFinger clients must neuter = (filter) secure rels when seen in HTTP responses. =20 Here's a picture: http://i.imgur.com/rvMtk.png (also attached) =20 ------=_NextPart_000_007E_01CDDBA9.5B4D7010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Brad,

 

Yep, I did understand that correctly.=C2=A0 It would certainly = address issues of certain rel types, but this approach still worries = me.

 

Let=E2=80=99s say I operate that bank to which I referred in my last = examples.=C2=A0 I want to provide contact information to my customers, = but I will only provide the contact information via HTTPS.=C2=A0 A = client looking for contact information must now look for either = =E2=80=9Csecure-vcard=E2=80=9D or =E2=80=9Cvcard=E2=80=9D.=C2=A0 The = client may not know which one it should use.=C2=A0 It gets = =E2=80=9Cvcard=E2=80=9D the =E2=80=9Cbad server=E2=80=9D and offers that = to the user.=C2=A0 User volunteers his personal information to some = person who then robs the person blind.

 

So, we end up possibly creating more names (vcard vs. secure-vcard), = clients do not always know exactly which form should be accepted, = etc.

 

Given all of the complexity, I think we should go with HTTPS only for = now and then work on an HTTP fallback in a WF working group.=C2=A0 = Somebody suggested something like that earlier this week (sorry, forgot = who), and I=E2=80=99m now of the mind that that is the way to go = forward.=C2=A0 Start secure, introduce non-secure modes = later.

 

Paul

 

From:= = Brad Fitzpatrick [mailto:bradfitz@google.com]
Sent: Sunday, = December 16, 2012 4:05 PM
To: Paul E. Jones
Cc: Nick = Jennings; webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Current HTTP/HTTPS = Language

 

My proposal = doesn't prevent MITM on HTTP fallback (because you can't); rather, it = neuters it:

 

In my secure = rel proposal, after the client tries HTTPS and it fails, the client then = tries HTTP, but the client knows it's using HTTP.  It doesn't know = who the remote party is anymore (since it's just using HTTP), but the = client knows that it's speaking HTTP and not speaking = HTTPS.

 

So, when the = client receives the HTTP response, it treats it suspiciously.  Any = link rel that's security-related MUST NOT be present.  If it's = present, the server is dumb or somebody's fucking with us.  Either = way, discard that link or abort.  But if the rel is for something = "unimportant" (this mailing list seems to have concluded that = names and pictures are insecure, so let's use that example), then it can = happily report: rel "avatar" =3D> href "http://evil.example.com/goats= e.jpg", or whatever.

 

But how does = the client know which link rels are security-related (ala = "HTTPS-only")?  Not a database, because that's hard to = keep all clients updated over time, as new link rels go into use and/or = get registered with the IANA.  Rather, we encode the HTTPS-only = property into the rel type itself: if the "rel" value begins = with "https:" or begins with "secure-", clients must = never respect it when seen over an HTTP connection.  That's the = neutering.

 

So a MITM = can stop webfinger, but can't inject fake = results.

 

And if you = want extra security for "avatar" (which isn't = "secure-avatar"), you tell your WebFinger client to go into = HTTPS-only mode.  But even with no configuration, all WebFinger = clients must neuter (filter) secure rels when seen in HTTP = responses.

 

Here's a = picture: http://i.imgur.com/rvMtk.png = (also attached)

 

------=_NextPart_000_007E_01CDDBA9.5B4D7010-- From perpetual-tripper@wwelves.org Sun Dec 16 13:26:12 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDD921F894C for ; Sun, 16 Dec 2012 13:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMj5YQkeXuOU for ; Sun, 16 Dec 2012 13:26:11 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBAA21F892A for ; Sun, 16 Dec 2012 13:26:11 -0800 (PST) X-Originating-IP: 217.70.178.132 Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id DA1CBA8068; Sun, 16 Dec 2012 22:26:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4wuUkMZsZDRb; Sun, 16 Dec 2012 22:25:59 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7A107A8077; Sun, 16 Dec 2012 22:25:59 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Brad Fitzpatrick In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> Date: Sun, 16 Dec 2012 21:25:58 +0000 Message-Id: <1355692749-sup-8085@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:26:12 -0000 Excerpts from Brad Fitzpatrick's message of 2012-12-16 21:04:40 +0000: > But how does the client know which link rels are security-related (ala > "HTTPS-only")? Not a database, because that's hard to keep all clients > updated over time, as new link rels go into use and/or get registered w= ith > the IANA. Rather, we encode the HTTPS-only property into the rel type > itself: if the "rel" value begins with "https:" or begins with "secure-= ", > clients must never respect it when seen over an HTTP connection. That'= s > the neutering. personally i find using URIs more attractive than just text labels, what = one gains by registering link relation with IANA?=20 From paulej@packetizer.com Sun Dec 16 13:27:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A221F894C for ; Sun, 16 Dec 2012 13:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5hV0gFLb2FQ for ; Sun, 16 Dec 2012 13:27:08 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D872821F892A for ; Sun, 16 Dec 2012 13:27:07 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBGLR2WF009418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 16:27:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355693223; bh=U+j1yA0q7gy4gYkHJ/oH1bGVM8dELwId/rCuzhuwWEI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Ndi5YDsy+GVMGhwfdrAUz73n4EQxR87c6DMjjjKSz4qmI3o67KN4pH6PWoE26llxv J80fo7K16YhQyWFsKTkhiT4LQlfm+bQTGFOHx7zLIshrgE37b3QvBZbNQwAWDEveIo B+j7BGbQ47F5bzddnGa5FsH12sLAUJqqWsCps1sY= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 16:27:03 -0500 Message-ID: <008a01cddbd4$17834140$4689c3c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01CDDBAA.2EAE4AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hCY5WOBQA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:27:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01CDDBAA.2EAE4AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Most of those issues have been addressed. We've divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It's six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We've addressed that by documenting JRD entirely within the WF spec itself. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Sunday, December 16, 2012 4:01 PM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process [snip] Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow consensus to be reached fastest. Today I ordered my StartSSL certificate, so hopefully I can do my little bit too :) However, that is not the greatest of the concerns that I have seen. The most serious critique I've seen to date is the thread form Mark Nottingham, "Looking at Webfinger" http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html In particular: [[ Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here). * What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space. ]] Mark Nottingham has a stellar reputation at the IETF, and these are some of the more serious concerns raised to date, imho, and have yet to be fully addressed. And that may take some time to work through. If perhaps going the "informational" route could save a significant amount of time, say, 6 months or a year, do you think would it be worth considering? Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Melvin Carvalho Sent: Sunday, December 16, 2012 10:08 AM To: webfinger@googlegroups.com Subject: Possibly speeding up the RFC process Webfinger is now in it's 4th year and I think everyone would agree that we are keen to see it shipped It seems to me that there are two value added use cases that have remained constant from the start. 1) Lookup of a string of type user@host to produce a HTTP URL 2) Lookup of a string of type mailto:user@host to produce a HTTP URL These are two things that would really be very useful, irrespective of all the other benefits that webfinger has to offer. We're perhaps at a point where both of these two cases have a solution. So maybe it may be an idea to tidy up the current RFC in the WG and mark it as informational in line with the following: http://www.ietf.org/iesg/informational-vs-experimental.html [[ An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process ]] I'm speculating here that this would get webfinger shipped more quickly. Getting webfinger to IETF to recommendation level would appear to be a greater task. Perhaps adding months to the time line, and if i have understood correctly there's no guarantee that an RFC will make it to recommendation status. Part of me wants webfinger to be the best spec it can be, and for quality to be really high, yet another part would like to see webfinger actually shipped asap, and to start using a stable form to complete the loop in discovering more information from email via HTTP. So, just putting the idea out there. [snip] ------=_NextPart_000_008B_01CDDBAA.2EAE4AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Most of those issues have been addressed.  We’ve divorced = WF from Hostmeta.  XRD is no longer used.  We are using JRD, = but I see no good reason to exchange it.  It’s six of one, = half a dozen of anther when it comes to a format like that.  JRD is = clean and it has some nice properties about it that allow us to do = things like are shown in the examples.  I think the biggest concern = people had was the need to go read RFC 6415 or the XRD spec.  = We’ve addressed that by documenting JRD entirely within the WF = spec itself.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 = 4:01 PM
To: webfinger@googlegroups.com
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

[snip]

Re: the HTTP/HTTPS debate, I'm really supportive of = whatever will allow consensus to be reached fastest.  Today I = ordered my StartSSL certificate, so hopefully I can do my little bit too = :)

However, that is not the greatest of the concerns that I have = seen.  The most serious critique I've seen to date is the thread = form Mark Nottingham, "Looking at Webfinger"

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg0648= 7.html

In particular:

[[

Astute observers will = notice that this approach removes the need for an ACCT URI scheme (at = least here).

* What's the fascination with XRD and JRD? These = specifications seem to be creeping into IETF architecture; first it was = in a pure security context, but now folks are talking about using them = in a much more generic way, as a cornerstone of what we do. As such, I = think they deserve a MUCH closer look, especially since we're defining = things with "Web" in their name when the W3C has already = defined solutions in this space.

]]

Mark Nottingham has a = stellar reputation at the IETF, and these are some of the more serious = concerns raised to date, imho, and have yet to be fully addressed.  = And that may take some time to work through.

If perhaps going the = "informational" route could save a significant amount of time, = say, 6 months or a year, do you think would it be worth = considering?
 

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 = AM
To: webfinger@googlegroups.com
Subject: = Possibly speeding up the RFC = process

 <= /o:p>

Webfinger = is now in it's 4th year and I think everyone would agree that we are = keen to see it shipped

It seems to me that there are two value = added use cases that have remained constant from the start.

1) = Lookup of a string of type user@host to produce a HTTP URL
2) Lookup = of a string of type mailto:user@host to produce a HTTP URL

These are = two things that would really be very useful, irrespective of all the = other benefits that webfinger has to offer.

We're perhaps at a = point where both of these two cases have a solution.

So maybe it = may be an idea to tidy up the current RFC in the WG and mark it as = informational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.= html

[[
An "Informational" specification is = published for the general information of the Internet community, and = does not represent an Internet community consensus or recommendation. = The Informational designation is intended to provide for the timely = publication of a very broad range of responsible informational documents = from many sources, subject only to editorial considerations and to = verification that there has been adequate coordination with the = standards process
]]

I'm speculating here that this would get = webfinger shipped more quickly.  Getting webfinger to IETF to = recommendation level would appear to be a greater task.  Perhaps = adding months to the time line, and if i have understood correctly = there's no guarantee that an RFC will make it to recommendation = status.

Part of me wants webfinger to be the best spec it can be, = and for quality to be really high, yet another part would like to see = webfinger actually shipped asap, and to start using a stable form to = complete the loop in discovering more information from email via = HTTP.  So, just putting the idea out there.

[snip]

------=_NextPart_000_008B_01CDDBAA.2EAE4AB0-- From bradfitz@google.com Sun Dec 16 13:31:57 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB921F8951 for ; Sun, 16 Dec 2012 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWK+CaVo78Fu for ; Sun, 16 Dec 2012 13:31:57 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E921F894D for ; Sun, 16 Dec 2012 13:31:56 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so1545093wib.13 for ; Sun, 16 Dec 2012 13:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1XVOfy0WnP6JTAvMJJWjjA6/f1rX/wfegUBBu0T4/6w=; b=VtrZ0To8AvytpWpkdrAOY2+4vfu8wFJIApk0k5r2PZ6XRwg9cMwpok0LhGUYPQXxE2 uLT+ZAyOBDEgNZVzH3C/MbmWBP2i8/hniZlbEHn/ziWSjtz8ZoBZM3Sva5vRSRrSfNZg aAcmZqeDXdBSvc+bvFFyj3wXSfkK7So09+gve30aREu4O7jktIDSSw1HF4EISg3VgMSv iYtgVICj1FFERpqlyWOxQZJy93QZzDoGKmNbP22uq+icnT/mDisA7d8uP3B+dUiAxb+p aoMrP6k8F1rLEZ9PIuZi61IZjAaCHKsR5VYyPnE007tn6tNSuBOe53K5soHlSXnuhAPg EuIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1XVOfy0WnP6JTAvMJJWjjA6/f1rX/wfegUBBu0T4/6w=; b=j+0D/qAxmXqcMdqtkWb8e4E9OjUtDZfokBoZXQwLEnYLTtFH4L0fJ6BBl4c2G1DNwh 5cLLKCGsnUYGArJjJg91vbr+4p57WSBOUWS+1MLU00t8m99Prm1y5nPvOO1RHrlPUr6v ptBnZ6ngF03SsJEiWFbLsHC3Hl39Gw5dBNVZ4p/0umUcjdfHFddbc6FfJ3Yp/EF943H5 6UELF8ynpMuqgragABVrrkl91j5Diz6+6+BEqo7FYGca4OURjdSImSuyj0xrAmo+GCqz RuWN5s3tXVqJrAwQR8DTXGKEclpmTs3Ohe1iwQjNG3dibzWHW1jZMXm8WW9FBHi6bjWz cDmA== MIME-Version: 1.0 Received: by 10.180.108.236 with SMTP id hn12mr3255267wib.6.1355693515867; Sun, 16 Dec 2012 13:31:55 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sun, 16 Dec 2012 13:31:55 -0800 (PST) In-Reply-To: <007d01cddbd3$44228db0$cc67a910$@packetizer.com> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> Date: Sun, 16 Dec 2012 13:31:55 -0800 Message-ID: From: Brad Fitzpatrick To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f3ba7717005cf04d0fefeea X-Gm-Message-State: ALoCoQl/DWSryceQegp0slgI/FaUYFc1Og/Wo5J7khNyxvd0e2V8VY9KyOUubUdKnKMjiZ31+es0g46D9Ww+5rckdPTNFi0KmIg4m8W1bsyz5HrozjAHyjzgYDA1kR/dWX08u8AFIo4tsTlr6uylt7pvLdUeNVzZMFOg9MzRAK0j1yY6g6YOku4b99MBmmzXDTcSjw8PRMWN Cc: webfinger@ietf.org, Nick Jennings , webfinger@googlegroups.com Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:31:58 -0000 --e89a8f3ba7717005cf04d0fefeea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 16, 2012 at 1:21 PM, Paul E. Jones wrote= : > Brad,**** > > ** ** > > Yep, I did understand that correctly. It would certainly address issues > of certain rel types, but this approach still worries me.**** > > ** ** > > Let=E2=80=99s say I operate that bank to which I referred in my last exam= ples. I > want to provide contact information to my customers, but I will only > provide the contact information via HTTPS. A client looking for contact > information must now look for either =E2=80=9Csecure-vcard=E2=80=9D or = =E2=80=9Cvcard=E2=80=9D. The client > may not know which one it should use. > ... > So, we end up possibly creating more names (vcard vs. secure-vcard), > clients do not always know exactly which form should be accepted, etc. > I never proposed that for every "foo" there exists "secure-foo". But let's imagine that's the case: why would a client ever pick "foo" over "secure-foo"? The choice seems obvious. But if the client DOES know it's doing a secure operation (it's a banking client), it goes into HTTPS-only mode. The secure relations are just a mechanism to say "regardless of what the client thinks, these relation types must be HTTPS-only". I don't think a bank would ever use any relation type which wasn't secure, though. Further, I don't think it would use any relation type "secure-X" for which "X" was widely in use, lest existing clients treat X as secure-X. But to be realistic: banks don't have public APIs because of this and so many other reasons. They write their own clients, because they know/imagine everybody sucks. **** > > Given all of the complexity, I think we should go with HTTPS only for now > and then work on an HTTP fallback in a WF working group. Somebody > suggested something like that earlier this week (sorry, forgot who), and > I=E2=80=99m now of the mind that that is the way to go forward. Start se= cure, > introduce non-secure modes later. > Yes, please! :-) I was hoping that would be the result of this thread. DirtyFinger could introduce secure rels or maybe dirty rels. --e89a8f3ba7717005cf04d0fefeea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Sun, Dec 16, 2012 at 1:21 PM, Paul E. = Jones <paulej@packetizer.com> wrote:

Brad,<= u>

=C2=A0

Yep, I did understa= nd that correctly.=C2=A0 It would certainly address issues of certain rel t= ypes, but this approach still worries me.

=C2=A0

Let=E2=80=99s say I= operate that bank to which I referred in my last examples.=C2=A0 I want to= provide contact information to my customers, but I will only provide the c= ontact information via HTTPS.=C2=A0 A client looking for contact informatio= n must now look for either =E2=80=9Csecure-vcard=E2=80=9D or =E2=80=9Cvcard= =E2=80=9D.=C2=A0 The client may not know which one it should use.=C2=A0

...

So, we end up possibly creating more names (vcard vs. = secure-vcard), clients do not always know exactly which form should be acce= pted, etc.


I never proposed that for every= "foo" there exists "secure-foo". =C2=A0But let's i= magine that's the case: =C2=A0why would a client ever pick "foo&qu= ot; over "secure-foo"? =C2=A0The choice seems obvious.=C2=A0

But if the client DOES know it's doing a secure ope= ration (it's a banking client), it goes into HTTPS-only mode. =C2=A0The= secure relations are just a mechanism to say "regardless of what the = client thinks, these relation types must be HTTPS-only". =C2=A0I don&#= 39;t think a bank would ever use any relation type which wasn't secure,= though. =C2=A0Further, I don't think it would use any relation type &q= uot;secure-X" for which "X" was widely in use, lest existing= clients treat X as secure-X.

But to be realistic: banks don't have public APIs b= ecause of this and so many other reasons. They write their own clients, bec= ause they know/imagine everybody sucks.


<= u>

Given all of the complexity, I think we shou= ld go with HTTPS only for now and then work on an HTTP fallback in a WF wor= king group.=C2=A0 Somebody suggested something like that earlier this week = (sorry, forgot who), and I=E2=80=99m now of the mind that that is the way t= o go forward.=C2=A0 Start secure, introduce non-secure modes later.<= /p>


Yes, please! =C2=A0:-) =C2=A0I was h= oping that would be the result of this thread.

Dir= tyFinger could introduce secure rels or maybe dirty rels.
--e89a8f3ba7717005cf04d0fefeea-- From melvincarvalho@gmail.com Sun Dec 16 13:37:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AAE21F89AB for ; Sun, 16 Dec 2012 13:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeetEzT+poCX for ; Sun, 16 Dec 2012 13:37:45 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1AEF21F89A9 for ; Sun, 16 Dec 2012 13:37:44 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4843766iaz.31 for ; Sun, 16 Dec 2012 13:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pc089/OLlJj+s9C0/r4OyFDnC/Bp+IQCwolDDBwLyKY=; b=irYYerIPOemsAakWCce6h79vbHgzwZpkck/FshWvjqbt1wQk6iM372FeL9aml/N2P/ vlORc2AMyKFoMtnfrWK2N3Odq/Ky7WWQg8kPwg87bQ1gI67/S6Aq1t5Fwx54FL9gsv/b 6hH9VDjVimMmjzYZl0PMQ3vVs3OfMewsBIK4/bUaLTRjBzZtpMq/vZknjuY03AhR09KP cOYh5HoDLnsU2LBv7WdOxRyYgaz6TnQgJBAg0tmekIo0c+Xl/iwNHaw3n2gwj//gmL36 rEogwVfrZn244nMDXumFdWjNOf346aLr5SoacEIMPG+Acfb4BpCWGvqZ/C4i1aRvjv8L 8mjA== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr7462368igk.41.1355693864477; Sun, 16 Dec 2012 13:37:44 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 13:37:44 -0800 (PST) In-Reply-To: <008a01cddbd4$17834140$4689c3c0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> Date: Sun, 16 Dec 2012 22:37:44 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae934090137643b04d0ff134c Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:37:46 -0000 --14dae934090137643b04d0ff134c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16 December 2012 22:27, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Most of those issues have been addressed. We=92ve divorced WF from > Hostmeta. XRD is no longer used. We are using JRD, but I see no good > reason to exchange it. It=92s six of one, half a dozen of anther when it > comes to a format like that. JRD is clean and it has some nice propertie= s > about it that allow us to do things like are shown in the examples. I > think the biggest concern people had was the need to go read RFC 6415 or > the XRD spec. We=92ve addressed that by documenting JRD entirely within = the > WF spec itself. > Yes, I did note that those changes were made, and I particularly like the move from XML to JSON. I could be mistaken, but I am unsure that that all of the concerns will have been addressed to the satisfaction of the IESG. The ones I noted: - Should webfinger use the acct: scheme rather than simply a query parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are important, but I'm unsure how popular a choice that will be with the IETF. - JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue. - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at. - Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc. I accept that some or all of these concerns may be invalid, but as webfinger draws nearer to the standards track, perhaps it is possible that more people upstream could weigh in. > **** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Sunday, December 16, 2012 4:01 PM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > ** ** > > [snip]**** > > Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow > consensus to be reached fastest. Today I ordered my StartSSL certificate= , > so hopefully I can do my little bit too :) > > However, that is not the greatest of the concerns that I have seen. The > most serious critique I've seen to date is the thread form Mark Nottingha= m, > "Looking at Webfinger" > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html > > In particular: > > [[ > > Astute observers will notice that this approach removes the need for an > ACCT URI scheme (at least here). > > * What's the fascination with XRD and JRD? These specifications seem to b= e > creeping into IETF architecture; first it was in a pure security context, > but now folks are talking about using them in a much more generic way, as= a > cornerstone of what we do. As such, I think they deserve a MUCH closer > look, especially since we're defining things with "Web" in their name whe= n > the W3C has already defined solutions in this space. > > ]] > > Mark Nottingham has a stellar reputation at the IETF, and these are some > of the more serious concerns raised to date, imho, and have yet to be ful= ly > addressed. And that may take some time to work through. > > If perhaps going the "informational" route could save a significant amoun= t > of time, say, 6 months or a year, do you think would it be worth > considering? > **** > > **** > > Paul**** > > **** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Sunday, December 16, 2012 10:08 AM > *To:* webfinger@googlegroups.com > *Subject:* Possibly speeding up the RFC process**** > > **** > > Webfinger is now in it's 4th year and I think everyone would agree that w= e > are keen to see it shipped > > It seems to me that there are two value added use cases that have remaine= d > constant from the start. > > 1) Lookup of a string of type user@host to produce a HTTP URL > 2) Lookup of a string of type mailto:user@host to produce a HTTP URL > > These are two things that would really be very useful, irrespective of al= l > the other benefits that webfinger has to offer. > > We're perhaps at a point where both of these two cases have a solution. > > So maybe it may be an idea to tidy up the current RFC in the WG and mark > it as informational in line with the following: > > http://www.ietf.org/iesg/informational-vs-experimental.html > > [[ > An "Informational" specification is published for the general information > of the Internet community, and does not represent an Internet community > consensus or recommendation. The Informational designation is intended to > provide for the timely publication of a very broad range of responsible > informational documents from many sources, subject only to editorial > considerations and to verification that there has been adequate > coordination with the standards process > ]] > > I'm speculating here that this would get webfinger shipped more quickly. > Getting webfinger to IETF to recommendation level would appear to be a > greater task. Perhaps adding months to the time line, and if i have > understood correctly there's no guarantee that an RFC will make it to > recommendation status. > > Part of me wants webfinger to be the best spec it can be, and for quality > to be really high, yet another part would like to see webfinger actually > shipped asap, and to start using a stable form to complete the loop in > discovering more information from email via HTTP. So, just putting the > idea out there. **** > > [snip]**** > --14dae934090137643b04d0ff134c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 16 December 2012 22:27, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Most of those issues have been addressed.=A0 = We=92ve divorced WF from Hostmeta.=A0 XRD is no longer used.=A0 We are usin= g JRD, but I see no good reason to exchange it.=A0 It=92s six of one, half = a dozen of anther when it comes to a format like that.=A0 JRD is clean and = it has some nice properties about it that allow us to do things like are sh= own in the examples.=A0 I think the biggest concern people had was the need= to go read RFC 6415 or the XRD spec.=A0 We=92ve addressed that by document= ing JRD entirely within the WF spec itself.


Yes, I did note that those changes were m= ade, and I particularly like the move from XML to JSON.

I could be m= istaken, but I am unsure that that all of the concerns will have been addre= ssed to the satisfaction of the IESG.

The ones I noted:

- Should webfinger use the acct: scheme rather= than simply a query parameter.=A0 This strikes me as a 'vanity' UR= I scheme.=A0 Aesthetics are important, but I'm unsure how popular a cho= ice that will be with the IETF.

- JRD does not allow an array of items/subjects to be rendered in respo= nse to an HTTP request, whereas other serializations do allow that.=A0 This= leads to an interoperability issue.=A0

- Concerns were raised over= the IPR of XRD/JRD.=A0 IANAL, but to the best of my knowledge they are not= creative commons, or royalty free under, say, IETF / W3C / ISO.=A0 This to= pic would be well outside my area of expertize, but something the IETF may = look at.=A0

- Could webfinger be recommended as a best practice if the scope is suf= ficiently wide, to overlap in areas where the W3C has already standardized.= =A0 Namely those of discovery via http (aka linked data) etc.

I acce= pt that some or all of these concerns may be invalid, but as webfinger draw= s nearer to the standards track, perhaps it is possible that more people up= stream could weigh in.
=A0

<= /u>

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 4:01 PM
To: webfinger@googlegroups.co= m
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process=

=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">[snip]

Re: the HTTP/HTTPS debat= e, I'm really supportive of whatever will allow consensus to be reached= fastest.=A0 Today I ordered my StartSSL certificate, so hopefully I can do= my little bit too :)

However, that is not the greatest of the concerns that I have seen.=A0 = The most serious critique I've seen to date is the thread form Mark Not= tingham, "Looking at Webfinger"

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html

In particular:

[[

Astute observers will notice that this = approach removes the need for an ACCT URI scheme (at least here).

*= What's the fascination with XRD and JRD? These specifications seem to = be creeping into IETF architecture; first it was in a pure security context= , but now folks are talking about using them in a much more generic way, as= a cornerstone of what we do. As such, I think they deserve a MUCH closer l= ook, especially since we're defining things with "Web" in the= ir name when the W3C has already defined solutions in this space.

]]

Mark Nottingham has a stellar reputation at the IETF, and the= se are some of the more serious concerns raised to date, imho, and have yet= to be fully addressed.=A0 And that may take some time to work through.

If perhaps going the "informational" route could save a signi= ficant amount of time, say, 6 months or a year, do you think would it be wo= rth considering?
=A0

=A0

Paul<= u>

=A0<= /p>

From: webfi= nger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 AM
To: webfinger@googlegroups.c= om
Subject: Possibly speeding up the RFC process

=A0

Webfinger is= now in it's 4th year and I think everyone would agree that we are keen= to see it shipped

It seems to me that there are two value added use cases that have remai= ned constant from the start.

1) Lookup of a string of type user@host= to produce a HTTP URL
2) Lookup of a string of type mailto:user@host to produce a HTTP URL

These are two things that would really be very useful, irrespective of = all the other benefits that webfinger has to offer.

We're perhap= s at a point where both of these two cases have a solution.

So maybe= it may be an idea to tidy up the current RFC in the WG and mark it as info= rmational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.h= tml

[[
An "Informational" specification is publishe= d for the general information of the Internet community, and does not repre= sent an Internet community consensus or recommendation. The Informational d= esignation is intended to provide for the timely publication of a very broa= d range of responsible informational documents from many sources, subject o= nly to editorial considerations and to verification that there has been ade= quate coordination with the standards process
]]

I'm speculating here that this would get webfinger shipped mo= re quickly.=A0 Getting webfinger to IETF to recommendation level would appe= ar to be a greater task.=A0 Perhaps adding months to the time line, and if = i have understood correctly there's no guarantee that an RFC will make = it to recommendation status.

Part of me wants webfinger to be the best spec it can be, and for quali= ty to be really high, yet another part would like to see webfinger actually= shipped asap, and to start using a stable form to complete the loop in dis= covering more information from email via HTTP.=A0 So, just putting the idea= out there.

[snip]


--14dae934090137643b04d0ff134c-- From bradfitz@google.com Sun Dec 16 13:40:20 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AB621F89AB for ; Sun, 16 Dec 2012 13:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhIUKsAXmefp for ; Sun, 16 Dec 2012 13:40:19 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 618A821F89A9 for ; Sun, 16 Dec 2012 13:40:19 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1545513wib.13 for ; Sun, 16 Dec 2012 13:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QZes1KID9ZyleqCiKGd5488E99JJ+qsDZPJ3XSRdet8=; b=AlX4yrGog3dpJGfVv+oP5DLZlMmXI4273duMYdwmUgf41lRnfky/ryggnJ9Eohtjj5 y8DsM+X/f+TEKzYdfNizA16F9u6zRWCsyLFEXUPLuWLwAZGdsQDHHt1X6/393Yg3HJwa Zs60mMm0SGrzoiEOkKZchTXMIcrAMqiRzGXWgkqykf5wvCQQDEpd3p0AQIeGHV1OT8om qAuoF5b834y0NOvA48cfjO/f4w6kwHi6K4DX/UmDtETNla3NswcZDhQ0OpvAOIuwhQcb ecOOjQDWlI4CBXR4d7D7dVQk4QUYgV2I7gO16vx1pGqxHumQ2xiHTJgZNy2lG9PpSrpM r9Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QZes1KID9ZyleqCiKGd5488E99JJ+qsDZPJ3XSRdet8=; b=GIHZ9FSCmjO0HDtszKXwyPBiq+9oghAvth5ih+KKAg/nwDHqBJiTFEh8XKKusvxY0a RTn3n17G5o1Di0JZfdhGhpHUYH/BcdK3ifPp76V9oenZYVn64D4xqy3fivZ5ABZ+aiMu as3mQjqbhkRDitbzC7mFuM4my0JxhauhY05UjZadJzAQ19dRyYot0q98tr7MBY2zH1eD iMB/sMY5EYf23KI6QUX/YYuAIEZ27+Z/Yg+JEeqQG2+6fJRD2x3qMtQ03fwysu8vu10X lHUBbJpkrimGDB20ssVOA68B2nwFcQslhVHRNxOptHkgIJCw+8oLw+UhbiR9smz/C1gA yUrA== MIME-Version: 1.0 Received: by 10.194.242.69 with SMTP id wo5mr11645448wjc.10.1355694018339; Sun, 16 Dec 2012 13:40:18 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sun, 16 Dec 2012 13:40:18 -0800 (PST) In-Reply-To: <1355692749-sup-8085@heahdk.net> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <1355692749-sup-8085@heahdk.net> Date: Sun, 16 Dec 2012 13:40:18 -0800 Message-ID: From: Brad Fitzpatrick To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: multipart/alternative; boundary=089e0122f0fe63220104d0ff1cb2 X-Gm-Message-State: ALoCoQmC4SeiFAwotdN9ynrcPq6o+0wzNgoFoh1Zu+MfdZz+T7K6ourDMiH2YKdvmGN/gOG08JStjnU9Ps6064/NMacVPRZi06N46s0Itjv/jVC9x4GkZ7NRdFnNnvIZrBU0TQT4Lxfw83RaQDo65iQ2Fk3Jl+8wsyXmsqgAeuBx2BXNsf26y9LCl7TZyhKMzbWrTmjCaIN2 Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:40:20 -0000 --089e0122f0fe63220104d0ff1cb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 16, 2012 at 1:25 PM, =E2=98=AE elf Pavlik =E2=98=AE < perpetual-tripper@wwelves.org> wrote: > Excerpts from Brad Fitzpatrick's message of 2012-12-16 21:04:40 +0000: > > But how does the client know which link rels are security-related (ala > > "HTTPS-only")? Not a database, because that's hard to keep all clients > > updated over time, as new link rels go into use and/or get registered > with > > the IANA. Rather, we encode the HTTPS-only property into the rel type > > itself: if the "rel" value begins with "https:" or begins with "secure-= ", > > clients must never respect it when seen over an HTTP connection. That'= s > > the neutering. > personally i find using URIs more attractive than just text labels, what > one gains by registering link relation with IANA? > One might ask the same question about writing an RFC for the WebFinger protocol. Writing an RFC or registering a link relation is a formalization= . I only proposed the "secure-" prefix for IANA-registered relations in response to a criticism that IANA-registered links could not begin with "https://". I personally don't care either way about which namespace rel types are in. --089e0122f0fe63220104d0ff1cb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Sun, Dec 16, 2012 at 1:25 PM, =E2=98=AE elf Pavlik =E2=98=AE <perpetual-tripper@wwelves.org> wrote:
Excerpts from Bra= d Fitzpatrick's message of 2012-12-16 21:04:40 +0000:
> But how does the client know which link rels are sec= urity-related (ala
> "HTTPS-only")? =C2=A0Not a database, because that's hard= to keep all clients
> updated over time, as new link rels go into use and/or get registered = with
> the IANA. =C2=A0Rather, we encode the HTTPS-only property into the rel= type
> itself: if the "rel" value begins with "https:" or= begins with "secure-",
> clients must never respect it when seen over an HTTP connection. =C2= =A0That's
> the neutering.
personally i find using URIs more attractive than just text labels, w= hat one gains by registering link relation with IANA?

One might ask the same question about writing a= n RFC for the WebFinger protocol. =C2=A0Writing an RFC or registering a lin= k relation is a formalization.

I only proposed the= "secure-" prefix for IANA-registered relations in response to a = criticism that IANA-registered links could not begin with "https://&qu= ot;.

I personally don't care either way about which name= space rel types are in.

--089e0122f0fe63220104d0ff1cb2-- From paulej@packetizer.com Sun Dec 16 14:12:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E721F855A for ; Sun, 16 Dec 2012 14:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saJd-s9IfJz0 for ; Sun, 16 Dec 2012 14:12:35 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1036621F8559 for ; Sun, 16 Dec 2012 14:12:34 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBGMCWUm011453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 17:12:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355695953; bh=htyF5rfcxVRAljq/nhTsfKmgJaHbxq9WzpJxJoKLcU0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=WiVRdWEk6pGd6qvAfEi70qEp+KzS7sRfByZjG+CPUY9myW4ohrC2iWZIrPQlJEU5t FmVSj++/qzOWbxm4lX6wgVwtj9KO00UidrGmpmx6DDLRcuzy1GE/dUgd29cIiusVr6 mYKCDeqBoS01sCIFtUNrEIH6tVoO9q76EnBwMt2M= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 17:12:33 -0500 Message-ID: <00c801cddbda$72cc7d90$586578b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01CDDBB0.89F82340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlmMjm0vA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:12:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C9_01CDDBB0.89F82340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Comments are in inline: From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Sunday, December 16, 2012 4:38 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process On 16 December 2012 22:27, Paul E. Jones wrote: Melvin, Most of those issues have been addressed. We've divorced WF from Hostmeta. XRD is no longer used. We are using JRD, but I see no good reason to exchange it. It's six of one, half a dozen of anther when it comes to a format like that. JRD is clean and it has some nice properties about it that allow us to do things like are shown in the examples. I think the biggest concern people had was the need to go read RFC 6415 or the XRD spec. We've addressed that by documenting JRD entirely within the WF spec itself. Yes, I did note that those changes were made, and I particularly like the move from XML to JSON. I could be mistaken, but I am unsure that that all of the concerns will have been addressed to the satisfaction of the IESG. The ones I noted: - Should webfinger use the acct: scheme rather than simply a query parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are important, but I'm unsure how popular a choice that will be with the IETF. PEJ: WebFinger uses any URI scheme. The "acct" scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the "acct" URI, and it's a valid purpose. The one example I like to give is "How do we identify an account at Twitter?" There is no email, so "mailto" is not the right URI. A user has an account at any service provider and the "acct" URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever). - JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue. PEJ: I don't understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I'm looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the "rel" value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like "properties", "titles", etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it's simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far. - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at. PEJ: It has been said before that there were IPR claims on XRI. I've never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a "document" that contains "links" and "metadata" or something - like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody's IPR, so there's no point worrying about it without solid evidence. - Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc. PEJ: I'm not sure what you are asking here. Paul I accept that some or all of these concerns may be invalid, but as webfinger draws nearer to the standards track, perhaps it is possible that more people upstream could weigh in. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Sunday, December 16, 2012 4:01 PM To: webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process [snip] Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow consensus to be reached fastest. Today I ordered my StartSSL certificate, so hopefully I can do my little bit too :) However, that is not the greatest of the concerns that I have seen. The most serious critique I've seen to date is the thread form Mark Nottingham, "Looking at Webfinger" http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html In particular: [[ Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here). * What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space. ]] Mark Nottingham has a stellar reputation at the IETF, and these are some of the more serious concerns raised to date, imho, and have yet to be fully addressed. And that may take some time to work through. If perhaps going the "informational" route could save a significant amount of time, say, 6 months or a year, do you think would it be worth considering? Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Melvin Carvalho Sent: Sunday, December 16, 2012 10:08 AM To: webfinger@googlegroups.com Subject: Possibly speeding up the RFC process Webfinger is now in it's 4th year and I think everyone would agree that we are keen to see it shipped It seems to me that there are two value added use cases that have remained constant from the start. 1) Lookup of a string of type user@host to produce a HTTP URL 2) Lookup of a string of type mailto:user@host to produce a HTTP URL These are two things that would really be very useful, irrespective of all the other benefits that webfinger has to offer. We're perhaps at a point where both of these two cases have a solution. So maybe it may be an idea to tidy up the current RFC in the WG and mark it as informational in line with the following: http://www.ietf.org/iesg/informational-vs-experimental.html [[ An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process ]] I'm speculating here that this would get webfinger shipped more quickly. Getting webfinger to IETF to recommendation level would appear to be a greater task. Perhaps adding months to the time line, and if i have understood correctly there's no guarantee that an RFC will make it to recommendation status. Part of me wants webfinger to be the best spec it can be, and for quality to be really high, yet another part would like to see webfinger actually shipped asap, and to start using a stable form to complete the loop in discovering more information from email via HTTP. So, just putting the idea out there. [snip] ------=_NextPart_000_00C9_01CDDBB0.89F82340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Comments are in inline:

 

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Sunday, December 16, 2012 4:38 PM
To: Paul E. = Jones
Cc: webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

 

On 16 December 2012 22:27, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

Most of those issues have been addressed.  We’ve divorced = WF from Hostmeta.  XRD is no longer used.  We are using JRD, = but I see no good reason to exchange it.  It’s six of one, = half a dozen of anther when it comes to a format like that.  JRD is = clean and it has some nice properties about it that allow us to do = things like are shown in the examples.  I think the biggest concern = people had was the need to go read RFC 6415 or the XRD spec.  = We’ve addressed that by documenting JRD entirely within the WF = spec itself.


Yes, I did note that those changes were made, and = I particularly like the move from XML to JSON.

I could be = mistaken, but I am unsure that that all of the concerns will have been = addressed to the satisfaction of the IESG.

The ones I = noted:

- Should webfinger use the acct: scheme rather than simply = a query parameter.  This strikes me as a 'vanity' URI scheme.  = Aesthetics are important, but I'm unsure how popular a choice that will = be with the IETF.

 

PEJ: WebFinger uses any URI scheme.  The = “acct” scheme is just one of them and is not core to the = spec now, though there is a statement recommending its use to identify = accounts.  That is its purpose and the “acct” URI, and = it’s a valid purpose.  The one example I like to give is = “How do we identify an account at Twitter?”  There is = no email, so “mailto” is not the right URI.  A user has = an account at any service provider and the “acct” URI would = identify the account, not the particular service at the service provider = (e.g., email, XMPP, or whatever).


- JRD does not allow an array of items/subjects to = be rendered in response to an HTTP request, whereas other serializations = do allow that.  This leads to an interoperability issue.

 

PEJ: I don’t understand your concern. If I query my server, I = get an array of link relations. I can step through those sequentially to = find what I’m looking for.  If I want to arrange the data = different, I could.  There was a proposal, for example, to allow = the “rel” value be the key that refers to an array of = possible values.  That works, but the issue is that we lose useful = constructs like “properties”, “titles”, etc., = unless we have keys that point to arrays of objects.  This can get = syntactically ugly.  I personally like the way JRD is defined: = it’s simple and clean.  It definitely does not present = interoperability issues.  An interop problem exists when two = devices implanting the same thing do it differently.  If you = implement JRD, there is no interop issue.  JRD is JRD as defined = entirely in the WF spec. People have been able to use it just fine so = far.

- Concerns were raised over the IPR of XRD/JRD.  = IANAL, but to the best of my knowledge they are not creative commons, or = royalty free under, say, IETF / W3C / ISO.  This topic would be = well outside my area of expertize, but something the IETF may look = at.

 

PEJ: It has been said before that there were IPR claims on XRI.  = I’ve never heard an IPR claim on XRD, though.  And JRD is an = entirely different syntax defined within the IETF (Eran, specifically). =  If there are IPR claims on JRD, then it must have something to do = with very high-level concepts for which there would be no way to escape, = such as the notion of defining a “document” that contains = “links” and “metadata” or something – like = HTML.  Until an IPR statement is filed, I think we can ignore = this.  Anything we would consider might fall into the realm of = somebody’s IPR, so there’s no point worrying about it = without solid evidence.

- Could webfinger be recommended = as a best practice if the scope is sufficiently wide, to overlap in = areas where the W3C has already standardized.  Namely those of = discovery via http (aka linked data) etc.

 

PEJ: I’m not sure what you are asking = here.

 

Paul

I accept that some or all of these concerns may be = invalid, but as webfinger draws nearer to the standards track, perhaps = it is possible that more people upstream could weigh = in.
 

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 4:01 = PM
To: webfinger@googlegroups.com
Cc: webfinger@ietf.org
Subject: Re: = [webfinger] Possibly speeding up the RFC = process

 <= /o:p>

[snip]

Re: the = HTTP/HTTPS debate, I'm really supportive of whatever will allow = consensus to be reached fastest.  Today I ordered my StartSSL = certificate, so hopefully I can do my little bit too :)

However, = that is not the greatest of the concerns that I have seen.  The = most serious critique I've seen to date is the thread form Mark = Nottingham, "Looking at Webfinger"

http://www.ietf.org/mail-archive/web/apps-discuss/curre= nt/msg06487.html

In particular:

[[

Astute = observers will notice that this approach removes the need for an ACCT = URI scheme (at least here).

* What's the fascination with XRD = and JRD? These specifications seem to be creeping into IETF = architecture; first it was in a pure security context, but now folks are = talking about using them in a much more generic way, as a cornerstone of = what we do. As such, I think they deserve a MUCH closer look, especially = since we're defining things with "Web" in their name when the = W3C has already defined solutions in this space.

]]

Mark = Nottingham has a stellar reputation at the IETF, and these are some of = the more serious concerns raised to date, imho, and have yet to be fully = addressed.  And that may take some time to work through.

If = perhaps going the "informational" route could save a = significant amount of time, say, 6 months or a year, do you think would = it be worth considering?
 

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 = AM
To: webfinger@googlegroups.com
Subject: = Possibly speeding up the RFC = process

 <= /o:p>

Webfinger = is now in it's 4th year and I think everyone would agree that we are = keen to see it shipped

It seems to me that there are two value = added use cases that have remained constant from the start.

1) = Lookup of a string of type user@host to produce a HTTP URL
2) Lookup = of a string of type mailto:user@host to produce a HTTP URL

These are = two things that would really be very useful, irrespective of all the = other benefits that webfinger has to offer.

We're perhaps at a = point where both of these two cases have a solution.

So maybe it = may be an idea to tidy up the current RFC in the WG and mark it as = informational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.= html

[[
An "Informational" specification is = published for the general information of the Internet community, and = does not represent an Internet community consensus or recommendation. = The Informational designation is intended to provide for the timely = publication of a very broad range of responsible informational documents = from many sources, subject only to editorial considerations and to = verification that there has been adequate coordination with the = standards process
]]

I'm speculating here that this would get = webfinger shipped more quickly.  Getting webfinger to IETF to = recommendation level would appear to be a greater task.  Perhaps = adding months to the time line, and if i have understood correctly = there's no guarantee that an RFC will make it to recommendation = status.

Part of me wants webfinger to be the best spec it can be, = and for quality to be really high, yet another part would like to see = webfinger actually shipped asap, and to start using a stable form to = complete the loop in discovering more information from email via = HTTP.  So, just putting the idea out there.

[snip]

 

------=_NextPart_000_00C9_01CDDBB0.89F82340-- From melvincarvalho@gmail.com Sun Dec 16 14:32:50 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7D21F84BC for ; Sun, 16 Dec 2012 14:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEFmIpPTU6lg for ; Sun, 16 Dec 2012 14:32:49 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0C1721F8477 for ; Sun, 16 Dec 2012 14:32:48 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4868027iaz.31 for ; Sun, 16 Dec 2012 14:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GyH/EqLa4+506+RYgEziMhVXSB6BSlam2cFbCdnTNC0=; b=fy+amCH2C4Umj74X0FogZTvjtCLR7H3M2oU0gT0fGj5Ta9q620TQspyAtpkR/UB4X+ jjWjyRtKO+7BpFXNNj11NAh2LUkd5wue1Rclh7MMwgnoTazjNdlU0qJWHdFLvS/QuTEY Xv923vyAgyQAKxsm3+1rG8mTxW33EXJBDiFV9mn/ek0i3Yr+hitp64F43U7rJvoqt5gy T2XtYlvmze1Kk0K+cjF7JuBsCIvy7bsdpwLHv68qFFK3XVcivIc4cBCFXGdUfhRBg65C kcAExTeZcyJEiy8Bk2gK7o5iZ71UTrQBRoSq9QC6g0qbTi9HjB3H9mxYAXzMXoRMqubv plgg== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr7546220igk.41.1355697168384; Sun, 16 Dec 2012 14:32:48 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 14:32:48 -0800 (PST) In-Reply-To: <00c801cddbda$72cc7d90$586578b0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> Date: Sun, 16 Dec 2012 23:32:48 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93409012501ab04d0ffd85c Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:32:50 -0000 --14dae93409012501ab04d0ffd85c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16 December 2012 23:12, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Comments are in inline:**** > > ** ** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Sunday, December 16, 2012 4:38 PM > *To:* Paul E. Jones > *Cc:* webfinger@googlegroups.com; webfinger@ietf.org > > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > ** ** > > ** ** > > On 16 December 2012 22:27, Paul E. Jones wrote:**= * > * > > Melvin,**** > > **** > > Most of those issues have been addressed. We=92ve divorced WF from > Hostmeta. XRD is no longer used. We are using JRD, but I see no good > reason to exchange it. It=92s six of one, half a dozen of anther when it > comes to a format like that. JRD is clean and it has some nice propertie= s > about it that allow us to do things like are shown in the examples. I > think the biggest concern people had was the need to go read RFC 6415 or > the XRD spec. We=92ve addressed that by documenting JRD entirely within = the > WF spec itself.**** > > > Yes, I did note that those changes were made, and I particularly like the > move from XML to JSON. > > I could be mistaken, but I am unsure that that all of the concerns will > have been addressed to the satisfaction of the IESG. > > The ones I noted: > > - Should webfinger use the acct: scheme rather than simply a query > parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are > important, but I'm unsure how popular a choice that will be with the IETF= . > **** > > ** ** > > PEJ: WebFinger uses *any* URI scheme. The =93acct=94 scheme is just one = of > them and is not core to the spec now, though there is a statement > recommending its use to identify accounts. That is its purpose and the > =93acct=94 URI, and it=92s a valid purpose. The one example I like to gi= ve is > =93How do we identify an account at Twitter?=94 There is no email, so = =93mailto=94 > is not the right URI. A user has an account at any service provider and > the =93acct=94 URI would identify the account, not the particular service= at > the service provider (e.g., email, XMPP, or whatever). > It's great that acct: is almost completely decoupled from the spec. Sure I do understand why acct: would be useful. But Mark and others pointed out you could equally use webfinger?acct=3Dbob or /.well-known/user/bob my own suggestion from February was /@/bob None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme. > **** > > > - JRD does not allow an array of items/subjects to be rendered in respons= e > to an HTTP request, whereas other serializations do allow that. This lea= ds > to an interoperability issue.**** > > ** ** > > PEJ: I don=92t understand your concern. If I query my server, I get an ar= ray > of link relations. I can step through those sequentially to find what I= =92m > looking for. If I want to arrange the data different, I could. There wa= s > a proposal, for example, to allow the =93rel=94 value be the key that ref= ers to > an array of possible values. That works, but the issue is that we lose > useful constructs like =93properties=94, =93titles=94, etc., unless we ha= ve keys > that point to arrays of objects. This can get syntactically ugly. I > personally like the way JRD is defined: it=92s simple and clean. It > definitely does not present interoperability issues. An interop problem > exists when two devices implanting the same thing do it differently. If > you implement JRD, there is no interop issue. JRD is JRD as defined > entirely in the WF spec. People have been able to use it just fine so far= . > The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link. In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations. > > > - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best o= f > my knowledge they are not creative commons, or royalty free under, say, > IETF / W3C / ISO. This topic would be well outside my area of expertize, > but something the IETF may look at.**** > > ** ** > > PEJ: It has been said before that there were IPR claims on XRI. I=92ve > never heard an IPR claim on XRD, though. And JRD is an entirely differen= t > syntax defined within the IETF (Eran, specifically). If there are IPR > claims on JRD, then it must have something to do with very high-level > concepts for which there would be no way to escape, such as the notion of > defining a =93document=94 that contains =93links=94 and =93metadata=94 or= something =96 > like HTML. Until an IPR statement is filed, I think we can ignore this. > Anything we would consider might fall into the realm of somebody=92s IPR,= so > there=92s no point worrying about it without solid evidence. > If JRD is completely under the IETF IPR, that would be extremely cool. I was unaware of that, if you have a pointer that would be great. > > > - Could webfinger be recommended as a best practice if the scope is > sufficiently wide, to overlap in areas where the W3C has already > standardized. Namely those of discovery via http (aka linked data) etc.*= * > ** > > ** ** > > PEJ: I=92m not sure what you are asking here. > I think the point Mark was suggesting is that both webfinger and the w3c 'web stack' offer options for discovery. Namely the W3C has spent much of the last 10 years working on discovery based on HTTP identifiers. If webfinger becomes a general purpose discovery method for any URI, then there is a possible overlap, which may perhaps lead to further discussion. As you point out, it's just speculation at this point. Tho my understanding of the IETF process is that they do tend to drill down into the details, so sometimes it doesnt hurt to be prepared, or have a plan B := ) > **** > > ** ** > > Paul > > > I accept that some or all of these concerns may be invalid, but as > webfinger draws nearer to the standards track, perhaps it is possible tha= t > more people upstream could weigh in. > **** > > **** > > Paul**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Sunday, December 16, 2012 4:01 PM > *To:* webfinger@googlegroups.com > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > **** > > [snip]**** > > Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow > consensus to be reached fastest. Today I ordered my StartSSL certificate= , > so hopefully I can do my little bit too :) > > However, that is not the greatest of the concerns that I have seen. The > most serious critique I've seen to date is the thread form Mark Nottingha= m, > "Looking at Webfinger" > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html > > In particular: > > [[ > > Astute observers will notice that this approach removes the need for an > ACCT URI scheme (at least here). > > * What's the fascination with XRD and JRD? These specifications seem to b= e > creeping into IETF architecture; first it was in a pure security context, > but now folks are talking about using them in a much more generic way, as= a > cornerstone of what we do. As such, I think they deserve a MUCH closer > look, especially since we're defining things with "Web" in their name whe= n > the W3C has already defined solutions in this space. > > ]] > > Mark Nottingham has a stellar reputation at the IETF, and these are some > of the more serious concerns raised to date, imho, and have yet to be ful= ly > addressed. And that may take some time to work through. > > If perhaps going the "informational" route could save a significant amoun= t > of time, say, 6 months or a year, do you think would it be worth > considering? > **** > > **** > > Paul**** > > **** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Melvin Carvalho > *Sent:* Sunday, December 16, 2012 10:08 AM > *To:* webfinger@googlegroups.com > *Subject:* Possibly speeding up the RFC process**** > > **** > > Webfinger is now in it's 4th year and I think everyone would agree that w= e > are keen to see it shipped > > It seems to me that there are two value added use cases that have remaine= d > constant from the start. > > 1) Lookup of a string of type user@host to produce a HTTP URL > 2) Lookup of a string of type mailto:user@host to produce a HTTP URL > > These are two things that would really be very useful, irrespective of al= l > the other benefits that webfinger has to offer. > > We're perhaps at a point where both of these two cases have a solution. > > So maybe it may be an idea to tidy up the current RFC in the WG and mark > it as informational in line with the following: > > http://www.ietf.org/iesg/informational-vs-experimental.html > > [[ > An "Informational" specification is published for the general information > of the Internet community, and does not represent an Internet community > consensus or recommendation. The Informational designation is intended to > provide for the timely publication of a very broad range of responsible > informational documents from many sources, subject only to editorial > considerations and to verification that there has been adequate > coordination with the standards process > ]] > > I'm speculating here that this would get webfinger shipped more quickly. > Getting webfinger to IETF to recommendation level would appear to be a > greater task. Perhaps adding months to the time line, and if i have > understood correctly there's no guarantee that an RFC will make it to > recommendation status. > > Part of me wants webfinger to be the best spec it can be, and for quality > to be really high, yet another part would like to see webfinger actually > shipped asap, and to start using a stable form to complete the loop in > discovering more information from email via HTTP. So, just putting the > idea out there. **** > > [snip]**** > > ** ** > --14dae93409012501ab04d0ffd85c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 16 December 2012 23:12, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Comments are in inline:

=A0<= /p>

=A0

From:= Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Sunday, December 16, 2012 4:38 PM
To: Paul E. Jones<= br>Cc: webfinger@googlegroups.com; webfinger@ietf.org


Subject: Re: [webfinger] Possibly speeding up = the RFC process

=A0

=A0

On 16 December 2012 22:27, Paul E. Jones <paulej@packetizer.= com> wrote:

Melvin,

=A0

Most of those issues have= been addressed.=A0 We=92ve divorced WF from Hostmeta.=A0 XRD is no longer = used.=A0 We are using JRD, but I see no good reason to exchange it.=A0 It= =92s six of one, half a dozen of anther when it comes to a format like that= .=A0 JRD is clean and it has some nice properties about it that allow us to= do things like are shown in the examples.=A0 I think the biggest concern p= eople had was the need to go read RFC 6415 or the XRD spec.=A0 We=92ve addr= essed that by documenting JRD entirely within the WF spec itself.=


Yes, I = did note that those changes were made, and I particularly like the move fro= m XML to JSON.

I could be mistaken, but I am unsure that that all of= the concerns will have been addressed to the satisfaction of the IESG.

The ones I noted:

- Should webfinger use the acct: scheme rather= than simply a query parameter.=A0 This strikes me as a 'vanity' UR= I scheme.=A0 Aesthetics are important, but I'm unsure how popular a cho= ice that will be with the IETF.=

=A0<= /p>

PEJ: WebFinger u= ses any URI scheme.=A0 The =93acct=94 scheme is just one of them and= is not core to the spec now, though there is a statement recommending its = use to identify accounts.=A0 That is its purpose and the =93acct=94 URI, an= d it=92s a valid purpose.=A0 The one example I like to give is =93How do we= identify an account at Twitter?=94=A0 There is no email, so =93mailto=94 i= s not the right URI.=A0 A user has an account at any service provider and t= he =93acct=94 URI would identify the account, not the particular service at= the service provider (e.g., email, XMPP, or whatever).


It's great that acc= t: is almost completely decoupled from the spec.

Sure I do understan= d why acct: would be useful.=A0

But Mark and others pointed out you= could equally use

webfinger?acct=3Dbob

or

/.well-known/user/bob

my o= wn suggestion from February was

/@/bob

None of the above are = as beautiful as acct: but the debate may arise this is worth creating a new= uri scheme.=A0
=A0

<= /span>


- JRD does not allow= an array of items/subjects to be rendered in response to an HTTP request, = whereas other serializations do allow that.=A0 This leads to an interoperab= ility issue.

=A0<= /p>

PEJ: I don=92t u= nderstand your concern. If I query my server, I get an array of link relati= ons. I can step through those sequentially to find what I=92m looking for.= =A0 If I want to arrange the data different, I could.=A0 There was a propos= al, for example, to allow the =93rel=94 value be the key that refers to an = array of possible values.=A0 That works, but the issue is that we lose usef= ul constructs like =93properties=94, =93titles=94, etc., unless we have key= s that point to arrays of objects.=A0 This can get syntactically ugly. =A0I= personally like the way JRD is defined: it=92s simple and clean.=A0 It def= initely does not present interoperability issues.=A0 An interop problem exi= sts when two devices implanting the same thing do it differently.=A0 If you= implement JRD, there is no interop issue.=A0 JRD is JRD as defined entirel= y in the WF spec. People have been able to use it just fine so far.<= /p>


The link relations cont= ain 3 components.=A0=A0 The subject, the predicate and the object.=A0 In ot= her language the entity the attribute and the value.=A0 The Entity in this = case would be @subject, the attribute would be the rel of the link, and the= value would be the value of the link.

In almost every serialization I know, multiple subjects/entities are pe= rmissible, in an array of (say JSON) objects.=A0 In JRD there is a constrai= nt limiting the serialization to exactly one entity/subject.=A0 This imho c= ould be seen as a slight weakness, especially it it makes the serialization= of choice not 100% interoperable with others more permissible serializatio= ns.
=A0


- Concerns were raised over the IPR of = XRD/JRD.=A0 IANAL, but to the best of my knowledge they are not creative co= mmons, or royalty free under, say, IETF / W3C / ISO.=A0 This topic would be= well outside my area of expertize, but something the IETF may look at.

=A0<= /span>

PEJ: It has bee= n said before that there were IPR claims on XRI.=A0 I=92ve never heard an I= PR claim on XRD, though.=A0 And JRD is an entirely different syntax defined= within the IETF (Eran, specifically). =A0If there are IPR claims on JRD, t= hen it must have something to do with very high-level concepts for which th= ere would be no way to escape, such as the notion of defining a =93document= =94 that contains =93links=94 and =93metadata=94 or something =96 like HTML= .=A0 Until an IPR statement is filed, I think we can ignore this.=A0 Anythi= ng we would consider might fall into the realm of somebody=92s IPR, so ther= e=92s no point worrying about it without solid evidence.


If JRD is completely un= der the IETF IPR, that would be extremely cool.=A0 I was unaware of that, i= f you have a pointer that would be great.
=A0


- Could webfin= ger be recommended as a best practice if the scope is sufficiently wide, to= overlap in areas where the W3C has already standardized.=A0 Namely those o= f discovery via http (aka linked data) etc.

=A0<= /span>

PEJ: I=92m not = sure what you are asking here.


I think the point Mark = was suggesting is that both webfinger and the w3c 'web stack' offer= options for discovery.=A0 Namely the W3C has spent much of the last 10 yea= rs working on discovery based on HTTP identifiers.=A0 If webfinger becomes = a general purpose discovery method for any URI, then there is a possible ov= erlap, which may perhaps lead to further discussion.

As you point out, it's just speculation at this point.=A0 Tho my un= derstanding of the IETF process is that they do tend to drill down into the= details, so sometimes it doesnt hurt to be prepared, or have a plan B :) =A0

=A0

Paul



I accept that some or all of these concerns = may be invalid, but as webfinger draws nearer to the standards track, perha= ps it is possible that more people upstream could weigh in.
=A0

=A0

Paul=

=A0<= /u>

From:= webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf = Of Melvin Carvalho
Sent: Sunday, December 16, 2012 4:01 PM
To: webfinger@googlegroups.co= m
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process=

=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">[snip]

Re: the HTTP/HTTPS debate, I'm re= ally supportive of whatever will allow consensus to be reached fastest.=A0 = Today I ordered my StartSSL certificate, so hopefully I can do my little bi= t too :)

However, that is not the greatest of the concerns that I have seen.=A0 = The most serious critique I've seen to date is the thread form Mark Not= tingham, "Looking at Webfinger"

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html

In particular:

[[

Astute observers will notice that this = approach removes the need for an ACCT URI scheme (at least here).

*= What's the fascination with XRD and JRD? These specifications seem to = be creeping into IETF architecture; first it was in a pure security context= , but now folks are talking about using them in a much more generic way, as= a cornerstone of what we do. As such, I think they deserve a MUCH closer l= ook, especially since we're defining things with "Web" in the= ir name when the W3C has already defined solutions in this space.

]]

Mark Nottingham has a stellar reputation at the IETF, and the= se are some of the more serious concerns raised to date, imho, and have yet= to be fully addressed.=A0 And that may take some time to work through.

If perhaps going the "informational" route could save a signi= ficant amount of time, say, 6 months or a year, do you think would it be wo= rth considering?
=A0

=A0

Paul<= u>

=A0<= /p>

From: webfi= nger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 AM
To: webfinger@googlegroups.c= om
Subject: Possibly speeding up the RFC process

=A0

Webfinger is= now in it's 4th year and I think everyone would agree that we are keen= to see it shipped

It seems to me that there are two value added use cases that have remai= ned constant from the start.

1) Lookup of a string of type user@host= to produce a HTTP URL
2) Lookup of a string of type mailto:user@host to produce a HTTP URL

These are two things that would really be very useful, irrespective of = all the other benefits that webfinger has to offer.

We're perhap= s at a point where both of these two cases have a solution.

So maybe= it may be an idea to tidy up the current RFC in the WG and mark it as info= rmational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.h= tml

[[
An "Informational" specification is publishe= d for the general information of the Internet community, and does not repre= sent an Internet community consensus or recommendation. The Informational d= esignation is intended to provide for the timely publication of a very broa= d range of responsible informational documents from many sources, subject o= nly to editorial considerations and to verification that there has been ade= quate coordination with the standards process
]]

I'm speculating here that this would get webfinger shipped mo= re quickly.=A0 Getting webfinger to IETF to recommendation level would appe= ar to be a greater task.=A0 Perhaps adding months to the time line, and if = i have understood correctly there's no guarantee that an RFC will make = it to recommendation status.

Part of me wants webfinger to be the best spec it can be, and for quali= ty to be really high, yet another part would like to see webfinger actually= shipped asap, and to start using a stable form to complete the loop in dis= covering more information from email via HTTP.=A0 So, just putting the idea= out there.

[snip]

=A0


--14dae93409012501ab04d0ffd85c-- From nick@silverbucket.net Sun Dec 16 14:33:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67021F84CE for ; Sun, 16 Dec 2012 14:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8A0VfhMVUFb for ; Sun, 16 Dec 2012 14:33:38 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1076521F8496 for ; Sun, 16 Dec 2012 14:33:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5287343oag.31 for ; Sun, 16 Dec 2012 14:33:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=bw/2ySI47dx6mFgLavesrJExDcalWHeh9jko0uEvoIM=; b=ffSMtc8vKJo7MNtvizM9/FPB7XGgfU2x2lrkzRJ5idrpKv0AZjHezePeEoaNo3OS6r CvT1B31G1wzYK3FZRJc7Nnx6TQ1L1+EE2jUaoGHWRwcxLVVL2RdcMAkVRO/h29BzH5PU tt5ZdOwnTjpVf8nOpK4zvHty6gs3zuPVWuRmRuVdxqzmJmzaoqhs7GJHaWMySC9mtHsS hp3hmAxNErXSe+Sfu2q0mKbqJgpwFGVjXZ/qAkKp73fDsIlIgWPxSAf5XQg0lqzpW+mZ Dawy0cSOZXioSKJ+CI7C77kVzvHgFwF2YC+fTZkFa+3Rb2jrQLXChy/HEq9iVBkIOrRr a0rg== Received: by 10.182.54.103 with SMTP id i7mr10004189obp.62.1355697217602; Sun, 16 Dec 2012 14:33:37 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id o3sm8392444obk.13.2012.12.16.14.33.35 (version=SSLv3 cipher=OTHER); Sun, 16 Dec 2012 14:33:36 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5075665obc.31 for ; Sun, 16 Dec 2012 14:33:35 -0800 (PST) Received: by 10.60.32.200 with SMTP id l8mr10452141oei.43.1355697215086; Sun, 16 Dec 2012 14:33:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.92.66 with HTTP; Sun, 16 Dec 2012 14:33:04 -0800 (PST) In-Reply-To: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> From: Nick Jennings Date: Sun, 16 Dec 2012 23:33:04 +0100 Message-ID: To: Brad Fitzpatrick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmQYuoxN/861wODosaf9nxFdM4u88ZTDG1tIhKd/BagQ/INrn1OOz9Nvz1LOMlft0KNpRNG Cc: "Paul E. Jones" , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:33:38 -0000 On Sun, Dec 16, 2012 at 10:31 PM, Brad Fitzpatrick wr= ote: > On Sun, Dec 16, 2012 at 1:21 PM, Paul E. Jones > wrote: > >> Given all of the complexity, I think we should go with HTTPS only for no= w >> and then work on an HTTP fallback in a WF working group. Somebody sugge= sted >> something like that earlier this week (sorry, forgot who), and I=E2=80= =99m now of >> the mind that that is the way to go forward. Start secure, introduce >> non-secure modes later. > > > Yes, please! :-) I was hoping that would be the result of this thread. I'm OK with it as well, it makes sense to keep things secure, and moving this process along is more important to me than the downsides of no HTTP option. However, I really hope that not only does StartSSL stay operational, but that other free cert providers pop up. I'm a little uneasy about that for the indieweb community. I certainly don't want to pay $50-100/year for a cert on my personal domain just to serve WF traffic (that would be a little silly). From bradfitz@google.com Sun Dec 16 14:38:22 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9FF21F84DC for ; Sun, 16 Dec 2012 14:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3pEJIHOyH7t for ; Sun, 16 Dec 2012 14:38:21 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0821F84CC for ; Sun, 16 Dec 2012 14:38:20 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2539101wey.31 for ; Sun, 16 Dec 2012 14:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tFmZTw5qhD3rFiCUMzS5BrPnvf78oLSB5BwKO2VEhSg=; b=FuZvva6Bmdp0z3998g1RoINo222kn1Av72wTmc4iY9T2mXXg7UdyqlIW5pEbiPKnKM XVHM8thkg9+rnNs9y+PfU1c9cacB5xGA6c4ulgDGJsigiA31JQm/HWlXmfjKt+oTOBAg xI7yXzL0hDknKzHwx/Gfu3AcYk2O6U9vi2/lp41BjxRAG+aGeJdC6mVackFUprozHwYQ fe7nn3J6mRcIgem/nHsVzdoBD5/TuuoVRcJGsCx9jOfgMmwDuNYItvYmlR0kPbXN/eMo aI9mi5nfHEeIQlcR1tv25tOy9Q1Zsk9P53clulQXZK0pgF86TKBN2tsXPkZYNk0QMfEo y4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tFmZTw5qhD3rFiCUMzS5BrPnvf78oLSB5BwKO2VEhSg=; b=XTQWi12BLMcihmnBJCdg21rvE5W3fLny+sSYR+rBwG/h4gM0KaL1OnVmoIytIyp/XP nR4nATuZhn+IzyXbKLxrAvW+7T4+dCW7JA5VBqemqWOSuMECFaUBR8oSkCpMbsFdpOH9 qtfb2IX3aglRNVOF8zqlvvqbM/KxA69ZhUQXMfc3O4Ixcw+EpJV1dnfRWbXEOAp20N4h FwFAE2P3p2QiDvSYIeb3aoxxZ07n3IRucJcirNokGdZWfBnP4V8z/dh1vHTiCCzqKLoM re65Vb3p8M5r7z5gGDlsKM6Ai6k93p1/SQemezVVLC/RIRHePfg1gmSi4ga6XqSjBRT9 pTng== MIME-Version: 1.0 Received: by 10.194.58.175 with SMTP id s15mr13697042wjq.31.1355697500038; Sun, 16 Dec 2012 14:38:20 -0800 (PST) Received: by 10.194.166.100 with HTTP; Sun, 16 Dec 2012 14:38:19 -0800 (PST) In-Reply-To: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> Date: Sun, 16 Dec 2012 14:38:19 -0800 Message-ID: From: Brad Fitzpatrick To: Nick Jennings Content-Type: multipart/alternative; boundary=047d7ba97924e9a7b104d0ffebea X-Gm-Message-State: ALoCoQk2fADtbQOalObe0AJAwwaVWZt4W6hibqDar5xU/Kok2QRPmpmNcFRtCph2cF+maPpLkSv7r05Uftp2LQD7c35IPkgyKOGoDR4ZOT9qMZvkyTL8Ls3dAjaDIYc+kjKDAuyGHnf23jARHeFWe+yLYC7UpQVYBXlOsYybSBOT8aF33mWxk6GhGLp1OAe9lk+PsDMNhD3C Cc: "Paul E. Jones" , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 22:38:22 -0000 --047d7ba97924e9a7b104d0ffebea Content-Type: text/plain; charset=UTF-8 On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings wrote: > > However, I really hope that not only does StartSSL stay operational, > but that other free cert providers pop up. I'm a little uneasy about > that for the indieweb community. I certainly don't want to pay > $50-100/year for a cert on my personal domain just to serve WF traffic > (that would be a little silly). > FWIW, I'm in the same boat. My personal email address is at danga.com, which doesn't currently serve on https, so I'll have to do the Startcom dance for that, just for WebFinger. I likewise hope that more free SSL options become available, so we're not reliant on them or the other "30-day-free" options. --047d7ba97924e9a7b104d0ffebea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
O= n Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings <nick@silverbucket.net> wrote:

However, I really hope that not only does StartSSL stay operational,
but that other free cert providers pop up. I'm a little uneasy about that for the indieweb community. I certainly don't want to pay
$50-100/year for a cert on my personal domain just to serve WF traffic
(that would be a little silly).

FWIW, I'm in the same boat. =C2=A0My person= al email address is at danga.com, which do= esn't currently serve on https, so I'll have to do the Startcom dan= ce for that, just for WebFinger.

I likewise hope that more free SSL options become avail= able, so we're not reliant on them or the other "30-day-free"= options.
--047d7ba97924e9a7b104d0ffebea-- From paulej@packetizer.com Sun Dec 16 15:21:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90A21F869B for ; Sun, 16 Dec 2012 15:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6U36MYhSgsi for ; Sun, 16 Dec 2012 15:21:22 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52921F865D for ; Sun, 16 Dec 2012 15:21:22 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBGNLK0r014561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 18:21:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355700080; bh=aaxU0gJQAYM3GMtSh8y6uArrNegsLph8/XmbzwLsesg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Bn36i/gJ4ZLlYJIjmwwC9EPZw6VEn/s6e57VygEy2Ohxs0qRQ6rCDv4XEFUEEf02d Omr0IbR5q3UmsNjEfS9HlImV9g8l+5s9ZfvSj1CGObmWEhw+TQNIRBBMZNFrWNgexg MZTPkMQ/jq4lYAQmayvHwZxQuax6PDw9XWta1T+8= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> In-Reply-To: Date: Sun, 16 Dec 2012 18:21:20 -0500 Message-ID: <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01CDDBBA.26185020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgBk3yM2pivedrg Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 23:21:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EF_01CDDBBA.26185020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Comments inline again: PEJ: WebFinger uses any URI scheme. The "acct" scheme is just one of them and is not core to the spec now, though there is a statement recommending its use to identify accounts. That is its purpose and the "acct" URI, and it's a valid purpose. The one example I like to give is "How do we identify an account at Twitter?" There is no email, so "mailto" is not the right URI. A user has an account at any service provider and the "acct" URI would identify the account, not the particular service at the service provider (e.g., email, XMPP, or whatever). It's great that acct: is almost completely decoupled from the spec. Sure I do understand why acct: would be useful. But Mark and others pointed out you could equally use webfinger?acct=bob or /.well-known/user/bob my own suggestion from February was /@/bob None of the above are as beautiful as acct: but the debate may arise this is worth creating a new uri scheme. PEJ: Yeah, all of these are possibilities. The one thing that I personally think is important is that the "thing" we query is a URI. So, forms that do not utilize URIs I think we should not consider. There are several ways to utilize URIs and I think it comes down to putting the URI as a part of the path or using a URI parameter. We're presently heading down the latter path. The disadvantage is that one cannot build a "truly" static site, though one can come close using Apache re-writing rules. That said, there is utility in the approach, since once can query for a specific URI and request the response to be filtered for a particular set of link relations ("rel" parameters). Thus, it's making the web programmable. I think we're past that debate now. I hope so. - JRD does not allow an array of items/subjects to be rendered in response to an HTTP request, whereas other serializations do allow that. This leads to an interoperability issue. PEJ: I don't understand your concern. If I query my server, I get an array of link relations. I can step through those sequentially to find what I'm looking for. If I want to arrange the data different, I could. There was a proposal, for example, to allow the "rel" value be the key that refers to an array of possible values. That works, but the issue is that we lose useful constructs like "properties", "titles", etc., unless we have keys that point to arrays of objects. This can get syntactically ugly. I personally like the way JRD is defined: it's simple and clean. It definitely does not present interoperability issues. An interop problem exists when two devices implanting the same thing do it differently. If you implement JRD, there is no interop issue. JRD is JRD as defined entirely in the WF spec. People have been able to use it just fine so far. The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link. In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations. PEJ: My understanding of subject is the "thing" I'm querying (e.g., acct:paulej@packetizer.com). Given that definition, JRD covers a single subject since WF is looking for a single "thing". Inside, there may be multiple "properties" for the "thing" (e.g., "http://packetizer.com/ns/name" is a property with a value "Paul E. Jones). Then there is an array of "link relations". The definition follows that of RFC 5988. Each link relation is identified by a "rel" value. There is also an optional "type". And there is an "href". JRD also allows for self-describing link relations, where the "href" is absent and "properties" are used to describe the value of the relation to the "rel". An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a "titles" array. You can see an example here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1. - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best of my knowledge they are not creative commons, or royalty free under, say, IETF / W3C / ISO. This topic would be well outside my area of expertize, but something the IETF may look at. PEJ: It has been said before that there were IPR claims on XRI. I've never heard an IPR claim on XRD, though. And JRD is an entirely different syntax defined within the IETF (Eran, specifically). If there are IPR claims on JRD, then it must have something to do with very high-level concepts for which there would be no way to escape, such as the notion of defining a "document" that contains "links" and "metadata" or something - like HTML. Until an IPR statement is filed, I think we can ignore this. Anything we would consider might fall into the realm of somebody's IPR, so there's no point worrying about it without solid evidence. If JRD is completely under the IETF IPR, that would be extremely cool. I was unaware of that, if you have a pointer that would be great. PEJ: I didn't say that, only that JRD was entirely documented in an IETF document (RFC 6415). The syntax was derived from XRD, though. I'm just not aware of any IPR claims on XRD, and whatever is claimed may or may not apply to JRD (since it is a different syntax). As I said, it would have to be a pretty broad, generic claim. - Could webfinger be recommended as a best practice if the scope is sufficiently wide, to overlap in areas where the W3C has already standardized. Namely those of discovery via http (aka linked data) etc. PEJ: I'm not sure what you are asking here. I think the point Mark was suggesting is that both webfinger and the w3c 'web stack' offer options for discovery. Namely the W3C has spent much of the last 10 years working on discovery based on HTTP identifiers. If webfinger becomes a general purpose discovery method for any URI, then there is a possible overlap, which may perhaps lead to further discussion. PEJ: WebFinger is narrowly defined. If there is another standard doing exactly the same thing with the same level of simplicity, I think it would have been adopted already. There are certainly other kinds of "discovery" protocols, but each that I have seen has a different scope, complexity, value, etc. The support for WF has been pretty strong thus far. I cannot say it will be the recommended best practice, though. We'll have to see what the adoption rate looks like. As you point out, it's just speculation at this point. Tho my understanding of the IETF process is that they do tend to drill down into the details, so sometimes it doesnt hurt to be prepared, or have a plan B :) PEJ: I'm too tired for a Plan B. WebFinger started as a spec with a lot of stuff inside and we've thrown out lots of options. We're now down to this, a product of several years' worth of work by multiple people. Once we settle on the HTTP/HTTPS issue, I hope we can say we're finished (modulo less controversial editorial things). There will be a review process, but I would not expect that to result is significant technical changes. Paul ------=_NextPart_000_00EF_01CDDBBA.26185020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Comments inline again:

 

 

PEJ: WebFinger uses any URI scheme.  The = “acct” scheme is just one of them and is not core to the = spec now, though there is a statement recommending its use to identify = accounts.  That is its purpose and the “acct” URI, and = it’s a valid purpose.  The one example I like to give is = “How do we identify an account at Twitter?”  There is = no email, so “mailto” is not the right URI.  A user has = an account at any service provider and the “acct” URI would = identify the account, not the particular service at the service provider = (e.g., email, XMPP, or = whatever).


It's great that acct: is almost completely = decoupled from the spec.

Sure I do understand why acct: would be = useful. 

But Mark and others pointed out you could equally = use

webfinger?acct=3Dbob

or

/.well-known/user/bob
my own suggestion from February was

/@/bob

None of = the above are as beautiful as acct: but the debate may arise this is = worth creating a new uri scheme. 

 

PEJ: Yeah, all of these are possibilities. The one thing that I = personally think is important is that the “thing” we query = is a URI.  So, forms that do not utilize URIs I think we should not = consider.  There are several ways to utilize URIs and  I think = it comes down to putting the URI as a part of the path or using a URI = parameter.  We’re presently heading down the latter = path.  The disadvantage is that one cannot build a = “truly” static site, though one can come close using Apache = re-writing rules.  That said, there is utility in the approach, = since once can query for a specific URI and request the response to be = filtered for a particular set of link relations (“rel” = parameters).  Thus, it’s making the web programmable.  I = think we’re past that debate now.  I hope = so.
 


- JRD = does not allow an array of items/subjects to be rendered in response to = an HTTP request, whereas other serializations do allow that.  This = leads to an interoperability issue.

 

PEJ: I don’t understand your concern. If I query my server, I = get an array of link relations. I can step through those sequentially to = find what I’m looking for.  If I want to arrange the data = different, I could.  There was a proposal, for example, to allow = the “rel” value be the key that refers to an array of = possible values.  That works, but the issue is that we lose useful = constructs like “properties”, “titles”, etc., = unless we have keys that point to arrays of objects.  This can get = syntactically ugly.  I personally like the way JRD is defined: = it’s simple and clean.  It definitely does not present = interoperability issues.  An interop problem exists when two = devices implanting the same thing do it differently.  If you = implement JRD, there is no interop issue.  JRD is JRD as defined = entirely in the WF spec. People have been able to use it just fine so = far.


The link relations contain 3 = components.   The subject, the predicate and the object.  = In other language the entity the attribute and the value.  The = Entity in this case would be @subject, the attribute would be the rel of = the link, and the value would be the value of the link.

In almost = every serialization I know, multiple subjects/entities are permissible, = in an array of (say JSON) objects.  In JRD there is a constraint = limiting the serialization to exactly one entity/subject.  This = imho could be seen as a slight weakness, especially it it makes the = serialization of choice not 100% interoperable with others more = permissible serializations.

 

PEJ: My understanding of subject is the “thing” I’m = querying (e.g., acct:paulej@packetizer.com).  Given that = definition, JRD covers a single subject since WF is looking for a single = “thing”.  Inside, there may be multiple = “properties” for the “thing” (e.g., = “http://packetizer.com/ns/name” is a property with a value = “Paul E. Jones).  Then there is an array of “link = relations”.  The definition follows that of RFC 5988.  = Each link relation is identified by a “rel” value.  = There is also an optional “type”.  And there is an = “href”.  JRD also allows for self-describing link = relations, where the “href” is absent and = “properties” are used to describe the value of the relation = to the “rel”.  An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section= -4.3.  Lastly, any link may have one or more human-readable = names in a “titles” array.  You can see an example = here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section= -4.1.

 

 



- Concerns were = raised over the IPR of XRD/JRD.  IANAL, but to the best of my = knowledge they are not creative commons, or royalty free under, say, = IETF / W3C / ISO.  This topic would be well outside my area of = expertize, but something the IETF may look at.

 

PEJ: It has been said before that there were IPR claims on XRI.  = I’ve never heard an IPR claim on XRD, though.  And JRD is an = entirely different syntax defined within the IETF (Eran, specifically). =  If there are IPR claims on JRD, then it must have something to do = with very high-level concepts for which there would be no way to escape, = such as the notion of defining a “document” that contains = “links” and “metadata” or something – like = HTML.  Until an IPR statement is filed, I think we can ignore = this.  Anything we would consider might fall into the realm of = somebody’s IPR, so there’s no point worrying about it = without solid = evidence.


If JRD is completely under the IETF IPR, = that would be extremely cool.  I was unaware of that, if you have a = pointer that would be great.

 

PEJ: I didn’t say that, only that JRD was entirely documented = in an IETF document (RFC 6415).  The syntax was derived from XRD, = though.  I’m just not aware of any IPR claims on XRD, and = whatever is claimed may or may not apply to JRD (since it is a different = syntax).  As I said, it would have to be a pretty broad, generic = claim.


 



- Could webfinger be recommended = as a best practice if the scope is sufficiently wide, to overlap in = areas where the W3C has already standardized.  Namely those of = discovery via http (aka linked data) etc.

 

PEJ: I’m not sure what you are asking = here.


I think the point Mark was suggesting is that = both webfinger and the w3c 'web stack' offer options for = discovery.  Namely the W3C has spent much of the last 10 years = working on discovery based on HTTP identifiers.  If webfinger = becomes a general purpose discovery method for any URI, then there is a = possible overlap, which may perhaps lead to further discussion.

 

PEJ: WebFinger is narrowly defined.  If there is another = standard doing exactly the same thing with the same level of simplicity, = I think it would have been adopted already.  There are certainly = other kinds of “discovery” protocols, but each that I have = seen has a different scope, complexity, value, etc. The support for WF = has been pretty strong thus far.  I cannot say it will be the = recommended best practice, though.  We’ll have to see what = the adoption rate looks like.


As you point out, it's just speculation at this = point.  Tho my understanding of the IETF process is that they do = tend to drill down into the details, so sometimes it doesnt hurt to be = prepared, or have a plan B :)

 

PEJ: I’m too tired for a Plan B.  WebFinger started as a = spec with a lot of stuff inside and we’ve thrown out lots of = options.  We’re now down to this, a product of several = years’ worth of work by multiple people.  Once we settle on = the HTTP/HTTPS issue, I hope we can say we’re finished (modulo = less controversial editorial things).  There will be a review = process, but I would not expect that to result is significant technical = changes.

 

Paul 

 

------=_NextPart_000_00EF_01CDDBBA.26185020-- From melvincarvalho@gmail.com Sun Dec 16 15:45:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2D21F865D for ; Sun, 16 Dec 2012 15:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBw2UhBpa0F3 for ; Sun, 16 Dec 2012 15:45:07 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3621F8504 for ; Sun, 16 Dec 2012 15:45:07 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4899447iaz.31 for ; Sun, 16 Dec 2012 15:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wAK/WMKZkZFQX6cFytFhdCGjoxU+cWHsjVy5swMAeco=; b=FKYb5Svzs9mYbmNbumScf/EvfQLxcA9hpe4iTqKtMcdvjQN+Vcp7zI5Mw3yMtdM76K 5d9cFSFfdwjwevb4uItJ5B3DA5GSe/Uaopv3qHI4p3AqYoeK5g2EuB8sr+3eOybFsjkt TNw3Ql/bFtzgF075JRCFVfiJkevWhcYN9BiZDwM+SeywdVkfyioBUHoN2HgCEP97nUz7 s4qe30/ept4YpC0tCXspJerFE2BvUB9lHuTaxAu3S8UC8mr97dDSsnNKSVh2/JWgofnx ZhDOssgIurh+RwuiQl//EMvpZT3Ld7NrvIb75gE1DQcamU7SW44Vqe6KG/Q9c4AcHPzn ldWQ== MIME-Version: 1.0 Received: by 10.50.179.99 with SMTP id df3mr7536119igc.20.1355701507132; Sun, 16 Dec 2012 15:45:07 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 15:45:07 -0800 (PST) In-Reply-To: <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> Date: Mon, 17 Dec 2012 00:45:07 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9340347c10e6004d100da39 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 23:45:09 -0000 --14dae9340347c10e6004d100da39 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17 December 2012 00:21, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Comments inline again:**** > > ** ** > > ** ** > > PEJ: WebFinger uses *any* URI scheme. The =93acct=94 scheme is just one = of > them and is not core to the spec now, though there is a statement > recommending its use to identify accounts. That is its purpose and the > =93acct=94 URI, and it=92s a valid purpose. The one example I like to gi= ve is > =93How do we identify an account at Twitter?=94 There is no email, so = =93mailto=94 > is not the right URI. A user has an account at any service provider and > the =93acct=94 URI would identify the account, not the particular service= at > the service provider (e.g., email, XMPP, or whatever).**** > > > It's great that acct: is almost completely decoupled from the spec. > > Sure I do understand why acct: would be useful. > > But Mark and others pointed out you could equally use > > webfinger?acct=3Dbob > > or > > /.well-known/user/bob > > my own suggestion from February was > > /@/bob > > None of the above are as beautiful as acct: but the debate may arise this > is worth creating a new uri scheme. **** > > ** ** > > PEJ: Yeah, all of these are possibilities. The one thing that I personall= y > think is important is that the =93thing=94 we query is a URI. So, forms = that > do not utilize URIs I think we should not consider. There are several wa= ys > to utilize URIs and I think it comes down to putting the URI as a part o= f > the path or using a URI parameter. We=92re presently heading down the la= tter > path. The disadvantage is that one cannot build a =93truly=94 static sit= e, > though one can come close using Apache re-writing rules. That said, ther= e > is utility in the approach, since once can query for a specific URI and > request the response to be filtered for a particular set of link relation= s > (=93rel=94 parameters). Thus, it=92s making the web programmable. I thi= nk we=92re > past that debate now. I hope so. > Sure, but query parameters can take URIs too, SWD did, for example. > **** > > > - JRD does not allow an array of items/subjects to be rendered in respons= e > to an HTTP request, whereas other serializations do allow that. This lea= ds > to an interoperability issue.**** > > **** > > PEJ: I don=92t understand your concern. If I query my server, I get an ar= ray > of link relations. I can step through those sequentially to find what I= =92m > looking for. If I want to arrange the data different, I could. There wa= s > a proposal, for example, to allow the =93rel=94 value be the key that ref= ers to > an array of possible values. That works, but the issue is that we lose > useful constructs like =93properties=94, =93titles=94, etc., unless we ha= ve keys > that point to arrays of objects. This can get syntactically ugly. I > personally like the way JRD is defined: it=92s simple and clean. It > definitely does not present interoperability issues. An interop problem > exists when two devices implanting the same thing do it differently. If > you implement JRD, there is no interop issue. JRD is JRD as defined > entirely in the WF spec. People have been able to use it just fine so far= . > **** > > > The link relations contain 3 components. The subject, the predicate and > the object. In other language the entity the attribute and the value. T= he > Entity in this case would be @subject, the attribute would be the rel of > the link, and the value would be the value of the link. > > In almost every serialization I know, multiple subjects/entities are > permissible, in an array of (say JSON) objects. In JRD there is a > constraint limiting the serialization to exactly one entity/subject. Thi= s > imho could be seen as a slight weakness, especially it it makes the > serialization of choice not 100% interoperable with others more permissib= le > serializations.**** > > ** ** > > PEJ: My understanding of subject is the =93thing=94 I=92m querying (e.g., > acct:paulej@packetizer.com). Given that definition, JRD covers a single > subject since WF is looking for a single =93thing=94. Inside, there may = be > multiple =93properties=94 for the =93thing=94 (e.g., =93 > http://packetizer.com/ns/name=94 is a property with a value =93Paul E. > Jones). Then there is an array of =93link relations=94. The definition > follows that of RFC 5988. Each link relation is identified by a =93rel= =94 > value. There is also an optional =93type=94. And there is an =93href=94= . JRD > also allows for self-describing link relations, where the =93href=94 is a= bsent > and =93properties=94 are used to describe the value of the relation to th= e > =93rel=94. An example is this: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. > Lastly, any link may have one or more human-readable names in a =93titles= =94 > array. You can see an example here: **** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.**= * > * > > ** ** > > **** > > > > - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best o= f > my knowledge they are not creative commons, or royalty free under, say, > IETF / W3C / ISO. This topic would be well outside my area of expertize, > but something the IETF may look at.**** > > **** > > PEJ: It has been said before that there were IPR claims on XRI. I=92ve > never heard an IPR claim on XRD, though. And JRD is an entirely differen= t > syntax defined within the IETF (Eran, specifically). If there are IPR > claims on JRD, then it must have something to do with very high-level > concepts for which there would be no way to escape, such as the notion of > defining a =93document=94 that contains =93links=94 and =93metadata=94 or= something =96 > like HTML. Until an IPR statement is filed, I think we can ignore this. > Anything we would consider might fall into the realm of somebody=92s IPR,= so > there=92s no point worrying about it without solid evidence.**** > > > If JRD is completely under the IETF IPR, that would be extremely cool. I > was unaware of that, if you have a pointer that would be great.**** > > ** ** > > PEJ: I didn=92t say that, only that JRD was entirely documented in an IET= F > document (RFC 6415). The syntax was derived from XRD, though. I=92m jus= t > not aware of any IPR claims on XRD, and whatever is claimed may or may no= t > apply to JRD (since it is a different syntax). As I said, it would have = to > be a pretty broad, generic claim. > This is outside of my scope of expertize. I couldnt really comment further, tho others may. > **** > > > **** > > > > - Could webfinger be recommended as a best practice if the scope is > sufficiently wide, to overlap in areas where the W3C has already > standardized. Namely those of discovery via http (aka linked data) etc.*= * > ** > > **** > > PEJ: I=92m not sure what you are asking here.**** > > > I think the point Mark was suggesting is that both webfinger and the w3c > 'web stack' offer options for discovery. Namely the W3C has spent much o= f > the last 10 years working on discovery based on HTTP identifiers. If > webfinger becomes a general purpose discovery method for any URI, then > there is a possible overlap, which may perhaps lead to further discussion= . > **** > > ** ** > > PEJ: WebFinger is narrowly defined. If there is another standard doing > exactly the same thing with the same level of simplicity, I think it woul= d > have been adopted already. There are certainly other kinds of =93discove= ry=94 > protocols, but each that I have seen has a different scope, complexity, > value, etc. The support for WF has been pretty strong thus far. I cannot > say it will be the recommended best practice, though. We=92ll have to se= e > what the adoption rate looks like. > Well linked data is adopted by many of the G7 govts., the world bank, cities, fire deparments, 1000s of businesses, academia, search engines and grass roots. > **** > > > As you point out, it's just speculation at this point. Tho my > understanding of the IETF process is that they do tend to drill down into > the details, so sometimes it doesnt hurt to be prepared, or have a plan B= :) > **** > > ** ** > > PEJ: I=92m too tired for a Plan B. WebFinger started as a spec with a lo= t > of stuff inside and we=92ve thrown out lots of options. We=92re now down= to > this, a product of several years=92 worth of work by multiple people. On= ce > we settle on the HTTP/HTTPS issue, I hope we can say we=92re finished (mo= dulo > less controversial editorial things). There will be a review process, bu= t > I would not expect that to result is significant technical changes. > Sure I appreciate the effort you've put in here. I'm just saying, as per my original post, that if there is pushback, it may be expedient to switch to "informational" status, as it would seemingly not have a big impact on implementers. As I said, just an idea, let's see how the spec is received after the HTTPS issue is resolved. > **** > > ** ** > > Paul **** > > ** ** > --14dae9340347c10e6004d100da39 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 00:21, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Comments in= line again:

=A0<= /p>

=A0

PEJ: WebFinger uses any URI scheme.=A0 Th= e =93acct=94 scheme is just one of them and is not core to the spec now, th= ough there is a statement recommending its use to identify accounts.=A0 Tha= t is its purpose and the =93acct=94 URI, and it=92s a valid purpose.=A0 The= one example I like to give is =93How do we identify an account at Twitter?= =94=A0 There is no email, so =93mailto=94 is not the right URI.=A0 A user h= as an account at any service provider and the =93acct=94 URI would identify= the account, not the particular service at the service provider (e.g., ema= il, XMPP, or whatever).


It's great that acct: is almost completely decoupled from th= e spec.

Sure I do understand why acct: would be useful.=A0

B= ut Mark and others pointed out you could equally use

webfinger?acct=3Dbob

or

/.well-known/user/bob

my o= wn suggestion from February was

/@/bob

None of the above are = as beautiful as acct: but the debate may arise this is worth creating a new= uri scheme.=A0

=A0<= /p>

PEJ: Yeah, all o= f these are possibilities. The one thing that I personally think is importa= nt is that the =93thing=94 we query is a URI.=A0 So, forms that do not util= ize URIs I think we should not consider. =A0There are several ways to utili= ze URIs and=A0 I think it comes down to putting the URI as a part of the pa= th or using a URI parameter.=A0 We=92re presently heading down the latter p= ath.=A0 The disadvantage is that one cannot build a =93truly=94 static site= , though one can come close using Apache re-writing rules.=A0 That said, th= ere is utility in the approach, since once can query for a specific URI and= request the response to be filtered for a particular set of link relations= (=93rel=94 parameters).=A0 Thus, it=92s making the web programmable.=A0 I = think we=92re past that debate now.=A0 I hope so.


Sure, but query par= ameters can take URIs too, SWD did, for example.
=A0
=A0


- JRD does not a= llow an array of items/subjects to be rendered in response to an HTTP reque= st, whereas other serializations do allow that.=A0 This leads to an interop= erability issue.

=A0<= /p>

PEJ: I don=92t u= nderstand your concern. If I query my server, I get an array of link relati= ons. I can step through those sequentially to find what I=92m looking for.= =A0 If I want to arrange the data different, I could.=A0 There was a propos= al, for example, to allow the =93rel=94 value be the key that refers to an = array of possible values.=A0 That works, but the issue is that we lose usef= ul constructs like =93properties=94, =93titles=94, etc., unless we have key= s that point to arrays of objects.=A0 This can get syntactically ugly. =A0I= personally like the way JRD is defined: it=92s simple and clean.=A0 It def= initely does not present interoperability issues.=A0 An interop problem exi= sts when two devices implanting the same thing do it differently.=A0 If you= implement JRD, there is no interop issue.=A0 JRD is JRD as defined entirel= y in the WF spec. People have been able to use it just fine so far.<= u>


The link relations contain 3 components.=A0=A0 The = subject, the predicate and the object.=A0 In other language the entity the = attribute and the value.=A0 The Entity in this case would be @subject, the = attribute would be the rel of the link, and the value would be the value of= the link.

In almost every serialization I know, multiple subjects/entities are pe= rmissible, in an array of (say JSON) objects.=A0 In JRD there is a constrai= nt limiting the serialization to exactly one entity/subject.=A0 This imho c= ould be seen as a slight weakness, especially it it makes the serialization= of choice not 100% interoperable with others more permissible serializatio= ns.

=A0<= /p>

PEJ: My understa= nding of subject is the =93thing=94 I=92m querying (e.g., acct:paulej@packetizer.com= ).=A0 Given that definition, JRD covers a single subject since WF is lo= oking for a single =93thing=94.=A0 Inside, there may be multiple =93propert= ies=94 for the =93thing=94 (e.g., =93http://packetizer.com/ns/name=94 is a property wi= th a value =93Paul E. Jones).=A0 Then there is an array of =93link relation= s=94.=A0 The definition follows that of RFC 5988.=A0 Each link relation is = identified by a =93rel=94 value.=A0 There is also an optional =93type=94.= =A0 And there is an =93href=94.=A0 JRD also allows for self-describing link= relations, where the =93href=94 is absent and =93properties=94 are used to= describe the value of the relation to the =93rel=94.=A0 An example is this= : http://tools.ietf.org/html/draft-ietf-appsawg-w= ebfinger-07#section-4.3.=A0 Lastly, any link may have one or more human= -readable names in a =93titles=94 array.=A0 You can see an example here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1= .

=A0<= /p>

=A0



- Concerns w= ere raised over the IPR of XRD/JRD.=A0 IANAL, but to the best of my knowled= ge they are not creative commons, or royalty free under, say, IETF / W3C / = ISO.=A0 This topic would be well outside my area of expertize, but somethin= g the IETF may look at.

=A0

PEJ: It has been= said before that there were IPR claims on XRI.=A0 I=92ve never heard an IP= R claim on XRD, though.=A0 And JRD is an entirely different syntax defined = within the IETF (Eran, specifically). =A0If there are IPR claims on JRD, th= en it must have something to do with very high-level concepts for which the= re would be no way to escape, such as the notion of defining a =93document= =94 that contains =93links=94 and =93metadata=94 or something =96 like HTML= .=A0 Until an IPR statement is filed, I think we can ignore this.=A0 Anythi= ng we would consider might fall into the realm of somebody=92s IPR, so ther= e=92s no point worrying about it without solid evidence.


If JRD is completely under the IETF IPR, that would= be extremely cool.=A0 I was unaware of that, if you have a pointer that wo= uld be great.

=A0<= /p>

PEJ: I didn=92t = say that, only that JRD was entirely documented in an IETF document (RFC 64= 15).=A0 The syntax was derived from XRD, though.=A0 I=92m just not aware of= any IPR claims on XRD, and whatever is claimed may or may not apply to JRD= (since it is a different syntax).=A0 As I said, it would have to be a pret= ty broad, generic claim.


This is outside of my s= cope of expertize.=A0 I couldnt really comment further, tho others may.
= =A0


=A0



- Could webfinger be recommended as a best practice if the scope is= sufficiently wide, to overlap in areas where the W3C has already standardi= zed.=A0 Namely those of discovery via http (aka linked data) etc.=

=A0

PEJ: I=92m not s= ure what you are asking here.


I think the point Mark was suggesting is that both = webfinger and the w3c 'web stack' offer options for discovery.=A0 N= amely the W3C has spent much of the last 10 years working on discovery base= d on HTTP identifiers.=A0 If webfinger becomes a general purpose discovery = method for any URI, then there is a possible overlap, which may perhaps lea= d to further discussion.=

=A0<= /p>

PEJ: WebFinger i= s narrowly defined.=A0 If there is another standard doing exactly the same = thing with the same level of simplicity, I think it would have been adopted= already.=A0 There are certainly other kinds of =93discovery=94 protocols, = but each that I have seen has a different scope, complexity, value, etc. Th= e support for WF has been pretty strong thus far. =A0I cannot say it will b= e the recommended best practice, though.=A0 We=92ll have to see what the ad= option rate looks like.


Well linked data is ado= pted by many of the G7 govts., the world bank, cities, fire deparments, 100= 0s of businesses, academia, search engines and grass roots.=A0
=A0

<= /span>


As you point out, it= 's just speculation at this point.=A0 Tho my understanding of the IETF = process is that they do tend to drill down into the details, so sometimes i= t doesnt hurt to be prepared, or have a plan B :)

=A0<= /p>

PEJ: I=92m too t= ired for a Plan B.=A0 WebFinger started as a spec with a lot of stuff insid= e and we=92ve thrown out lots of options.=A0 We=92re now down to this, a pr= oduct of several years=92 worth of work by multiple people.=A0 Once we sett= le on the HTTP/HTTPS issue, I hope we can say we=92re finished (modulo less= controversial editorial things).=A0 There will be a review process, but I = would not expect that to result is significant technical changes.


Sure I appreciate the e= ffort you've put in here.=A0 I'm just saying, as per my original po= st, that if there is pushback, it may be expedient to switch to "infor= mational" status, as it would seemingly not have a big impact on imple= menters.=A0 As I said, just an idea, let's see how the spec is received= after the HTTPS issue is resolved.
=A0

=A0

Paul=A0

=A0


--14dae9340347c10e6004d100da39-- From perpetual-tripper@wwelves.org Sun Dec 16 16:00:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4300221F87C3 for ; Sun, 16 Dec 2012 16:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC6NJMmsmTM5 for ; Sun, 16 Dec 2012 16:00:37 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id B009221F87C0 for ; Sun, 16 Dec 2012 16:00:37 -0800 (PST) X-Originating-IP: 217.70.178.136 Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0B2C6A807D; Mon, 17 Dec 2012 01:00:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id p3Dm8L2tAmbb; Mon, 17 Dec 2012 01:00:25 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BB605A8070; Mon, 17 Dec 2012 01:00:25 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Brad Fitzpatrick In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> Date: Mon, 17 Dec 2012 00:00:25 +0000 Message-Id: <1355702194-sup-482@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:00:38 -0000 Excerpts from Brad Fitzpatrick's message of 2012-12-16 21:04:40 +0000: > But how does the client know which link rels are security-related (ala > "HTTPS-only")? Not a database, because that's hard to keep all clients > updated over time, as new link rels go into use and/or get registered w= ith > the IANA. Rather, we encode the HTTPS-only property into the rel type > itself: if the "rel" value begins with "https:" or begins with "secure-= ", > clients must never respect it when seen over an HTTP connection. That'= s > the neutering. just for the record... Open Graph Protocol has bit similar 'secure' notion in image, audio and v= ideo properties, from http://ogp.me "The og:image property has some optional structured properties: og:image:url - Identical to og:image. og:image:secure_url - An alternate url to use if the webpage requires= HTTPS. " From perpetual-tripper@wwelves.org Sun Dec 16 16:03:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA07C21F842A for ; Sun, 16 Dec 2012 16:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZyys8c5v9JN for ; Sun, 16 Dec 2012 16:03:29 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id E36FE21F8235 for ; Sun, 16 Dec 2012 16:03:28 -0800 (PST) X-Originating-IP: 217.70.178.142 Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id AA6B1172085; Mon, 17 Dec 2012 01:03:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id wi2AN6LsZFLa; Mon, 17 Dec 2012 01:03:16 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E6D521720AC; Mon, 17 Dec 2012 01:03:15 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Brad Fitzpatrick In-reply-to: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> Date: Mon, 17 Dec 2012 00:03:15 +0000 Message-Id: <1355702438-sup-4666@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , Nick Jennings , webfinger , webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:03:29 -0000 Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000: > On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings w= rote: >=20 > > > > However, I really hope that not only does StartSSL stay operational, > > but that other free cert providers pop up. I'm a little uneasy about > > that for the indieweb community. I certainly don't want to pay > > $50-100/year for a cert on my personal domain just to serve WF traffi= c > > (that would be a little silly). > > >=20 > FWIW, I'm in the same boat. My personal email address is at danga.com, > which doesn't currently serve on https, so I'll have to do the Startcom > dance for that, just for WebFinger. >=20 > I likewise hope that more free SSL options become available, so we're n= ot > reliant on them or the other "30-day-free" options. i hope we can join forces with folks from CAcert and other related projec= t to help fixing current situation with CAs... any suggestion in which co= rner of cyberspace we can collaborate on this issue? From melvincarvalho@gmail.com Sun Dec 16 16:14:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51F521F861F for ; Sun, 16 Dec 2012 16:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG-Zn4EN5+rN for ; Sun, 16 Dec 2012 16:14:04 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6B6921F860D for ; Sun, 16 Dec 2012 16:14:03 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so8429585ieb.31 for ; Sun, 16 Dec 2012 16:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rdNoZitMoCW+cCL+j48k6QGXQvtTCSk0Wa3YpTvZ4LU=; b=Tu0+t70r5Da+4wGahAKIgvnQTO9Nq6VHU+6HOATohagk+z4YuNhWazboHFyFcvseuh +UzRuntptzRqNxfKjvvzNyyQU4oFgVWmm2+9sbJ2InuxsZzzeLe0e+zDEc+RbJ25goIR brybnmMatkIWl41pOvG4PvANxCYPtoBwsP0zeTHA8JkAzewlfKbrP2u2bl50XiYxZbbx WIx3phTlB2l0amBwfX/uk7sBM/0USCnCuic+rybCRoLD5j39n/edndvboLAR7EKypmmv 6SQhZvFs/4Ol5SRsEIonYnxNjSlAY739u7aLCJV5AG55I4Y/AC30ofwIDvnGrIUz6BUf rICw== MIME-Version: 1.0 Received: by 10.50.179.99 with SMTP id df3mr7581234igc.20.1355703243237; Sun, 16 Dec 2012 16:14:03 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 16:14:03 -0800 (PST) In-Reply-To: <1355702438-sup-4666@heahdk.net> References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> <1355702438-sup-4666@heahdk.net> Date: Mon, 17 Dec 2012 01:14:03 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae93403473beb5b04d101420b Cc: webfinger , Brad Fitzpatrick , Nick Jennings , "Paul E. Jones" Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:14:04 -0000 --14dae93403473beb5b04d101420b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 December 2012 01:03, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000: > > On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings >wrote: > > > > > > > > However, I really hope that not only does StartSSL stay operational, > > > but that other free cert providers pop up. I'm a little uneasy about > > > that for the indieweb community. I certainly don't want to pay > > > $50-100/year for a cert on my personal domain just to serve WF traffi= c > > > (that would be a little silly). > > > > > > > FWIW, I'm in the same boat. My personal email address is at danga.com, > > which doesn't currently serve on https, so I'll have to do the Startcom > > dance for that, just for WebFinger. > > > > I likewise hope that more free SSL options become available, so we're n= ot > > reliant on them or the other "30-day-free" options. > i hope we can join forces with folks from CAcert and other related projec= t > to help fixing current situation with CAs... any suggestion in which corn= er > of cyberspace we can collaborate on this issue? > http://convergence.io/ https://www.eff.org/sovereign-keys http://web.monkeysphere.info/ --14dae93403473beb5b04d101420b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 01:03, =E2=98=AE elf= Pavlik =E2=98=AE <perpetual-tripper@wwelves.org> wrote:
Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000:<= br>
> On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings = <nick@silverbucket.net>w= rote:
>
> >
> > However, I really hope that not only does StartSSL stay operation= al,
> > but that other free cert providers pop up. I'm a little uneas= y about
> > that for the indieweb community. I certainly don't want to pa= y
> > $50-100/year for a cert on my personal domain just to serve WF tr= affic
> > (that would be a little silly).
> >
>
> FWIW, I'm in the same boat. =C2=A0My personal email address is at = danga.com,
> which doesn't currently serve on https, so I'll have to do the= Startcom
> dance for that, just for WebFinger.
>
> I likewise hope that more free SSL options become available, so we'= ;re not
> reliant on them or the other "30-day-free" options.
i hope we can join forces with folks from CAcert and other rela= ted project to help fixing current situation with CAs... any suggestion in = which corner of cyberspace we can collaborate on this issue?

http://convergence.io/
<= a href=3D"https://www.eff.org/sovereign-keys">https://www.eff.org/sovereign= -keys
http://web.monkeysph= ere.info/

--14dae93403473beb5b04d101420b-- From romeda@gmail.com Sun Dec 16 16:25:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5F521F8681 for ; Sun, 16 Dec 2012 16:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSSgVhOJJYSD for ; Sun, 16 Dec 2012 16:25:20 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A36321F8654 for ; Sun, 16 Dec 2012 16:25:20 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2229021dae.31 for ; Sun, 16 Dec 2012 16:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0AV4SyUuzwrphgB4dk5QllG0DgHUKVRKxJiwZvZ0QoI=; b=oZhSoqyp9h3l1DSIorYbRCSUU8grUghCtDw80oB1xRFkJcGitn2/zEGqF+wBrWiV3c nM+SXUutenLqavs9oVtIhkIk567fQ3ktuo1QQUhbTNNa0225hD96GGNpEvDxt19MRbLD fsLHxAto7Maz64CdRvQL9VcFrqBQsxo8uWonVcRaJrucwrSd99y6eTWtmPPXtHqR9S5l 5/g5/EYLlUdEwJubv9GKMz1PI+Py54TNH+Oler3x5AmcgrMvz8JvCLY/fqB/jl18pghe BGJZKC49UsKiD8m9ZHljK0pFzG+aLqQZV8wISnCjYfcspPgxBXnD+S0TtWfFVGLtEgaf aXtA== Received: by 10.68.226.71 with SMTP id rq7mr38232910pbc.60.1355703920145; Sun, 16 Dec 2012 16:25:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.59.229 with HTTP; Sun, 16 Dec 2012 16:25:00 -0800 (PST) In-Reply-To: References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> <1355702438-sup-4666@heahdk.net> From: Blaine Cook Date: Mon, 17 Dec 2012 00:25:00 +0000 Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8ff252e694b50c04d1016a28 Cc: webfinger , Brad Fitzpatrick , Nick Jennings , "Paul E. Jones" Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:25:21 -0000 --e89a8ff252e694b50c04d1016a28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What are the chances browsers (e.g., Chrome) are going to support any of those non-corporate CAs? If we're planning webfinger to be supported in the browser, that's going to be essential (c.f., CORS support), and I for one am not keeping my hopes up. *No-one* has said *anything* about my Github Pages example. As I've said before, there are loads of people using that (and other, similar, less progressive hosting options). The reason I raise Github Pages is explicitly because they're the most progressive web host, and they don't support SSL. I'd like to see *one* person from this community reach out to Github and ask if they'd be willing to support SSL. If they come back and so much as say "we'd like to support it in the future", then I'm all for going SSL-only. For the record, I'm totally opposed to Paul's recent suggestion that we should just ignore deployment realities and hope webfinger drags the rest of the web along. Most webfinger deployments are going to be Server-to-Server anyways, so I for one think the threat model being MITM attacks is totally blown out of proportion (a rooted server is far more likely), and the only thing forcing SSL is going to do is slow adoption. b. On 17 December 2012 00:14, Melvin Carvalho wrote= : > > > On 17 December 2012 01:03, =E2=98=AE elf Pavlik =E2=98=AE wrote: > >> Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000: >> > On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings > >wrote: >> > >> > > >> > > However, I really hope that not only does StartSSL stay operational, >> > > but that other free cert providers pop up. I'm a little uneasy about >> > > that for the indieweb community. I certainly don't want to pay >> > > $50-100/year for a cert on my personal domain just to serve WF traff= ic >> > > (that would be a little silly). >> > > >> > >> > FWIW, I'm in the same boat. My personal email address is at danga.com= , >> > which doesn't currently serve on https, so I'll have to do the Startco= m >> > dance for that, just for WebFinger. >> > >> > I likewise hope that more free SSL options become available, so we're >> not >> > reliant on them or the other "30-day-free" options. >> i hope we can join forces with folks from CAcert and other related >> project to help fixing current situation with CAs... any suggestion in >> which corner of cyberspace we can collaborate on this issue? >> > > http://convergence.io/ > https://www.eff.org/sovereign-keys > http://web.monkeysphere.info/ > > --e89a8ff252e694b50c04d1016a28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What are the chances browsers (e.g., Chrome) are going to support any of th= ose non-corporate CAs? If we're planning webfinger to be supported in t= he browser, that's going to be essential (c.f., CORS support), and I fo= r one am not keeping my hopes up.

*No-one* has said *anything* about my Github Pages example. = As I've said before, there are loads of people using that (and other, s= imilar, less progressive hosting options). The reason I raise Github Pages = is explicitly because they're the most progressive web host, and they d= on't support SSL. I'd like to see *one* person from this community = reach out to Github and ask if they'd be willing to support SSL. If the= y come back and so much as say "we'd like to support it in the fut= ure", then I'm all for going SSL-only.

For the record, I'm totally opposed to Paul's r= ecent suggestion that we should just ignore deployment realities and hope w= ebfinger drags the rest of the web along. Most webfinger deployments are go= ing to be Server-to-Server anyways, so I for one think the threat model bei= ng MITM attacks is totally blown out of proportion (a rooted server is far = more likely), and the only thing forcing SSL is going to do is slow adoptio= n.

b.


On 17 December 2012 00:14, Melvin Carvalho <melvin= carvalho@gmail.com> wrote:


On 17 December 2012 01:03, =E2=98=AE elf Pavlik =E2=98=AE <perpetual-tripper@wwelves.org> wrote:
Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000:<= br> i hope we can join forces with folks from CAcert and other rela= ted project to help fixing current situation with CAs... any suggestion in = which corner of cyberspace we can collaborate on this issue?


--e89a8ff252e694b50c04d1016a28-- From paulej@packetizer.com Sun Dec 16 16:41:56 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EEB21F8782 for ; Sun, 16 Dec 2012 16:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc0lYdSCBGll for ; Sun, 16 Dec 2012 16:41:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4B21F877C for ; Sun, 16 Dec 2012 16:41:54 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBH0fp2L018082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 19:41:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355704912; bh=uQf0pVqjSOIeetC/mzsGewIjn/T6npxRTdlybvWJCoQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=IB97lNrtNRmK70ueEr6P7TQYGpHXFGl3wkKnE0Ngg6UJpPH7ts/Owt/sCLLSEgw/y NgtwIy+JsayT0Zu9Pa3B2ff6he2/PDZZCdsCMTQN7OAS11Ns4sKWUeGY+DiCkXSCRi NJr9UpZZkHgMQMRJ6Z+aLgWuKRvkZ57/AfIzum50= From: "Paul E. Jones" To: "=?UTF-8?Q?'=E2=98=AE_elf_Pavlik_=E2=98=AE'?=" , "'Brad Fitzpatrick'" Date: Sun, 16 Dec 2012 19:41:52 -0500 Message-ID: <011e01cddbef$4f053360$ed0f9a20$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3b7xisT3IrisNhQ52Ysqhaucy05w== Content-Language: en-us Cc: 'webfinger' , 'Nick Jennings' , 'webfinger' Subject: [webfinger] Certificate Authorities (was Current HTTP/HTTPS Language) X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:41:56 -0000 > > FWIW, I'm in the same boat. My personal email address is at > > danga.com, which doesn't currently serve on https, so I'll have to = do > > the Startcom dance for that, just for WebFinger. > > > > I likewise hope that more free SSL options become available, so = we're > > not reliant on them or the other "30-day-free" options. > > i hope we can join forces with folks from CAcert and other related > project to help fixing current situation with CAs... any suggestion in > which corner of cyberspace we can collaborate on this issue? I mentioned before that there is another option: DNSSEC + DANE. I can = appreciate why people would not put trust in CACert. It has nothing to = do with the integrity of the people running the service, but the fact = that they're not part of the "inner circle" of CAs. If there happened = to be one unscrupulous person in the group that issued a certificate to = somebank.com, who is liable for the damages? It presents a problem for = the bank, for the CACert organization, and for the whole industry, = really. DNSSEC + DANE puts the security in the hands of the domain owner, as = they issue their own certificates. The trusted entities with DNSSEC are = the domain owner itself, the provider of DNS services (which might be = the domain owner), the registrar, and the DNS path leading to the root. = These have to be trusted with the current CA approach, since many have = to power to create a certificate or manipulate DNS responses to allow = themselves to get a certificate from a CA. DNS offers a huge MITM attack plane. Why the world has not made firm = steps to move to DNSSEC, I don't know. I've never seen a bank that used = DNSSEC, for example. I flipped the switch on packetizer.com, so at = least your DNS servers can verify my DNS records. But very, very few = domains utilize DNSSEC and some registrars do not even support it. Paul From paulej@packetizer.com Sun Dec 16 16:52:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3614B21F87D8 for ; Sun, 16 Dec 2012 16:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz205HtAghtx for ; Sun, 16 Dec 2012 16:51:59 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFFE21F87B4 for ; Sun, 16 Dec 2012 16:51:59 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBH0pug4018544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Dec 2012 19:51:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355705517; bh=seeq8SQGvxwqD6YDtUOFK/atZqOcilELYPT9QrOiYhU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=fH5oh0latDDQ2g6YFeQztR4JXqybtGH7q3WKvlQ7GuEKr93M9tFefktnGPi0s+H4T Lb22brwFZTyaadl4W0WOnA47vS7gHHr71QfonQ6cj7nu6FhKhod3/i47IJWL69bUJC nKo/P+g8aV3T8XA7CUxB1BJFMAfNY3I7MHX8Fcuk= From: "Paul E. Jones" To: "'Blaine Cook'" , References: <0bac01cdda99$c2ebb0d0$48c31270$@packetizer.com> <50CC9F00.50303@openlinksw.com> <00b501cddb57$2ebb0aa0$8c311fe0$@packetizer.com> <010501cddb61$340a3fd0$9c1ebf70$@packetizer.com> <007d01cddbd3$44228db0$cc67a910$@packetizer.com> <1355702438-sup-4666@heahdk.net> In-Reply-To: Date: Sun, 16 Dec 2012 19:51:57 -0500 Message-ID: <012901cddbf0$b74ea130$25ebe390$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01CDDBC6.CE79AAA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINxxnVRt1U0EjaYahwXPWGux9M3gJf97KaA2wuLZcB+QAw/wFuEMI5AgW/GFMBsCR8OgHrpYLmAihx3M8A4xFv6gNF4YPWAaozZK4Ctl0KEAH2Ps8FlsBqJ/A= Content-Language: en-us Cc: 'Brad Fitzpatrick' , 'Nick Jennings' , 'webfinger' Subject: Re: [webfinger] Current HTTP/HTTPS Language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:52:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012A_01CDDBC6.CE79AAA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Blaine, =20 I was not suggesting we do TLS only and stop. First, define TLS-only = signaling in the current RFC. This allows for services like OpenID = Connect to use it. There will be others who can and will use it. =20 But, we then continue the dialog on how to introduce a non-secure mode. = There are several approaches on the table and there are various security = considerations that we need to address for each. There is also the user = interface aspect. I don=E2=80=99t want to query my bank and get the = phone number of a scammer. That might be an extreme example, but = similar other examples exist. So, we need to work through the language = on UI and trust issues. =20 I=E2=80=99m only proposing we split the problem into two pieces. There = are those who want TLS only, so we offer a solution for that right away. = For the non-secure / fallback option, we take a little more time to = define procedures. We=E2=80=99re holding up everything on this one = issue, but it ought not be the gaiting factor it is. =20 Paul =20 From: Blaine Cook [mailto:romeda@gmail.com]=20 Sent: Sunday, December 16, 2012 7:25 PM To: webfinger@googlegroups.com Cc: Brad Fitzpatrick; Nick Jennings; Paul E. Jones; webfinger Subject: Re: [webfinger] Current HTTP/HTTPS Language =20 What are the chances browsers (e.g., Chrome) are going to support any of = those non-corporate CAs? If we're planning webfinger to be supported in = the browser, that's going to be essential (c.f., CORS support), and I = for one am not keeping my hopes up. =20 *No-one* has said *anything* about my Github Pages example. As I've said = before, there are loads of people using that (and other, similar, less = progressive hosting options). The reason I raise Github Pages is = explicitly because they're the most progressive web host, and they don't = support SSL. I'd like to see *one* person from this community reach out = to Github and ask if they'd be willing to support SSL. If they come back = and so much as say "we'd like to support it in the future", then I'm all = for going SSL-only. =20 For the record, I'm totally opposed to Paul's recent suggestion that we = should just ignore deployment realities and hope webfinger drags the = rest of the web along. Most webfinger deployments are going to be = Server-to-Server anyways, so I for one think the threat model being MITM = attacks is totally blown out of proportion (a rooted server is far more = likely), and the only thing forcing SSL is going to do is slow adoption. =20 b. =20 On 17 December 2012 00:14, Melvin Carvalho = wrote: =20 On 17 December 2012 01:03, =E2=98=AE elf Pavlik =E2=98=AE = wrote: Excerpts from Brad Fitzpatrick's message of 2012-12-16 22:38:19 +0000: > On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings = wrote: > > > > > However, I really hope that not only does StartSSL stay operational, > > but that other free cert providers pop up. I'm a little uneasy about > > that for the indieweb community. I certainly don't want to pay > > $50-100/year for a cert on my personal domain just to serve WF = traffic > > (that would be a little silly). > > > > FWIW, I'm in the same boat. My personal email address is at = danga.com, > which doesn't currently serve on https, so I'll have to do the = Startcom > dance for that, just for WebFinger. > > I likewise hope that more free SSL options become available, so we're = not > reliant on them or the other "30-day-free" options. i hope we can join forces with folks from CAcert and other related = project to help fixing current situation with CAs... any suggestion in = which corner of cyberspace we can collaborate on this issue? http://convergence.io/ https://www.eff.org/sovereign-keys http://web.monkeysphere.info/=20 =20 =20 ------=_NextPart_000_012A_01CDDBC6.CE79AAA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Blaine,

 

I was not suggesting we do TLS only and stop.=C2=A0 First, define = TLS-only signaling in the current RFC.=C2=A0 This allows for services = like OpenID Connect to use it.=C2=A0 There will be others who can and = will use it.

 

But, we then continue the dialog on how to introduce a non-secure = mode.=C2=A0 There are several approaches on the table and there are = various security considerations that we need to address for each.=C2=A0 = There is also the user interface aspect.=C2=A0 I don=E2=80=99t want to = query my bank and get the phone number of a scammer.=C2=A0 That might be = an extreme example, but similar other examples exist.=C2=A0 So, we need = to work through the language on UI and trust = issues.

 

I=E2=80=99m only proposing we split the problem into two = pieces.=C2=A0 There are those who want TLS only, so we offer a solution = for that right away.=C2=A0 For the non-secure / fallback option, we take = a little more time to define procedures.=C2=A0 We=E2=80=99re holding up = everything on this one issue, but it ought not be the gaiting factor it = is.

 

Paul

 

From:= = Blaine Cook [mailto:romeda@gmail.com]
Sent: Sunday, December = 16, 2012 7:25 PM
To: webfinger@googlegroups.com
Cc: = Brad Fitzpatrick; Nick Jennings; Paul E. Jones; = webfinger
Subject: Re: [webfinger] Current HTTP/HTTPS = Language

 

What are the = chances browsers (e.g., Chrome) are going to support any of those = non-corporate CAs? If we're planning webfinger to be supported in the = browser, that's going to be essential (c.f., CORS support), and I for = one am not keeping my hopes up.

 

*No-one* has said *anything* about my Github Pages = example. As I've said before, there are loads of people using that (and = other, similar, less progressive hosting options). The reason I raise = Github Pages is explicitly because they're the most progressive web = host, and they don't support SSL. I'd like to see *one* person from this = community reach out to Github and ask if they'd be willing to support = SSL. If they come back and so much as say "we'd like to support it = in the future", then I'm all for going = SSL-only.

 

For the record, I'm totally opposed to Paul's recent = suggestion that we should just ignore deployment realities and hope = webfinger drags the rest of the web along. Most webfinger deployments = are going to be Server-to-Server anyways, so I for one think the threat = model being MITM attacks is totally blown out of proportion (a rooted = server is far more likely), and the only thing forcing SSL is going to = do is slow adoption.

 

b.

 

On 17 December 2012 00:14, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:

 

On 17 December 2012 01:03, =E2=98=AE elf Pavlik =E2=98=AE <perpetual-tripper@wwelves.org> = wrote:

Excerpts from Brad = Fitzpatrick's message of 2012-12-16 22:38:19 = +0000:

> On Sun, Dec 16, = 2012 at 2:33 PM, Nick Jennings <nick@silverbucket.net>wrote:
>
> = >
> > However, I really hope that not only does StartSSL = stay operational,
> > but that other free cert providers pop = up. I'm a little uneasy about
> > that for the indieweb = community. I certainly don't want to pay
> > $50-100/year for a = cert on my personal domain just to serve WF traffic
> > (that = would be a little silly).
> >
>
> FWIW, I'm in the = same boat.  My personal email address is at danga.com,
> which = doesn't currently serve on https, so I'll have to do the = Startcom
> dance for that, just for WebFinger.
>
> I = likewise hope that more free SSL options become available, so we're = not
> reliant on them or the other "30-day-free" = options.

i hope we can = join forces with folks from CAcert and other related project to help = fixing current situation with CAs... any suggestion in which corner of = cyberspace we can collaborate on this = issue?

 

 

------=_NextPart_000_012A_01CDDBC6.CE79AAA0-- From melvincarvalho@gmail.com Mon Dec 17 04:22:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEDD21F8AA1 for ; Mon, 17 Dec 2012 04:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm-wgU5Bv2QF for ; Mon, 17 Dec 2012 04:22:27 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13FF921F8A96 for ; Mon, 17 Dec 2012 04:22:26 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9064100ieb.31 for ; Mon, 17 Dec 2012 04:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EaLXaZL/rFmKtT7QVjqgdf+PHDg1MbwwE5rOxAtEm5A=; b=ijxeyS4ywEaki5coKcmUPR6o8hcDcvyjhiM8IXKp/1IVSPOHaN/WrNUSsC9pKSHMdw JD1vSbVnDwSoLJ4ZuPn9mVmI50tDMnolaDh9pH/PK3Rttlddb3pAAMDPGAtIW2f3/MqO mNLTcGKVxWCkmfbS/E8bfZXrQQWRxaLnGVlUCn7Bq/CRgutihzpm4eBxHhR+mvSYfs8g 2W8GSDH43gV1KkronuAkSy8xxcxkAvoruIbsrbwldlYDipMRoy1WfEvsEPTlV04QmmLa xK9MxQBg7Ix2BR5Z/A7RoLffYC3RMtcK0hLqlrEUlPPv/pD88BOoYMVEb7np0wi8qKC+ LkUA== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr8892364igk.41.1355746946642; Mon, 17 Dec 2012 04:22:26 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 04:22:26 -0800 (PST) In-Reply-To: References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> Date: Mon, 17 Dec 2012 13:22:26 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae934090128f15004d10b6f8e Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:22:29 -0000 --14dae934090128f15004d10b6f8e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17 December 2012 00:45, Melvin Carvalho wrote= : > > > On 17 December 2012 00:21, Paul E. Jones wrote: > >> Melvin,**** >> >> ** ** >> >> Comments inline again:**** >> >> ** ** >> >> ** ** >> >> PEJ: WebFinger uses *any* URI scheme. The =93acct=94 scheme is just one= of >> them and is not core to the spec now, though there is a statement >> recommending its use to identify accounts. That is its purpose and the >> =93acct=94 URI, and it=92s a valid purpose. The one example I like to g= ive is >> =93How do we identify an account at Twitter?=94 There is no email, so = =93mailto=94 >> is not the right URI. A user has an account at any service provider and >> the =93acct=94 URI would identify the account, not the particular servic= e at >> the service provider (e.g., email, XMPP, or whatever).**** >> >> >> It's great that acct: is almost completely decoupled from the spec. >> >> Sure I do understand why acct: would be useful. >> >> But Mark and others pointed out you could equally use >> >> webfinger?acct=3Dbob >> >> or >> >> /.well-known/user/bob >> >> my own suggestion from February was >> >> /@/bob >> >> None of the above are as beautiful as acct: but the debate may arise thi= s >> is worth creating a new uri scheme. **** >> >> ** ** >> >> PEJ: Yeah, all of these are possibilities. The one thing that I >> personally think is important is that the =93thing=94 we query is a URI.= So, >> forms that do not utilize URIs I think we should not consider. There ar= e >> several ways to utilize URIs and I think it comes down to putting the U= RI >> as a part of the path or using a URI parameter. We=92re presently headi= ng >> down the latter path. The disadvantage is that one cannot build a =93tr= uly=94 >> static site, though one can come close using Apache re-writing rules. T= hat >> said, there is utility in the approach, since once can query for a speci= fic >> URI and request the response to be filtered for a particular set of link >> relations (=93rel=94 parameters). Thus, it=92s making the web programma= ble. I >> think we=92re past that debate now. I hope so. >> > > Sure, but query parameters can take URIs too, SWD did, for example. > > >> **** >> >> >> - JRD does not allow an array of items/subjects to be rendered in >> response to an HTTP request, whereas other serializations do allow that. >> This leads to an interoperability issue.**** >> >> **** >> >> PEJ: I don=92t understand your concern. If I query my server, I get an >> array of link relations. I can step through those sequentially to find w= hat >> I=92m looking for. If I want to arrange the data different, I could. T= here >> was a proposal, for example, to allow the =93rel=94 value be the key tha= t >> refers to an array of possible values. That works, but the issue is tha= t >> we lose useful constructs like =93properties=94, =93titles=94, etc., unl= ess we have >> keys that point to arrays of objects. This can get syntactically ugly. = I >> personally like the way JRD is defined: it=92s simple and clean. It >> definitely does not present interoperability issues. An interop problem >> exists when two devices implanting the same thing do it differently. If >> you implement JRD, there is no interop issue. JRD is JRD as defined >> entirely in the WF spec. People have been able to use it just fine so fa= r. >> **** >> >> >> The link relations contain 3 components. The subject, the predicate an= d >> the object. In other language the entity the attribute and the value. = The >> Entity in this case would be @subject, the attribute would be the rel of >> the link, and the value would be the value of the link. >> >> In almost every serialization I know, multiple subjects/entities are >> permissible, in an array of (say JSON) objects. In JRD there is a >> constraint limiting the serialization to exactly one entity/subject. Th= is >> imho could be seen as a slight weakness, especially it it makes the >> serialization of choice not 100% interoperable with others more permissi= ble >> serializations.**** >> >> ** ** >> >> PEJ: My understanding of subject is the =93thing=94 I=92m querying (e.g.= , >> acct:paulej@packetizer.com). Given that definition, JRD covers a single >> subject since WF is looking for a single =93thing=94. Inside, there may= be >> multiple =93properties=94 for the =93thing=94 (e.g., =93 >> http://packetizer.com/ns/name=94 is a property with a value =93Paul E. >> Jones). Then there is an array of =93link relations=94. The definition >> follows that of RFC 5988. Each link relation is identified by a =93rel= =94 >> value. There is also an optional =93type=94. And there is an =93href= =94. JRD >> also allows for self-describing link relations, where the =93href=94 is = absent >> and =93properties=94 are used to describe the value of the relation to t= he >> =93rel=94. An example is this: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. >> Lastly, any link may have one or more human-readable names in a =93title= s=94 >> array. You can see an example here: **** >> >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1. >> > Sorry forgot to respond to this point. (only did the red ones :)) Thanks, I think I understand the JRD format and it's great that A) it's JSON based and B) it can be self describing and C) that it can include references (links) to other URIs The weakness in this serialization is that it becomes tightly coupled to the query that generated it. A data document should be an entity in it's own right that is independent of how it is generated. What we are getting is data, that happened to be delivered via webfinger. While it is often the case on the web that a document will yield a single subject, and indeed in many cases this is a best practice, it is not always the case. There are many cases where there are multiple items in a single page, a good example is wikipedia which divides itself up into many sections; the page may be about Germany, then the sections could be about Geography, History, Economy etc. This leads to interoperability issues with the rest of the web. My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured? > **** >> >> ** ** >> >> **** >> >> >> >> - Concerns were raised over the IPR of XRD/JRD. IANAL, but to the best >> of my knowledge they are not creative commons, or royalty free under, sa= y, >> IETF / W3C / ISO. This topic would be well outside my area of expertize= , >> but something the IETF may look at.**** >> >> **** >> >> PEJ: It has been said before that there were IPR claims on XRI. I=92ve >> never heard an IPR claim on XRD, though. And JRD is an entirely differe= nt >> syntax defined within the IETF (Eran, specifically). If there are IPR >> claims on JRD, then it must have something to do with very high-level >> concepts for which there would be no way to escape, such as the notion o= f >> defining a =93document=94 that contains =93links=94 and =93metadata=94 o= r something =96 >> like HTML. Until an IPR statement is filed, I think we can ignore this. >> Anything we would consider might fall into the realm of somebody=92s IPR= , so >> there=92s no point worrying about it without solid evidence.**** >> >> >> If JRD is completely under the IETF IPR, that would be extremely cool. = I >> was unaware of that, if you have a pointer that would be great.**** >> >> ** ** >> >> PEJ: I didn=92t say that, only that JRD was entirely documented in an IE= TF >> document (RFC 6415). The syntax was derived from XRD, though. I=92m ju= st >> not aware of any IPR claims on XRD, and whatever is claimed may or may n= ot >> apply to JRD (since it is a different syntax). As I said, it would have= to >> be a pretty broad, generic claim. >> > > This is outside of my scope of expertize. I couldnt really comment > further, tho others may. > > >> **** >> >> >> **** >> >> >> >> - Could webfinger be recommended as a best practice if the scope is >> sufficiently wide, to overlap in areas where the W3C has already >> standardized. Namely those of discovery via http (aka linked data) etc.= * >> *** >> >> **** >> >> PEJ: I=92m not sure what you are asking here.**** >> >> >> I think the point Mark was suggesting is that both webfinger and the w3c >> 'web stack' offer options for discovery. Namely the W3C has spent much = of >> the last 10 years working on discovery based on HTTP identifiers. If >> webfinger becomes a general purpose discovery method for any URI, then >> there is a possible overlap, which may perhaps lead to further discussio= n. >> **** >> >> ** ** >> >> PEJ: WebFinger is narrowly defined. If there is another standard doing >> exactly the same thing with the same level of simplicity, I think it wou= ld >> have been adopted already. There are certainly other kinds of =93discov= ery=94 >> protocols, but each that I have seen has a different scope, complexity, >> value, etc. The support for WF has been pretty strong thus far. I canno= t >> say it will be the recommended best practice, though. We=92ll have to s= ee >> what the adoption rate looks like. >> > > Well linked data is adopted by many of the G7 govts., the world bank, > cities, fire deparments, 1000s of businesses, academia, search engines an= d > grass roots. > > >> **** >> >> >> As you point out, it's just speculation at this point. Tho my >> understanding of the IETF process is that they do tend to drill down int= o >> the details, so sometimes it doesnt hurt to be prepared, or have a plan = B :) >> **** >> >> ** ** >> >> PEJ: I=92m too tired for a Plan B. WebFinger started as a spec with a l= ot >> of stuff inside and we=92ve thrown out lots of options. We=92re now dow= n to >> this, a product of several years=92 worth of work by multiple people. O= nce >> we settle on the HTTP/HTTPS issue, I hope we can say we=92re finished (m= odulo >> less controversial editorial things). There will be a review process, b= ut >> I would not expect that to result is significant technical changes. >> > > Sure I appreciate the effort you've put in here. I'm just saying, as per > my original post, that if there is pushback, it may be expedient to switc= h > to "informational" status, as it would seemingly not have a big impact on > implementers. As I said, just an idea, let's see how the spec is receive= d > after the HTTPS issue is resolved. > > >> **** >> >> ** ** >> >> Paul **** >> >> ** ** >> > > --14dae934090128f15004d10b6f8e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 00:45, Melvin Carval= ho <melvincarvalho@gmail.com> wrote:


On 17 December 2012 00= :21, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0

Comments in= line again:

=A0<= /p>

=A0

PEJ: WebFinger uses any URI scheme.=A0 Th= e =93acct=94 scheme is just one of them and is not core to the spec now, th= ough there is a statement recommending its use to identify accounts.=A0 Tha= t is its purpose and the =93acct=94 URI, and it=92s a valid purpose.=A0 The= one example I like to give is =93How do we identify an account at Twitter?= =94=A0 There is no email, so =93mailto=94 is not the right URI.=A0 A user h= as an account at any service provider and the =93acct=94 URI would identify= the account, not the particular service at the service provider (e.g., ema= il, XMPP, or whatever).


It= 's great that acct: is almost completely decoupled from the spec.
Sure I do understand why acct: would be useful.=A0

But Mark and o= thers pointed out you could equally use

webfinger?acct=3Dbob

or

/.well-known/user/bob

my o= wn suggestion from February was

/@/bob

None of the above are = as beautiful as acct: but the debate may arise this is worth creating a new= uri scheme.=A0

=A0<= /p>

PEJ: Yeah, all o= f these are possibilities. The one thing that I personally think is importa= nt is that the =93thing=94 we query is a URI.=A0 So, forms that do not util= ize URIs I think we should not consider. =A0There are several ways to utili= ze URIs and=A0 I think it comes down to putting the URI as a part of the pa= th or using a URI parameter.=A0 We=92re presently heading down the latter p= ath.=A0 The disadvantage is that one cannot build a =93truly=94 static site= , though one can come close using Apache re-writing rules.=A0 That said, th= ere is utility in the approach, since once can query for a specific URI and= request the response to be filtered for a particular set of link relations= (=93rel=94 parameters).=A0 Thus, it=92s making the web programmable.=A0 I = think we=92re past that debate now.=A0 I hope so.


Sure, but que= ry parameters can take URIs too, SWD did, for example.
=A0
=A0


- JRD does not a= llow an array of items/subjects to be rendered in response to an HTTP reque= st, whereas other serializations do allow that.=A0 This leads to an interop= erability issue.

=A0<= /p>

PEJ: I don=92t u= nderstand your concern. If I query my server, I get an array of link relati= ons. I can step through those sequentially to find what I=92m looking for.= =A0 If I want to arrange the data different, I could.=A0 There was a propos= al, for example, to allow the =93rel=94 value be the key that refers to an = array of possible values.=A0 That works, but the issue is that we lose usef= ul constructs like =93properties=94, =93titles=94, etc., unless we have key= s that point to arrays of objects.=A0 This can get syntactically ugly. =A0I= personally like the way JRD is defined: it=92s simple and clean.=A0 It def= initely does not present interoperability issues.=A0 An interop problem exi= sts when two devices implanting the same thing do it differently.=A0 If you= implement JRD, there is no interop issue.=A0 JRD is JRD as defined entirel= y in the WF spec. People have been able to use it just fine so far.<= u>


The link relations contain 3 components.=A0=A0 The subject, the = predicate and the object.=A0 In other language the entity the attribute and= the value.=A0 The Entity in this case would be @subject, the attribute wou= ld be the rel of the link, and the value would be the value of the link.
In almost every serialization I know, multiple subjects/entities are pe= rmissible, in an array of (say JSON) objects.=A0 In JRD there is a constrai= nt limiting the serialization to exactly one entity/subject.=A0 This imho c= ould be seen as a slight weakness, especially it it makes the serialization= of choice not 100% interoperable with others more permissible serializatio= ns.

=A0<= /p>

PEJ: My understa= nding of subject is the =93thing=94 I=92m querying (e.g., acct:paulej@packetizer.com= ).=A0 Given that definition, JRD covers a single subject since WF is lo= oking for a single =93thing=94.=A0 Inside, there may be multiple =93propert= ies=94 for the =93thing=94 (e.g., =93http://packetizer.com/ns/name=94 is a property wi= th a value =93Paul E. Jones).=A0 Then there is an array of =93link relation= s=94.=A0 The definition follows that of RFC 5988.=A0 Each link relation is = identified by a =93rel=94 value.=A0 There is also an optional =93type=94.= =A0 And there is an =93href=94.=A0 JRD also allows for self-describing link= relations, where the =93href=94 is absent and =93properties=94 are used to= describe the value of the relation to the =93rel=94.=A0 An example is this= : http://tools.ietf.org/html/draft-ietf-appsawg-w= ebfinger-07#section-4.3.=A0 Lastly, any link may have one or more human= -readable names in a =93titles=94 array.=A0 You can see an example here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1= .

Sorry forgot to respond to this point.=A0 (only did the red ones :))
<= br>Thanks, I think I understand the JRD format and it's great that A) i= t's JSON based and B) it can be self describing and C) that it can incl= ude references (links) to other URIs

The weakness in this serialization is that it becomes tightly coupled t= o the query that generated it.=A0 A data document should be an entity in it= 's own right that is independent of how it is generated.=A0 What we are= getting is data, that happened to be delivered via webfinger.=A0 While it = is often the case on the web that a document will yield a single subject, a= nd indeed in many cases this is a best practice, it is not always the case.= =A0 There are many cases where there are multiple items in a single page, a= good example is wikipedia which divides itself up into many sections; the = page may be about Germany, then the sections could be about Geography, Hist= ory, Economy etc.=A0 This leads to interoperability issues with the rest of= the web.

My view is that webfinger should be serialization agnostic and operate = using content negotiation.=A0 JRD is one of the weaker serializations, imho= , and as mark has suggested, if favoured especially it will need greater re= view, which may take time.=A0 Im not sure anyone has ever answered the ques= tion as to why has it been consistently favoured?
=A0

=A0<= /p>

=A0



- Concerns w= ere raised over the IPR of XRD/JRD.=A0 IANAL, but to the best of my knowled= ge they are not creative commons, or royalty free under, say, IETF / W3C / = ISO.=A0 This topic would be well outside my area of expertize, but somethin= g the IETF may look at.

=A0

PEJ: It has been= said before that there were IPR claims on XRI.=A0 I=92ve never heard an IP= R claim on XRD, though.=A0 And JRD is an entirely different syntax defined = within the IETF (Eran, specifically). =A0If there are IPR claims on JRD, th= en it must have something to do with very high-level concepts for which the= re would be no way to escape, such as the notion of defining a =93document= =94 that contains =93links=94 and =93metadata=94 or something =96 like HTML= .=A0 Until an IPR statement is filed, I think we can ignore this.=A0 Anythi= ng we would consider might fall into the realm of somebody=92s IPR, so ther= e=92s no point worrying about it without solid evidence.


If JRD is completely under the IETF IPR, that would be extremely= cool.=A0 I was unaware of that, if you have a pointer that would be great.=

=A0<= /p>

PEJ: I didn=92t = say that, only that JRD was entirely documented in an IETF document (RFC 64= 15).=A0 The syntax was derived from XRD, though.=A0 I=92m just not aware of= any IPR claims on XRD, and whatever is claimed may or may not apply to JRD= (since it is a different syntax).=A0 As I said, it would have to be a pret= ty broad, generic claim.


This is outside o= f my scope of expertize.=A0 I couldnt really comment further, tho others ma= y.
=A0


=A0



- Could webfinger be recommended as a best practice if the scope is= sufficiently wide, to overlap in areas where the W3C has already standardi= zed.=A0 Namely those of discovery via http (aka linked data) etc.=

=A0

PEJ: I=92m not s= ure what you are asking here.


I think the point Mark was suggesting is that both webfinger and= the w3c 'web stack' offer options for discovery.=A0 Namely the W3C= has spent much of the last 10 years working on discovery based on HTTP ide= ntifiers.=A0 If webfinger becomes a general purpose discovery method for an= y URI, then there is a possible overlap, which may perhaps lead to further = discussion.

=A0<= /p>

PEJ: WebFinger i= s narrowly defined.=A0 If there is another standard doing exactly the same = thing with the same level of simplicity, I think it would have been adopted= already.=A0 There are certainly other kinds of =93discovery=94 protocols, = but each that I have seen has a different scope, complexity, value, etc. Th= e support for WF has been pretty strong thus far. =A0I cannot say it will b= e the recommended best practice, though.=A0 We=92ll have to see what the ad= option rate looks like.


Well linked data = is adopted by many of the G7 govts., the world bank, cities, fire deparment= s, 1000s of businesses, academia, search engines and grass roots.=A0
=A0

<= /span>


As you point out, it's just s= peculation at this point.=A0 Tho my understanding of the IETF process is th= at they do tend to drill down into the details, so sometimes it doesnt hurt= to be prepared, or have a plan B :)

=A0<= /p>

PEJ: I=92m too t= ired for a Plan B.=A0 WebFinger started as a spec with a lot of stuff insid= e and we=92ve thrown out lots of options.=A0 We=92re now down to this, a pr= oduct of several years=92 worth of work by multiple people.=A0 Once we sett= le on the HTTP/HTTPS issue, I hope we can say we=92re finished (modulo less= controversial editorial things).=A0 There will be a review process, but I = would not expect that to result is significant technical changes.


Sure I appreciate= the effort you've put in here.=A0 I'm just saying, as per my origi= nal post, that if there is pushback, it may be expedient to switch to "= ;informational" status, as it would seemingly not have a big impact on= implementers.=A0 As I said, just an idea, let's see how the spec is re= ceived after the HTTPS issue is resolved.
=A0

=A0

Paul=A0

=A0



--14dae934090128f15004d10b6f8e-- From nick@silverbucket.net Mon Dec 17 06:17:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BF121F89CC for ; Mon, 17 Dec 2012 06:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2igrLCZ-5aTA for ; Mon, 17 Dec 2012 06:17:12 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11DCD21F8A44 for ; Mon, 17 Dec 2012 06:17:12 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5704589obc.31 for ; Mon, 17 Dec 2012 06:17:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=lcT44Thaz8e11OD7UveCDGzquDkKyzPSeK+pglAd3sM=; b=SdEzBo1k6gtmBUzSujfaszL+ylGMoGtdglqqxkZZpZnhguD36aLbdfrTxJVtl+72Bv V9QFzjrQWXKdxmjvcJaHTxW8Mii9uV7kluJOeEyToeoC5t8XlCiWg1nIwn6QrxArioKF aw5YjwV//lCyi+73rv6oZ+OnRNFHdlkcrAcAA1GqjzRNS4gX0VKEzRYtFrW2G5W89ZKT a0ij4/pNFESQE6Y5ZuUzeeFFzeT+yRRjyx0GC3q6I8PpHAk4zcMXu+IEjZrpqtr9lEOo CztCSftDfFSCWyDTh8uM0+CSFGCuqZoFvN3VlFN4hck0NAMNc5tV8bhOm31qxKkaQKri EQvQ== Received: by 10.182.38.69 with SMTP id e5mr11766053obk.79.1355753831372; Mon, 17 Dec 2012 06:17:11 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx.google.com with ESMTPS id hz6sm9744032obb.1.2012.12.17.06.17.08 (version=SSLv3 cipher=OTHER); Mon, 17 Dec 2012 06:17:10 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5928341oag.31 for ; Mon, 17 Dec 2012 06:17:08 -0800 (PST) Received: by 10.60.171.112 with SMTP id at16mr11439029oec.47.1355753828130; Mon, 17 Dec 2012 06:17:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.92.66 with HTTP; Mon, 17 Dec 2012 06:16:38 -0800 (PST) In-Reply-To: <00c801cddbda$72cc7d90$586578b0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> From: Nick Jennings Date: Mon, 17 Dec 2012 15:16:38 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl3K6J4IpBUDlE44QHDo7Zpxp/+Sz059ATBvMvSDjqg1qtv+cD1qDEyAraE+u4OwLfFdjaX Cc: webfinger@ietf.org, Melvin Carvalho Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:17:18 -0000 On Sun, Dec 16, 2012 at 11:12 PM, Paul E. Jones wro= te: > From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] > Sent: Sunday, December 16, 2012 4:38 PM > To: Paul E. Jones > Cc: webfinger@googlegroups.com; webfinger@ietf.org > Subject: Re: [webfinger] Possibly speeding up the RFC process > > - Should webfinger use the acct: scheme rather than simply a query > parameter. This strikes me as a 'vanity' URI scheme. Aesthetics are > important, but I'm unsure how popular a choice that will be with the IETF= . > > > PEJ: WebFinger uses any URI scheme. The =E2=80=9Cacct=E2=80=9D scheme is= just one of them > and is not core to the spec now, though there is a statement recommending > its use to identify accounts. That is its purpose and the =E2=80=9Cacct= =E2=80=9D URI, and > it=E2=80=99s a valid purpose. The one example I like to give is =E2=80= =9CHow do we identify > an account at Twitter?=E2=80=9D There is no email, so =E2=80=9Cmailto=E2= =80=9D is not the right > URI. A user has an account at any service provider and the =E2=80=9Cacct= =E2=80=9D URI would > identify the account, not the particular service at the service provider > (e.g., email, XMPP, or whatever). > Hi Paul, I just wanted to run a few thoughts by you to make sure I'm not missing something. Maybe I don't fully understand the various use-cases, but it seems like you are saying that when querying a 'resource', the value does NOT need to be prefixed with acct (or anything). I know there's the idea that at some point another type of resource could be identified as relevant and so that was the argument for having the 'acct' prefix. However your wording suggests that even 'acct' is not needed. So someone's WF service could accept 'resource=3Dbob' and not 'resource=3Dacct:bob@example.com' and it would still be a compliant WF service? If true, it seems like there could be a lot of room for uncertainty in query format and client libraries would have to try a number of different value formats. Another thing, in regards to the twitter example you gave. What's to differentiate a user of twitter and an employee of twitter? There could be a user '@janice' and an employee 'janice@twitter.com', who may be different people. As I understand it, in your example, these different accounts would be queried in the same way. /.host-meta/webfinger?resource=3Dacct:janice@twitter.com Am I misunderstanding? Or does this create a problem. -Nick From kidehen@openlinksw.com Sat Dec 15 14:01:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF63421F8468 for ; Sat, 15 Dec 2012 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.511 X-Spam-Level: * X-Spam-Status: No, score=1.511 tagged_above=-999 required=5 tests=[AWL=4.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc19LBtAsXtG for ; Sat, 15 Dec 2012 14:01:43 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1832A21F8467 for ; Sat, 15 Dec 2012 14:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qhSrVoMMAHEs6faJBcaJ18ShxUOdu78SJMNc7Zu60NQ=; b=C8LDjL1+Yx4O14OzhUY3c6ZBSMCCwhuYnq/AntMM8bFhS4Pm6oRAueXQgXQ+OgWjpgfYMS2m6krZMsZbEh++NGvwm1y7XnVHdgjoRPy62lpGg1L733ySXFiGVURktnOs; Received: from pool-173-48-165-129.bstnma.fios.verizon.net ([173.48.165.129] helo=macintosh-96.home) by mail.openlinksw.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1Tjzng-0006Z2-Lj; Sat, 15 Dec 2012 17:01:40 -0500 Message-ID: <50CCF343.4070904@openlinksw.com> Date: Sat, 15 Dec 2012 17:01:39 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@googlegroups.com References: <0b9901cdda97$eba63e70$c2f2bb50$@packetizer.com> <97135BA5-9E51-48A1-A613-706F92F0A15D@gmail.com> <23858499-9385-44C9-B3D6-20A997727C12@gmail.com> In-Reply-To: <23858499-9385-44C9-B3D6-20A997727C12@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020307060902040801070001" X-Mailman-Approved-At: Mon, 17 Dec 2012 07:37:22 -0800 Cc: John Panzer , "Paul E. Jones" , James M Snell , Goix Laurent Walter , Brad Fitzpatrick , webfinger@ietf.org, Dick Hardt Subject: Re: [webfinger] A third (or is it twelfth?) way [was: secure links with https rels] X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 02:24:44 -0000 This is a cryptographically signed message in MIME format. --------------ms020307060902040801070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/15/12 12:05 PM, Dick Hardt wrote: > Remember that payments drove the deployment of HTTPS to all ecommerce s= ights. Intercepted credentials drove HTTPS to web mail and Twitter etc. = Perhaps WF will drive HTTPS further? Yes, and none of that happened as a result of an HTTPS-only spec., which = is the most important point here. As per usual, folks found out for themselves the hard way -- because we=20 humans don't like prevention, we are wired for cures :-) We need to make a spec that's going to make Webfinger widely adopted.=20 Once adopted, folks will end up in the right place. What you shouldn't=20 do is issue a mandate disguised as a spec, it never works re., broad=20 adoption. --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms020307060902040801070001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjE1MjIwMTM5WjAjBgkqhkiG9w0BCQQxFgQU1wnJuk+76zyPuYI2 IdQW2Y9GYIswVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAjw7CShCfG+eg 76sq75XTAHZjibZbdOB2eQUVIMy8pQgUa5HYgLpH7FdYsF0go6JqooWKBZlCpfyBv+Zxzux8 TVauDllfwf/txg0M4f5OmTJIdfcc/aPeXyfMX/tVwQP09MKoqc9bfnrwKtPQvgDdoBFp73rJ UMgIiDE6Lgbhk+BdSPlmnKMULebn498NSOteHVjwUQZg3pPZjrcri/7wyLF4qv0Bjg64QHJg ksiwa1smobGuIXlPLgWHfJ9GeWOrZoZUJExFOwWWjIJGYy+8F3moYUI074/SuCb7SPO1Gd0N z2Erzw3aBj2/YgJOL7IOmfcF4xs2mIbJ8/wULqePWwAAAAAAAA== --------------ms020307060902040801070001-- From paulej@packetizer.com Mon Dec 17 11:19:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0251E21F8859 for ; Mon, 17 Dec 2012 11:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywpb2LdKuba8 for ; Mon, 17 Dec 2012 11:19:39 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1B21F85C0 for ; Mon, 17 Dec 2012 11:19:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBHJJakq006921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 14:19:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355771977; bh=h8gF/+Y08NKI72onfCaZ/JFF8tnndmnecbxSEQ/Rirg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kOuQ5H0/zJQxB1il3a78n3q9eIMHvV9HPLdz332UMW6AvhS5JFtsTR2VSgOVMoIRm mEvGpqStEiEWm+n+RhZs4Ot+Tw5PfXhrulqg7n9tElbmCfWhs4KNFaVyRJu28ytvl8 ecPGdEwXiP6hS7/7UnSPFeKe+2lzb6vM/emKUP00= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> In-Reply-To: Date: Mon, 17 Dec 2012 14:19:39 -0500 Message-ID: <028001cddc8b$75b0ac50$611204f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01CDDC61.8CDB67A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgBk3yM2gFLlorYAZrIBocCj3r0zZiFID2Q Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:19:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0281_01CDDC61.8CDB67A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Comments below: The link relations contain 3 components. The subject, the predicate and the object. In other language the entity the attribute and the value. The Entity in this case would be @subject, the attribute would be the rel of the link, and the value would be the value of the link. In almost every serialization I know, multiple subjects/entities are permissible, in an array of (say JSON) objects. In JRD there is a constraint limiting the serialization to exactly one entity/subject. This imho could be seen as a slight weakness, especially it it makes the serialization of choice not 100% interoperable with others more permissible serializations. PEJ: My understanding of subject is the "thing" I'm querying (e.g., acct:paulej@packetizer.com ). Given that definition, JRD covers a single subject since WF is looking for a single "thing". Inside, there may be multiple "properties" for the "thing" (e.g., "http://packetizer.com/ns/name" is a property with a value "Paul E. Jones). Then there is an array of "link relations". The definition follows that of RFC 5988. Each link relation is identified by a "rel" value. There is also an optional "type". And there is an "href". JRD also allows for self-describing link relations, where the "href" is absent and "properties" are used to describe the value of the relation to the "rel". An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. Lastly, any link may have one or more human-readable names in a "titles" array. You can see an example here: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1. Sorry forgot to respond to this point. (only did the red ones :)) Thanks, I think I understand the JRD format and it's great that A) it's JSON based and B) it can be self describing and C) that it can include references (links) to other URIs The weakness in this serialization is that it becomes tightly coupled to the query that generated it. A data document should be an entity in it's own right that is independent of how it is generated. What we are getting is data, that happened to be delivered via webfinger. While it is often the case on the web that a document will yield a single subject, and indeed in many cases this is a best practice, it is not always the case. There are many cases where there are multiple items in a single page, a good example is wikipedia which divides itself up into many sections; the page may be about Germany, then the sections could be about Geography, History, Economy etc. This leads to interoperability issues with the rest of the web. My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured? PEJ: It is tightly coupled with the query, but view that as positive. JRD has a limited use. It's not HTML where we're creating elaborate documents. It's a simple data structure that conveys link relations and properties about a "subject". If one wanted to have a more complex document that included multiple "subjects", one could create an array or hash table of JRDs. Such use, though, is entirely outside the scope of WebFinger. I do like use of content negotiation. Nothing precludes that from happening in WF, either, since it is built on top of HTTP. We're just not specifying what would be negotiated. The current text says: WebFinger servers MUST return a JRD as the representation for the resource if the client requests no format explicitly via the HTTP "Accept" header. A client MAY include the "Accept" header to indicate a desired representation, though no other representation is defined in this specification. ------=_NextPart_000_0281_01CDDC61.8CDB67A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Comments below:

 

The link = relations contain 3 components.   The subject, the predicate = and the object.  In other language the entity the attribute and the = value.  The Entity in this case would be @subject, the attribute = would be the rel of the link, and the value would be the value of the = link.

In almost every serialization I know, multiple = subjects/entities are permissible, in an array of (say JSON) = objects.  In JRD there is a constraint limiting the serialization = to exactly one entity/subject.  This imho could be seen as a slight = weakness, especially it it makes the serialization of choice not 100% = interoperable with others more permissible = serializations.

 

PEJ: My understanding of subject is the “thing” I’m = querying (e.g., acct:paulej@packetizer.com).  Given that = definition, JRD covers a single subject since WF is looking for a single = “thing”.  Inside, there may be multiple = “properties” for the “thing” (e.g., “http://packetizer.com/ns/name” is a property = with a value “Paul E. Jones).  Then there is an array of = “link relations”.  The definition follows that of RFC = 5988.  Each link relation is identified by a “rel” = value.  There is also an optional “type”.  And = there is an “href”.  JRD also allows for = self-describing link relations, where the “href” is absent = and “properties” are used to describe the value of the = relation to the “rel”.  An example is this: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07#section-4.3.  Lastly, any link may have one or more = human-readable names in a “titles” array.  You can see = an example here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger= -07#section-4.1.

<= /blockquote>


Sorry forgot to = respond to this point.  (only did the red ones :))

Thanks, I = think I understand the JRD format and it's great that A) it's JSON based = and B) it can be self describing and C) that it can include references = (links) to other URIs

The weakness in this serialization is that = it becomes tightly coupled to the query that generated it.  A data = document should be an entity in it's own right that is independent of = how it is generated.  What we are getting is data, that happened to = be delivered via webfinger.  While it is often the case on the web = that a document will yield a single subject, and indeed in many cases = this is a best practice, it is not always the case.  There are many = cases where there are multiple items in a single page, a good example is = wikipedia which divides itself up into many sections; the page may be = about Germany, then the sections could be about Geography, History, = Economy etc.  This leads to interoperability issues with the rest = of the web.

My view is that webfinger should be serialization = agnostic and operate using content negotiation.  JRD is one of the = weaker serializations, imho, and as mark has suggested, if favoured = especially it will need greater review, which may take time.  Im = not sure anyone has ever answered the question as to why has it been = consistently favoured?
 

PEJ: It is tightly coupled with the query, but  view that as = positive.  JRD has a limited use.  It’s not HTML where = we’re creating elaborate documents.  It’s a simple data = structure that conveys link relations and properties about a = “subject”.  If one wanted to have a more complex = document that included multiple “subjects”, one could create = an array or hash table of JRDs.  Such use, though, is entirely = outside the scope of WebFinger.  I do like use of content = negotiation.  Nothing precludes that from happening in WF, either, = since it is built on top of HTTP.  We’re just not specifying = what would be negotiated.  The current text = says:

 

WebFinger servers MUST return a JRD as the representation for the = resource if the client requests no format explicitly via the HTTP = “Accept” header.  A client MAY include the = “Accept” header to indicate a desired representation, though = no other representation is defined in this = specification.

 

 

 

------=_NextPart_000_0281_01CDDC61.8CDB67A0-- From melvincarvalho@gmail.com Mon Dec 17 11:44:19 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8121F88B7 for ; Mon, 17 Dec 2012 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtrxWW8h0LvS for ; Mon, 17 Dec 2012 11:44:18 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6E321F887B for ; Mon, 17 Dec 2012 11:44:18 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9858878ieb.31 for ; Mon, 17 Dec 2012 11:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f7PVYR5GI34by466Qa2w2QUr/0d0TmANsnZS8/wVCUc=; b=MEL+iM0uN0DjtNTq4lIJ8CyWM6rT/4cXLi3NLYcU3paTo3RBLJRLpeiop5+Tn11BEP kWdsJDXxVsqBlwhPUko75frY2FE9yhv+ln5TNcNWyCqhQRFyiRPuCcvVxE5XD6HuIBNQ hc7u22aGOOqbR8PAiobsxy7Z5tsY4Hly7pDTe6WODfnAXDymqwkyt0EFEwB/pwou+nnE Kh1BUXzfb51J2JW+ykqQX4KtbYKKlEGq0YgoLupcAhhb/06jt/y8RpgxCQD1B/fxoBqB 1klevpWxrF0ANJLNGdy2lY7zB7b95VCmzU8krJ56tD81kxt0lcSBc/kFiOy16BnxWjIM ZDWw== MIME-Version: 1.0 Received: by 10.42.101.66 with SMTP id d2mr12282070ico.11.1355773457827; Mon, 17 Dec 2012 11:44:17 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 11:44:17 -0800 (PST) In-Reply-To: <028001cddc8b$75b0ac50$611204f0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> <028001cddc8b$75b0ac50$611204f0$@packetizer.com> Date: Mon, 17 Dec 2012 20:44:17 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec53143b559861d04d1119b78 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:44:19 -0000 --bcaec53143b559861d04d1119b78 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17 December 2012 20:19, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Comments below:**** > > ** ** > > The link relations contain 3 components. The subject, the predicate and > the object. In other language the entity the attribute and the value. T= he > Entity in this case would be @subject, the attribute would be the rel of > the link, and the value would be the value of the link. > > In almost every serialization I know, multiple subjects/entities are > permissible, in an array of (say JSON) objects. In JRD there is a > constraint limiting the serialization to exactly one entity/subject. Thi= s > imho could be seen as a slight weakness, especially it it makes the > serialization of choice not 100% interoperable with others more permissib= le > serializations.**** > > **** > > PEJ: My understanding of subject is the =93thing=94 I=92m querying (e.g., > acct:paulej@packetizer.com). Given that definition, JRD covers a single > subject since WF is looking for a single =93thing=94. Inside, there may = be > multiple =93properties=94 for the =93thing=94 (e.g., =93 > http://packetizer.com/ns/name=94 is a property with a value =93Paul E. > Jones). Then there is an array of =93link relations=94. The definition > follows that of RFC 5988. Each link relation is identified by a =93rel= =94 > value. There is also an optional =93type=94. And there is an =93href=94= . JRD > also allows for self-describing link relations, where the =93href=94 is a= bsent > and =93properties=94 are used to describe the value of the relation to th= e > =93rel=94. An example is this: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3. > Lastly, any link may have one or more human-readable names in a =93titles= =94 > array. You can see an example here: **** > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.**= * > * > > > Sorry forgot to respond to this point. (only did the red ones :)) > > Thanks, I think I understand the JRD format and it's great that A) it's > JSON based and B) it can be self describing and C) that it can include > references (links) to other URIs > > The weakness in this serialization is that it becomes tightly coupled to > the query that generated it. A data document should be an entity in it's > own right that is independent of how it is generated. What we are gettin= g > is data, that happened to be delivered via webfinger. While it is often > the case on the web that a document will yield a single subject, and inde= ed > in many cases this is a best practice, it is not always the case. There > are many cases where there are multiple items in a single page, a good > example is wikipedia which divides itself up into many sections; the page > may be about Germany, then the sections could be about Geography, History= , > Economy etc. This leads to interoperability issues with the rest of the > web. > > My view is that webfinger should be serialization agnostic and operate > using content negotiation. JRD is one of the weaker serializations, imho= , > and as mark has suggested, if favoured especially it will need greater > review, which may take time. Im not sure anyone has ever answered the > question as to why has it been consistently favoured? > **** > > PEJ: It is tightly coupled with the query, but view that as positive. > JRD has a limited use. It=92s not HTML where we=92re creating elaborate > documents. It=92s a simple data structure that conveys link relations an= d > properties about a =93subject=94. If one wanted to have a more complex > document that included multiple =93subjects=94, one could create an array= or > hash table of JRDs. Such use, though, is entirely outside the scope of > WebFinger. I do like use of content negotiation. Nothing precludes that > from happening in WF, either, since it is built on top of HTTP. We=92re = just > not specifying what would be negotiated. The current text says: > I dont know that much about JRD, but I'd just like to double check this point. Are you sure it is possible to create an array of JRDs? My understanding was that in XRD this was forbidden. If it's possible in JRD, that would be a *major* plus, imho, because it would mean that at least *theoretically* the default webfinger serialization is interoperable with the rest of the web. > **** > > ** ** > > WebFinger servers MUST return a JRD as the representation for the resourc= e > if the client requests no format explicitly via the HTTP =93Accept=94 hea= der. > A client MAY include the =93Accept=94 header to indicate a desired > representation, though no other representation is defined in this > specification.**** > > ** ** > > ** ** > > ** ** > --bcaec53143b559861d04d1119b78 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 20:19, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Comments be= low:

=A0<= /p>

The link relations contain 3 componen= ts.=A0=A0 The subject, the predicate and the object.=A0 In other language t= he entity the attribute and the value.=A0 The Entity in this case would be = @subject, the attribute would be the rel of the link, and the value would b= e the value of the link.

In almost every serialization I know, multiple subjects/entities are pe= rmissible, in an array of (say JSON) objects.=A0 In JRD there is a constrai= nt limiting the serialization to exactly one entity/subject.=A0 This imho c= ould be seen as a slight weakness, especially it it makes the serialization= of choice not 100% interoperable with others more permissible serializatio= ns.

=A0<= /p>

PEJ: My understa= nding of subject is the =93thing=94 I=92m querying (e.g., acct:paulej@packetizer.com= ).=A0 Given that definition, JRD covers a single subject since WF is lo= oking for a single =93thing=94.=A0 Inside, there may be multiple =93propert= ies=94 for the =93thing=94 (e.g., =93http://packetizer.com/ns/name=94 is a property wi= th a value =93Paul E. Jones).=A0 Then there is an array of =93link relation= s=94.=A0 The definition follows that of RFC 5988.=A0 Each link relation is = identified by a =93rel=94 value.=A0 There is also an optional =93type=94.= =A0 And there is an =93href=94.=A0 JRD also allows for self-describing link= relations, where the =93href=94 is absent and =93properties=94 are used to= describe the value of the relation to the =93rel=94.=A0 An example is this= : http://tools.ietf.org/html/draft-ietf-appsawg-w= ebfinger-07#section-4.3.=A0 Lastly, any link may have one or more human= -readable names in a =93titles=94 array.=A0 You can see an example here:

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1= .


Sorry forgot to respond to this point.= =A0 (only did the red ones :))

Thanks, I think I understand the JRD = format and it's great that A) it's JSON based and B) it can be self= describing and C) that it can include references (links) to other URIs

The weakness in this serialization is that it becomes tightly coupled t= o the query that generated it.=A0 A data document should be an entity in it= 's own right that is independent of how it is generated.=A0 What we are= getting is data, that happened to be delivered via webfinger.=A0 While it = is often the case on the web that a document will yield a single subject, a= nd indeed in many cases this is a best practice, it is not always the case.= =A0 There are many cases where there are multiple items in a single page, a= good example is wikipedia which divides itself up into many sections; the = page may be about Germany, then the sections could be about Geography, Hist= ory, Economy etc.=A0 This leads to interoperability issues with the rest of= the web.

My view is that webfinger should be serialization agnostic and operate = using content negotiation.=A0 JRD is one of the weaker serializations, imho= , and as mark has suggested, if favoured especially it will need greater re= view, which may take time.=A0 Im not sure anyone has ever answered the ques= tion as to why has it been consistently favoured?
=A0

<= /span>

=A0

=A0<= /p>

=A0

=A0<= /p>


--bcaec53143b559861d04d1119b78-- From paulej@packetizer.com Mon Dec 17 12:30:55 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85B21F8436 for ; Mon, 17 Dec 2012 12:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsgcDzVqgDSY for ; Mon, 17 Dec 2012 12:30:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED721F8446 for ; Mon, 17 Dec 2012 12:30:54 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBHKUp28010192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 15:30:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355776253; bh=LTKWTyrd4WHWMAlYlgJSFsW3aH4F2D9xOBg91YIBBX8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qalLaPpSX4vanL/jjscoP8MMmG/K74CcD0rZbIaLb7wsX2UWb8DUEt3Cgt+9P3Kiy yzfgVj9RjGxiG11gW38ZKqszeZax0+mlx1ofW/uOd0Obd+8yuhTZS/dW6FbdqBDxD+ S0YiH7DuJ+lvgkA+2JwnRdr1veKv/SFNy4T1t06k= From: "Paul E. Jones" To: "'Nick Jennings'" , References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> In-Reply-To: Date: Mon, 17 Dec 2012 15:30:54 -0500 Message-ID: <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2JirENMw Content-Language: en-us Cc: webfinger@ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:30:55 -0000 Nick, > > PEJ: WebFinger uses any URI scheme. The =E2=80=9Cacct=E2=80=9D = scheme is just one of > > them and is not core to the spec now, though there is a statement > > recommending its use to identify accounts. That is its purpose and > > the =E2=80=9Cacct=E2=80=9D URI, and it=E2=80=99s a valid purpose. = The one example I like to > > give is =E2=80=9CHow do we identify an account at Twitter?=E2=80=9D = There is no > > email, so =E2=80=9Cmailto=E2=80=9D is not the right URI. A user has = an account at any > > service provider and the =E2=80=9Cacct=E2=80=9D URI would identify = the account, not > > the particular service at the service provider (e.g., email, XMPP, = or > whatever). > > >=20 > Hi Paul, I just wanted to run a few thoughts by you to make sure I'm = not > missing something. >=20 > Maybe I don't fully understand the various use-cases, but it seems = like > you are saying that when querying a 'resource', the value does NOT = need > to be prefixed with acct (or anything). I know there's the idea that = at > some point another type of resource could be identified as relevant = and > so that was the argument for having the 'acct' prefix. > However your wording suggests that even 'acct' is not needed. So > someone's WF service could accept 'resource=3Dbob' and not > 'resource=3Dacct:bob@example.com' and it would still be a compliant WF > service? If true, it seems like there could be a lot of room for > uncertainty in query format and client libraries would have to try a > number of different value formats. What the spec says is that any URI may be queried. That's what I meant. = The protocol is not designed to be used only with "acct:". One may = query WF using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or = "tel:" or "urn:". Obviously, URI schemes that do not have domain names = present issues, but that it's certainly possible and I suspect there = would be an agreed client/server relationship. My own server code actually will accept just "paulej@packetizer.com", = for example. If it sees that, it assumes the requestor wants = "acct:paulej@packetizer.com" and returns the results from the database = for the "acct:" URI. However, the "subject" is just the bare = "paulej@packetizer.com" and the "acct:" URI is inserted into the = response as an alias. However, none of that is in the spec. I did that = long ago, because Blaine preferred to not require a URI scheme for = user@domain forms. > Another thing, in regards to the twitter example you gave. What's to > differentiate a user of twitter and an employee of twitter? > > There could be a user '@janice' and an employee 'janice@twitter.com', > who may be different people. As I understand it, in your example, = these > different accounts would be queried in the same way. > > /.host-meta/webfinger?resource=3Dacct:janice@twitter.com Users and employees must have different values within the scope = of the domain (or sub-domain). Some time ago, somebody mentioned that = they have a domain with user accounts and employees where the user = account names did clash with employee names. I don't have a solution = for that. Personally, I think that's an unfortunate situation to be in. On my own web site, I run phpBB. There are user accounts. So, I can = appreciate how people get into that situation. However, I placed the = discussion forms at forums.packetizer.com and so if the phpBB software = ever supported WebFinger (hmmmm... more holiday coding opportunities) = then I would expect it to respond only to = acct:@forums.packetizer.com. That would be perfectly fine and = would avoid the name clash. WF does not require queries only to the = domain. Queries can be sent to any appropriate host within the domain. > Am I misunderstanding? Or does this create a problem. There are potential issues for domain owners who have allocated the same = user identifier to more than one person on the same domain or = sub-domain. Domain owners will have to address that before deploying = WF. Paul From paulej@packetizer.com Mon Dec 17 13:04:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5321F884B for ; Mon, 17 Dec 2012 13:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV5JbNRUkmYa for ; Mon, 17 Dec 2012 13:04:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53421F8834 for ; Mon, 17 Dec 2012 13:04:18 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBHL4GlT011775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 16:04:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355778256; bh=VEV23mThKNMRj2K4z6bbCW7NEK9GRvvHoV/z37aPGt0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g4MKcozmvO6IT3RRH2fqxPfzSndpED/qMEiyOJpWzO2H45l3iSsG/R5AxP8PvSAgQ Z6zxW2kICWQZ8U6ReDIJGs+k0kjfRAvckreX7gUAA29R3WAtZqnzNdVeDIsWKNTbp3 mMNRDxuQifsjUC2FbhTE9vJP2P1ud/+2TyB1X9ig= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> <028001cddc8b$75b0ac50$611204f0$@packetizer.com> In-Reply-To: Date: Mon, 17 Dec 2012 16:04:18 -0500 Message-ID: <02ad01cddc9a$149d9b80$3dd8d280$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AE_01CDDC70.2BC856D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgBk3yM2gFLlorYAZrIBocCj3r0zQHzK0s3AWyV0AGYajpf4A== Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:04:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02AE_01CDDC70.2BC856D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, The JRD spec itself (and I've extracted it out and placed it here for convenience: http://www.packetizer.com/json/jrd/) does not define creating an array of itself. However, programmatically it would be trivial to create an array of JRD objects in virtually any language. WebFinger only deals with a single "subject" at a time. So, the data returned from the server does not need to have multiple sections with a "subject" per section. However, since the "subject" is an element within the JRD, then you can imagine a JSON object like this: { "jrds" : [ { }, { }, { ... } ] } or { "" : { ", { }, ... } Neither are defined, but you can see how JRDs could be used within more complex documents. Paul My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured? PEJ: It is tightly coupled with the query, but view that as positive. JRD has a limited use. It's not HTML where we're creating elaborate documents. It's a simple data structure that conveys link relations and properties about a "subject". If one wanted to have a more complex document that included multiple "subjects", one could create an array or hash table of JRDs. Such use, though, is entirely outside the scope of WebFinger. I do like use of content negotiation. Nothing precludes that from happening in WF, either, since it is built on top of HTTP. We're just not specifying what would be negotiated. The current text says: I dont know that much about JRD, but I'd just like to double check this point. Are you sure it is possible to create an array of JRDs? My understanding was that in XRD this was forbidden. If it's possible in JRD, that would be a *major* plus, imho, because it would mean that at least *theoretically* the default webfinger serialization is interoperable with the rest of the web. ------=_NextPart_000_02AE_01CDDC70.2BC856D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

The JRD spec itself (and I’ve extracted it out and placed it = here for convenience: http://www.packetizer.com/js= on/jrd/) does not define creating an array of = itself.

 

However, programmatically it would be trivial to create an array of = JRD objects in virtually any language.  WebFinger only deals with a = single “subject” at a time.  So, the data returned from = the server does not need to have multiple sections with a = “subject” per section.  However, since the = “subject” is an element within the JRD, then you can imagine = a JSON object like this:

 

{ “jrds” : [ { <jrd1> }, { <jrd2> }, { ... } = ] }

 

or

 

{ “<jrd subject 1>” : { <jrd 1 }, “<jrd = subject 2>”, { <jrd 2> }, ... }

 

Neither are defined, but you can see how JRDs could be used within = more complex documents.

 

Paul

My view is = that webfinger should be serialization agnostic and operate using = content negotiation.  JRD is one of the weaker serializations, = imho, and as mark has suggested, if favoured especially it will need = greater review, which may take time.  Im not sure anyone has ever = answered the question as to why has it been consistently = favoured?
 

PEJ: It is tightly coupled with the query, but  view that as = positive.  JRD has a limited use.  It’s not HTML where = we’re creating elaborate documents.  It’s a simple data = structure that conveys link relations and properties about a = “subject”.  If one wanted to have a more complex = document that included multiple “subjects”, one could create = an array or hash table of JRDs.  Such use, though, is entirely = outside the scope of WebFinger.  I do like use of content = negotiation.  Nothing precludes that from happening in WF, either, = since it is built on top of HTTP.  We’re just not specifying = what would be negotiated.  The current text = says:


I dont know that much about JRD, but I'd just like = to double check this point.  Are you sure it is possible to create = an array of JRDs? 

My understanding was that in XRD this = was forbidden.  If it's possible in JRD, that would be a *major* = plus, imho, because it would mean that at least *theoretically* the = default webfinger serialization is interoperable with the rest of the = web.

 

------=_NextPart_000_02AE_01CDDC70.2BC856D0-- From salvatore.loreto@ericsson.com Mon Dec 17 13:20:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C63921F8828 for ; Mon, 17 Dec 2012 13:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRYH3PBxCTTO for ; Mon, 17 Dec 2012 13:20:25 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A565821F86FC for ; Mon, 17 Dec 2012 13:20:24 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-cf-50cf8c977db0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8A.44.10459.79C8FC05; Mon, 17 Dec 2012 22:20:23 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 17 Dec 2012 22:20:23 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 323CB2383; Mon, 17 Dec 2012 23:20:23 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D690753E6B; Mon, 17 Dec 2012 23:20:21 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3372553DAA; Mon, 17 Dec 2012 23:20:21 +0200 (EET) Message-ID: <50CF8C95.3050702@ericsson.com> Date: Mon, 17 Dec 2012 22:20:21 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvje70nvMBBlP+qFscWnyJ1WLi9wY2 i0U3pjM6MHu0rOpl9tg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mu69PMFUcJ2zov3WC8YG xn3sXYycHBICJhLXLl5jgbDFJC7cW88GYgsJnGSUmPKGs4uRC8jewCjx/vYBFghnF6NEx6Qd zBDOWkaJiTNaGSGcbYwSn3pXMHUxcnDwCmhL7LtZBzKKRUBV4v68C4wgNpuAmcTzh1uYQWxR gViJrZcug63jFRCUODnzCdgZIkBnrD/6ACzOLBApseT8ErC4sICOxOmPZ1gh4rYSF+ZcZ4Gw 5SW2v53DDPGCmsTVc5uYIV7Qkug928k0gVF4FpIVs5C0z0LSvoCReRUje25iZk56ueEmRmBo H9zyW3cH46lzIocYpTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpgbBXYvuTC BcWmvUfeT1x4VtO9vvH68YDjp07fKuyQ8+2QWffKeWvQiQcvHJxWGNtdkdq+uba+1anI590v H81beztSs99vyZW3bVj4Mua5WsPq6dNanFb3ay6tS7v9b8PhH5E2PbIaoefWqvTWhRb/aXh5 8I7yfDHlQgabQ31JfXcr7f8yLF8mrcRSnJFoqMVcVJwIAIq14Uo7AgAA Cc: Barry Leiba , "Murray S. Kucherawy" Subject: [webfinger] consensus declaration on HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:20:26 -0000 Thanks everybody for your participation in the "HTTPS only vs HTTPS-and-HTTP" discussion and for providing feedback and alternatives. In light of the last two weeks mail discussion on the subject, spread among different threads, I, as chair responsible for this draft, am declaring rough consensus on the "HTTPS only" option. My reading of the mail discussion is that at this point there is rough consensus to specify only WebFinger over HTTPS because 1) it does not open room to any unknown and/or not enough analyzed security risks, allowing at the same time to finalize and deploy the first version of WebFinger quite soon 2) the work to support plain HTTP, while is recognized to be important and necessary, still requires quite a lot of discussions both to come to an agreement on which approach to use among the different ones on the table and to fully investigate all the security aspects and implications. For those reasons is much better to specify only the secure way in the first version of WebFinger but at the same time start to work on the non-secure modes on a separate document Salvatore Loreto -- Salvatore Loreto, PhD www.sloreto.com From melvincarvalho@gmail.com Mon Dec 17 13:36:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522B521F85C0 for ; Mon, 17 Dec 2012 13:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4bF9-LQoMbd for ; Mon, 17 Dec 2012 13:36:25 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24A21F857D for ; Mon, 17 Dec 2012 13:36:25 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so5945885iaz.31 for ; Mon, 17 Dec 2012 13:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/1CViSn+4QgTGt45ayqsJ+vnK8mO7lRzwuhY8JCwrGk=; b=VjGtOA0nfUGdNxFFEo1v48VHGs8u/wrxwZAY0J8pQ6bLfrUmBI7JDJaA0o0d7FIoVv wdtuHbI2Dt4Snj0+1XPE2ewmpwB1x9S2RO24JRurqEoQlJu0gT8uJJ+HkabwJyzhBbXW zmQaIzst4PKxZCJMcxQS3/DcFuaX0PYI1ITTXMdP4bgceOnjoic/gNBNOOOxFvefI2We xUgEgzqoSjo4KN2Iy18X5PCeCPRmHFDFEUWOr15YNkciFiXIh5Fj7+stdhR8fUhvzFIs 6qyn5l+gn6KSUhMTFaOLMQa939MAj78QNlUYmZ0Wb8PHCab6IfHTfFU2mL/BQ6mJcvhh V29w== MIME-Version: 1.0 Received: by 10.50.5.239 with SMTP id v15mr9913igv.41.1355780184858; Mon, 17 Dec 2012 13:36:24 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 13:36:24 -0800 (PST) In-Reply-To: <02ad01cddc9a$149d9b80$3dd8d280$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> <028001cddc8b$75b0ac50$611204f0$@packetizer.com> <02ad01cddc9a$149d9b80$3dd8d280$@packetizer.com> Date: Mon, 17 Dec 2012 22:36:24 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f502cd64fe09804d1132c9b Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:36:26 -0000 --e89a8f502cd64fe09804d1132c9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 17 December 2012 22:04, Paul E. Jones wrote: > Melvin,**** > > ** ** > > The JRD spec itself (and I=92ve extracted it out and placed it here for > convenience: http://www.packetizer.com/json/jrd/) does not define > creating an array of itself.**** > > ** ** > > However, programmatically it would be trivial to create an array of JRD > objects in virtually any language. WebFinger only deals with a single > =93subject=94 at a time. So, the data returned from the server does not = need > to have multiple sections with a =93subject=94 per section. However, sin= ce the > =93subject=94 is an element within the JRD, then you can imagine a JSON o= bject > like this:**** > > ** ** > > { =93jrds=94 : [ { }, { }, { ... } ] }**** > > ** ** > > or**** > > ** ** > > { =93=94 : { =94, { },= ... }*** > * > > ** ** > > Neither are defined, but you can see how JRDs could be used within more > complex documents. > Sounds great I think all you would need to do is [ { JRD1 }, { JRD2 }, { JRD3 } ] See Example 51 from : http://json-ld.org/spec/latest/json-ld-syntax/ The reason that I asked is that the XML Schema or XRD strictly forbids more than one object. I do not know the rationale for this, because other serializations definitely allow multiple. If JRD can do this, that's a big plus. Thanks for extracting the spec. Do you know who maintains JRD currently? > **** > > ** ** > > Paul**** > > My view is that webfinger should be serialization agnostic and operate > using content negotiation. JRD is one of the weaker serializations, imho= , > and as mark has suggested, if favoured especially it will need greater > review, which may take time. Im not sure anyone has ever answered the > question as to why has it been consistently favoured? > **** > > PEJ: It is tightly coupled with the query, but view that as positive. > JRD has a limited use. It=92s not HTML where we=92re creating elaborate > documents. It=92s a simple data structure that conveys link relations an= d > properties about a =93subject=94. If one wanted to have a more complex > document that included multiple =93subjects=94, one could create an array= or > hash table of JRDs. Such use, though, is entirely outside the scope of > WebFinger. I do like use of content negotiation. Nothing precludes that > from happening in WF, either, since it is built on top of HTTP. We=92re = just > not specifying what would be negotiated. The current text says:**** > > > I dont know that much about JRD, but I'd just like to double check this > point. Are you sure it is possible to create an array of JRDs? > > My understanding was that in XRD this was forbidden. If it's possible in > JRD, that would be a *major* plus, imho, because it would mean that at > least *theoretically* the default webfinger serialization is interoperabl= e > with the rest of the web. **** > > ** ** > --e89a8f502cd64fe09804d1132c9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 22:04, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

The JRD spec itself (and I=92ve extracted it = out and placed it here for convenience: http://www.packetizer.com/json/jrd/) doe= s not define creating an array of itself.

=A0<= /p>

However, programmatica= lly it would be trivial to create an array of JRD objects in virtually any = language.=A0 WebFinger only deals with a single =93subject=94 at a time.=A0= So, the data returned from the server does not need to have multiple secti= ons with a =93subject=94 per section.=A0 However, since the =93subject=94 i= s an element within the JRD, then you can imagine a JSON object like this:<= u>

=A0<= /p>

{ =93jrds=94 : [ { <= ;jrd1> }, { <jrd2> }, { ... } ] }

=A0<= /p>

or

=A0<= /p>

{ =93<jrd subject 1= >=94 : { <jrd 1 }, =93<jrd subject 2>=94, { <jrd 2> }, ..= . }

=A0<= /p>

Neither are defined, b= ut you can see how JRDs could be used within more complex documents.=


Sounds great

I think all you would= need to do is

[
=A0 { JRD1 },
=A0 { JRD2 },
=A0 { JRD3 }<= br>]

See Example 51 from :

http://json-ld.org/spec/latest/json-ld-syntax/=

The reason that I asked is that the XML Schema or XRD strictly forbids = more than one object.=A0 I do not know the rationale for this, because othe= r serializations definitely allow multiple.=A0

If JRD can do this, = that's a big plus.=A0 Thanks for extracting the spec.=A0 Do you know wh= o maintains JRD currently?
=A0

=

=A0

Paul

My view is that webfinger should be serialization agnostic and operate usin= g content negotiation.=A0 JRD is one of the weaker serializations, imho, an= d as mark has suggested, if favoured especially it will need greater review= , which may take time.=A0 Im not sure anyone has ever answered the question= as to why has it been consistently favoured?
=A0


I dont know t= hat much about JRD, but I'd just like to double check this point.=A0 Ar= e you sure it is possible to create an array of JRDs?=A0

My underst= anding was that in XRD this was forbidden.=A0 If it's possible in JRD, = that would be a *major* plus, imho, because it would mean that at least *th= eoretically* the default webfinger serialization is interoperable with the = rest of the web.

=A0<= /p>


--e89a8f502cd64fe09804d1132c9b-- From melvincarvalho@gmail.com Mon Dec 17 15:43:00 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535F211E809C for ; Mon, 17 Dec 2012 15:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s21OWFZKH549 for ; Mon, 17 Dec 2012 15:42:59 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAD11E8097 for ; Mon, 17 Dec 2012 15:42:56 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e13so9954642iej.18 for ; Mon, 17 Dec 2012 15:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3dhvU+1QBiZiLLIKeZaQ+QVLFiGEkKqUzkCzPX+GMw=; b=JvSeXAlh2Zns8NKRKrsoC6qFObCGBwOQzU7Qia8g0Y+nj2PyGU1SULtF80srvziRTb ICxJt/mscDUWwzgyBTbKzboq4yvxQpFDexWCDA7nEDgRCprFC2x6X6EMa+TKXaCHDqCc aYf+pYVrTHkUH7tOzcCjn8BndKYvvpdodXX4fslh7jp5lxom5+1nR37ajFH/kgheoWf2 xzJLVWtBUxTjKYdTYrH+yrYIDyIg/xVbkT6PUm8XKzXC/3Idfco2aaFUoF+ObGoHqPzR TvwjlT74hTfzeMND7AF+hS+qTqnpx0wiuLjB3dxUPa/Y8DqAuvoR0XTkfFZqd4+/u8O0 EzRw== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr423796igk.41.1355787775756; Mon, 17 Dec 2012 15:42:55 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 15:42:55 -0800 (PST) In-Reply-To: <50CF8C95.3050702@ericsson.com> References: <50CF8C95.3050702@ericsson.com> Date: Tue, 18 Dec 2012 00:42:55 +0100 Message-ID: From: Melvin Carvalho To: Salvatore Loreto Content-Type: multipart/alternative; boundary=14dae9340901c3c7c604d114f02e Cc: webfinger@ietf.org, Barry Leiba , "Murray S. Kucherawy" Subject: Re: [webfinger] consensus declaration on HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 23:43:00 -0000 --14dae9340901c3c7c604d114f02e Content-Type: text/plain; charset=ISO-8859-1 On 17 December 2012 22:20, Salvatore Loreto wrote: > > Thanks everybody for your participation in the "HTTPS only vs > HTTPS-and-HTTP" discussion > and for providing feedback and alternatives. > > In light of the last two weeks mail discussion on the subject, spread > among different threads, > I, as chair responsible for this draft, am declaring rough consensus on > the "HTTPS only" option. > > My reading of the mail discussion is that at this point there is rough > consensus to specify > only WebFinger over HTTPS because > > 1) it does not open room to any unknown and/or not enough analyzed > security risks, > allowing at the same time to finalize and deploy the first version of > WebFinger quite soon > > 2) the work to support plain HTTP, while is recognized to be important > and necessary, > still requires quite a lot of discussions both to > come to an agreement on which approach to use among the different ones > on the table and > to fully investigate all the security aspects and implications. > For those reasons is much better to specify only the secure way in the > first version of WebFinger but at > the same time start to work on the non-secure modes on a separate > document > +1 > > > Salvatore Loreto > > -- > Salvatore Loreto, PhD > www.sloreto.com > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --14dae9340901c3c7c604d114f02e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 22:20, Salvatore Lor= eto <salvatore.loreto@ericsson.com> wrote:

Thanks everybody for your participation in the "HTTPS only vs HTTPS-an= d-HTTP" discussion
and for providing feedback and alternatives.

In light of the last two weeks mail discussion on the subject, spread among= different threads,
I, as chair responsible for this draft, am declaring rough consensus on the= "HTTPS only" option.

My reading of the mail discussion is that at this point there is rough cons= ensus to specify
only WebFinger over HTTPS because

1) it does not open room to any unknown and/or not enough analyzed security= risks,
=A0 =A0 allowing at the same time to finalize and deploy the first version = of WebFinger quite soon

2) the work to support plain HTTP, =A0while is recognized to be important a= nd necessary,
=A0 =A0 still requires quite a lot of discussions =A0both to
=A0 =A0 come to an agreement on which approach to use among the different o= nes on the table and
=A0 =A0 to fully investigate all the security aspects and implications.
=A0 =A0 For those reasons is much better to specify only the secure way in = the first version of WebFinger but at
=A0 =A0 the same time start to work on the non-secure modes on a separate d= ocument

+1
=A0


Salvatore Loreto

--
Salvatore Loreto, PhD
www.sloreto.com
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--14dae9340901c3c7c604d114f02e-- From paulej@packetizer.com Mon Dec 17 23:01:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33221F8AC4 for ; Mon, 17 Dec 2012 23:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LXEtCof1PVQ for ; Mon, 17 Dec 2012 23:01:21 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F20B221F8ABD for ; Mon, 17 Dec 2012 23:01:20 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBI71Iap005682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Dec 2012 02:01:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355814079; bh=rqIBV5ehuZBHQBfmGkoNabJMoUS1PiiAFa6sORJ/NrQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ThfJ8diWQ5lhOqRkg7sS3MCsBWYzqU7x5wGx+NGqcw1KcSfVsHoj7KTtCfNP8sPWe VWBhwgxDm0k0dF/DHsLhqhbN/TdJ+tuaTY079hGzWHytU9rf8C6TvZevf2BumTy7kR 9DxBjO3TpAVODSJ2mWLnGj5tMnTBMWaZ8IV0hisE= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <00ee01cddbe4$0eecaa70$2cc5ff50$@packetizer.com> <028001cddc8b$75b0ac50$611204f0$@packetizer.com> <02ad01cddc9a$149d9b80$3dd8d280$@packetizer.com> In-Reply-To: Date: Tue, 18 Dec 2012 02:01:21 -0500 Message-ID: <006901cddced$7cff5300$76fdf900$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01CDDCC3.942A5C70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgBk3yM2gFLlorYAZrIBocCj3r0zQHzK0s3AWyV0AECZWLKPgGq6vrwmEplt4A= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 07:01:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01CDDCC3.942A5C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Yep, that syntax will work just fine if you want an array. I was thinking only about object syntax. In any case, the JRD syntax is documented in the current WF spec. That's where it will be cast into stone and I don't expect any need for making changes to it once we're finished. We ought not add more complexity to it than is already defined. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Monday, December 17, 2012 4:36 PM To: Paul E. Jones Cc: webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process On 17 December 2012 22:04, Paul E. Jones wrote: Melvin, The JRD spec itself (and I've extracted it out and placed it here for convenience: http://www.packetizer.com/json/jrd/) does not define creating an array of itself. However, programmatically it would be trivial to create an array of JRD objects in virtually any language. WebFinger only deals with a single "subject" at a time. So, the data returned from the server does not need to have multiple sections with a "subject" per section. However, since the "subject" is an element within the JRD, then you can imagine a JSON object like this: { "jrds" : [ { }, { }, { ... } ] } or { "" : { ", { }, ... } Neither are defined, but you can see how JRDs could be used within more complex documents. Sounds great I think all you would need to do is [ { JRD1 }, { JRD2 }, { JRD3 } ] See Example 51 from : http://json-ld.org/spec/latest/json-ld-syntax/ The reason that I asked is that the XML Schema or XRD strictly forbids more than one object. I do not know the rationale for this, because other serializations definitely allow multiple. If JRD can do this, that's a big plus. Thanks for extracting the spec. Do you know who maintains JRD currently? Paul My view is that webfinger should be serialization agnostic and operate using content negotiation. JRD is one of the weaker serializations, imho, and as mark has suggested, if favoured especially it will need greater review, which may take time. Im not sure anyone has ever answered the question as to why has it been consistently favoured? PEJ: It is tightly coupled with the query, but view that as positive. JRD has a limited use. It's not HTML where we're creating elaborate documents. It's a simple data structure that conveys link relations and properties about a "subject". If one wanted to have a more complex document that included multiple "subjects", one could create an array or hash table of JRDs. Such use, though, is entirely outside the scope of WebFinger. I do like use of content negotiation. Nothing precludes that from happening in WF, either, since it is built on top of HTTP. We're just not specifying what would be negotiated. The current text says: I dont know that much about JRD, but I'd just like to double check this point. Are you sure it is possible to create an array of JRDs? My understanding was that in XRD this was forbidden. If it's possible in JRD, that would be a *major* plus, imho, because it would mean that at least *theoretically* the default webfinger serialization is interoperable with the rest of the web. ------=_NextPart_000_006A_01CDDCC3.942A5C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Yep, that syntax will work just fine if you want an array.  I = was thinking only about object syntax.

 

In any case, the JRD syntax is documented in the current WF = spec.  That’s where it will be cast into stone and I = don’t expect any need for making changes to it once we’re = finished.  We ought not add more complexity to it than is already = defined.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Monday, December 17, 2012 4:36 PM
To: Paul E. = Jones
Cc: webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

 

On 17 December 2012 22:04, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

The JRD spec itself (and I’ve extracted it out and placed it = here for convenience: http://www.packetizer.com/json/jrd/) does not = define creating an array of itself.

 

However, programmatically it would be trivial to create an array of = JRD objects in virtually any language.  WebFinger only deals with a = single “subject” at a time.  So, the data returned from = the server does not need to have multiple sections with a = “subject” per section.  However, since the = “subject” is an element within the JRD, then you can imagine = a JSON object like this:

 

{ “jrds” : [ { <jrd1> }, { <jrd2> }, { ... } = ] }

 

or

 

{ “<jrd subject 1>” : { <jrd 1 }, “<jrd = subject 2>”, { <jrd 2> }, ... }

 

Neither are defined, but you can see how JRDs could be used within = more complex documents.


Sounds great

I think all you would need to = do is

[
  { JRD1 },
  { JRD2 },
  { JRD3 = }
]

See Example 51 from :

http://json-ld.or= g/spec/latest/json-ld-syntax/

The reason that I asked is that = the XML Schema or XRD strictly forbids more than one object.  I do = not know the rationale for this, because other serializations definitely = allow multiple. 

If JRD can do this, that's a big = plus.  Thanks for extracting the spec.  Do you know who = maintains JRD currently?
 

 

Paul

My view is = that webfinger should be serialization agnostic and operate using = content negotiation.  JRD is one of the weaker serializations, = imho, and as mark has suggested, if favoured especially it will need = greater review, which may take time.  Im not sure anyone has ever = answered the question as to why has it been consistently = favoured?
 

PEJ: It is tightly coupled with the query, but  view that as = positive.  JRD has a limited use.  It’s not HTML where = we’re creating elaborate documents.  It’s a simple data = structure that conveys link relations and properties about a = “subject”.  If one wanted to have a more complex = document that included multiple “subjects”, one could create = an array or hash table of JRDs.  Such use, though, is entirely = outside the scope of WebFinger.  I do like use of content = negotiation.  Nothing precludes that from happening in WF, either, = since it is built on top of HTTP.  We’re just not specifying = what would be negotiated.  The current text = says:


I dont = know that much about JRD, but I'd just like to double check this = point.  Are you sure it is possible to create an array of = JRDs? 

My understanding was that in XRD this was = forbidden.  If it's possible in JRD, that would be a *major* plus, = imho, because it would mean that at least *theoretically* the default = webfinger serialization is interoperable with the rest of the web.

 

 

------=_NextPart_000_006A_01CDDCC3.942A5C70-- From evan@status.net Tue Dec 18 10:01:41 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A5721F8AC3 for ; Tue, 18 Dec 2012 10:01:41 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W61Sq-AC3ke1 for ; Tue, 18 Dec 2012 10:01:41 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 04FC121F8AB8 for ; Tue, 18 Dec 2012 10:01:40 -0800 (PST) Received: from [10.0.1.34] (unknown [24.53.26.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id C8C028D45A0 for ; Tue, 18 Dec 2012 18:14:20 +0000 (UTC) Message-ID: <50D0AF7D.60809@status.net> Date: Tue, 18 Dec 2012 13:01:33 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <50CF8C95.3050702@ericsson.com> In-Reply-To: <50CF8C95.3050702@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] consensus declaration on HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:01:41 -0000 On 12-12-17 04:20 PM, Salvatore Loreto wrote: > > Thanks everybody for your participation in the "HTTPS only vs > HTTPS-and-HTTP" discussion > and for providing feedback and alternatives. > > In light of the last two weeks mail discussion on the subject, spread > among different threads, > I, as chair responsible for this draft, am declaring rough consensus > on the "HTTPS only" option. > > My reading of the mail discussion is that at this point there is rough > consensus to specify > only WebFinger over HTTPS because > > 1) it does not open room to any unknown and/or not enough analyzed > security risks, > allowing at the same time to finalize and deploy the first version > of WebFinger quite soon > > 2) the work to support plain HTTP, while is recognized to be > important and necessary, > still requires quite a lot of discussions both to > come to an agreement on which approach to use among the different > ones on the table and > to fully investigate all the security aspects and implications. > For those reasons is much better to specify only the secure way in > the first version of WebFinger but at > the same time start to work on the non-secure modes on a separate > document > > > Salvatore Loreto > +1 -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From perpetual-tripper@wwelves.org Tue Dec 18 10:05:58 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C145821E8045 for ; Tue, 18 Dec 2012 10:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBLLrIIlLx+1 for ; Tue, 18 Dec 2012 10:05:58 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2999C21E803D for ; Tue, 18 Dec 2012 10:05:58 -0800 (PST) X-Originating-IP: 217.70.178.135 Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D2779A805E for ; Tue, 18 Dec 2012 19:05:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aarhvNbf22uC for ; Tue, 18 Dec 2012 19:05:45 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 23196A8093 for ; Tue, 18 Dec 2012 19:05:45 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: webfinger In-reply-to: <50CF8C95.3050702@ericsson.com> References: <50CF8C95.3050702@ericsson.com> Date: Tue, 18 Dec 2012 18:05:44 +0000 Message-Id: <1355853921-sup-6527@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Subject: Re: [webfinger] consensus declaration on HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:05:58 -0000 Excerpts from Salvatore Loreto's message of 2012-12-17 21:20:21 +0000: >=20 > Thanks everybody for your participation in the "HTTPS only vs=20 > HTTPS-and-HTTP" discussion > and for providing feedback and alternatives. >=20 > In light of the last two weeks mail discussion on the subject, spread=20 > among different threads, > I, as chair responsible for this draft, am declaring rough consensus on= =20 > the "HTTPS only" option. >=20 > My reading of the mail discussion is that at this point there is rough=20 > consensus to specify > only WebFinger over HTTPS because >=20 > 1) it does not open room to any unknown and/or not enough analyzed=20 > security risks, > allowing at the same time to finalize and deploy the first version= =20 > of WebFinger quite soon >=20 > 2) the work to support plain HTTP, while is recognized to be important= =20 > and necessary, > still requires quite a lot of discussions both to > come to an agreement on which approach to use among the different=20 > ones on the table and > to fully investigate all the security aspects and implications. > For those reasons is much better to specify only the secure way in= =20 > the first version of WebFinger but at > the same time start to work on the non-secure modes on a separate=20 > document +1 From nick@silverbucket.net Tue Dec 18 10:50:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C9121F8ABB for ; Tue, 18 Dec 2012 10:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ+K6m-sC8Mr for ; Tue, 18 Dec 2012 10:50:39 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4621F8AA5 for ; Tue, 18 Dec 2012 10:50:37 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id h1so1066364oag.34 for ; Tue, 18 Dec 2012 10:50:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Ej28BuQmALMJQYO7vTNKOHKhX3QH1a1HNx7sLiB+hkg=; b=iqr1raQLBt37UfsBBLHMtTDOGUvkFxAHIZC4/3ScK0D2Q3HYy19labjaCb9/l8IVrj wefIksfgtUAVIBCzFdTaMQUdkgTgJJyXYPAmqI5xFYlndC7qhzk8kMmKMQcL+a0dGuOl b7y9QmfqFTZqG49uh9/Q7EbxoMvWR64ftmkZ3JzV9SQNHOEDuR8bepaNlVR0X7PKxdy0 5iChQa2UXX5rxcFW0TgWDCgkFLaaZLyYNdW6hENiDRlW3Pl+Qqias8iDwUW5mftpZSNf sWz/Qv3qOHsErUrc683dDjAYxXw/5tfrDpoHKwS/Fo/eRJ39ChlGbfRi1jVg5NsqeHl3 nw/w== X-Received: by 10.182.38.65 with SMTP id e1mr2548668obk.3.1355856637432; Tue, 18 Dec 2012 10:50:37 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mx.google.com with ESMTPS id ag15sm1706352oec.11.2012.12.18.10.50.34 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 10:50:35 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id x4so1016656obh.38 for ; Tue, 18 Dec 2012 10:50:34 -0800 (PST) Received: by 10.182.52.105 with SMTP id s9mr2562719obo.25.1355856634215; Tue, 18 Dec 2012 10:50:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.92.66 with HTTP; Tue, 18 Dec 2012 10:50:04 -0800 (PST) In-Reply-To: <1355853921-sup-6527@heahdk.net> References: <50CF8C95.3050702@ericsson.com> <1355853921-sup-6527@heahdk.net> From: Nick Jennings Date: Tue, 18 Dec 2012 19:50:04 +0100 Message-ID: To: =?UTF-8?B?4piuIGVsZiBQYXZsaWsg4piu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnF1jtAiT0C0IR8+U/Q++OSLW+5k219XfxFq5BI1l8Qhw+IlB+DhaI2qyC71dLCGRH9EC/j Cc: webfinger Subject: Re: [webfinger] consensus declaration on HTTPS only X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:50:40 -0000 +1 On Tue, Dec 18, 2012 at 7:05 PM, =E2=98=AE elf Pavlik =E2=98=AE wrote: > Excerpts from Salvatore Loreto's message of 2012-12-17 21:20:21 +0000: >> >> Thanks everybody for your participation in the "HTTPS only vs >> HTTPS-and-HTTP" discussion >> and for providing feedback and alternatives. >> >> In light of the last two weeks mail discussion on the subject, spread >> among different threads, >> I, as chair responsible for this draft, am declaring rough consensus on >> the "HTTPS only" option. >> >> My reading of the mail discussion is that at this point there is rough >> consensus to specify >> only WebFinger over HTTPS because >> >> 1) it does not open room to any unknown and/or not enough analyzed >> security risks, >> allowing at the same time to finalize and deploy the first version >> of WebFinger quite soon >> >> 2) the work to support plain HTTP, while is recognized to be important >> and necessary, >> still requires quite a lot of discussions both to >> come to an agreement on which approach to use among the different >> ones on the table and >> to fully investigate all the security aspects and implications. >> For those reasons is much better to specify only the secure way in >> the first version of WebFinger but at >> the same time start to work on the non-secure modes on a separate >> document > > +1 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From nick@silverbucket.net Tue Dec 18 11:37:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5BF21E8047 for ; Tue, 18 Dec 2012 11:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLPJEsPME26W for ; Tue, 18 Dec 2012 11:37:04 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 233B721E803C for ; Tue, 18 Dec 2012 11:37:04 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id j6so1085013oag.40 for ; Tue, 18 Dec 2012 11:37:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=k9GAw2tM0P52nk+404w1S3sZeTEdV0vfw9yMlFH2z3I=; b=P88snANsDoChz39wfbJ4FXsG69ZrN5dsk0zA7BkLWOl4ITSASDSdBLaEYisgSb4dio ZcNyR1I7GvKMQPxLvaz1pOc4GDPQT28vbtxnTs+8nYMZpp115aJ5NxaeqQWgEXymmuw5 nGnc4jbL1+GKpa2h8yEQZe44z4HhbbaOjjXaX9PLB6+1R6rU9Q/mVYHuDAFT3VEt9FQN eqeNegRZAlXDAjE2tp++X1zm2UoNBN7/KZOQq4dpFGVwcgD/RqioI4YUsHBgKt4yf5W0 sTDlf/naef2Va+5qCnb8ByR8hcXqSbOd3mrBQbe5AMgweKvCb336mtl3PpBhRkc4tuoP Ulng== X-Received: by 10.182.92.70 with SMTP id ck6mr2670903obb.46.1355859423673; Tue, 18 Dec 2012 11:37:03 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx.google.com with ESMTPS id c4sm1816247oee.0.2012.12.18.11.37.01 (version=SSLv3 cipher=OTHER); Tue, 18 Dec 2012 11:37:02 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id o6so1125355oag.11 for ; Tue, 18 Dec 2012 11:37:00 -0800 (PST) Received: by 10.182.52.105 with SMTP id s9mr2703680obo.25.1355859420616; Tue, 18 Dec 2012 11:37:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.92.66 with HTTP; Tue, 18 Dec 2012 11:36:30 -0800 (PST) In-Reply-To: <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> From: Nick Jennings Date: Tue, 18 Dec 2012 20:36:30 +0100 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmkN0k122nNIbe5sCpruBDBcXm9Spb3U9DbKme8F7XZNTSwubxJUQDtk1ExPgnliqbQkrrO Cc: webfinger@ietf.org, webfinger@googlegroups.com, Melvin Carvalho Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 19:37:05 -0000 On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones wrot= e: > Nick, > >> > PEJ: WebFinger uses any URI scheme. The =E2=80=9Cacct=E2=80=9D scheme= is just one of >> > them and is not core to the spec now, though there is a statement >> > recommending its use to identify accounts. That is its purpose and >> > the =E2=80=9Cacct=E2=80=9D URI, and it=E2=80=99s a valid purpose. The= one example I like to >> > give is =E2=80=9CHow do we identify an account at Twitter?=E2=80=9D T= here is no >> > email, so =E2=80=9Cmailto=E2=80=9D is not the right URI. A user has a= n account at any >> > service provider and the =E2=80=9Cacct=E2=80=9D URI would identify the= account, not >> > the particular service at the service provider (e.g., email, XMPP, or >> whatever). >> > >> >> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm not >> missing something. >> >> Maybe I don't fully understand the various use-cases, but it seems like >> you are saying that when querying a 'resource', the value does NOT need >> to be prefixed with acct (or anything). I know there's the idea that at >> some point another type of resource could be identified as relevant and >> so that was the argument for having the 'acct' prefix. >> However your wording suggests that even 'acct' is not needed. So >> someone's WF service could accept 'resource=3Dbob' and not >> 'resource=3Dacct:bob@example.com' and it would still be a compliant WF >> service? If true, it seems like there could be a lot of room for >> uncertainty in query format and client libraries would have to try a >> number of different value formats. > > What the spec says is that any URI may be queried. That's what I meant. = The protocol is not designed to be used only with "acct:". One may query = WF using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" or= "urn:". Obviously, URI schemes that do not have domain names present issu= es, but that it's certainly possible and I suspect there would be an agreed= client/server relationship. > > My own server code actually will accept just "paulej@packetizer.com", for= example. If it sees that, it assumes the requestor wants "acct:paulej@pac= ketizer.com" and returns the results from the database for the "acct:" URI.= However, the "subject" is just the bare "paulej@packetizer.com" and the "= acct:" URI is inserted into the response as an alias. However, none of tha= t is in the spec. I did that long ago, because Blaine preferred to not req= uire a URI scheme for user@domain forms. > >> Another thing, in regards to the twitter example you gave. What's to >> differentiate a user of twitter and an employee of twitter? >> >> There could be a user '@janice' and an employee 'janice@twitter.com', >> who may be different people. As I understand it, in your example, these >> different accounts would be queried in the same way. >> >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com > > Users and employees must have different values within the scope of= the domain (or sub-domain). Some time ago, somebody mentioned that they h= ave a domain with user accounts and employees where the user account names = did clash with employee names. I don't have a solution for that. Personal= ly, I think that's an unfortunate situation to be in. > > On my own web site, I run phpBB. There are user accounts. So, I can app= reciate how people get into that situation. However, I placed the discussi= on forms at forums.packetizer.com and so if the phpBB software ever support= ed WebFinger (hmmmm... more holiday coding opportunities) then I would expe= ct it to respond only to acct:@forums.packetizer.com. That would be = perfectly fine and would avoid the name clash. WF does not require queries= only to the domain. Queries can be sent to any appropriate host within th= e domain. > >> Am I misunderstanding? Or does this create a problem. > > There are potential issues for domain owners who have allocated the same = user identifier to more than one person on the same domain or sub-domain. = Domain owners will have to address that before deploying WF. > Hi Paul, I've been giving this some more thought, if the person running the WF service can make up their own system of identifying users (whatever works for them), then in order to write a robust WF client, you're going to have to do a lot of second guessing. I don't understand why we have 'acct:' if (a) it's not required at all, and (b) it's suggested we use the full 'user@example.com' anyway, however (c) we also don't have to do that... In the case of that twitter example. If they wanted to solve this issue, they might impose a system like: /.host-meta/webfinger?resource=3Djanice@twitter.com ...that gets the record for the employee Janice /.host-meta/webfinger?resource=3Dacct:janice ...that gets the record for the user-account 'janice' In this case 'acct' prefix referring to just the 'webapp' accounts, and not 'admin/employee' accounts. I think a clarification of what to use as the resource value to signify whether we are, querying an email address (used by, for example, and email client, or blog comments). or a user account (used by, for example, phpBB, wordpress, twitter, etc.) would be really helpful. Otherwise we're going to have similar client complexity to the issues we've already discussed regarding using fallback methods. though maybe more complicated because we could have false positives if, for example, janice@twitter.com is queried for a user account but the profile for the employee is returned. Does anyone else see the ambiguity here as a potentially pretty bad problem= ? -nick From jasnell@gmail.com Tue Dec 18 12:22:57 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F4C21E8045 for ; Tue, 18 Dec 2012 12:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3C5+J524aYJ for ; Tue, 18 Dec 2012 12:22:56 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7821E803C for ; Tue, 18 Dec 2012 12:22:56 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id 13so1555222iea.35 for ; Tue, 18 Dec 2012 12:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=dUjvu2s0IQKZfU47vLnEjlMc36rd6jvejoKHfMOpgSc=; b=S2TZHEvydk4qn/B0trc2EBRiIbf6RAqazgmDjKV9/KCORDPGCfpiYx8SpCKjAwe7Xj GdSbYnWLtCRI+4ERakEht+HQ1MZO91ONI4XiKIiJpMBlmouCTg5iLi5bu4YC3/5UGSKI HaHXvgz/R1y4oGJLf8/mlCIBSnoSCvFTIQEQwRjcHjxwmo/fuzQyOVxvZNi0CoLMxmuG TJd9qrSmog/dIri2EAru5pMFZDMfalj0ey5NHK7HM1wSyf9MXnEXLmP2IgYiWo5ewtPb 1/HS8y3Ohb4K0gH6M7lQFznyN34eBBifX3bDzokgHullazd1jSrvxXvhyUgtkuMMu3RG j32Q== Received: by 10.50.178.106 with SMTP id cx10mr4826544igc.24.1355862175817; Tue, 18 Dec 2012 12:22:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Tue, 18 Dec 2012 12:22:34 -0800 (PST) From: James M Snell Date: Tue, 18 Dec 2012 12:22:34 -0800 Message-ID: To: "webfinger@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f5036c85aa18504d1264399 Subject: [webfinger] Additional comments on WebFinger draft X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 20:22:57 -0000 --e89a8f5036c85aa18504d1264399 Content-Type: text/plain; charset=UTF-8 Now that we seem to finally be past the HTTP/HTTPS discussion, some additional non-HTTPS related feedback for the draft... 1. Section 5.2.1 [1] It would be better to define the date-time stamp by referencing RFC3339 or ISO 8601. Those are familiar references. Also, the way things are defined in 5.2.1 currently, it would appear that numeric timezone offsets are not permitted.. which seems wrong and unintentional. See RFC 4287 for an example of how it should be done. [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-5.2.1 2. Section 5.2.5.4 [2] Rather than using simple language tags for the title labels, consider using RFC4647 Language Ranges. Then, instead of defining a special "default" key value, you can use the wildcard range "*" as the default. The difference is subtle but good. For instasnce, { "*": "This is the default", "en-*": "This matches all English-language variants", "fr-*": "This matches all Fresh-language variants", "en-UK": "This matches only UK English" } It's just a better model. [2] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-5.2.5.4 3. Right now the properties object is completely arbitrary. The key names are supposed to be absolute IRI's but no guidance is given at all on how those keys are to be selected and how they are to be used. Is there going to be a registry model? Do people just throw whatever they want in there and hope for the best? What kind of interop issues can we potential expect? It would likely be good to flesh out that detail just a little. 4. Currently, both the resource parameter and subject property values are not strictly limited to absolute URIs. Relative URI paths are permitted. I believe that's an error. - James --e89a8f5036c85aa18504d1264399 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that we seem to f= inally be past the HTTP/HTTPS discussion, some additional non-HTTPS related= feedback for the draft...
=
1. Section 5.2= .1 [1]

It would be bette= r to define the date-time stamp by referencing RFC3339 or ISO 8601. Those a= re familiar references. Also, the way things are defined in 5.2.1 currently= , it would appear that numeric timezone offsets are not permitted.. which s= eems wrong and unintentional. See RFC 4287 for an example of how it should = be done.


2. Section 5.2.5.4 [2]
=

Rather than using simple language tag= s for the title labels, consider using RFC4647 Language Ranges. Then, inste= ad of defining a special "default" key value, you can use the wil= dcard range "*" as the default. The difference is subtle but good= . For instasnce,=C2=A0

{
=C2=A0 "*": "This is the default= ",
=C2=A0 "en-*": &= quot;This matches all English-language variants",
=C2=A0 "fr-*": "Thi= s matches all Fresh-language variants",
=C2=A0 "en-UK": = "This matches only UK English"
}

It's just= a better model.


3. Right now the properties object = is completely arbitrary. The key names are supposed to be absolute IRI'= s but no guidance is given at all on how those keys are to be selected and = how they are to be used. Is there going to be a registry model? Do people j= ust throw whatever they want in there and hope for the best? What kind of i= nterop issues can we potential expect? It would likely be good to flesh out= that detail just a little.

4. Currently, both the resource par= ameter and subject property values are not strictly limited to absolute URI= s. Relative URI paths are permitted. I believe that's an error.<= /div>

- James
--e89a8f5036c85aa18504d1264399-- From laurentwalter.goix@telecomitalia.it Tue Dec 18 14:22:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98A21E8054 for ; Tue, 18 Dec 2012 14:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODw92k1iyVrE for ; Tue, 18 Dec 2012 14:22:10 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 470C121E8039 for ; Tue, 18 Dec 2012 14:22:09 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 18 Dec 2012 23:21:59 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 18 Dec 2012 23:21:59 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" , "Paul E. Jones" Date: Tue, 18 Dec 2012 23:19:56 +0100 Thread-Topic: [webfinger] Possibly speeding up the RFC process Thread-Index: Ac3dVxCdw0+/jmgWQc+3TQugOT/4PAAFS7tA Message-ID: References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Melvin Carvalho Subject: [webfinger] R: Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:22:11 -0000 PiAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KPiBEYTogd2ViZmluZ2VyQGdvb2dsZWdy b3Vwcy5jb20gW21haWx0bzp3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNvbV0gUGVyIGNvbnRvDQo+ IGRpIE5pY2sgSmVubmluZ3MNCj4gSW52aWF0bzogbWFydGVkw6wgMTggZGljZW1icmUgMjAxMiAy MC4zNw0KPiBBOiBQYXVsIEUuIEpvbmVzDQo+IENjOiB3ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNv bTsgd2ViZmluZ2VyQGlldGYub3JnOyBNZWx2aW4gQ2FydmFsaG8NCj4gT2dnZXR0bzogUmU6IFt3 ZWJmaW5nZXJdIFBvc3NpYmx5IHNwZWVkaW5nIHVwIHRoZSBSRkMgcHJvY2Vzcw0KPg0KPiBPbiBN b24sIERlYyAxNywgMjAxMiBhdCA5OjMwIFBNLCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0 aXplci5jb20+IHdyb3RlOg0KPiA+IE5pY2ssDQo+ID4NCj4gPj4gPiBQRUo6IFdlYkZpbmdlciB1 c2VzIGFueSBVUkkgc2NoZW1lLiAgVGhlIOKAnGFjY3TigJ0gc2NoZW1lIGlzIGp1c3Qgb25lIG9m DQo+ID4+ID4gdGhlbSBhbmQgaXMgbm90IGNvcmUgdG8gdGhlIHNwZWMgbm93LCB0aG91Z2ggdGhl cmUgaXMgYSBzdGF0ZW1lbnQNCj4gPj4gPiByZWNvbW1lbmRpbmcgaXRzIHVzZSB0byBpZGVudGlm eSBhY2NvdW50cy4gIFRoYXQgaXMgaXRzIHB1cnBvc2UgYW5kDQo+ID4+ID4gdGhlIOKAnGFjY3Ti gJ0gVVJJLCBhbmQgaXTigJlzIGEgdmFsaWQgcHVycG9zZS4gIFRoZSBvbmUgZXhhbXBsZSBJIGxp a2UgdG8NCj4gPj4gPiBnaXZlIGlzIOKAnEhvdyBkbyB3ZSBpZGVudGlmeSBhbiBhY2NvdW50IGF0 IFR3aXR0ZXI/4oCdICBUaGVyZSBpcyBubw0KPiA+PiA+IGVtYWlsLCBzbyDigJxtYWlsdG/igJ0g aXMgbm90IHRoZSByaWdodCBVUkkuICBBIHVzZXIgaGFzIGFuIGFjY291bnQgYXQgYW55DQo+ID4+ ID4gc2VydmljZSBwcm92aWRlciBhbmQgdGhlIOKAnGFjY3TigJ0gVVJJIHdvdWxkIGlkZW50aWZ5 IHRoZSBhY2NvdW50LCBub3QNCj4gPj4gPiB0aGUgcGFydGljdWxhciBzZXJ2aWNlIGF0IHRoZSBz ZXJ2aWNlIHByb3ZpZGVyIChlLmcuLCBlbWFpbCwgWE1QUCwgb3INCj4gPj4gd2hhdGV2ZXIpLg0K PiA+PiA+DQo+ID4+DQo+ID4+IEhpIFBhdWwsIEkganVzdCB3YW50ZWQgdG8gcnVuIGEgZmV3IHRo b3VnaHRzIGJ5IHlvdSB0byBtYWtlIHN1cmUgSSdtIG5vdA0KPiA+PiBtaXNzaW5nIHNvbWV0aGlu Zy4NCj4gPj4NCj4gPj4gTWF5YmUgSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kIHRoZSB2YXJpb3Vz IHVzZS1jYXNlcywgYnV0IGl0IHNlZW1zIGxpa2UNCj4gPj4geW91IGFyZSBzYXlpbmcgdGhhdCB3 aGVuIHF1ZXJ5aW5nIGEgJ3Jlc291cmNlJywgdGhlIHZhbHVlIGRvZXMgTk9UIG5lZWQNCj4gPj4g dG8gYmUgcHJlZml4ZWQgd2l0aCBhY2N0IChvciBhbnl0aGluZykuIEkga25vdyB0aGVyZSdzIHRo ZSBpZGVhIHRoYXQgYXQNCj4gPj4gc29tZSBwb2ludCBhbm90aGVyIHR5cGUgb2YgcmVzb3VyY2Ug Y291bGQgYmUgaWRlbnRpZmllZCBhcyByZWxldmFudCBhbmQNCj4gPj4gc28gdGhhdCB3YXMgdGhl IGFyZ3VtZW50IGZvciBoYXZpbmcgdGhlICdhY2N0JyBwcmVmaXguDQo+ID4+IEhvd2V2ZXIgeW91 ciB3b3JkaW5nIHN1Z2dlc3RzIHRoYXQgZXZlbiAnYWNjdCcgaXMgbm90IG5lZWRlZC4gU28NCj4g Pj4gc29tZW9uZSdzIFdGIHNlcnZpY2UgY291bGQgYWNjZXB0ICdyZXNvdXJjZT1ib2InIGFuZCBu b3QNCj4gPj4gJ3Jlc291cmNlPWFjY3Q6Ym9iQGV4YW1wbGUuY29tJyBhbmQgaXQgd291bGQgc3Rp bGwgYmUgYSBjb21wbGlhbnQgV0YNCj4gPj4gc2VydmljZT8gSWYgdHJ1ZSwgaXQgc2VlbXMgbGlr ZSB0aGVyZSBjb3VsZCBiZSBhIGxvdCBvZiByb29tIGZvcg0KPiA+PiB1bmNlcnRhaW50eSBpbiBx dWVyeSBmb3JtYXQgYW5kIGNsaWVudCBsaWJyYXJpZXMgd291bGQgaGF2ZSB0byB0cnkgYQ0KPiA+ PiBudW1iZXIgb2YgZGlmZmVyZW50IHZhbHVlIGZvcm1hdHMuDQo+ID4NCj4gPiBXaGF0IHRoZSBz cGVjIHNheXMgaXMgdGhhdCBhbnkgVVJJIG1heSBiZSBxdWVyaWVkLiAgVGhhdCdzIHdoYXQgSSBt ZWFudC4NCj4gVGhlIHByb3RvY29sIGlzIG5vdCBkZXNpZ25lZCB0byBiZSB1c2VkIG9ubHkgd2l0 aCAiYWNjdDoiLiAgT25lIG1heSBxdWVyeSBXRg0KPiB1c2luZyAiaHR0cDoiIChlLmcuLCAiaHR0 cDovL3d3dy5wYXVsZWouY29tLyIpIG9yICJtYWlsdG86IiBvciAidGVsOiIgb3INCj4gInVybjoi LiAgT2J2aW91c2x5LCBVUkkgc2NoZW1lcyB0aGF0IGRvIG5vdCBoYXZlIGRvbWFpbiBuYW1lcyBw cmVzZW50IGlzc3VlcywNCj4gYnV0IHRoYXQgaXQncyBjZXJ0YWlubHkgcG9zc2libGUgYW5kIEkg c3VzcGVjdCB0aGVyZSB3b3VsZCBiZSBhbiBhZ3JlZWQNCj4gY2xpZW50L3NlcnZlciByZWxhdGlv bnNoaXAuDQo+ID4NCj4gPiBNeSBvd24gc2VydmVyIGNvZGUgYWN0dWFsbHkgd2lsbCBhY2NlcHQg anVzdCAicGF1bGVqQHBhY2tldGl6ZXIuY29tIiwgZm9yDQo+IGV4YW1wbGUuICBJZiBpdCBzZWVz IHRoYXQsIGl0IGFzc3VtZXMgdGhlIHJlcXVlc3RvciB3YW50cw0KPiAiYWNjdDpwYXVsZWpAcGFj a2V0aXplci5jb20iIGFuZCByZXR1cm5zIHRoZSByZXN1bHRzIGZyb20gdGhlIGRhdGFiYXNlIGZv ciB0aGUNCj4gImFjY3Q6IiBVUkkuICBIb3dldmVyLCB0aGUgInN1YmplY3QiIGlzIGp1c3QgdGhl IGJhcmUgInBhdWxlakBwYWNrZXRpemVyLmNvbSINCj4gYW5kIHRoZSAiYWNjdDoiIFVSSSBpcyBp bnNlcnRlZCBpbnRvIHRoZSByZXNwb25zZSBhcyBhbiBhbGlhcy4gIEhvd2V2ZXIsIG5vbmUNCj4g b2YgdGhhdCBpcyBpbiB0aGUgc3BlYy4gIEkgZGlkIHRoYXQgbG9uZyBhZ28sIGJlY2F1c2UgQmxh aW5lIHByZWZlcnJlZCB0byBub3QNCj4gcmVxdWlyZSBhIFVSSSBzY2hlbWUgZm9yIHVzZXJAZG9t YWluIGZvcm1zLg0KPiA+DQo+ID4+IEFub3RoZXIgdGhpbmcsIGluIHJlZ2FyZHMgdG8gdGhlIHR3 aXR0ZXIgZXhhbXBsZSB5b3UgZ2F2ZS4gV2hhdCdzIHRvDQo+ID4+IGRpZmZlcmVudGlhdGUgYSB1 c2VyIG9mIHR3aXR0ZXIgYW5kIGFuIGVtcGxveWVlIG9mIHR3aXR0ZXI/DQo+ID4+DQo+ID4+IFRo ZXJlIGNvdWxkIGJlIGEgdXNlciAnQGphbmljZScgYW5kIGFuIGVtcGxveWVlICdqYW5pY2VAdHdp dHRlci5jb20nLA0KPiA+PiB3aG8gbWF5IGJlIGRpZmZlcmVudCBwZW9wbGUuIEFzIEkgdW5kZXJz dGFuZCBpdCwgaW4geW91ciBleGFtcGxlLCB0aGVzZQ0KPiA+PiBkaWZmZXJlbnQgYWNjb3VudHMg d291bGQgYmUgcXVlcmllZCBpbiB0aGUgc2FtZSB3YXkuDQo+ID4+DQo+ID4+IC8uaG9zdC1tZXRh L3dlYmZpbmdlcj9yZXNvdXJjZT1hY2N0OmphbmljZUB0d2l0dGVyLmNvbQ0KPiA+DQo+ID4gVXNl cnMgYW5kIGVtcGxveWVlcyBtdXN0IGhhdmUgZGlmZmVyZW50IDx1c2VyPiB2YWx1ZXMgd2l0aGlu IHRoZSBzY29wZSBvZg0KPiB0aGUgZG9tYWluIChvciBzdWItZG9tYWluKS4gIFNvbWUgdGltZSBh Z28sIHNvbWVib2R5IG1lbnRpb25lZCB0aGF0IHRoZXkgaGF2ZQ0KPiBhIGRvbWFpbiB3aXRoIHVz ZXIgYWNjb3VudHMgYW5kIGVtcGxveWVlcyB3aGVyZSB0aGUgdXNlciBhY2NvdW50IG5hbWVzIGRp ZA0KPiBjbGFzaCB3aXRoIGVtcGxveWVlIG5hbWVzLiAgSSBkb24ndCBoYXZlIGEgc29sdXRpb24g Zm9yIHRoYXQuICBQZXJzb25hbGx5LCBJDQo+IHRoaW5rIHRoYXQncyBhbiB1bmZvcnR1bmF0ZSBz aXR1YXRpb24gdG8gYmUgaW4uDQo+ID4NCj4gPiBPbiBteSBvd24gd2ViIHNpdGUsIEkgcnVuIHBo cEJCLiAgVGhlcmUgYXJlIHVzZXIgYWNjb3VudHMuICBTbywgSSBjYW4NCj4gYXBwcmVjaWF0ZSBo b3cgcGVvcGxlIGdldCBpbnRvIHRoYXQgc2l0dWF0aW9uLiAgSG93ZXZlciwgSSBwbGFjZWQgdGhl DQo+IGRpc2N1c3Npb24gZm9ybXMgYXQgZm9ydW1zLnBhY2tldGl6ZXIuY29tIGFuZCBzbyBpZiB0 aGUgcGhwQkIgc29mdHdhcmUgZXZlcg0KPiBzdXBwb3J0ZWQgV2ViRmluZ2VyIChobW1tbS4uLiBt b3JlIGhvbGlkYXkgY29kaW5nIG9wcG9ydHVuaXRpZXMpIHRoZW4gSSB3b3VsZA0KPiBleHBlY3Qg aXQgdG8gcmVzcG9uZCBvbmx5IHRvIGFjY3Q6PHVzZXI+QGZvcnVtcy5wYWNrZXRpemVyLmNvbS4g IFRoYXQgd291bGQgYmUNCj4gcGVyZmVjdGx5IGZpbmUgYW5kIHdvdWxkIGF2b2lkIHRoZSBuYW1l IGNsYXNoLiAgV0YgZG9lcyBub3QgcmVxdWlyZSBxdWVyaWVzDQo+IG9ubHkgdG8gdGhlIGRvbWFp bi4gIFF1ZXJpZXMgY2FuIGJlIHNlbnQgdG8gYW55IGFwcHJvcHJpYXRlIGhvc3Qgd2l0aGluIHRo ZQ0KPiBkb21haW4uDQo+ID4NCj4gPj4gQW0gSSBtaXN1bmRlcnN0YW5kaW5nPyBPciBkb2VzIHRo aXMgY3JlYXRlIGEgcHJvYmxlbS4NCj4gPg0KPiA+IFRoZXJlIGFyZSBwb3RlbnRpYWwgaXNzdWVz IGZvciBkb21haW4gb3duZXJzIHdobyBoYXZlIGFsbG9jYXRlZCB0aGUgc2FtZQ0KPiB1c2VyIGlk ZW50aWZpZXIgdG8gbW9yZSB0aGFuIG9uZSBwZXJzb24gb24gdGhlIHNhbWUgZG9tYWluIG9yIHN1 Yi1kb21haW4uDQo+IERvbWFpbiBvd25lcnMgd2lsbCBoYXZlIHRvIGFkZHJlc3MgdGhhdCBiZWZv cmUgZGVwbG95aW5nIFdGLg0KPiA+DQo+DQo+IEhpIFBhdWwsDQo+DQo+IEkndmUgYmVlbiBnaXZp bmcgdGhpcyBzb21lIG1vcmUgdGhvdWdodCwgaWYgdGhlIHBlcnNvbiBydW5uaW5nIHRoZSBXRg0K PiBzZXJ2aWNlIGNhbiBtYWtlIHVwIHRoZWlyIG93biBzeXN0ZW0gb2YgaWRlbnRpZnlpbmcgdXNl cnMgKHdoYXRldmVyDQo+IHdvcmtzIGZvciB0aGVtKSwgdGhlbiBpbiBvcmRlciB0byB3cml0ZSBh IHJvYnVzdCBXRiBjbGllbnQsIHlvdSdyZQ0KPiBnb2luZyB0byBoYXZlIHRvIGRvIGEgbG90IG9m IHNlY29uZCBndWVzc2luZy4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeQ0KPiB3ZSBoYXZlICdhY2N0 OicgaWYgKGEpIGl0J3Mgbm90IHJlcXVpcmVkIGF0IGFsbCwgYW5kIChiKSBpdCdzDQo+IHN1Z2dl c3RlZCB3ZSB1c2UgdGhlIGZ1bGwgJ3VzZXJAZXhhbXBsZS5jb20nICBhbnl3YXksIGhvd2V2ZXIg KGMpIHdlDQo+IGFsc28gZG9uJ3QgaGF2ZSB0byBkbyB0aGF0Li4uDQo+DQo+IEluIHRoZSBjYXNl IG9mIHRoYXQgdHdpdHRlciBleGFtcGxlLiBJZiB0aGV5IHdhbnRlZCB0byBzb2x2ZSB0aGlzDQo+ IGlzc3VlLCB0aGV5IG1pZ2h0IGltcG9zZSBhIHN5c3RlbSBsaWtlOg0KPg0KPiAvLmhvc3QtbWV0 YS93ZWJmaW5nZXI/cmVzb3VyY2U9amFuaWNlQHR3aXR0ZXIuY29tDQo+DQo+IC4uLnRoYXQgZ2V0 cyB0aGUgcmVjb3JkIGZvciB0aGUgZW1wbG95ZWUgSmFuaWNlDQo+DQo+IC8uaG9zdC1tZXRhL3dl YmZpbmdlcj9yZXNvdXJjZT1hY2N0OmphbmljZQ0KPg0KPiAuLi50aGF0IGdldHMgdGhlIHJlY29y ZCBmb3IgdGhlIHVzZXItYWNjb3VudCAnamFuaWNlJw0KPg0KPiBJbiB0aGlzIGNhc2UgJ2FjY3Qn IHByZWZpeCByZWZlcnJpbmcgdG8ganVzdCB0aGUgJ3dlYmFwcCcgYWNjb3VudHMsDQo+IGFuZCBu b3QgJ2FkbWluL2VtcGxveWVlJyBhY2NvdW50cy4NCj4NCj4gSSB0aGluayBhIGNsYXJpZmljYXRp b24gb2Ygd2hhdCB0byB1c2UgYXMgdGhlIHJlc291cmNlIHZhbHVlIHRvDQo+IHNpZ25pZnkgd2hl dGhlciB3ZSBhcmUsIHF1ZXJ5aW5nIGFuIGVtYWlsIGFkZHJlc3MgKHVzZWQgYnksIGZvcg0KPiBl eGFtcGxlLCBhbmQgZW1haWwgY2xpZW50LCBvciBibG9nIGNvbW1lbnRzKS4gb3IgYSB1c2VyIGFj Y291bnQgKHVzZWQNCj4gYnksIGZvciBleGFtcGxlLCBwaHBCQiwgd29yZHByZXNzLCB0d2l0dGVy LCBldGMuKSB3b3VsZCBiZSByZWFsbHkNCj4gaGVscGZ1bC4NCj4NCj4gT3RoZXJ3aXNlIHdlJ3Jl IGdvaW5nIHRvIGhhdmUgc2ltaWxhciBjbGllbnQgY29tcGxleGl0eSB0byB0aGUgaXNzdWVzDQo+ IHdlJ3ZlIGFscmVhZHkgZGlzY3Vzc2VkIHJlZ2FyZGluZyB1c2luZyBmYWxsYmFjayBtZXRob2Rz LiB0aG91Z2ggbWF5YmUNCj4gbW9yZSBjb21wbGljYXRlZCBiZWNhdXNlIHdlIGNvdWxkIGhhdmUg ZmFsc2UgcG9zaXRpdmVzIGlmLCBmb3INCj4gZXhhbXBsZSwgamFuaWNlQHR3aXR0ZXIuY29tIGlz IHF1ZXJpZWQgZm9yIGEgdXNlciBhY2NvdW50IGJ1dCB0aGUNCj4gcHJvZmlsZSBmb3IgdGhlIGVt cGxveWVlIGlzIHJldHVybmVkLg0KPg0KPiBEb2VzIGFueW9uZSBlbHNlIHNlZSB0aGUgYW1iaWd1 aXR5IGhlcmUgYXMgYSBwb3RlbnRpYWxseSBwcmV0dHkgYmFkIHByb2JsZW0/DQoNCkkgcGVyc29u YWxseSBkb24ndCBzZWUgdGhlIGlzc3VlIGhlcmUuIEZhY2Vib29rIHVzZXMgZGlmZmVyZW50IGRv bWFpbnMgZm9yIHRoZWlyIHVzZXJzIHZzIHRoZWlyIGVtcGxveWVzcy4gSXQncyB1bmZvcnR1bmF0 ZSBpZiB0aXR0ZXIgZG8gbm90IGRvZXMgdGhpcyBidXQgaSB0d2FzIHNhaWQgbWFueSB0aW1lcyBp biB0aGUgcGFzdCBvbiB0aGlzIGxpc3QgdGhhdCBhY2N0OiBhZGRyZXNzZXMgd2l0aCB0aGUgc2Ft ZSB2YWx1ZSB0aGFuIG1haWx0bzogYWRkcmVzc2VzIG1heSBhY3R1YWxseSBub3QgYmUgcmVsYXRl ZCB0byB0aGUgc2FtZSBwZXJzb24uIChhbHRob3VnaCBpdCB3b3VsZCBtYWtlIHNlbnNlLCB0ZWNo bmljYWxseSB0aGVyZSBpcyBubyBiaW5kaW5nIGZvciB0aGlzKS4NCkkgd291bGRuJ3QgZW50ZXIg dGhlIGRlYmF0ZSBvZiB3aG8ncyByZXByZXNlbnRlZCBiZWhpbmQgYSBzcGVjaWZpYyBVUkkuIEl0 IGlzIHVwIHRvIHRoZSBkb21haW4gYWRtaW4gdG8gbWFuYWdlIHRoZSBhY2NvdW50IG5hbWVzcGFj ZS4gQ291bGQgeW91IGJldHRlciBjbGFyaWZ5IHlvdXIgaXNzdWUgaGVyZT8NCg0KUmUgdGhlIGFj Y3Q6IFVSSSBzY2hlbWUgSSBkbyBzdXBwb3J0IFBhdWwncyB2aWV3IHRoYXQgYXQgdGhpcyBzdGFn ZSB0aGVyZSBpcyBubyBVUkktd2F5IG9mIGlkZW50aWZ5aW5nICp1c2VyIGFjY291bnRzKiBnbG9i YWxseS4gSXQgaXMgYWxyZWFkeSB3aWRlbHkgdXNlZCBpbiBmZWRlcmF0ZWQgc29jaWFsIG5ldHdv cmtzIHRoYXQgd2lsbCBiZWNvbWUgYSBiaWcgY29uc3VtZXIgb2Ygd2ViZmluZ2VyIGV2ZW50dWFs bHkgYW5kIGNvdWxkIGVhc2lseSByZXVzZSB0aGVzZSAiYWNjdDoiIFVSSXMgaW4gYWN0aXZpdHkg c3RyZWFtcyBpbiB0aGUgYWN0b3IvaWQgZmllbGQgKG5vcm1hdGl2ZWx5IGRlZmluZWQgYXMgYW55 VVJJKS4NCg0KVGhpcmQsIHdmIHdhcyBkZXNpZ25lZCBmb3Igc3VwcG9ydGluZyBhbnkgVVJJIGlu Y2x1ZGluZyBmb3IgZXhhbXBsZSBodHRwOiwgd2hpY2ggYXJlIG5vdCBpbiB0aGUgZm9ybSBvZiB1 c2VyQGRvbWFpbi4gQW5kIGluIGdlbmVyYWwgSSB3b3VsZCByZWNvbW1lbmQgdGhhdCBhbiBpZXRm IHNwZWMgZm9ybWFsbHkgZGVmaW5lIHRoZSAicmVzb3VyY2UiIHBhcmFtZXRlciBhcyBhbnlVUkkg aW5zdGVhZCBvZiBhIGZyZWUtZm9ybSBzdHJpbmcuDQoNCndhbHRlcg0KDQo+IC1uaWNrDQoNClF1 ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVh bHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUg aW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUg cmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBw cmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkg cHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNz ZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVu YXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBz ZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo= From melvincarvalho@gmail.com Tue Dec 18 18:10:15 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FD221F847B for ; Tue, 18 Dec 2012 18:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqlhjBmR0lP2 for ; Tue, 18 Dec 2012 18:10:14 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4093C21F8476 for ; Tue, 18 Dec 2012 18:10:13 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so2000597ieb.9 for ; Tue, 18 Dec 2012 18:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Y0cq4ruzScbuZizbGq+YC68nSiFgSyE4b+iXuRYomU=; b=HoSfctw4jGRZSs2sCH/JY4RzeP0GqSbRYg+waZNN0wJDwa1HmPzOAcpgi5hj1Xdm6v 0/PPBfhVoe/oLx3ovB03vumc2buE3o/zwDEnuig5KmniUyaTNCBc+jIMPBXluSktd7Gc sBZ/fQ92Y5k4Pomf3tpVPBuCWqcAdMdGbw2rEV4ymAz4wQM5ZS1zhWiUHpzjHPt43CdV Sgh3nwzxood6sDpDyFhJ0i7lRGDXhYarUeCmwd2dXsQxg82uneQGmGEreis2+BMSdxFe RS51xP2RrPBXyYoyzXTVMmtXn9SEl832Kp1TEObOpQvuoi/v8Korhd78UjvJUSGvNrbA +1UA== MIME-Version: 1.0 Received: by 10.50.77.230 with SMTP id v6mr5648433igw.11.1355883012743; Tue, 18 Dec 2012 18:10:12 -0800 (PST) Received: by 10.42.61.203 with HTTP; Tue, 18 Dec 2012 18:10:12 -0800 (PST) In-Reply-To: References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> Date: Wed, 19 Dec 2012 03:10:12 +0100 Message-ID: From: Melvin Carvalho To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=e89a8f3ba87f54e3b904d12b1d84 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 02:10:15 -0000 --e89a8f3ba87f54e3b904d12b1d84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 18 December 2012 23:19, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > > -----Messaggio originale----- > > Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] Per > conto > > di Nick Jennings > > Inviato: marted=EC 18 dicembre 2012 20.37 > > A: Paul E. Jones > > Cc: webfinger@googlegroups.com; webfinger@ietf.org; Melvin Carvalho > > Oggetto: Re: [webfinger] Possibly speeding up the RFC process > > > > On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones > wrote: > > > Nick, > > > > > >> > PEJ: WebFinger uses any URI scheme. The =93acct=94 scheme is just= one > of > > >> > them and is not core to the spec now, though there is a statement > > >> > recommending its use to identify accounts. That is its purpose an= d > > >> > the =93acct=94 URI, and it=92s a valid purpose. The one example I= like to > > >> > give is =93How do we identify an account at Twitter?=94 There is = no > > >> > email, so =93mailto=94 is not the right URI. A user has an accoun= t at > any > > >> > service provider and the =93acct=94 URI would identify the account= , not > > >> > the particular service at the service provider (e.g., email, XMPP, > or > > >> whatever). > > >> > > > >> > > >> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm > not > > >> missing something. > > >> > > >> Maybe I don't fully understand the various use-cases, but it seems > like > > >> you are saying that when querying a 'resource', the value does NOT > need > > >> to be prefixed with acct (or anything). I know there's the idea that > at > > >> some point another type of resource could be identified as relevant > and > > >> so that was the argument for having the 'acct' prefix. > > >> However your wording suggests that even 'acct' is not needed. So > > >> someone's WF service could accept 'resource=3Dbob' and not > > >> 'resource=3Dacct:bob@example.com' and it would still be a compliant = WF > > >> service? If true, it seems like there could be a lot of room for > > >> uncertainty in query format and client libraries would have to try a > > >> number of different value formats. > > > > > > What the spec says is that any URI may be queried. That's what I > meant. > > The protocol is not designed to be used only with "acct:". One may > query WF > > using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" o= r > > "urn:". Obviously, URI schemes that do not have domain names present > issues, > > but that it's certainly possible and I suspect there would be an agreed > > client/server relationship. > > > > > > My own server code actually will accept just "paulej@packetizer.com", > for > > example. If it sees that, it assumes the requestor wants > > "acct:paulej@packetizer.com" and returns the results from the database > for the > > "acct:" URI. However, the "subject" is just the bare " > paulej@packetizer.com" > > and the "acct:" URI is inserted into the response as an alias. However= , > none > > of that is in the spec. I did that long ago, because Blaine preferred > to not > > require a URI scheme for user@domain forms. > > > > > >> Another thing, in regards to the twitter example you gave. What's to > > >> differentiate a user of twitter and an employee of twitter? > > >> > > >> There could be a user '@janice' and an employee 'janice@twitter.com'= , > > >> who may be different people. As I understand it, in your example, > these > > >> different accounts would be queried in the same way. > > >> > > >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com > > > > > > Users and employees must have different values within the scop= e > of > > the domain (or sub-domain). Some time ago, somebody mentioned that the= y > have > > a domain with user accounts and employees where the user account names > did > > clash with employee names. I don't have a solution for that. > Personally, I > > think that's an unfortunate situation to be in. > > > > > > On my own web site, I run phpBB. There are user accounts. So, I can > > appreciate how people get into that situation. However, I placed the > > discussion forms at forums.packetizer.com and so if the phpBB software > ever > > supported WebFinger (hmmmm... more holiday coding opportunities) then I > would > > expect it to respond only to acct:@forums.packetizer.com. That > would be > > perfectly fine and would avoid the name clash. WF does not require > queries > > only to the domain. Queries can be sent to any appropriate host within > the > > domain. > > > > > >> Am I misunderstanding? Or does this create a problem. > > > > > > There are potential issues for domain owners who have allocated the > same > > user identifier to more than one person on the same domain or sub-domai= n. > > Domain owners will have to address that before deploying WF. > > > > > > > Hi Paul, > > > > I've been giving this some more thought, if the person running the WF > > service can make up their own system of identifying users (whatever > > works for them), then in order to write a robust WF client, you're > > going to have to do a lot of second guessing. I don't understand why > > we have 'acct:' if (a) it's not required at all, and (b) it's > > suggested we use the full 'user@example.com' anyway, however (c) we > > also don't have to do that... > > > > In the case of that twitter example. If they wanted to solve this > > issue, they might impose a system like: > > > > /.host-meta/webfinger?resource=3Djanice@twitter.com > > > > ...that gets the record for the employee Janice > > > > /.host-meta/webfinger?resource=3Dacct:janice > > > > ...that gets the record for the user-account 'janice' > > > > In this case 'acct' prefix referring to just the 'webapp' accounts, > > and not 'admin/employee' accounts. > > > > I think a clarification of what to use as the resource value to > > signify whether we are, querying an email address (used by, for > > example, and email client, or blog comments). or a user account (used > > by, for example, phpBB, wordpress, twitter, etc.) would be really > > helpful. > > > > Otherwise we're going to have similar client complexity to the issues > > we've already discussed regarding using fallback methods. though maybe > > more complicated because we could have false positives if, for > > example, janice@twitter.com is queried for a user account but the > > profile for the employee is returned. > > > > Does anyone else see the ambiguity here as a potentially pretty bad > problem? > > I personally don't see the issue here. Facebook uses different domains fo= r > their users vs their employess. It's unfortunate if titter do not does th= is > but i twas said many times in the past on this list that acct: addresses > with the same value than mailto: addresses may actually not be related to > the same person. (although it would make sense, technically there is no > binding for this). > I wouldn't enter the debate of who's represented behind a specific URI. I= t > is up to the domain admin to manage the account namespace. Could you bett= er > clarify your issue here? > > Re the acct: URI scheme I do support Paul's view that at this stage there > is no URI-way of identifying *user accounts* globally. It is already wide= ly > used in federated social networks that will become a big consumer of > webfinger eventually and could easily reuse these "acct:" URIs in activit= y > streams in the actor/id field (normatively defined as anyURI). > > Third, wf was designed for supporting any URI including for example http:= , > which are not in the form of user@domain. And in general I would > recommend that an ietf spec formally define the "resource" parameter as > anyURI instead of a free-form string. > Taking your example of http:, how might this work? > > walter > > > -nick > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > --e89a8f3ba87f54e3b904d12b1d84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 18 December 2012 23:19, Goix Laurent = Walter <laurentwalter.goix@telecomitalia.it> wrote:
> -----Messaggio originale-----
> Da: webfinger@googlegrou= ps.com [mailto:webfinger@= googlegroups.com] Per conto
> di Nick Jennings
> Inviato: marted=EC 18 dicembre 2012 20.37
> A: Paul E. Jones
> Cc: webfinger@googlegrou= ps.com; webfinger@ietf.org; M= elvin Carvalho
> Oggetto: Re: [webfinger] Possibly speeding up the RFC process
>
> On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones <paulej@packetizer.com> wrote:
> > Nick,
> >
> >> > PEJ: WebFinger uses any URI scheme. =A0The =93acct=94 sc= heme is just one of
> >> > them and is not core to the spec now, though there is a = statement
> >> > recommending its use to identify accounts. =A0That is it= s purpose and
> >> > the =93acct=94 URI, and it=92s a valid purpose. =A0The o= ne example I like to
> >> > give is =93How do we identify an account at Twitter?=94 = =A0There is no
> >> > email, so =93mailto=94 is not the right URI. =A0A user h= as an account at any
> >> > service provider and the =93acct=94 URI would identify t= he account, not
> >> > the particular service at the service provider (e.g., em= ail, XMPP, or
> >> whatever).
> >> >
> >>
> >> Hi Paul, I just wanted to run a few thoughts by you to make s= ure I'm not
> >> missing something.
> >>
> >> Maybe I don't fully understand the various use-cases, but= it seems like
> >> you are saying that when querying a 'resource', the v= alue does NOT need
> >> to be prefixed with acct (or anything). I know there's th= e idea that at
> >> some point another type of resource could be identified as re= levant and
> >> so that was the argument for having the 'acct' prefix= .
> >> However your wording suggests that even 'acct' is not= needed. So
> >> someone's WF service could accept 'resource=3Dbob'= ; and not
> >> 'resource=3Dacc= t:bob@example.com' and it would still be a compliant WF
> >> service? If true, it seems like there could be a lot of room = for
> >> uncertainty in query format and client libraries would have t= o try a
> >> number of different value formats.
> >
> > What the spec says is that any URI may be queried. =A0That's = what I meant.
> The protocol is not designed to be used only with "acct:". = =A0One may query WF
> using "http:" (e.g., "http://www.paulej.com/") or "mailto:"= ; or "tel:" or
> "urn:". =A0Obviously, URI schemes that do not have domain na= mes present issues,
> but that it's certainly possible and I suspect there would be an a= greed
> client/server relationship.
> >
> > My own server code actually will accept just "paulej@packetizer.com", for
> example. =A0If it sees that, it assumes the requestor wants
> "acct:paulej@pack= etizer.com" and returns the results from the database for the
> "acct:" URI. =A0However, the "subject" is just the= bare "paulej@packetizer.com<= /a>"
> and the "acct:" URI is inserted into the response as an alia= s. =A0However, none
> of that is in the spec. =A0I did that long ago, because Blaine preferr= ed to not
> require a URI scheme for user@domain forms.
> >
> >> Another thing, in regards to the twitter example you gave. Wh= at's to
> >> differentiate a user of twitter and an employee of twitter? > >>
> >> There could be a user '@janice' and an employee '= janice@twitter.com',
> >> who may be different people. As I understand it, in your exam= ple, these
> >> different accounts would be queried in the same way.
> >>
> >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com
> >
> > Users and employees must have different <user> values withi= n the scope of
> the domain (or sub-domain). =A0Some time ago, somebody mentioned that = they have
> a domain with user accounts and employees where the user account names= did
> clash with employee names. =A0I don't have a solution for that. = =A0Personally, I
> think that's an unfortunate situation to be in.
> >
> > On my own web site, I run phpBB. =A0There are user accounts. =A0S= o, I can
> appreciate how people get into that situation. =A0However, I placed th= e
> discussion forms at forums.packetizer.com and so if the phpBB software ever
> supported WebFinger (hmmmm... more holiday coding opportunities) then = I would
> expect it to respond only to acct:<user>@forums.packetizer.com. =A0That woul= d be
> perfectly fine and would avoid the name clash. =A0WF does not require = queries
> only to the domain. =A0Queries can be sent to any appropriate host wit= hin the
> domain.
> >
> >> Am I misunderstanding? Or does this create a problem.
> >
> > There are potential issues for domain owners who have allocated t= he same
> user identifier to more than one person on the same domain or sub-doma= in.
> Domain owners will have to address that before deploying WF.
> >
>
> Hi Paul,
>
> I've been giving this some more thought, if the person running the= WF
> service can make up their own system of identifying users (whatever > works for them), then in order to write a robust WF client, you're=
> going to have to do a lot of second guessing. I don't understand w= hy
> we have 'acct:' if (a) it's not required at all, and (b) i= t's
> suggested we use the full 'use= r@example.com' =A0anyway, however (c) we
> also don't have to do that...
>
> In the case of that twitter example. If they wanted to solve this
> issue, they might impose a system like:
>
> /.host-meta/webfinger?resource=3Djanice@twitter.com
>
> ...that gets the record for the employee Janice
>
> /.host-meta/webfinger?resource=3Dacct:janice
>
> ...that gets the record for the user-account 'janice'
>
> In this case 'acct' prefix referring to just the 'webapp&#= 39; accounts,
> and not 'admin/employee' accounts.
>
> I think a clarification of what to use as the resource value to
> signify whether we are, querying an email address (used by, for
> example, and email client, or blog comments). or a user account (used<= br> > by, for example, phpBB, wordpress, twitter, etc.) would be really
> helpful.
>
> Otherwise we're going to have similar client complexity to the iss= ues
> we've already discussed regarding using fallback methods. though m= aybe
> more complicated because we could have false positives if, for
> example, janice@twitter.com = is queried for a user account but the
> profile for the employee is returned.
>
> Does anyone else see the ambiguity here as a potentially pretty bad pr= oblem?

I personally don't see the issue here. Facebook uses differ= ent domains for their users vs their employess. It's unfortunate if tit= ter do not does this but i twas said many times in the past on this list th= at acct: addresses with the same value than mailto: addresses may actually = not be related to the same person. (although it would make sense, technical= ly there is no binding for this).
I wouldn't enter the debate of who's represented behind a specific = URI. It is up to the domain admin to manage the account namespace. Could yo= u better clarify your issue here?

Re the acct: URI scheme I do support Paul's view that at this stage the= re is no URI-way of identifying *user accounts* globally. It is already wid= ely used in federated social networks that will become a big consumer of we= bfinger eventually and could easily reuse these "acct:" URIs in a= ctivity streams in the actor/id field (normatively defined as anyURI).

Third, wf was designed for supporting any URI including for example http:, = which are not in the form of user@domain. And in general I would recommend = that an ietf spec formally define the "resource" parameter as any= URI instead of a free-form string.

Taking your example of http:, how might this work?=A0

walter

> -nick

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.


--e89a8f3ba87f54e3b904d12b1d84-- From paulej@packetizer.com Tue Dec 18 20:39:49 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18DF21F8574 for ; Tue, 18 Dec 2012 20:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syMh+riPgsHg for ; Tue, 18 Dec 2012 20:39:49 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E9BDB21F8570 for ; Tue, 18 Dec 2012 20:39:48 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBJ4djPd031351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Dec 2012 23:39:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355891986; bh=rT2PUT+zGSqZPu0DOgJ2shPcNWBc71Ctgm3wSBOIvHk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lBYsKTYwkXc2nHAvh1Fypck3ZeZ18DneKrF9P5VXiCcWkNZmt3kBfq4p5zC+6+DbV 6YUJs/L2HMHqAnzGwt6lDlKnzpkUjn0f+d4D4gL2nSzuQj/Apg7WRn5HGhOS/85/Ly xhqzFij7vSDlVBDIJnR9t5ORldjqNanId0Cr2anU= From: "Paul E. Jones" To: "'Nick Jennings'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> In-Reply-To: Date: Tue, 18 Dec 2012 23:39:50 -0500 Message-ID: <018f01cddda2$e2acac60$a8060520$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZCYjsvioA== Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com, 'Melvin Carvalho' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 04:39:49 -0000 Nick, > I've been giving this some more thought, if the person running the WF > service can make up their own system of identifying users (whatever > works for them), then in order to write a robust WF client, you're = going > to have to do a lot of second guessing. I don't understand why we have > 'acct:' if (a) it's not required at all, and (b) it's suggested we use > the full 'user@example.com' anyway, however (c) we also don't have to > do that... (a) It's not required, but I think most people will use it. This refers = to a user's account, where other URIs refer to web pages, devices, phone = numbers, other addressable things on the Internet (b) The user@domain for will be present with acct:, but not with http: = The "resource" being queried is a URI, this we need URI syntax (c) I don't understand (c) > In the case of that twitter example. If they wanted to solve this = issue, > they might impose a system like: >=20 > /.host-meta/webfinger?resource=3Djanice@twitter.com >=20 > ...that gets the record for the employee Janice >=20 > /.host-meta/webfinger?resource=3Dacct:janice >=20 > ...that gets the record for the user-account 'janice' > > In this case 'acct' prefix referring to just the 'webapp' accounts, = and > not 'admin/employee' accounts. That does not make it any clearer to me and I would never encourage that = kind of behavior. I think it's OK to assume "user@domain" is = "acct:user@domain", much like people typing www.example.com into their = browsers, the browsers assume the users meant "http://" at the front. But I would suggest that no URI prefix (which is not even valid, anyway) = is somehow different than "acct:". I would either treat them as equal = on the server or reject the plain "user@domain" form that lacks the URI = scheme. The client is supposed to ensure requests have a URI scheme. Now, before you say "I thought you said the 'acct:' scheme was not = required." It's not, but that's the recommended scheme for account = identifiers. WF provides a response to queries for URIs. Any URI can = be used. We just recommend "acct:" for accounts, but "http:" is = perfectly valid if requesting information about an HTTP URL. =20 > I think a clarification of what to use as the resource value to = signify > whether we are, querying an email address (used by, for example, and > email client, or blog comments). or a user account (used by, for = example, > phpBB, wordpress, twitter, etc.) would be really helpful. We have language in the draft now that makes a recommendation on what to = use. The "acct" scheme is recommended when querying for a user's = account. =20 > Otherwise we're going to have similar client complexity to the issues > we've already discussed regarding using fallback methods. though maybe > more complicated because we could have false positives if, for = example, > janice@twitter.com is queried for a user account but the profile for = the > employee is returned. I'd prefer to not document bare "user@domain" forms since the resource = parameter is always supposed to refer to a URI. Paul From paulej@packetizer.com Tue Dec 18 20:58:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF7421F859D for ; Tue, 18 Dec 2012 20:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahptj5zdUHFk for ; Tue, 18 Dec 2012 20:58:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32821F8597 for ; Tue, 18 Dec 2012 20:58:41 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBJ4wdDa032132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Dec 2012 23:58:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355893120; bh=lwFlYBhL0dMbJ/+ZSqfBMuq7GzWgcuqExE86yImEjrs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=uSFS3HENxBD1Ifmvnr+hakEt8H9/tSwrUfOXwzgFa54vaj44HXfGAtvV1lVm/2ve+ kMInfNvGV/zv8YQ2kKUI+8buKQHYXVdRQx6HOsFXjaUH8vY3IwgmfHa7dmbuaVbS/y OxMQuk1YrP1UIVHWHuGol8udhgim4RfWygMlH4Z8= From: "Paul E. Jones" To: "'Melvin Carvalho'" , "'Goix Laurent Walter'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> In-Reply-To: Date: Tue, 18 Dec 2012 23:58:44 -0500 Message-ID: <019101cddda5$86382060$92a86120$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01CDDD7B.9D63C610" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQJ90ToJmHKKpmA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 04:58:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0192_01CDDD7B.9D63C610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Melvin, =20 Here=92s an example: =20 curl 'https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packe= tizer .com/' =20 This does not return much useful information, but I return a = user-friendly =93Name=94 for the URI. I could include a URL to a site policy = document, have a link relation to a copyright statement, etc. =20 Paul =20 From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]=20 Sent: Tuesday, December 18, 2012 9:10 PM To: Goix Laurent Walter Cc: webfinger@googlegroups.com; Paul E. Jones; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process =20 =20 On 18 December 2012 23:19, Goix Laurent Walter wrote: > -----Messaggio originale----- > Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] Per conto > di Nick Jennings > Inviato: marted=EC 18 dicembre 2012 20.37 > A: Paul E. Jones > Cc: webfinger@googlegroups.com; webfinger@ietf.org; Melvin Carvalho > Oggetto: Re: [webfinger] Possibly speeding up the RFC process > > On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones wrote: > > Nick, > > > >> > PEJ: WebFinger uses any URI scheme. The =93acct=94 scheme is = just one of > >> > them and is not core to the spec now, though there is a statement > >> > recommending its use to identify accounts. That is its purpose = and > >> > the =93acct=94 URI, and it=92s a valid purpose. The one example = I like to > >> > give is =93How do we identify an account at Twitter?=94 There is = no > >> > email, so =93mailto=94 is not the right URI. A user has an = account at any > >> > service provider and the =93acct=94 URI would identify the = account, not > >> > the particular service at the service provider (e.g., email, = XMPP, or > >> whatever). > >> > > >> > >> Hi Paul, I just wanted to run a few thoughts by you to make sure = I'm not > >> missing something. > >> > >> Maybe I don't fully understand the various use-cases, but it seems = like > >> you are saying that when querying a 'resource', the value does NOT = need > >> to be prefixed with acct (or anything). I know there's the idea = that at > >> some point another type of resource could be identified as relevant = and > >> so that was the argument for having the 'acct' prefix. > >> However your wording suggests that even 'acct' is not needed. So > >> someone's WF service could accept 'resource=3Dbob' and not > >> 'resource=3Dacct:bob@example.com ' = and it would still be a compliant WF > >> service? If true, it seems like there could be a lot of room for > >> uncertainty in query format and client libraries would have to try = a > >> number of different value formats. > > > > What the spec says is that any URI may be queried. That's what I = meant. > The protocol is not designed to be used only with "acct:". One may = query WF > using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" = or > "urn:". Obviously, URI schemes that do not have domain names present issues, > but that it's certainly possible and I suspect there would be an = agreed > client/server relationship. > > > > My own server code actually will accept just = "paulej@packetizer.com", for > example. If it sees that, it assumes the requestor wants > "acct:paulej@packetizer.com " = and returns the results from the database for the > "acct:" URI. However, the "subject" is just the bare "paulej@packetizer.com" > and the "acct:" URI is inserted into the response as an alias. = However, none > of that is in the spec. I did that long ago, because Blaine preferred = to not > require a URI scheme for user@domain forms. > > > >> Another thing, in regards to the twitter example you gave. What's = to > >> differentiate a user of twitter and an employee of twitter? > >> > >> There could be a user '@janice' and an employee = 'janice@twitter.com', > >> who may be different people. As I understand it, in your example, = these > >> different accounts would be queried in the same way. > >> > >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com =20 > > > > Users and employees must have different values within the = scope of > the domain (or sub-domain). Some time ago, somebody mentioned that = they have > a domain with user accounts and employees where the user account names = did > clash with employee names. I don't have a solution for that. = Personally, I > think that's an unfortunate situation to be in. > > > > On my own web site, I run phpBB. There are user accounts. So, I = can > appreciate how people get into that situation. However, I placed the > discussion forms at forums.packetizer.com and so if the phpBB software ever > supported WebFinger (hmmmm... more holiday coding opportunities) then = I would > expect it to respond only to acct:@forums.packetizer.com. That would be > perfectly fine and would avoid the name clash. WF does not require queries > only to the domain. Queries can be sent to any appropriate host = within the > domain. > > > >> Am I misunderstanding? Or does this create a problem. > > > > There are potential issues for domain owners who have allocated the = same > user identifier to more than one person on the same domain or = sub-domain. > Domain owners will have to address that before deploying WF. > > > > Hi Paul, > > I've been giving this some more thought, if the person running the WF > service can make up their own system of identifying users (whatever > works for them), then in order to write a robust WF client, you're > going to have to do a lot of second guessing. I don't understand why > we have 'acct:' if (a) it's not required at all, and (b) it's > suggested we use the full 'user@example.com' anyway, however (c) we > also don't have to do that... > > In the case of that twitter example. If they wanted to solve this > issue, they might impose a system like: > > /.host-meta/webfinger?resource=3Djanice@twitter.com > > ...that gets the record for the employee Janice > > /.host-meta/webfinger?resource=3Dacct:janice > > ...that gets the record for the user-account 'janice' > > In this case 'acct' prefix referring to just the 'webapp' accounts, > and not 'admin/employee' accounts. > > I think a clarification of what to use as the resource value to > signify whether we are, querying an email address (used by, for > example, and email client, or blog comments). or a user account (used > by, for example, phpBB, wordpress, twitter, etc.) would be really > helpful. > > Otherwise we're going to have similar client complexity to the issues > we've already discussed regarding using fallback methods. though maybe > more complicated because we could have false positives if, for > example, janice@twitter.com is queried for a user account but the > profile for the employee is returned. > > Does anyone else see the ambiguity here as a potentially pretty bad problem? I personally don't see the issue here. Facebook uses different domains = for their users vs their employess. It's unfortunate if titter do not does = this but i twas said many times in the past on this list that acct: addresses with the same value than mailto: addresses may actually not be related = to the same person. (although it would make sense, technically there is no binding for this). I wouldn't enter the debate of who's represented behind a specific URI. = It is up to the domain admin to manage the account namespace. Could you = better clarify your issue here? Re the acct: URI scheme I do support Paul's view that at this stage = there is no URI-way of identifying *user accounts* globally. It is already widely used in federated social networks that will become a big consumer of webfinger eventually and could easily reuse these "acct:" URIs in = activity streams in the actor/id field (normatively defined as anyURI). Third, wf was designed for supporting any URI including for example = http:, which are not in the form of user@domain. And in general I would = recommend that an ietf spec formally define the "resource" parameter as anyURI = instead of a free-form string. Taking your example of http:, how might this work? =20 walter > -nick Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. = Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati = di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. =20 ------=_NextPart_000_0192_01CDDD7B.9D63C610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Here’s an example:

 

=A0 curl = 'https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packe= tizer.com/'

 

This does not return much useful information, but I return a = user-friendly “Name” for the URI.=A0 I could include a URL = to a site policy document, have a link relation to a copyright = statement, etc.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Tuesday, December 18, 2012 9:10 PM
To: Goix Laurent = Walter
Cc: webfinger@googlegroups.com; Paul E. Jones; = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

 

On 18 December 2012 23:19, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> = wrote:

> -----Messaggio = originale-----
> Da: webfinger@googlegroups.com= [mailto:webfinger@googlegroups.com= ] Per conto
> di Nick Jennings
> Inviato: marted=EC 18 = dicembre 2012 20.37
> A: Paul E. Jones
> Cc: webfinger@googlegroups.com= ; webfinger@ietf.org; Melvin = Carvalho
> Oggetto: Re: [webfinger] Possibly speeding up the RFC = process

>
> On Mon, Dec 17, 2012 at 9:30 = PM, Paul E. Jones <paulej@packetizer.com> = wrote:
> > Nick,
> >
> >> > PEJ: = WebFinger uses any URI scheme.  The “acct” scheme is = just one of
> >> > them and is not core to the spec now, = though there is a statement
> >> > recommending its use = to identify accounts.  That is its purpose and
> >> = > the “acct” URI, and it’s a valid purpose. =  The one example I like to
> >> > give is “How = do we identify an account at Twitter?”  There is no
> = >> > email, so “mailto” is not the right URI. =  A user has an account at any
> >> > service = provider and the “acct” URI would identify the account, = not
> >> > the particular service at the service provider = (e.g., email, XMPP, or
> >> whatever).
> >> = >
> >>
> >> Hi Paul, I just wanted to run a = few thoughts by you to make sure I'm not
> >> missing = something.
> >>
> >> Maybe I don't fully = understand the various use-cases, but it seems like
> >> you = are saying that when querying a 'resource', the value does NOT = need
> >> to be prefixed with acct (or anything). I know = there's the idea that at
> >> some point another type of = resource could be identified as relevant and
> >> so that = was the argument for having the 'acct' prefix.
> >> However = your wording suggests that even 'acct' is not needed. So
> = >> someone's WF service could accept 'resource=3Dbob' and = not
> >> 'resource=3Dacct:bob@example.com' and it = would still be a compliant WF
> >> service? If true, it = seems like there could be a lot of room for
> >> uncertainty = in query format and client libraries would have to try a
> = >> number of different value formats.
> >
> > = What the spec says is that any URI may be queried.  That's what I = meant.
> The protocol is not designed to be used only with = "acct:".  One may query WF
> using = "http:" (e.g., "http://www.paulej.com/") or = "mailto:" or "tel:" or
> "urn:". =  Obviously, URI schemes that do not have domain names present = issues,
> but that it's certainly possible and I suspect there = would be an agreed
> client/server relationship.
> = >
> > My own server code actually will accept just "paulej@packetizer.com", = for
> example.  If it sees that, it assumes the requestor = wants
> "acct:paulej@packetizer.com" and returns the results from the database for the
> = "acct:" URI.  However, the "subject" is just = the bare "paulej@packetizer.com"
= > and the "acct:" URI is inserted into the response as an = alias.  However, none
> of that is in the spec.  I did = that long ago, because Blaine preferred to not
> require a URI = scheme for user@domain forms.
> >
> >> Another = thing, in regards to the twitter example you gave. What's to
> = >> differentiate a user of twitter and an employee of = twitter?
> >>
> >> There could be a user = '@janice' and an employee 'janice@twitter.com',
> = >> who may be different people. As I understand it, in your = example, these
> >> different accounts would be queried in = the same way.
> >>
> >> = /.host-meta/webfinger?resource=3Dacct:janice@twitter.com
= > >
> > Users and employees must have different = <user> values within the scope of
> the domain (or = sub-domain).  Some time ago, somebody mentioned that they = have
> a domain with user accounts and employees where the user = account names did
> clash with employee names.  I don't have = a solution for that.  Personally, I
> think that's an = unfortunate situation to be in.
> >
> > On my own web = site, I run phpBB.  There are user accounts.  So, I = can
> appreciate how people get into that situation. =  However, I placed the
> discussion forms at forums.packetizer.com and so if the phpBB software = ever
> supported WebFinger (hmmmm... more holiday coding = opportunities) then I would
> expect it to respond only to = acct:<user>@forums.packetizer.com.  That would be
> = perfectly fine and would avoid the name clash.  WF does not require = queries
> only to the domain.  Queries can be sent to any = appropriate host within the
> domain.
> >
> = >> Am I misunderstanding? Or does this create a problem.
> = >
> > There are potential issues for domain owners who have = allocated the same
> user identifier to more than one person on = the same domain or sub-domain.
> Domain owners will have to = address that before deploying WF.
> >
>
> Hi = Paul,
>
> I've been giving this some more thought, if the = person running the WF
> service can make up their own system of = identifying users (whatever
> works for them), then in order to = write a robust WF client, you're
> going to have to do a lot of = second guessing. I don't understand why
> we have 'acct:' if (a) = it's not required at all, and (b) it's
> suggested we use the full = 'user@example.com'  anyway, = however (c) we
> also don't have to do that...
>
> In = the case of that twitter example. If they wanted to solve this
> = issue, they might impose a system like:
>
> = /.host-meta/webfinger?resource=3Djanice@twitter.com
>
>= ...that gets the record for the employee Janice
>
> = /.host-meta/webfinger?resource=3Dacct:janice
>
> ...that = gets the record for the user-account 'janice'
>
> In this = case 'acct' prefix referring to just the 'webapp' accounts,
> and = not 'admin/employee' accounts.
>
> I think a clarification = of what to use as the resource value to
> signify whether we are, = querying an email address (used by, for
> example, and email = client, or blog comments). or a user account (used
> by, for = example, phpBB, wordpress, twitter, etc.) would be really
> = helpful.
>
> Otherwise we're going to have similar client = complexity to the issues
> we've already discussed regarding using = fallback methods. though maybe
> more complicated because we could = have false positives if, for
> example, janice@twitter.com is queried for = a user account but the
> profile for the employee is = returned.
>
> Does anyone else see the ambiguity here as a = potentially pretty bad problem?

I personally don't see the issue here. Facebook uses = different domains for their users vs their employess. It's unfortunate = if titter do not does this but i twas said many times in the past on = this list that acct: addresses with the same value than mailto: = addresses may actually not be related to the same person. (although it = would make sense, technically there is no binding for this).
I = wouldn't enter the debate of who's represented behind a specific URI. It = is up to the domain admin to manage the account namespace. Could you = better clarify your issue here?

Re the acct: URI scheme I do = support Paul's view that at this stage there is no URI-way of = identifying *user accounts* globally. It is already widely used in = federated social networks that will become a big consumer of webfinger = eventually and could easily reuse these "acct:" URIs in = activity streams in the actor/id field (normatively defined as = anyURI).

Third, wf was designed for supporting any URI including = for example http:, which are not in the form of user@domain. And in = general I would recommend that an ietf spec formally define the = "resource" parameter as anyURI instead of a free-form = string.


Taking your example = of http:, how might this work?
 


walter

> = -nick

Questo messaggio e i suoi allegati sono indirizzati = esclusivamente alle persone indicate. La diffusione, copia o qualsiasi = altra azione derivante dalla conoscenza di queste informazioni sono = rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al = mittente e di provvedere alla sua distruzione, Grazie.

This = e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, = printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and = advise the sender by return e-mail, = Thanks.

 

------=_NextPart_000_0192_01CDDD7B.9D63C610-- From paulej@packetizer.com Tue Dec 18 23:37:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542221F8A88 for ; Tue, 18 Dec 2012 23:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwneNKcDqkxi for ; Tue, 18 Dec 2012 23:37:53 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 55ACB21F85A3 for ; Tue, 18 Dec 2012 23:37:53 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBJ7bpPB007080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 02:37:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355902672; bh=zaKU14Ao9huPouZZ5mE5FYYPIYsny72QIH0qxhWmuPA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=KG3Hi4oJgkR4/fyez+bo7+/v/ybcwdBD9W/abDzNEal20jOkqyQB3ISY9svtJv51D Iee2b0QLs2bSDEaDet3j3w7kooyB7OA+bBHuKpgtZt/Fo2UcVnkOwkDpJFtt79YCJx aL6kz+oV4D2KzcFiOysWB1dNcuNKt6uz9y8BCmIk= From: "Paul E. Jones" To: "'James M Snell'" , References: In-Reply-To: Date: Wed, 19 Dec 2012 02:37:57 -0500 Message-ID: <01ad01cdddbb$c3d23ad0$4b76b070$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01CDDD91.DAFD4440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE+d/lUhN6iEhAoMV+d78YkfVdzY5k+hWqA Content-Language: en-us Subject: Re: [webfinger] Additional comments on WebFinger draft X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 07:37:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AE_01CDDD91.DAFD4440 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable James, =20 Comments inline: =20 =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of James M Snell Sent: Tuesday, December 18, 2012 3:23 PM To: webfinger@ietf.org Subject: [webfinger] Additional comments on WebFinger draft =20 Now that we seem to finally be past the HTTP/HTTPS discussion, some = additional non-HTTPS related feedback for the draft... =20 1. Section 5.2.1 [1] =20 It would be better to define the date-time stamp by referencing RFC3339 = or ISO 8601. Those are familiar references. Also, the way things are = defined in 5.2.1 currently, it would appear that numeric timezone = offsets are not permitted.. which seems wrong and unintentional. See RFC = 4287 for an example of how it should be done. =20 [1] = http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-5.2.1 =20 PEJ: OK on using the RFC. However, I do not want to allow fractional = seconds or time zones, since that is disallowed in XRD and, = consequentially, in RFC 6415 where JRD was defined. I don=E2=80=99t = want to break compatibility in the data format. =20 2. Section 5.2.5.4 [2] =20 Rather than using simple language tags for the title labels, consider = using RFC4647 Language Ranges. Then, instead of defining a special = "default" key value, you can use the wildcard range "*" as the default. = The difference is subtle but good. For instasnce,=20 =20 { "*": "This is the default", "en-*": "This matches all English-language variants", "fr-*": "This matches all Fresh-language variants", "en-UK": "This matches only UK English" } =20 It's just a better model. =20 [2] = http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-5.2.5.= 4 =20 PEJ: I think we might also be constrained on the language definition, = too. The word =E2=80=9Cdefault=E2=80=9D is defined to mean = =E2=80=9C*=E2=80=9D. We don=E2=80=99t even need =E2=80=9Cen-*=E2=80=9D, = because that=E2=80=99s the same as =E2=80=9Cen=E2=80=9D. So, I = don=E2=80=99t want to change the reference. =20 3. Right now the properties object is completely arbitrary. The key = names are supposed to be absolute IRI's but no guidance is given at all = on how those keys are to be selected and how they are to be used. Is = there going to be a registry model? Do people just throw whatever they = want in there and hope for the best? What kind of interop issues can we = potential expect? It would likely be good to flesh out that detail just = a little. =20 PEJ: I have use for this, though you are correct that it=E2=80=99s not = defined. Just as we need to define WF-specific link relations, we need = to define some properties. One property that I want to define is = =E2=80=9Cname=E2=80=9D =E2=80=93 a friendly name that identifies the = subject. For example: =E2=80=9Chttp://www.ietf.org/ns/name=E2=80=9D : =E2=80=9CJames M. = Snell=E2=80=9D =20 Are there any examples in IETF specs that use namespace URIs like this? = In any case, I don=E2=80=99t want to define them right now, but that is = something I=E2=80=99d like to do as a follow-up to this document. For = the moment, people can throw in whatever they want, much like the many = link relations that have been unofficially adopted thus far under the = webfinger.net domain. =20 4. Currently, both the resource parameter and subject property values = are not strictly limited to absolute URIs. Relative URI paths are = permitted. I believe that's an error. =20 PEJ: These must be absolute per: = http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.subject =20 Paul =20 - James ------=_NextPart_000_01AE_01CDDD91.DAFD4440 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

James,

 

Comments inline:

 

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of James M Snell
Sent: Tuesday, December 18, 2012 = 3:23 PM
To: webfinger@ietf.org
Subject: [webfinger] = Additional comments on WebFinger = draft

 

Now that we seem to finally be past = the HTTP/HTTPS discussion, some additional non-HTTPS related feedback = for the draft...

 

1. Section = 5.2.1 [1]

 

It would be = better to define the date-time stamp by referencing RFC3339 or ISO 8601. = Those are familiar references. Also, the way things are defined in 5.2.1 = currently, it would appear that numeric timezone offsets are not = permitted.. which seems wrong and unintentional. See RFC 4287 for an = example of how it should be done.

 

 

PEJ: OK on using the RFC.=C2=A0 However, I do not want to allow = fractional seconds or time zones, since that is disallowed in XRD and, = consequentially, in RFC 6415 where JRD was defined.=C2=A0 I = don=E2=80=99t want to break compatibility in the data = format.

 

2. Section 5.2.5.4 = [2]

 

Rather than = using simple language tags for the title labels, consider using RFC4647 = Language Ranges. Then, instead of defining a special "default" = key value, you can use the wildcard range "*" as the default. = The difference is subtle but good. For = instasnce, 

 

{

  "*": "This is = the default",

  = "en-*": "This matches all English-language = variants",

  = "fr-*": "This matches all Fresh-language = variants",

  = "en-UK": "This matches only UK = English"

}

 

It's just a = better model.

 

 

PEJ: I think we might also be constrained on the language definition, = too.=C2=A0 The word =E2=80=9Cdefault=E2=80=9D is defined to mean = =E2=80=9C*=E2=80=9D.=C2=A0 We don=E2=80=99t even need = =E2=80=9Cen-*=E2=80=9D, because that=E2=80=99s the same as = =E2=80=9Cen=E2=80=9D.=C2=A0 So, I don=E2=80=99t want to change the = reference.

 

3. Right now the properties object = is completely arbitrary. The key names are supposed to be absolute IRI's = but no guidance is given at all on how those keys are to be selected and = how they are to be used. Is there going to be a registry model? Do = people just throw whatever they want in there and hope for the best? = What kind of interop issues can we potential expect? It would likely be = good to flesh out that detail just a little.

 

PEJ: I have use for this, though you are correct that it=E2=80=99s = not defined.=C2=A0 Just as we need to define WF-specific link relations, = we need to define some properties. =C2=A0One property that I want to = define is =E2=80=9Cname=E2=80=9D =E2=80=93 a friendly name that = identifies the subject.=C2=A0 For example:

=E2=80=9Chttp://www.ietf.org/ns/name=E2=80=9D : =E2=80=9CJames M. = Snell=E2=80=9D

 

Are there any examples in IETF specs that use namespace URIs like = this?=C2=A0 In any case, I don=E2=80=99t want to define them right now, = but that is something I=E2=80=99d like to do as a follow-up to this = document.=C2=A0 For the moment, people can throw in whatever they want, = much like the many link relations that have been unofficially adopted = thus far under the webfinger.net domain.

 

4. = Currently, both the resource parameter and subject property values are = not strictly limited to absolute URIs. Relative URI paths are permitted. = I believe that's an error.

 

PEJ: These must be absolute per: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.subject=

 

Paul

 

- = James

------=_NextPart_000_01AE_01CDDD91.DAFD4440-- From melvincarvalho@gmail.com Wed Dec 19 05:43:31 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0921F850D for ; Wed, 19 Dec 2012 05:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSEIXg3bahPI for ; Wed, 19 Dec 2012 05:43:30 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2869F21F84D1 for ; Wed, 19 Dec 2012 05:43:30 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so2771711ieb.9 for ; Wed, 19 Dec 2012 05:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gcHfGIyXaFiYgUD/arZGof9N40qM5YzkpBPv8dEW1ak=; b=Ny/h96R3DsC0mYD1NjcUztnIWZtUZCNlQYmkji5aizyUviz3b2dp9ME7dIhvexsYo+ F+H1ahWCFtIqZzH6Yb3vZfeCAjl/MJq+sVk3xodV+0qrisiJgAUZsPcC0+RHrNnxV8Sw 2FqrDdkP+4ZWsLfIsb29ecnNpvHotVwf++jly/bwtImGc7lsbdm7oxmAHXFhTWGD5Ueo K4r93sP6WCxWpO6+kR/Y/1vuL0TNhPcTnDyb7TAmzWX+zqjgHKZiatUzCDyH0PMXtRKu SngGVx6qdNc0np702b6MOxIBO6x2EcCdN7uk8m4FPVjrcgsuRZTtSOTi1y5h8IakcVZy s1Ng== MIME-Version: 1.0 Received: by 10.50.77.230 with SMTP id v6mr7041612igw.11.1355924609410; Wed, 19 Dec 2012 05:43:29 -0800 (PST) Received: by 10.42.61.203 with HTTP; Wed, 19 Dec 2012 05:43:29 -0800 (PST) In-Reply-To: <019101cddda5$86382060$92a86120$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <019101cddda5$86382060$92a86120$@packetizer.com> Date: Wed, 19 Dec 2012 14:43:29 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f3ba87fafa73904d134cc91 Cc: webfinger@ietf.org, webfinger@googlegroups.com, Goix Laurent Walter Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:43:32 -0000 --e89a8f3ba87fafa73904d134cc91 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 December 2012 05:58, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Here=92s an example:**** > > ** ** > > curl ' > https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packet= izer.com/ > '**** > > ** ** > > This does not return much useful information, but I return a user-friendl= y > =93Name=94 for the URI. I could include a URL to a site policy document,= have > a link relation to a copyright statement, etc. > I see what you are doing here and it's a neat implementation. I think that if http discovery is in scope of webfinger, then data returned should be consistent with HTTP GET, which is currently the best practice for http discovery, imho. Otherwise there is the potential danger, for things getting out of sync, depending on which discovery method is used. Does that make sense? > **** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Tuesday, December 18, 2012 9:10 PM > *To:* Goix Laurent Walter > *Cc:* webfinger@googlegroups.com; Paul E. Jones; webfinger@ietf.org > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > ** ** > > ** ** > > On 18 December 2012 23:19, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote:**** > > > -----Messaggio originale----- > > Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] Per > conto > > di Nick Jennings > > Inviato: marted=EC 18 dicembre 2012 20.37 > > A: Paul E. Jones > > Cc: webfinger@googlegroups.com; webfinger@ietf.org; Melvin Carvalho > > Oggetto: Re: [webfinger] Possibly speeding up the RFC process**** > > > > > On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones > wrote: > > > Nick, > > > > > >> > PEJ: WebFinger uses any URI scheme. The =93acct=94 scheme is just= one > of > > >> > them and is not core to the spec now, though there is a statement > > >> > recommending its use to identify accounts. That is its purpose an= d > > >> > the =93acct=94 URI, and it=92s a valid purpose. The one example I= like to > > >> > give is =93How do we identify an account at Twitter?=94 There is = no > > >> > email, so =93mailto=94 is not the right URI. A user has an accoun= t at > any > > >> > service provider and the =93acct=94 URI would identify the account= , not > > >> > the particular service at the service provider (e.g., email, XMPP, > or > > >> whatever). > > >> > > > >> > > >> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm > not > > >> missing something. > > >> > > >> Maybe I don't fully understand the various use-cases, but it seems > like > > >> you are saying that when querying a 'resource', the value does NOT > need > > >> to be prefixed with acct (or anything). I know there's the idea that > at > > >> some point another type of resource could be identified as relevant > and > > >> so that was the argument for having the 'acct' prefix. > > >> However your wording suggests that even 'acct' is not needed. So > > >> someone's WF service could accept 'resource=3Dbob' and not > > >> 'resource=3Dacct:bob@example.com' and it would still be a compliant = WF > > >> service? If true, it seems like there could be a lot of room for > > >> uncertainty in query format and client libraries would have to try a > > >> number of different value formats. > > > > > > What the spec says is that any URI may be queried. That's what I > meant. > > The protocol is not designed to be used only with "acct:". One may > query WF > > using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" o= r > > "urn:". Obviously, URI schemes that do not have domain names present > issues, > > but that it's certainly possible and I suspect there would be an agreed > > client/server relationship. > > > > > > My own server code actually will accept just "paulej@packetizer.com", > for > > example. If it sees that, it assumes the requestor wants > > "acct:paulej@packetizer.com" and returns the results from the database > for the > > "acct:" URI. However, the "subject" is just the bare " > paulej@packetizer.com" > > and the "acct:" URI is inserted into the response as an alias. However= , > none > > of that is in the spec. I did that long ago, because Blaine preferred > to not > > require a URI scheme for user@domain forms. > > > > > >> Another thing, in regards to the twitter example you gave. What's to > > >> differentiate a user of twitter and an employee of twitter? > > >> > > >> There could be a user '@janice' and an employee 'janice@twitter.com'= , > > >> who may be different people. As I understand it, in your example, > these > > >> different accounts would be queried in the same way. > > >> > > >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com > > > > > > Users and employees must have different values within the scop= e > of > > the domain (or sub-domain). Some time ago, somebody mentioned that the= y > have > > a domain with user accounts and employees where the user account names > did > > clash with employee names. I don't have a solution for that. > Personally, I > > think that's an unfortunate situation to be in. > > > > > > On my own web site, I run phpBB. There are user accounts. So, I can > > appreciate how people get into that situation. However, I placed the > > discussion forms at forums.packetizer.com and so if the phpBB software > ever > > supported WebFinger (hmmmm... more holiday coding opportunities) then I > would > > expect it to respond only to acct:@forums.packetizer.com. That > would be > > perfectly fine and would avoid the name clash. WF does not require > queries > > only to the domain. Queries can be sent to any appropriate host within > the > > domain. > > > > > >> Am I misunderstanding? Or does this create a problem. > > > > > > There are potential issues for domain owners who have allocated the > same > > user identifier to more than one person on the same domain or sub-domai= n. > > Domain owners will have to address that before deploying WF. > > > > > > > Hi Paul, > > > > I've been giving this some more thought, if the person running the WF > > service can make up their own system of identifying users (whatever > > works for them), then in order to write a robust WF client, you're > > going to have to do a lot of second guessing. I don't understand why > > we have 'acct:' if (a) it's not required at all, and (b) it's > > suggested we use the full 'user@example.com' anyway, however (c) we > > also don't have to do that... > > > > In the case of that twitter example. If they wanted to solve this > > issue, they might impose a system like: > > > > /.host-meta/webfinger?resource=3Djanice@twitter.com > > > > ...that gets the record for the employee Janice > > > > /.host-meta/webfinger?resource=3Dacct:janice > > > > ...that gets the record for the user-account 'janice' > > > > In this case 'acct' prefix referring to just the 'webapp' accounts, > > and not 'admin/employee' accounts. > > > > I think a clarification of what to use as the resource value to > > signify whether we are, querying an email address (used by, for > > example, and email client, or blog comments). or a user account (used > > by, for example, phpBB, wordpress, twitter, etc.) would be really > > helpful. > > > > Otherwise we're going to have similar client complexity to the issues > > we've already discussed regarding using fallback methods. though maybe > > more complicated because we could have false positives if, for > > example, janice@twitter.com is queried for a user account but the > > profile for the employee is returned. > > > > Does anyone else see the ambiguity here as a potentially pretty bad > problem?**** > > I personally don't see the issue here. Facebook uses different domains fo= r > their users vs their employess. It's unfortunate if titter do not does th= is > but i twas said many times in the past on this list that acct: addresses > with the same value than mailto: addresses may actually not be related to > the same person. (although it would make sense, technically there is no > binding for this). > I wouldn't enter the debate of who's represented behind a specific URI. I= t > is up to the domain admin to manage the account namespace. Could you bett= er > clarify your issue here? > > Re the acct: URI scheme I do support Paul's view that at this stage there > is no URI-way of identifying *user accounts* globally. It is already wide= ly > used in federated social networks that will become a big consumer of > webfinger eventually and could easily reuse these "acct:" URIs in activit= y > streams in the actor/id field (normatively defined as anyURI). > > Third, wf was designed for supporting any URI including for example http:= , > which are not in the form of user@domain. And in general I would > recommend that an ietf spec formally define the "resource" parameter as > anyURI instead of a free-form string.**** > > > Taking your example of http:, how might this work? > **** > > > walter > > > -nick > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.**** > > ** ** > --e89a8f3ba87fafa73904d134cc91 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


--e89a8f3ba87fafa73904d134cc91-- From paulej@packetizer.com Wed Dec 19 07:42:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775ED21F8866 for ; Wed, 19 Dec 2012 07:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLd9vNC3GGSO for ; Wed, 19 Dec 2012 07:42:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5721F85BA for ; Wed, 19 Dec 2012 07:42:15 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBJFgDPG029369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 10:42:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355931734; bh=LyGDNaePC+clfGshU1s4aSeDkjsRxnEe/PRyACvWvlc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=rrwGH3vNQyMrE3ZZ39GaxnF+qwiZ+qlMygxd2bD7pEFQLtNrKtoP+k3bBN6w7gVl0 fWFA/541sq7o7A2Mohze8zOWPWOVHL18F9bWLkGDajh5h4z6dTinaY1PMDzZNqPl0u 32tY+Sg3e6+DOQfKHE/FHrnNcrBetLz2+TJ597bc= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <019101cddda5$86382060$92a86120$@packetizer.com> In-Reply-To: Date: Wed, 19 Dec 2012 10:42:19 -0500 Message-ID: <022301cdddff$6ea071a0$4be154e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0224_01CDDDD5.85CB05E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQJ90ToJAjU+m5gCSZguwphPR68A Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com, 'Goix Laurent Walter' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:42:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0224_01CDDDD5.85CB05E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Honestly, I don't follow exactly what you're saying. WF allows any URI, this this form is allowed. What the server chooses to include in the response is not specified. The concept here is not new. This was also possible in RFC 6415 (host-meta & LRDD). But, how that relates to "HTTP GET", I do not know. Are you referring to mark-up in an HTML document? If so, it's impossible to ensure consistency in all cases, since many HTTP resources return non-HTML content. In any case, this is really a subject that should be outside the scope of WF. WF defines how to convey information. We should not get into comparison between "HTTP GET" discovery mechanisms. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, December 19, 2012 8:43 AM To: Paul E. Jones Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process On 19 December 2012 05:58, Paul E. Jones wrote: Melvin, Here's an example: curl 'https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer .com/' This does not return much useful information, but I return a user-friendly "Name" for the URI. I could include a URL to a site policy document, have a link relation to a copyright statement, etc. I see what you are doing here and it's a neat implementation. I think that if http discovery is in scope of webfinger, then data returned should be consistent with HTTP GET, which is currently the best practice for http discovery, imho. Otherwise there is the potential danger, for things getting out of sync, depending on which discovery method is used. Does that make sense? ------=_NextPart_000_0224_01CDDDD5.85CB05E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Honestly, I don’t follow exactly what you’re = saying.  WF allows any URI, this this form is allowed.  = What the server chooses to include in the response is not = specified.  The concept here is not new.  This was also = possible in RFC 6415 (host-meta & LRDD).  But, how that relates = to “HTTP GET”, I do not know.  Are you referring to = mark-up in an HTML document?  If so, it's impossible to ensure = consistency in all cases, since many HTTP resources return non-HTML = content.  In any case, this is really a subject that should be = outside the scope of WF.  WF defines how to convey = information.  We should not get into comparison between “HTTP = GET” discovery mechanisms.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Wednesday, December 19, 2012 8:43 AM
To: Paul E. = Jones
Cc: Goix Laurent Walter; webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

 

On 19 December 2012 05:58, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

Here’s an example:

 

  curl 'https://packetizer.com/.well-known/webfinger?resource=3D= http://www.packetizer.com/'

 

This does not return much useful information, but I return a = user-friendly “Name” for the URI.  I could include a = URL to a site policy document, have a link relation to a copyright = statement, etc.


I see what you are doing here and it's a neat = implementation.  I think that if http discovery is in scope of = webfinger, then data returned should be consistent with HTTP GET, which = is currently the best practice for http discovery, imho.  Otherwise = there is the potential danger, for things getting out of sync, depending = on which discovery method is used.

Does that make = sense?

------=_NextPart_000_0224_01CDDDD5.85CB05E0-- From melvincarvalho@gmail.com Wed Dec 19 09:26:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2CA21F89AD for ; Wed, 19 Dec 2012 09:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDCzRrC84nFp for ; Wed, 19 Dec 2012 09:26:00 -0800 (PST) Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by ietfa.amsl.com (Postfix) with ESMTP id D80D921F878F for ; Wed, 19 Dec 2012 09:25:59 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id k27so1964398iad.2 for ; Wed, 19 Dec 2012 09:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=seSIxKPNgx18nQJNaVa9Cryy2crCMbuCkF9viIkEQgQ=; b=Jy46RGBmtJmSE4W+nqPt+4Xb4cHY98FD8q1/r64Ku4zaMs3NoLy2H0zAv/QZIDd7+P ngAhrpnpkCYDgxpnWh4gYJc8HVcqots0WBwF5ucims29/JA4CYj3GJAWH9eSvhi1bMpy 5DAMPaIPJExvL7bg9bNttBz4dk00QsHdlRiQW8tKx3FQjIFRjH9bM4UrFh6lUifSaZN1 SjfQfWT0ak6LfCatp/cELEHQBcSb2lhkYUpl6l2iVxvejRAnwbCKQMVhXm2gRG7Aur8N rv/FvErRfZ+bCFmHl9LpABkRfT+bRxx6e7r8VpNpi/JG2GTRkr6v8DKhe6uDJsD44d+W b3ow== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr7922433igk.41.1355937958730; Wed, 19 Dec 2012 09:25:58 -0800 (PST) Received: by 10.42.61.203 with HTTP; Wed, 19 Dec 2012 09:25:58 -0800 (PST) In-Reply-To: <022301cdddff$6ea071a0$4be154e0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <019101cddda5$86382060$92a86120$@packetizer.com> <022301cdddff$6ea071a0$4be154e0$@packetizer.com> Date: Wed, 19 Dec 2012 18:25:58 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae93409015e1ae804d137e81f Cc: webfinger@ietf.org, webfinger@googlegroups.com, Goix Laurent Walter Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:26:02 -0000 --14dae93409015e1ae804d137e81f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 December 2012 16:42, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Honestly, I don=92t follow exactly what you=92re saying. WF allows *any*= URI, this this form is allowed. What the server chooses to include in the > response is not specified. The concept here is not new. This was also > possible in RFC 6415 (host-meta & LRDD). But, how that relates to =93HTT= P > GET=94, I do not know. Are you referring to mark-up in an HTML document?= If > so, it's impossible to ensure consistency in all cases, since many HTTP > resources return non-HTML content. In any case, this is really a subject > that should be outside the scope of WF. WF defines how to convey > information. We should not get into comparison between =93HTTP GET=94 > discovery mechanisms. > HTTP is not strictly coupled to HTML, HTML is simply one MIME type. GET can return HTML, images, audio, XML, JSON etc. Many of the serializations contain data points either in the header, or in the payload. This year, embedding data in html documents (as well as headers) has achieved REC status and has had significant deployment (25%-50% of the web). As such this is a form of 'follow your nose discovery'. There is a large body of work at the W3C and other places, that have covered HTTP based discovery in great detail, with 100s if man years worth of standardization. I could be mistaken, but if it is in scope that webfinger includes http, the overlap with existing methods of discovery may be sensible as part of standardization, to ensure compatibility across the whole internet. > **** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Wednesday, December 19, 2012 8:43 AM > *To:* Paul E. Jones > *Cc:* Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org > > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > ** ** > > ** ** > > On 19 December 2012 05:58, Paul E. Jones wrote:**= * > * > > Melvin,**** > > **** > > Here=92s an example:**** > > **** > > curl ' > https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packet= izer.com/ > '**** > > **** > > This does not return much useful information, but I return a user-friendl= y > =93Name=94 for the URI. I could include a URL to a site policy document,= have > a link relation to a copyright statement, etc.**** > > > I see what you are doing here and it's a neat implementation. I think > that if http discovery is in scope of webfinger, then data returned shoul= d > be consistent with HTTP GET, which is currently the best practice for htt= p > discovery, imho. Otherwise there is the potential danger, for things > getting out of sync, depending on which discovery method is used. > > Does that make sense? > > **** > --14dae93409015e1ae804d137e81f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 19 December 2012 16:42, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Honestly, I don=92t follow exactly what you= =92re saying.=A0 WF allows any URI, this this form is allowed.=A0 Wh= at the server chooses to include in the response is not specified.=A0 The c= oncept here is not new.=A0 This was also possible in RFC 6415 (host-meta &a= mp; LRDD). =A0But, how that relates to =93HTTP GET=94, I do not know.=A0 Ar= e you referring to mark-up in an HTML document?=A0 If so, it's impossib= le to ensure consistency in all cases, since many HTTP resources return non= -HTML content.=A0 In any case, this is really a subject that should be outs= ide the scope of WF.=A0 WF defines how to convey information.=A0 We should = not get into comparison between =93HTTP GET=94 discovery mechanisms.=


HTTP is not strictly coupled to HTML, HTM= L is simply one MIME type.=A0 GET can return HTML, images, audio, XML, JSON= etc.=A0 Many of the serializations contain data points either in the heade= r, or in the payload.=A0 This year, embedding data in html documents (as we= ll as headers) has achieved REC status and has had significant deployment (= 25%-50% of the web).=A0 As such this is a form of 'follow your nose dis= covery'.=A0 There is a large body of work at the W3C and other places, = that have covered HTTP based discovery in great detail, with 100s if man ye= ars worth of standardization.

I could be mistaken, but if it is in scope that webfinger includes http= , the overlap with existing methods of discovery may be sensible as part of= standardization, to ensure compatibility across the whole internet.=A0 =A0

<= /u>

=A0<= /p>

Paul

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Wednesday, December 19, 2012 8:43 AM
To: Paul E. Jon= es
Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org


Subject: Re: [webfinger] Possibly speeding up = the RFC process

=A0

=A0

On 19 December 2012 05:58, Paul E. Jones <paulej@packetizer.= com> wrote:

Melvin,

=A0

Here=92s an example:

=A0

=A0 curl 'https://packetizer.com/.well-known/webfinger?res= ource=3Dhttp://www.packetizer.com/'

=A0<= /p>

This does not return m= uch useful information, but I return a user-friendly =93Name=94 for the URI= .=A0 I could include a URL to a site policy document, have a link relation = to a copyright statement, etc.


I see what you are doing here a= nd it's a neat implementation.=A0 I think that if http discovery is in = scope of webfinger, then data returned should be consistent with HTTP GET, = which is currently the best practice for http discovery, imho.=A0 Otherwise= there is the potential danger, for things getting out of sync, depending o= n which discovery method is used.

Does that make sense?


--14dae93409015e1ae804d137e81f-- From paulej@packetizer.com Wed Dec 19 12:22:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA21821F8777 for ; Wed, 19 Dec 2012 12:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnuYm2whMb-u for ; Wed, 19 Dec 2012 12:22:07 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31B21F8578 for ; Wed, 19 Dec 2012 12:22:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBJKM45I010506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 15:22:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355948525; bh=bAJMM0HaIAez+3L5ckbAwHrokA42TeLGQEQOup+l0hI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZWdMXj+rsAE9r1UO4VMdr/SWS0sRJZ/f8SK6qwrrOi3cBTBEFoGMdptecSy/xNb5F EG9IOzzt/DiLuP2G7E4SxMmm1h5oJoHaH5UUKw555gmIt8tlIv9b8zHIfVw/bcge4V TyYOsI8RCKKx01zQoxfEimAzRFe0M+XnEAJG5joY= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <019101cddda5$86382060$92a86120$@packetizer.com> <022301cdddff$6ea071a0$4be154e0$@packetizer.com> In-Reply-To: Date: Wed, 19 Dec 2012 15:22:11 -0500 Message-ID: <029b01cdde26$8713d5c0$953b8140$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029C_01CDDDFC.9E3EDF30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQJ90ToJAjU+m5gCSZguwgF28XTzAb3MQDuYNegLcA== Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com, 'Goix Laurent Walter' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:22:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_029C_01CDDDFC.9E3EDF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, OK, I do understand a little better. WF does allow any URI, but does not go into detail about what information is returned when a client queries using a particular URI scheme as the resource parameter. One could make the argument that "http" ought not be used. One could also make the argument that there should be consistency between what WF returns for an "http" URI and what kind of metadata is returned when simply querying the resource should be consistent. However, I don't think that should be included in the WF spec itself. Just as we're going to be defining link relations, properties, perhaps methods for auto-provisioning, etc., this is a good subject to take up as a follow-on activity or even an activity in the W3C. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, December 19, 2012 12:26 PM To: Paul E. Jones Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process On 19 December 2012 16:42, Paul E. Jones wrote: Melvin, Honestly, I don't follow exactly what you're saying. WF allows any URI, this this form is allowed. What the server chooses to include in the response is not specified. The concept here is not new. This was also possible in RFC 6415 (host-meta & LRDD). But, how that relates to "HTTP GET", I do not know. Are you referring to mark-up in an HTML document? If so, it's impossible to ensure consistency in all cases, since many HTTP resources return non-HTML content. In any case, this is really a subject that should be outside the scope of WF. WF defines how to convey information. We should not get into comparison between "HTTP GET" discovery mechanisms. HTTP is not strictly coupled to HTML, HTML is simply one MIME type. GET can return HTML, images, audio, XML, JSON etc. Many of the serializations contain data points either in the header, or in the payload. This year, embedding data in html documents (as well as headers) has achieved REC status and has had significant deployment (25%-50% of the web). As such this is a form of 'follow your nose discovery'. There is a large body of work at the W3C and other places, that have covered HTTP based discovery in great detail, with 100s if man years worth of standardization. I could be mistaken, but if it is in scope that webfinger includes http, the overlap with existing methods of discovery may be sensible as part of standardization, to ensure compatibility across the whole internet. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Wednesday, December 19, 2012 8:43 AM To: Paul E. Jones Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org Subject: Re: [webfinger] Possibly speeding up the RFC process On 19 December 2012 05:58, Paul E. Jones wrote: Melvin, Here's an example: curl 'https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer .com/' This does not return much useful information, but I return a user-friendly "Name" for the URI. I could include a URL to a site policy document, have a link relation to a copyright statement, etc. I see what you are doing here and it's a neat implementation. I think that if http discovery is in scope of webfinger, then data returned should be consistent with HTTP GET, which is currently the best practice for http discovery, imho. Otherwise there is the potential danger, for things getting out of sync, depending on which discovery method is used. Does that make sense? ------=_NextPart_000_029C_01CDDDFC.9E3EDF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

OK, I do understand a little better.

 

WF does allow any URI, but does not go into detail about what = information is returned when a client queries using a particular URI = scheme as the resource parameter.  One could make the argument that = “http” ought not be used.  One could also make the = argument that there should be consistency between what WF returns for an = “http” URI and what kind of metadata is returned when simply = querying the resource should be consistent.

 

However, I don’t think that should be included in the WF spec = itself.  Just as we’re going to be defining link relations, = properties, perhaps methods for auto-provisioning, etc., this is a good = subject to take up as a follow-on activity or even an activity in the = W3C.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Wednesday, December 19, 2012 12:26 PM
To: Paul E. = Jones
Cc: Goix Laurent Walter; webfinger@googlegroups.com; = webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding = up the RFC process

 

 

On 19 December 2012 16:42, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

Honestly, I don’t follow exactly what you’re = saying.  WF allows any URI, this this form is allowed.  = What the server chooses to include in the response is not = specified.  The concept here is not new.  This was also = possible in RFC 6415 (host-meta & LRDD).  But, how that relates = to “HTTP GET”, I do not know.  Are you referring to = mark-up in an HTML document?  If so, it's impossible to ensure = consistency in all cases, since many HTTP resources return non-HTML = content.  In any case, this is really a subject that should be = outside the scope of WF.  WF defines how to convey = information.  We should not get into comparison between “HTTP = GET” discovery = mechanisms.


HTTP is not strictly coupled to HTML, HTML is = simply one MIME type.  GET can return HTML, images, audio, XML, = JSON etc.  Many of the serializations contain data points either in = the header, or in the payload.  This year, embedding data in html = documents (as well as headers) has achieved REC status and has had = significant deployment (25%-50% of the web).  As such this is a = form of 'follow your nose discovery'.  There is a large body of = work at the W3C and other places, that have covered HTTP based discovery = in great detail, with 100s if man years worth of = standardization.

I could be mistaken, but if it is in scope that = webfinger includes http, the overlap with existing methods of discovery = may be sensible as part of standardization, to ensure compatibility = across the whole internet.  =
 

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Wednesday, December 19, 2012 8:43 AM
To: Paul E. = Jones
Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org


Subject: Re: [webfinger] Possibly speeding = up the RFC process

 <= /o:p>

 <= /p>

On 19 = December 2012 05:58, Paul E. Jones <paulej@packetizer.com> = wrote:

Melvin,

 

Here’s an example:

 

  curl 'https://packetizer.com/.well-known/webfinger?resource=3D= http://www.packetizer.com/'

 

This does not return much useful information, but I return a = user-friendly “Name” for the URI.  I could include a = URL to a site policy document, have a link relation to a copyright = statement, etc.


I see what = you are doing here and it's a neat implementation.  I think that if = http discovery is in scope of webfinger, then data returned should be = consistent with HTTP GET, which is currently the best practice for http = discovery, imho.  Otherwise there is the potential danger, for = things getting out of sync, depending on which discovery method is = used.

Does that make = sense?

 

------=_NextPart_000_029C_01CDDDFC.9E3EDF30-- From melvincarvalho@gmail.com Wed Dec 19 12:41:03 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B0721F86AC for ; Wed, 19 Dec 2012 12:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69S0DHHBzEta for ; Wed, 19 Dec 2012 12:41:01 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6CFA21F8696 for ; Wed, 19 Dec 2012 12:41:01 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so3516102ieb.33 for ; Wed, 19 Dec 2012 12:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dm1ZC/KeTZPtCXnT5hgwxx5rC5Uc/gGg/wzDPD6SQCM=; b=Vy0pokxzI8Mqyvb2abSzaqiIIU/FfFE7QNfljwgObqC/f69BLiFmuaDg/izZPjN5wb N6+OwB12eHjzCUBrpcrLqPg8tgAD89d5dPy7/JZIXxthBT7PWKtui+O4Bz4tZ1jFCPZc UVvPOybIz1a/mPGO+hHPtYSyZFcaY5NidYXr9+DoWQ9DAAopr89GIt1w36c1GSDMlU0q EReG/R8iQHbP5kh/o/wXyZRhzJLINkn1wDeIWCyWvm+iyyLojoLrAcVL1dAhPt8IEb0F iZkL/GIFzF+olm3OBWvzEt+KQr3VHYwhgzYOPkaIlVJYcaMGiSsmibfkLfXH3Fq6e6hS W2fg== MIME-Version: 1.0 Received: by 10.42.101.66 with SMTP id d2mr7218997ico.11.1355949661128; Wed, 19 Dec 2012 12:41:01 -0800 (PST) Received: by 10.42.61.203 with HTTP; Wed, 19 Dec 2012 12:41:00 -0800 (PST) In-Reply-To: <029b01cdde26$8713d5c0$953b8140$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <019101cddda5$86382060$92a86120$@packetizer.com> <022301cdddff$6ea071a0$4be154e0$@packetizer.com> <029b01cdde26$8713d5c0$953b8140$@packetizer.com> Date: Wed, 19 Dec 2012 21:41:00 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec53143b5e2864f04d13aa1fe Cc: webfinger@ietf.org, webfinger@googlegroups.com, Goix Laurent Walter Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:41:03 -0000 --bcaec53143b5e2864f04d13aa1fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19 December 2012 21:22, Paul E. Jones wrote: > Melvin,**** > > ** ** > > OK, I do understand a little better.**** > > ** ** > > WF does allow any URI, but does not go into detail about what information > is returned when a client queries using a particular URI scheme as the > resource parameter. One could make the argument that =93http=94 ought no= t be > used. One could also make the argument that there should be consistency > between what WF returns for an =93http=94 URI and what kind of metadata i= s > returned when simply querying the resource should be consistent.**** > > ** ** > > However, I don=92t think that should be included in the WF spec itself. > Just as we=92re going to be defining link relations, properties, perhaps > methods for auto-provisioning, etc., this is a good subject to take up as= a > follow-on activity or even an activity in the W3C. > +1 > **** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Wednesday, December 19, 2012 12:26 PM > > *To:* Paul E. Jones > *Cc:* Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > ** ** > > ** ** > > On 19 December 2012 16:42, Paul E. Jones wrote:**= * > * > > Melvin,**** > > **** > > Honestly, I don=92t follow exactly what you=92re saying. WF allows *any*= URI, this this form is allowed. What the server chooses to include in the > response is not specified. The concept here is not new. This was also > possible in RFC 6415 (host-meta & LRDD). But, how that relates to =93HTT= P > GET=94, I do not know. Are you referring to mark-up in an HTML document?= If > so, it's impossible to ensure consistency in all cases, since many HTTP > resources return non-HTML content. In any case, this is really a subject > that should be outside the scope of WF. WF defines how to convey > information. We should not get into comparison between =93HTTP GET=94 > discovery mechanisms.**** > > > HTTP is not strictly coupled to HTML, HTML is simply one MIME type. GET > can return HTML, images, audio, XML, JSON etc. Many of the serialization= s > contain data points either in the header, or in the payload. This year, > embedding data in html documents (as well as headers) has achieved REC > status and has had significant deployment (25%-50% of the web). As such > this is a form of 'follow your nose discovery'. There is a large body of > work at the W3C and other places, that have covered HTTP based discovery = in > great detail, with 100s if man years worth of standardization. > > I could be mistaken, but if it is in scope that webfinger includes http, > the overlap with existing methods of discovery may be sensible as part of > standardization, to ensure compatibility across the whole internet. > **** > > **** > > Paul**** > > **** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Wednesday, December 19, 2012 8:43 AM > *To:* Paul E. Jones > *Cc:* Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org= * > *** > > > *Subject:* Re: [webfinger] Possibly speeding up the RFC process**** > > **** > > **** > > On 19 December 2012 05:58, Paul E. Jones wrote:**= * > * > > Melvin,**** > > **** > > Here=92s an example:**** > > **** > > curl ' > https://packetizer.com/.well-known/webfinger?resource=3Dhttp://www.packet= izer.com/ > '**** > > **** > > This does not return much useful information, but I return a user-friendl= y > =93Name=94 for the URI. I could include a URL to a site policy document,= have > a link relation to a copyright statement, etc.**** > > > I see what you are doing here and it's a neat implementation. I think > that if http discovery is in scope of webfinger, then data returned shoul= d > be consistent with HTTP GET, which is currently the best practice for htt= p > discovery, imho. Otherwise there is the potential danger, for things > getting out of sync, depending on which discovery method is used. > > Does that make sense?**** > > ** ** > --bcaec53143b5e2864f04d13aa1fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 19 December 2012 21:22, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

OK, I do understand a little better.

=A0<= /p>

WF does allow any URI,= but does not go into detail about what information is returned when a clie= nt queries using a particular URI scheme as the resource parameter.=A0 One = could make the argument that =93http=94 ought not be used.=A0 One could als= o make the argument that there should be consistency between what WF return= s for an =93http=94 URI and what kind of metadata is returned when simply q= uerying the resource should be consistent.

=A0<= /p>

However, I don=92t thi= nk that should be included in the WF spec itself.=A0 Just as we=92re going = to be defining link relations, properties, perhaps methods for auto-provisi= oning, etc., this is a good subject to take up as a follow-on activity or e= ven an activity in the W3C.


+1
=A0

=A0<= /p>

Paul

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Wednesday, December 19, 2012 12:26 PM


To: Paul E. Jones
Cc: Goix Laurent Walter; webfinger@googlegr= oups.com; webfi= nger@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process=

=A0

=A0

On 19 December 2012 16:42, Paul E. Jones <paulej@packetizer.= com> wrote:

Melvin,

=A0<= /p>

Honestly, I don=92t fo= llow exactly what you=92re saying.=A0 WF allows any URI, this this f= orm is allowed.=A0 What the server chooses to include in the response is no= t specified.=A0 The concept here is not new.=A0 This was also possible in R= FC 6415 (host-meta & LRDD). =A0But, how that relates to =93HTTP GET=94,= I do not know.=A0 Are you referring to mark-up in an HTML document?=A0 If = so, it's impossible to ensure consistency in all cases, since many HTTP= resources return non-HTML content.=A0 In any case, this is really a subjec= t that should be outside the scope of WF.=A0 WF defines how to convey infor= mation.=A0 We should not get into comparison between =93HTTP GET=94 discove= ry mechanisms.


HTTP is not strictly coupled to= HTML, HTML is simply one MIME type.=A0 GET can return HTML, images, audio,= XML, JSON etc.=A0 Many of the serializations contain data points either in= the header, or in the payload.=A0 This year, embedding data in html docume= nts (as well as headers) has achieved REC status and has had significant de= ployment (25%-50% of the web).=A0 As such this is a form of 'follow you= r nose discovery'.=A0 There is a large body of work at the W3C and othe= r places, that have covered HTTP based discovery in great detail, with 100s= if man years worth of standardization.

I could be mistaken, but if it is in scope that webfinger includes http= , the overlap with existing methods of discovery may be sensible as part of= standardization, to ensure compatibility across the whole internet.=A0 =A0

=A0<= u>

Paul=

=A0<= /u>

From:= Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Wednesday, December 19, 2012 8:43 AM
To: Paul E. Jon= es
Cc: Goix Laurent Walter; webfinger@googlegroups.com; webfinger@ietf.org


Subject: Re: [webfinger] Possibly sp= eeding up the RFC process

=A0

=A0

On 19 December 2012 05:58,= Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0

Here=92s an example:

=A0

=A0 curl 'https://packetizer.com/.well-known/webfinger?res= ource=3Dhttp://www.packetizer.com/'

=A0<= /p>

This does not return m= uch useful information, but I return a user-friendly =93Name=94 for the URI= .=A0 I could include a URL to a site policy document, have a link relation = to a copyright statement, etc.


= I see what you are doing here and it's a neat implementation.=A0 I thin= k that if http discovery is in scope of webfinger, then data returned shoul= d be consistent with HTTP GET, which is currently the best practice for htt= p discovery, imho.=A0 Otherwise there is the potential danger, for things g= etting out of sync, depending on which discovery method is used.

Does that make sense?

=A0


--bcaec53143b5e2864f04d13aa1fe-- From paulej@packetizer.com Wed Dec 19 18:39:01 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5F21F875D for ; Wed, 19 Dec 2012 18:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLOQz2Phmyny for ; Wed, 19 Dec 2012 18:39:00 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCCD21F85A3 for ; Wed, 19 Dec 2012 18:39:00 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBK2cvW5027002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 21:38:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355971139; bh=Vy4nGVrG4lS3tjaVqpHKTlKOviQXMdCew1fyr5yk5nE=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=pSpaCIgNcFY3e7FC4Zys3CMNL+JwWN9rfaTaoaQAM1Poib4O4ujd6xriuy1y2NP1j yfHtWHgsy0dxcTbveXG+ufCiRooR096I8OX04HHIkBWuVgmNmCOb0mqEbSZof1QqLn Yn6SZntS+embZgdowLV8jA7w1tpCEu6SdFMx0coM= From: "Paul E. Jones" To: , Date: Wed, 19 Dec 2012 21:39:04 -0500 Message-ID: <034501cdde5b$2e427570$8ac76050$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0346_01CDDE31.456CE2A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3eWy0NAa6B/yJ8R2G87hZNZ05y4A== Content-Language: en-us Subject: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:39:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0346_01CDDE31.456CE2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, We're looking at text like this related to redirection: WebFinger servers MAY redirect a client using a redirection HTTP status code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs. Note the word "SHOULD" on the client's requirement to follow redirects. This softer requirement has been floated around on the list now for a week or longer (e.g., see Sal's note on 12 Dec 2012), but the -07 version of the document mandates that clients follow redirects. I cannot recall why this change was made, but it might have been out of security concerns. Now that we are using HTTPS only, should we change that SHOULD back to a MUST as was in the -07 draft? Paul ------=_NextPart_000_0346_01CDDE31.456CE2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We’re = looking at text like this related to redirection:

 

WebFinger servers MAY redirect a client using = a redirection HTTP status code to another HTTPS URI, but MUST NOT = redirect a client to an HTTP URI.  Further, clients MUST NOT follow = a redirection to an HTTP URI, but SHOULD follow = all server redirects to HTTPS URIs.

 

Note the = word “SHOULD” on the client’s requirement to follow = redirects.  This softer requirement has been floated around on the = list now for a week or longer (e.g., see Sal’s note on 12 Dec = 2012), but the -07 version of the document mandates that clients follow = redirects.  I cannot recall why this change was made, but it might = have been out of security concerns.

 

Now that we = are using HTTPS only, should we change that SHOULD back to a MUST as was = in the -07 draft?

 

Paul

 

------=_NextPart_000_0346_01CDDE31.456CE2A0-- From bradfitz@google.com Wed Dec 19 18:41:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14B21F87DE for ; Wed, 19 Dec 2012 18:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSmUpa+QvgVx for ; Wed, 19 Dec 2012 18:41:16 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 921A021F875D for ; Wed, 19 Dec 2012 18:41:16 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so1548802qcs.27 for ; Wed, 19 Dec 2012 18:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RMUmo4Hh6QoSHQaiBxUQEueKy0BgyFhIvK/ned/8FwA=; b=IKULhZ8IGHC08e5jSVCuylLuSkwU4MqQEbXIEyRELMqcv/L+40FSsVAHU6c5OCFVoZ 0z+CoroNOfPsL963FF4lFcZ8k/My5CY1qyNukSJpZkCyRS4AjRpLaIKnD1PsCvWpd6BX ca7JEL/2CamkgSRX8emK1zqJ44Er56FZzDG5ck0Tnruno4u2UsNdcnvpvfYQH8rflowx F6g2v40vIG22TEFHzrOdqa/wn47mSUzl0aDv5NImzCTuULLc0Y54TBeiVWzKTJzxH0xA E8mX38l5mtGVtAj08949DLiLsTNKriz5HhoJU+yP0kMHJYItg4I0J79v7rTIajnaerYb JhXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RMUmo4Hh6QoSHQaiBxUQEueKy0BgyFhIvK/ned/8FwA=; b=JEY3+RQxQUDg38OyB0BfxUZXZETw69cmOhmfXEhLvmBDOXGOZbkTb4uCHqvvez4Y4k CeTsnMd0McFQsIA9z4mIxjiX4pM5n+OU7IzMzIzCm3OQiIW+r/oQXu6R0Jc4XaGCOUPX an0xiXfOBGS082FDGnkjseO2YZa3+ut86MV4oC5JzbWrq3Gpy7ja4It8iE6WOomcNvXU 0TKtALg6kEtD0KVwYXH56Ej0hA4zG3VXPNTu/vn2WE2lDR5P94elExCFFztqm8PHa/ri BBDRfLBIQZ9f6XJDYcQ9I9q8TBmqvA5fPkEuF3obDoi0vfza7XYBy9L35un43yjKkRWX H9bQ== MIME-Version: 1.0 Received: by 10.49.106.71 with SMTP id gs7mr4600587qeb.21.1355971275911; Wed, 19 Dec 2012 18:41:15 -0800 (PST) Received: by 10.224.70.146 with HTTP; Wed, 19 Dec 2012 18:41:15 -0800 (PST) In-Reply-To: <034501cdde5b$2e427570$8ac76050$@packetizer.com> References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> Date: Wed, 19 Dec 2012 18:41:15 -0800 Message-ID: From: Brad Fitzpatrick To: "webfinger@googlegroups.com" Content-Type: multipart/alternative; boundary=e89a8f921a1e39f22004d13faa32 X-Gm-Message-State: ALoCoQnuqETGKQGYZRVGRsyJLaGPUAzRjLfsep7wOrE7MNEfwkow4+Bmx5rVmcyKqv9z7J4eWK4k1Xfbq5VwY991H+NbvQ+9xDNPJnxMorW4qaO1nxHit889wQWXC+W3LJahmlVtLMCo3Wjj9hrB4R+YjRl0OSkleBmkUathP908jlh2CvXFze5mCa1QrtiTbws9zVf1uUJW Cc: "webfinger@ietf.org" Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:41:17 -0000 --e89a8f921a1e39f22004d13faa32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wouldn't worry about it. SHOULD is fine. Some small number of people will violate it anyway for security or paranoia reasons (and they probably know what they're doing), and most people will be using some higher-level HTTP client that doesn't give them options anyway and will probably just do the right thing. So changing the wording only affects a small number of people who won't care to necessarily follow it anyway. On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > We=E2=80=99re looking at text like this related to redirection:**** > > ** ** > > WebFinger servers MAY redirect a client using a redirection HTTP status > code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. > Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD= follow all server redirects to HTTPS URIs. > **** > > ** ** > > Note the word =E2=80=9CSHOULD=E2=80=9D on the client=E2=80=99s requiremen= t to follow redirects. > This softer requirement has been floated around on the list now for a wee= k > or longer (e.g., see Sal=E2=80=99s note on 12 Dec 2012), but the -07 vers= ion of the > document mandates that clients follow redirects. I cannot recall why thi= s > change was made, but it might have been out of security concerns.**** > > ** ** > > Now that we are using HTTPS only, should we change that SHOULD back to a > MUST as was in the -07 draft?**** > > ** ** > > Paul**** > > ** ** > --e89a8f921a1e39f22004d13faa32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
I wouldn't worry abo= ut it. =C2=A0SHOULD is fine.

Some small number of people will violate it anyway for security or paranoia= reasons (and they probably know what they're doing), and most people w= ill be using some higher-level HTTP client that doesn't give them optio= ns anyway and will probably just do the right thing.

So changing the wording only affects a small number of people who won&= #39;t care to necessarily follow it anyway.



On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones <paulej@packetizer.c= om> wrote:

Folks,

=C2=A0

We=E2=80=99re looking at text like this related to r= edirection:

=C2=A0

WebFinger servers MAY re= direct a client using a redirection HTTP status code to another HTTPS URI, = but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST = NOT follow a redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs.<= /p>

=C2=A0

Note = the word =E2=80=9CSHOULD=E2=80=9D on the client=E2=80=99s requirement to fo= llow redirects.=C2=A0 This softer requirement has been floated around on th= e list now for a week or longer (e.g., see Sal=E2=80=99s note on 12 Dec 201= 2), but the -07 version of the document mandates that clients follow redire= cts.=C2=A0 I cannot recall why this change was made, but it might have been= out of security concerns.

=C2=A0

Now t= hat we are using HTTPS only, should we change that SHOULD back to a MUST as= was in the -07 draft?

=C2=A0

Paul

=C2=A0

=

--e89a8f921a1e39f22004d13faa32-- From bradfitz@google.com Wed Dec 19 18:44:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D8521F88D4 for ; Wed, 19 Dec 2012 18:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvK3N4TOtyQd for ; Wed, 19 Dec 2012 18:44:16 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id D11A721F88A3 for ; Wed, 19 Dec 2012 18:44:15 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id j3so1511441qcs.20 for ; Wed, 19 Dec 2012 18:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UkvyBNDWNRHDuNMfFpjX/3oY41Cr1ZV0O4aR+eURnnA=; b=dELMsEzOcSPo1LLS+6f080eGC2f7cWZJrFmPYftkce1I4HJ9IIm52QsO7wayxZ1lFu 2w2hUaPnMlX7jiPaqJeayPySgEiIwnMn9MEEZASLa6f/8LIBKxksMtS2Ij48pLEFf5or P99PVONLD8lYZMnoyjnz31lCqAAQGHhUElwkRNAfdMKPewYzrPFq90fWoexS9gyEkJyq GFU3w091V72HyO2GuQMpOIeO4uSnik/LWb5tyRcEuHi/oRT6tQSIkZA/VzG3AkG0BTS0 hMETaofqaRNoxfsKYkjKGMbOhKxEEPPPfRuH186IjTUt4w1RKZxGElpsJ8eFaSp2Jo9h 7rng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=UkvyBNDWNRHDuNMfFpjX/3oY41Cr1ZV0O4aR+eURnnA=; b=Lu+wdybvmwm2LfVuRy6NQ5slahxIbMU4BBiJLuFDUHLB42atpb8K4XS+yjIws4VmKT GBfDoILhuD8W+W5AUeTmZSg6aavOa8lpsJDu1Fwty0/kd9ISpqoURfcwYsklsK/eErz+ NxyzxV81eFvSFBBzjD+G7tTI7j//eILo7x+VdEpnoX0kyTJqUJeDBo7GEnMwYooxJhb2 6ZZ3fhW/7OOUPwRXC5/rGX26RMU18HQPp6/6TUvXlyhJYP0q+6hrIuAW1QSoA8TNeAUg pzE9YeNvP5v0hdCKx3mQWZiqCyNpPIk4fTHVh6nvDkeXGPJZ8bOQ4PsCu6WxRv/D+GUB StrA== MIME-Version: 1.0 Received: by 10.49.106.71 with SMTP id gs7mr4603575qeb.21.1355971452541; Wed, 19 Dec 2012 18:44:12 -0800 (PST) Received: by 10.224.70.146 with HTTP; Wed, 19 Dec 2012 18:44:12 -0800 (PST) In-Reply-To: References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> Date: Wed, 19 Dec 2012 18:44:12 -0800 Message-ID: From: Brad Fitzpatrick To: "webfinger@googlegroups.com" Content-Type: multipart/alternative; boundary=e89a8f921a1ec11b7904d13fb423 X-Gm-Message-State: ALoCoQlg8Qpg6sSCb6PjDt36zgCMf/4RW6dmg2aqFqycfau+v18uHWfY/z9TPQdSMtsaBwfsDluvhemCd1EtLRZh+O9QqOznbklCYnxo5Wh7qgOIaHlk5MVC7J6X02naCOME6fujAGJj2hOMFYDye6pETHE8o92IQ0qBBrX4UVKNLvtWqFFgdMol8X3d5ac/qeyjdHgR0z0B Cc: "webfinger@ietf.org" Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:44:17 -0000 --e89a8f921a1ec11b7904d13fb423 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For instance, if I look up attacker@evil.example.net's WebFinger like: GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.comHTTP= /1.1 Host: evil.example.net And they reply: HTTP/1.1 302 Found Location: http://10.0.0.17/some/internal/service/delete_account?user=3Dvictim Is it a MUST that I follow that redirect? Hell no. This is why I wrote http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgent.= pmback in the day, but variants with similar policies exist for nearly all languages / organizations. On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick wrot= e: > I wouldn't worry about it. SHOULD is fine. > > Some small number of people will violate it anyway for security or > paranoia reasons (and they probably know what they're doing), and most > people will be using some higher-level HTTP client that doesn't give them > options anyway and will probably just do the right thing. > > So changing the wording only affects a small number of people who won't > care to necessarily follow it anyway. > > > > On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones wro= te: > >> Folks,**** >> >> ** ** >> >> We=E2=80=99re looking at text like this related to redirection:**** >> >> ** ** >> >> WebFinger servers MAY redirect a client using a redirection HTTP status >> code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI= . >> Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOUL= Dfollow all server redirects to HTTPS URIs. >> **** >> >> ** ** >> >> Note the word =E2=80=9CSHOULD=E2=80=9D on the client=E2=80=99s requireme= nt to follow redirects. >> This softer requirement has been floated around on the list now for a we= ek >> or longer (e.g., see Sal=E2=80=99s note on 12 Dec 2012), but the -07 ver= sion of the >> document mandates that clients follow redirects. I cannot recall why th= is >> change was made, but it might have been out of security concerns.**** >> >> ** ** >> >> Now that we are using HTTPS only, should we change that SHOULD back to a >> MUST as was in the -07 draft?**** >> >> ** ** >> >> Paul**** >> >> ** ** >> > > --e89a8f921a1ec11b7904d13fb423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
For instance, if I look = up attacker@evil.example.net's WebFinger like:

=C2=A0 =C2=A0GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.com HTTP/1.= 1
=C2=A0 =C2=A0Host: evil.example.net=

And they reply:

=C2=A0 HTTP/1.1 302 Found
=C2=A0 Lo= cation: http://10.0.0.17/some/internal/service/delete_account?user=3Dv= ictim

Is it a MUST that I follow that redirect? =C2=A0Hell no.

Thi= s is why I wrote=C2=A0http://search.cpan.org/~bradfitz/LWPx-= ParanoidAgent/lib/LWPx/ParanoidAgent.pm back in the day, but variants w= ith similar policies exist for nearly all languages / organizations.




On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@goog= le.com> wrote:
I wo= uldn't worry about it. =C2=A0SHOULD is fine.

Some small number of people will violate it anyway for security or paranoia= reasons (and they probably know what they're doing), and most people w= ill be using some higher-level HTTP client that doesn't give them optio= ns anyway and will probably just do the right thing.

So chan= ging the wording only affects a small number of people who won't care t= o necessarily follow it anyway.



<= div class=3D"gmail_quote">On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

We=E2=80=99re looking at text like this related to r= edirection:

=C2=A0

WebFinger servers MAY re= direct a client using a redirection HTTP status code to another HTTPS URI, = but MUST NOT redirect a client to an HTTP URI.=C2=A0 Further, clients MUST = NOT follow a redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs.<= /p>

=C2=A0

Note = the word =E2=80=9CSHOULD=E2=80=9D on the client=E2=80=99s requirement to fo= llow redirects.=C2=A0 This softer requirement has been floated around on th= e list now for a week or longer (e.g., see Sal=E2=80=99s note on 12 Dec 201= 2), but the -07 version of the document mandates that clients follow redire= cts.=C2=A0 I cannot recall why this change was made, but it might have been= out of security concerns.

=C2=A0

Now t= hat we are using HTTPS only, should we change that SHOULD back to a MUST as= was in the -07 draft?

=C2=A0

Paul

=C2=A0



--e89a8f921a1ec11b7904d13fb423-- From tbray@textuality.com Wed Dec 19 18:48:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2C21F88D4 for ; Wed, 19 Dec 2012 18:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79pjz10kuCct for ; Wed, 19 Dec 2012 18:48:10 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B78421F88A3 for ; Wed, 19 Dec 2012 18:48:10 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so865224wib.3 for ; Wed, 19 Dec 2012 18:48:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=n6aCOVObFaqLxiBpIywLuAgK+I+Q1+eH5xCzKGwvrks=; b=C5B7QO6riQcbIl8GZvJHoUF+ceNW4rWQEquEYIyN56YZ+BOvV+an1Zs7cta0SVO/ho 1Yr+qktKVZtogrGwbNT4o2T4gnXXH5XHB2OmZg5w3RajP//8s3iSgAKU36Z6i6KHKw6x buCscmPFGX9KNAGzJxue8WM0Mn1t6rhZYR/8LW3Qea6OrID8D9cpLpZvglgg1S2j7zTJ 9upJAbRUb6+YdftBO7pC6xzgfw+6r45sOkFzSYRJcleetrnfIwTlgShMx5TrRf5JCupn 16OjD4wARvbknUDOmIYY+8ACHcTAUNNsO0MHqxKHzXMnK2pvn3mG+t4ppG90chigvD2M Gd/g== MIME-Version: 1.0 Received: by 10.194.7.104 with SMTP id i8mr14903693wja.27.1355971685102; Wed, 19 Dec 2012 18:48:05 -0800 (PST) Received: by 10.227.11.202 with HTTP; Wed, 19 Dec 2012 18:48:04 -0800 (PST) X-Originating-IP: [65.123.3.106] Received: by 10.227.11.202 with HTTP; Wed, 19 Dec 2012 18:48:04 -0800 (PST) In-Reply-To: References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> Date: Wed, 19 Dec 2012 18:48:04 -0800 Message-ID: From: Tim Bray To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=047d7b5d43a49db39104d13fc23b X-Gm-Message-State: ALoCoQkYWpEebubvY+VwrnF5tD2z64EnQXWhoJokTW/S1fUQ6hFIs7qPWcHS2tSlzjPnTEOGJMPY Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:48:13 -0000 --047d7b5d43a49db39104d13fc23b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'd just say "retrieval must be via HTTPS" and defer all this http stuff to the http spec. I just don't see how we add value by discussing details of how to redirect; the state of that art is well understood On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" wrote: > For instance, if I look up attacker@evil.example.net's WebFinger like: > > GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.comHT= TP/1.1 > Host: evil.example.net > > And they reply: > > HTTP/1.1 302 Found > Location: > http://10.0.0.17/some/internal/service/delete_account?user=3Dvictim > > Is it a MUST that I follow that redirect? Hell no. > > This is why I wrote > http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgen= t.pmback in the day, but variants with similar policies exist for nearly al= l > languages / organizations. > > > > > On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick wr= ote: > >> I wouldn't worry about it. SHOULD is fine. >> >> Some small number of people will violate it anyway for security or >> paranoia reasons (and they probably know what they're doing), and most >> people will be using some higher-level HTTP client that doesn't give the= m >> options anyway and will probably just do the right thing. >> >> So changing the wording only affects a small number of people who won't >> care to necessarily follow it anyway. >> >> >> >> On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones wr= ote: >> >>> Folks,**** >>> >>> ** ** >>> >>> We=92re looking at text like this related to redirection:**** >>> >>> ** ** >>> >>> WebFinger servers MAY redirect a client using a redirection HTTP status >>> code to another HTTPS URI, but MUST NOT redirect a client to an HTTP UR= I. >>> Further, clients MUST NOT follow a redirection to an HTTP URI, but >>> SHOULD follow all server redirects to HTTPS URIs.**** >>> >>> ** ** >>> >>> Note the word =93SHOULD=94 on the client=92s requirement to follow redi= rects. >>> This softer requirement has been floated around on the list now for a w= eek >>> or longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version = of the >>> document mandates that clients follow redirects. I cannot recall why t= his >>> change was made, but it might have been out of security concerns.**** >>> >>> ** ** >>> >>> Now that we are using HTTPS only, should we change that SHOULD back to = a >>> MUST as was in the -07 draft?**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >> >> > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --047d7b5d43a49db39104d13fc23b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'd just say "retrieval must be via HTTPS" and= defer all this http stuff to the http spec. I just don't see how we ad= d value by discussing details of how to redirect; the state of that art is = well understood

On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick&= quot; <bradfitz@google.com>= ; wrote:
For instance, if I look up attacker@evil.examp= le.net's WebFinger like:

=A0 =A0= GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.com HTTP/1.= 1
=A0 =A0Host: evil.exa= mple.net

And they reply:

=A0 HTTP/1.1 302 Found
=A0 Location: http://10.0.0.17/some/internal/service/delete_account?us= er=3Dvictim

Is it a= MUST that I follow that redirect? =A0Hell no.

This is why I wrote=A0http://search.cpan.org/~bradfitz/LWPx-ParanoidAge= nt/lib/LWPx/ParanoidAgent.pm back in the day, but variants with similar= policies exist for nearly all languages / organizations.




On W= ed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@google.com&g= t; wrote:
I wo= uldn't worry about it. =A0SHOULD is fine.

Some small number of people will violate it anyway for security or paranoia= reasons (and they probably know what they're doing), and most people w= ill be using some higher-level HTTP client that doesn't give them optio= ns anyway and will probably just do the right thing.

So chan= ging the wording only affects a small number of people who won't care t= o necessarily follow it anyway.



On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones <paulej@pa= cketizer.com> wrote:

Folks,

=A0

We=92re looking at text like this related to redirec= tion:

=A0

WebFinger servers MAY redirect a = client using a redirection HTTP status code to another HTTPS URI, but MUST = NOT redirect a client to an HTTP URI.=A0 Further, clients MUST NOT follow a= redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs.

=A0

Note the= word =93SHOULD=94 on the client=92s requirement to follow redirects.=A0 Th= is softer requirement has been floated around on the list now for a week or= longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version of the= document mandates that clients follow redirects.=A0 I cannot recall why th= is change was made, but it might have been out of security concerns.=

=A0

Now that= we are using HTTPS only, should we change that SHOULD back to a MUST as wa= s in the -07 draft?

=A0

<= p class=3D"MsoNormal">Paul

= =A0




_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--047d7b5d43a49db39104d13fc23b-- From chris.dent@gmail.com Thu Dec 20 03:48:51 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56721F85A3 for ; Thu, 20 Dec 2012 03:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+uM1ZVYwCPK for ; Thu, 20 Dec 2012 03:48:51 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id BEDDE21F84F0 for ; Thu, 20 Dec 2012 03:48:50 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t11so1473414wey.40 for ; Thu, 20 Dec 2012 03:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:x-x-sender:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=UmqX0fEtPFATdn29ZVaD8Dawd4dDwywYrq6bEFRJbGE=; b=OXTdhDQRY96Z1Kd2IQY+VtpsW0znlnc7fgI5b9/x+55FuZ3AdNWirYREcbfkT03VpE rNX717vqshOxGe3WMrzMGJkRWyxrPJZEstq5WDVJpjk3dRs5ruJb31l59UPrGLdJA6+v 9yNOEAa6ZxijIHu1CAcOm/HgV2r+8JPgsn1S028MSNnMwE0ys3Kylrom5GsxTtQ/Zz7T h6Azjq5yt5R6x9lJ9/vjRppZczIh7pjxrNCPjBPMa9bLGku2KFLP4M1P+wqxsRrQjhCy TYUHgJVwgSEVLoNeB9p2dz/vEzLXj7PQ4YbX6lv/K6F0t59MeyVTCIby0sXeksaChplH 285g== X-Received: by 10.180.107.5 with SMTP id gy5mr9289910wib.30.1356004129977; Thu, 20 Dec 2012 03:48:49 -0800 (PST) Received: from [10.129.206.80] ([94.117.67.188]) by mx.google.com with ESMTPS id gz3sm24854378wib.2.2012.12.20.03.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 03:48:48 -0800 (PST) Date: Thu, 20 Dec 2012 11:48:43 +0000 (GMT) From: chris.dent@gmail.com X-X-Sender: cdent@crank.local In-Reply-To: Message-ID: References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:48:51 -0000 On Wed, 19 Dec 2012, Tim Bray wrote: > I'd just say "retrieval must be via HTTPS" and defer all this http stuff to > the http spec. I just don't see how we add value by discussing details of > how to redirect; the state of that art is well understood +1 -- Chris Dent http://burningchrome.com/ [...] From paulej@packetizer.com Thu Dec 20 07:51:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF321F90E5 for ; Thu, 20 Dec 2012 07:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRbTBdoaGXKE for ; Thu, 20 Dec 2012 07:51:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1D21F901E for ; Thu, 20 Dec 2012 07:51:32 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKFpR8Y029741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 10:51:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356018688; bh=r3U/1QMozqpelY7BDNP1OwrY50no1cMlfKRhlLaZDP0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=S+O8ShtpUAEBtXVBFvVBmFFZzLLM0YAU71FPd2W31HLMUOShLZ2MmbdIjqJB3eywk p9X/FwVo0EsAZ0GZHsrq2mNjEy90/JCU42831llapV4nW7GnstTqyTEJns/uwV1hhs DvBrv+uBcWKvphhCJO63MGYX5QbKtveTSHzSNNM0= From: "Paul E. Jones" To: "'Tim Bray'" , "'Brad Fitzpatrick'" References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 10:51:35 -0500 Message-ID: <040c01cddec9$e47889b0$ad699d10$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040D_01CDDE9F.FBA3BA30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOyPbJuXv3goOnONrSBfFeznWB/QLs/4vgAPvL3l0B5Gtxdpbxl73A Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:51:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040D_01CDDE9F.FBA3BA30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The reason the text is there relates to security. Specifically, we do not want it to be legal for a WF server to redirect a client that queried via HTTPS to be directed to a non-secure URI. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Wednesday, December 19, 2012 9:48 PM To: Brad Fitzpatrick Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? I'd just say "retrieval must be via HTTPS" and defer all this http stuff to the http spec. I just don't see how we add value by discussing details of how to redirect; the state of that art is well understood On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" wrote: For instance, if I look up attacker@evil.example.net's WebFinger like: GET /.well-known/webfinger?resource=acct:attacker@evil.example.com HTTP/1.1 Host: evil.example.net And they reply: HTTP/1.1 302 Found Location: http://10.0.0.17/some/internal/service/delete_account?user=victim Is it a MUST that I follow that redirect? Hell no. This is why I wrote http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgent.p m back in the day, but variants with similar policies exist for nearly all languages / organizations. On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick wrote: I wouldn't worry about it. SHOULD is fine. Some small number of people will violate it anyway for security or paranoia reasons (and they probably know what they're doing), and most people will be using some higher-level HTTP client that doesn't give them options anyway and will probably just do the right thing. So changing the wording only affects a small number of people who won't care to necessarily follow it anyway. On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones wrote: Folks, We're looking at text like this related to redirection: WebFinger servers MAY redirect a client using a redirection HTTP status code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs. Note the word "SHOULD" on the client's requirement to follow redirects. This softer requirement has been floated around on the list now for a week or longer (e.g., see Sal's note on 12 Dec 2012), but the -07 version of the document mandates that clients follow redirects. I cannot recall why this change was made, but it might have been out of security concerns. Now that we are using HTTPS only, should we change that SHOULD back to a MUST as was in the -07 draft? Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_040D_01CDDE9F.FBA3BA30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The reason the text is there relates to security.   = Specifically, we do not want it to be legal for a WF server to redirect = a client that queried via HTTPS to be directed to a non-secure = URI.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Tim Bray
Sent: Wednesday, December 19, 2012 9:48 = PM
To: Brad Fitzpatrick
Cc: webfinger@ietf.org; = webfinger@googlegroups.com
Subject: Re: [webfinger] WebFinger = redirection: client SHOULD or MUST?

 

I'd just say "retrieval = must be via HTTPS" and defer all this http stuff to the http spec. = I just don't see how we add value by discussing details of how to = redirect; the state of that art is well understood

On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" = <bradfitz@google.com> = wrote:

For = instance, if I look up attacker@evil.example.net's WebFinger = like:

 

  =  GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.com = HTTP/1.1

  =  Host: evil.example.net

 

And they = reply:

 

  = HTTP/1.1 302 Found

 

Is it a MUST = that I follow that redirect?  Hell = no.

 

This is why = I wrote http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib= /LWPx/ParanoidAgent.pm back in the day, but variants with similar = policies exist for nearly all languages / = organizations.

 

 

 

On Wed, Dec = 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

I wouldn't = worry about it.  SHOULD is fine.

 

Some small = number of people will violate it anyway for security or paranoia reasons = (and they probably know what they're doing), and most people will be = using some higher-level HTTP client that doesn't give them options = anyway and will probably just do the right = thing.

 

So changing = the wording only affects a small number of people who won't care to = necessarily follow it anyway.

 

 

On Wed, Dec = 19, 2012 at 6:39 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

We’re = looking at text like this related to redirection:

 <= /o:p>

WebFinger servers MAY redirect a client using a redirection HTTP = status code to another HTTPS URI, but MUST NOT redirect a client to an = HTTP URI.  Further, clients MUST NOT follow a redirection to an = HTTP URI, but SHOULD follow all = server redirects to HTTPS URIs.

 <= /o:p>

Note the = word “SHOULD” on the client’s requirement to follow = redirects.  This softer requirement has been floated around on the = list now for a week or longer (e.g., see Sal’s note on 12 Dec = 2012), but the -07 version of the document mandates that clients follow = redirects.  I cannot recall why this change was made, but it might = have been out of security concerns.

 <= /o:p>

Now that we = are using HTTPS only, should we change that SHOULD back to a MUST as was = in the -07 draft?

 

Paul

 

 

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

------=_NextPart_000_040D_01CDDE9F.FBA3BA30-- From tbray@textuality.com Thu Dec 20 07:53:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B683021F8842 for ; Thu, 20 Dec 2012 07:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6a8VeLedWMg for ; Thu, 20 Dec 2012 07:53:24 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id A00AD21F85DA for ; Thu, 20 Dec 2012 07:53:24 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so3374410obb.40 for ; Thu, 20 Dec 2012 07:53:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=geM6LqqxqqWKBJNcG5mBGYpf3tuRgOXFENIxNh4t+dE=; b=ExmhFfrOPTdYFg+NFDWrH0NIJuYJdtfOj2zqW5M4qL56ho1oxmgzrTa3bMTioXpDrf FExzCx5CoS6LlPm8RmKm8MSpwnVtsndVOo3YZj29aVK73BhuGLB3piVt+fM6/iDD0zwV O4Y3JMlXKOYm84IWmesXBG8LjcPSifEnaDC+g1Qg/KYYgUZdSzbkNbYCMf/UgVJ259Nq v1WOiGaN711xtF1Mfq173IxqNFK1BMHVwzNOQZXAaYXQKd8QOJkMduAZxZwCjsnZKjKY nybJQeUKU0AZUcWbdYBUSasx9UU9vFhtmdiFXha//qzNKrxMycCswadixwqqZjujj8j4 VTOg== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr8118993oeb.24.1356018804030; Thu, 20 Dec 2012 07:53:24 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 20 Dec 2012 07:53:23 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <040c01cddec9$e47889b0$ad699d10$@packetizer.com> References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> <040c01cddec9$e47889b0$ad699d10$@packetizer.com> Date: Thu, 20 Dec 2012 07:53:23 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f4181f7c4d04d14abb7b X-Gm-Message-State: ALoCoQkA0ejOpAkB1Tcq+Sw11kZy488O/+lqbg5/cY12VGe4JPYDf9yq68U03rvysXy+bkXUo/ER Cc: Brad Fitzpatrick , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:53:25 -0000 --e89a8fb1f4181f7c4d04d14abb7b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right, so if there=92s a one-liner at the beginning of the protocol section saying =93All requests (including redirects) MUST be directed to =93https:= =94 URIs=94 you=92ve got it covered. On Thu, Dec 20, 2012 at 7:51 AM, Paul E. Jones wrote= : > The reason the text is there relates to security. Specifically, we do > not want it to be legal for a WF server to redirect a client that queried > via HTTPS to be directed to a non-secure URI.**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Wednesday, December 19, 2012 9:48 PM > *To:* Brad Fitzpatrick > *Cc:* webfinger@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [webfinger] WebFinger redirection: client SHOULD or MUST?*= * > ** > > ** ** > > I'd just say "retrieval must be via HTTPS" and defer all this http stuff > to the http spec. I just don't see how we add value by discussing details > of how to redirect; the state of that art is well understood**** > > On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" wrote:*= * > ** > > For instance, if I look up attacker@evil.example.net's WebFinger like:***= * > > ** ** > > GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.comHT= TP/1.1 > **** > > Host: evil.example.net**** > > ** ** > > And they reply:**** > > ** ** > > HTTP/1.1 302 Found**** > > Location: > http://10.0.0.17/some/internal/service/delete_account?user=3Dvictim**** > > ** ** > > Is it a MUST that I follow that redirect? Hell no.**** > > ** ** > > This is why I wrote > http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgen= t.pmback in the day, but variants with similar policies exist for nearly al= l > languages / organizations.**** > > ** ** > > ** ** > > ** ** > > On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick > wrote:**** > > I wouldn't worry about it. SHOULD is fine.**** > > ** ** > > Some small number of people will violate it anyway for security or > paranoia reasons (and they probably know what they're doing), and most > people will be using some higher-level HTTP client that doesn't give them > options anyway and will probably just do the right thing.**** > > ** ** > > So changing the wording only affects a small number of people who won't > care to necessarily follow it anyway.**** > > ** ** > > ** ** > > On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > We=92re looking at text like this related to redirection:**** > > **** > > WebFinger servers MAY redirect a client using a redirection HTTP status > code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. > Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD= follow all server redirects to HTTPS URIs. > **** > > **** > > Note the word =93SHOULD=94 on the client=92s requirement to follow redire= cts. > This softer requirement has been floated around on the list now for a wee= k > or longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version of= the > document mandates that clients follow redirects. I cannot recall why thi= s > change was made, but it might have been out of security concerns.**** > > **** > > Now that we are using HTTPS only, should we change that SHOULD back to a > MUST as was in the -07 draft?**** > > **** > > Paul**** > > **** > > ** ** > > ** ** > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > --e89a8fb1f4181f7c4d04d14abb7b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right, so if there=92s a one-liner at the beginning of the protocol section= saying =93All requests (including redirects) MUST be directed to =93https:= =94 URIs=94 you=92ve got it covered.

On T= hu, Dec 20, 2012 at 7:51 AM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:

The reason th= e text is there relates to security.=A0=A0 Specifically, we do not want it = to be legal for a WF server to redirect a client that queried via HTTPS to = be directed to a non-secure URI.

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Wednesday, December 19, 2012 9:48 PM
To: Brad Fitzpa= trick
Cc: webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUS= T?

=A0

I'd just say "retrieval must be = via HTTPS" and defer all this http stuff to the http spec. I just don&= #39;t see how we add value by discussing details of how to redirect; the st= ate of that art is well understood

On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick= " <bradfit= z@google.com> wrote:

For instance, if I look up attacker@evil.example.net's WebFinger lik= e:

=A0

=A0 =A0GET /.well-known/webfinge= r?resource=3Dacct:attacker@evil.example.com HTTP/1.1

=A0 =A0Host: evil.example.net

=A0

And they reply:

=A0

=A0 HTTP/1.1 302 Found=

=A0

=A0

This is why I wrote=A0http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/= lib/LWPx/ParanoidAgent.pm back in the day, but variants with similar po= licies exist for nearly all languages / organizations.=

=A0

=A0

=A0

= On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

I wouldn't worry about= it. =A0SHOULD is fine.

=A0

Some small number of people will violate it anyway for security or= paranoia reasons (and they probably know what they're doing), and most= people will be using some higher-level HTTP client that doesn't give t= hem options anyway and will probably just do the right thing.=

=A0

So changing the wording only aff= ects a small number of people who won't care to necessarily follow it a= nyway.

=A0

=A0

On Wed, Dec 19, 2012 at 6:39 PM, Pau= l E. Jones <p= aulej@packetizer.com> wrote:

Folks,

=A0

We=92re looking at text li= ke this related to redirection:

=A0=

WebFinger servers MAY red= irect a client using a redirection HTTP status code to another HTTPS URI, b= ut MUST NOT redirect a client to an HTTP URI.=A0 Further, clients MUST NOT = follow a redirection to an HTTP URI, but = SHOULD follow all server redirects to HTTPS URIs.

=A0

Note the= word =93SHOULD=94 on the client=92s requirement to follow redirects.=A0 Th= is softer requirement has been floated around on the list now for a week or= longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version of the= document mandates that clients follow redirects.=A0 I cannot recall why th= is change was made, but it might have been out of security concerns.=

=A0

Now that= we are using HTTPS only, should we change that SHOULD back to a MUST as wa= s in the -07 draft?

=A0

Paul

=A0

=A0=

=A0<= u>


_______________________________________________
webfinger mailing li= st
webfinger@iet= f.org
https://www.ietf.org/mailman/listinfo/webfinger<= u>


--e89a8fb1f4181f7c4d04d14abb7b-- From paulej@packetizer.com Thu Dec 20 07:58:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5521F84E3 for ; Thu, 20 Dec 2012 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSMDWnGBSJZV for ; Thu, 20 Dec 2012 07:58:26 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9197821F843E for ; Thu, 20 Dec 2012 07:58:26 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKFwNLR030111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 10:58:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356019104; bh=zXWz1DFEd7BVPX1NsUr97B07jq2ilwB4rQVnA8o4xP4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=bCGHKsZ9qF5u3azVc+E8P/yw2wcr7DRECXMGxVWqIXq3kDHTYxrsDzZkQJRiZGdsP H7hSoJoM6kRIVmMSFi5VqXpTkq9hzX7x8YTPI0enr345NTQFN+yKmhmqgl3MzBZJk9 +2MfnlXUCHuZdOO0VsjvB4RCSJrFfdlLf2gI16Qw= From: "Paul E. Jones" To: "'Tim Bray'" References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> <040c01cddec9$e47889b0$ad699d10$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 10:58:31 -0500 Message-ID: <042501cddeca$dc4c4b40$94e4e1c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01CDDEA0.F377C9E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOyPbJuXv3goOnONrSBfFeznWB/QLs/4vgAPvL3l0B5GtxdgKolRHAAclG8cuWzgrOkA== Content-Language: en-us Cc: 'Brad Fitzpatrick' , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:58:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0426_01CDDEA0.F377C9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At present, it's just a two-liner. We could reduce it down to this: "A WebFinger server MAY redirect the client, but MUST only redirect the client to an HTTPS URI." Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, December 20, 2012 10:53 AM To: Paul E. Jones Cc: Brad Fitzpatrick; webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? Right, so if there's a one-liner at the beginning of the protocol section saying "All requests (including redirects) MUST be directed to "https:" URIs" you've got it covered. On Thu, Dec 20, 2012 at 7:51 AM, Paul E. Jones wrote: The reason the text is there relates to security. Specifically, we do not want it to be legal for a WF server to redirect a client that queried via HTTPS to be directed to a non-secure URI. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Wednesday, December 19, 2012 9:48 PM To: Brad Fitzpatrick Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? I'd just say "retrieval must be via HTTPS" and defer all this http stuff to the http spec. I just don't see how we add value by discussing details of how to redirect; the state of that art is well understood On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" wrote: For instance, if I look up attacker@evil.example.net's WebFinger like: GET /.well-known/webfinger?resource=acct:attacker@evil.example.com HTTP/1.1 Host: evil.example.net And they reply: HTTP/1.1 302 Found Location: http://10.0.0.17/some/internal/service/delete_account?user=victim Is it a MUST that I follow that redirect? Hell no. This is why I wrote http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgent.p m back in the day, but variants with similar policies exist for nearly all languages / organizations. On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick wrote: I wouldn't worry about it. SHOULD is fine. Some small number of people will violate it anyway for security or paranoia reasons (and they probably know what they're doing), and most people will be using some higher-level HTTP client that doesn't give them options anyway and will probably just do the right thing. So changing the wording only affects a small number of people who won't care to necessarily follow it anyway. On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones wrote: Folks, We're looking at text like this related to redirection: WebFinger servers MAY redirect a client using a redirection HTTP status code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD follow all server redirects to HTTPS URIs. Note the word "SHOULD" on the client's requirement to follow redirects. This softer requirement has been floated around on the list now for a week or longer (e.g., see Sal's note on 12 Dec 2012), but the -07 version of the document mandates that clients follow redirects. I cannot recall why this change was made, but it might have been out of security concerns. Now that we are using HTTPS only, should we change that SHOULD back to a MUST as was in the -07 draft? Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0426_01CDDEA0.F377C9E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At present, it’s just a two-liner.  We could reduce it = down to this:

 

“A WebFinger server MAY redirect the client, but MUST only = redirect the client to an HTTPS URI.”

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = December 20, 2012 10:53 AM
To: Paul E. Jones
Cc: = Brad Fitzpatrick; webfinger@ietf.org; = webfinger@googlegroups.com
Subject: Re: [webfinger] WebFinger = redirection: client SHOULD or MUST?

 

Right, so if there’s a one-liner at = the beginning of the protocol section saying “All requests = (including redirects) MUST be directed to “https:” = URIs” you’ve got it covered.

On Thu, Dec 20, 2012 at 7:51 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

The reason the text is there relates to security.   = Specifically, we do not want it to be legal for a WF server to redirect = a client that queried via HTTPS to be directed to a non-secure = URI.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Wednesday, December 19, 2012 9:48 = PM
To: Brad Fitzpatrick
Cc: webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] WebFinger redirection: client SHOULD or = MUST?

 <= /o:p>

I'd just say "retrieval must be via HTTPS" and = defer all this http stuff to the http spec. I just don't see how we add = value by discussing details of how to redirect; the state of that art is = well understood

On Dec 19, = 2012 6:44 PM, "Brad Fitzpatrick" <bradfitz@google.com> = wrote:

For = instance, if I look up attacker@evil.example.net's WebFinger = like:

 =

  =  GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.com = HTTP/1.1

  =  Host: evil.example.net

 =

And they = reply:

 =

  = HTTP/1.1 302 Found

 =

Is it a MUST = that I follow that redirect?  Hell = no.

 =

This is why = I wrote http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib= /LWPx/ParanoidAgent.pm back in the day, but variants with similar = policies exist for nearly all languages / = organizations.

 =

 =

 =

On Wed, Dec = 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@google.com> = wrote:

I wouldn't = worry about it.  SHOULD is fine.

 =

Some small = number of people will violate it anyway for security or paranoia reasons = (and they probably know what they're doing), and most people will be = using some higher-level HTTP client that doesn't give them options = anyway and will probably just do the right = thing.

 =

So changing = the wording only affects a small number of people who won't care to = necessarily follow it anyway.

 =

 =

On Wed, Dec = 19, 2012 at 6:39 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

We’re = looking at text like this related to redirection:

 <= /o:p>

WebFinger servers MAY redirect a client using a redirection HTTP = status code to another HTTPS URI, but MUST NOT redirect a client to an = HTTP URI.  Further, clients MUST NOT follow a redirection to an = HTTP URI, but SHOULD follow all = server redirects to HTTPS URIs.

 <= /o:p>

Note the = word “SHOULD” on the client’s requirement to follow = redirects.  This softer requirement has been floated around on the = list now for a week or longer (e.g., see Sal’s note on 12 Dec = 2012), but the -07 version of the document mandates that clients follow = redirects.  I cannot recall why this change was made, but it might = have been out of security concerns.

 <= /o:p>

Now that we = are using HTTPS only, should we change that SHOULD back to a MUST as was = in the -07 draft?

 

Paul

 

 =

 =


______________= _________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0426_01CDDEA0.F377C9E0-- From tbray@textuality.com Thu Dec 20 08:00:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06821F84F6 for ; Thu, 20 Dec 2012 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfIVkbfw777 for ; Thu, 20 Dec 2012 08:00:04 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2C65121F84E3 for ; Thu, 20 Dec 2012 07:59:59 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id xn12so3385085obc.4 for ; Thu, 20 Dec 2012 07:59:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dVubRrEN2Gt469Sm1MbOPbGYqop0wVf6JxjwcKp7nJ4=; b=F9vI9fBtqAFgchpoNpBVUkKCmNpVDnY3iCqVbOlWFnmUcJgIhDuXwpTD66feGZWcG/ f7sBWRHadP53fQb4fdwAtziR6aCYP4IZ+TLA5MqdLvboNrDs2i2XT+k4GyVqAQi/VkQS TC92jbFocdbNLN6m3whq/hI50I0Qhn/Kjn9Gfljj/JUOq4+DDcAnALixWCaGlszEYsDl yZIuA648J2V+FWn3fqF4x0bK64LBDrZPpaUPXTgjpJvTUPnKi0QxTcCSW17oVR4VdKn8 yQIEQN6rZRfjHIH8RMc1g1e4bly/DN7jtfFhp/VuNgh9XpphrPbfejpNNOZUubS9kFV7 0+mw== MIME-Version: 1.0 Received: by 10.182.52.105 with SMTP id s9mr8404289obo.25.1356019198593; Thu, 20 Dec 2012 07:59:58 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 20 Dec 2012 07:59:58 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <042501cddeca$dc4c4b40$94e4e1c0$@packetizer.com> References: <034501cdde5b$2e427570$8ac76050$@packetizer.com> <040c01cddec9$e47889b0$ad699d10$@packetizer.com> <042501cddeca$dc4c4b40$94e4e1c0$@packetizer.com> Date: Thu, 20 Dec 2012 07:59:58 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9399429a40ab204d14ad217 X-Gm-Message-State: ALoCoQnrKO5gGGhIyY4e4Yg5LtleC5tyrsIxyAX9KsLwNyTBmQdiyIf6ikkUscMVu7XLiimEvfWz Cc: Brad Fitzpatrick , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUST? X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:00:05 -0000 --14dae9399429a40ab204d14ad217 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 On Thu, Dec 20, 2012 at 7:58 AM, Paul E. Jones wrote= : > At present, it=92s just a two-liner. We could reduce it down to this:***= * > > ** ** > > =93A WebFinger server MAY redirect the client, but MUST only redirect the > client to an HTTPS URI.=94**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Thursday, December 20, 2012 10:53 AM > *To:* Paul E. Jones > *Cc:* Brad Fitzpatrick; webfinger@ietf.org; webfinger@googlegroups.com > > *Subject:* Re: [webfinger] WebFinger redirection: client SHOULD or MUST?*= * > ** > > ** ** > > Right, so if there=92s a one-liner at the beginning of the protocol secti= on > saying =93All requests (including redirects) MUST be directed to =93https= :=94 > URIs=94 you=92ve got it covered.**** > > On Thu, Dec 20, 2012 at 7:51 AM, Paul E. Jones > wrote:**** > > The reason the text is there relates to security. Specifically, we do > not want it to be legal for a WF server to redirect a client that queried > via HTTPS to be directed to a non-secure URI.**** > > **** > > Paul**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Wednesday, December 19, 2012 9:48 PM > *To:* Brad Fitzpatrick > *Cc:* webfinger@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [webfinger] WebFinger redirection: client SHOULD or MUST?*= * > ** > > **** > > I'd just say "retrieval must be via HTTPS" and defer all this http stuff > to the http spec. I just don't see how we add value by discussing details > of how to redirect; the state of that art is well understood**** > > On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick" wrote:*= * > ** > > For instance, if I look up attacker@evil.example.net's WebFinger like:***= * > > **** > > GET /.well-known/webfinger?resource=3Dacct:attacker@evil.example.comHT= TP/1.1 > **** > > Host: evil.example.net**** > > **** > > And they reply:**** > > **** > > HTTP/1.1 302 Found**** > > Location: > http://10.0.0.17/some/internal/service/delete_account?user=3Dvictim**** > > **** > > Is it a MUST that I follow that redirect? Hell no.**** > > **** > > This is why I wrote > http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/lib/LWPx/ParanoidAgen= t.pmback in the day, but variants with similar policies exist for nearly al= l > languages / organizations.**** > > **** > > **** > > **** > > On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick > wrote:**** > > I wouldn't worry about it. SHOULD is fine.**** > > **** > > Some small number of people will violate it anyway for security or > paranoia reasons (and they probably know what they're doing), and most > people will be using some higher-level HTTP client that doesn't give them > options anyway and will probably just do the right thing.**** > > **** > > So changing the wording only affects a small number of people who won't > care to necessarily follow it anyway.**** > > **** > > **** > > On Wed, Dec 19, 2012 at 6:39 PM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > We=92re looking at text like this related to redirection:**** > > **** > > WebFinger servers MAY redirect a client using a redirection HTTP status > code to another HTTPS URI, but MUST NOT redirect a client to an HTTP URI. > Further, clients MUST NOT follow a redirection to an HTTP URI, but SHOULD= follow all server redirects to HTTPS URIs. > **** > > **** > > Note the word =93SHOULD=94 on the client=92s requirement to follow redire= cts. > This softer requirement has been floated around on the list now for a wee= k > or longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version of= the > document mandates that clients follow redirects. I cannot recall why thi= s > change was made, but it might have been out of security concerns.**** > > **** > > Now that we are using HTTPS only, should we change that SHOULD back to a > MUST as was in the -07 draft?**** > > **** > > Paul**** > > **** > > **** > > **** > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --14dae9399429a40ab204d14ad217 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1

On Thu, Dec 20, 2012 at 7:58 AM, Paul = E. Jones <paulej@packetizer.com> wrote:

At present, it=92s just a two-liner.=A0 We c= ould reduce it down to this:

=A0<= /p>

=93A WebFinger server = MAY redirect the client, but MUST only redirect the client to an HTTPS URI.= =94

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, December 20, 2012 10:53 AM
To: Paul E. Jon= es
Cc: Brad Fitzpatrick; webfinger@ietf.org; webfinger@googlegroups.com


Subject: Re: [webfinger] WebFinger redire= ction: client SHOULD or MUST?

<= div>

=A0

Right, so if there=92s a one-liner at the beginning of the protocol section= saying =93All requests (including redirects) MUST be directed to =93https:= =94 URIs=94 you=92ve got it covered.

On Thu, Dec 20, 2012 at 7:51 AM, Paul E. Jones <paulej@packetizer.com> wro= te:

The reason the = text is there relates to security.=A0=A0 Specifically, we do not want it to= be legal for a WF server to redirect a client that queried via HTTPS to be= directed to a non-secure URI.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Wednesday, December 19, 2012 9:48 PM
To: Brad Fitzpa= trick
Cc: webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: [webfinger] WebFinger redirection: client SHOULD or MUS= T?

=A0=

I'd just say "retrieval must be via HTTPS&quo= t; and defer all this http stuff to the http spec. I just don't see how= we add value by discussing details of how to redirect; the state of that a= rt is well understood

On Dec 19, 2012 6:44 PM, "Brad Fitzpatrick= " <bradfit= z@google.com> wrote:

For instance, if I look up attacker@evil.example.net's WebFinger lik= e:

=A0

=A0 =A0GET /.well-known/webfinge= r?resource=3Dacct:attacker@evil.example.com HTTP/1.1

=A0 =A0Host: evil.example.net<= /u>

=A0

And they reply:

=A0

=A0 HTTP/1.1 302 Found=

=A0

=A0

This is why I wrote=A0http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent/= lib/LWPx/ParanoidAgent.pm back in the day, but variants with similar po= licies exist for nearly all languages / organizations.=

=A0

=A0

=A0

= On Wed, Dec 19, 2012 at 6:41 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:

I wouldn't worry about= it. =A0SHOULD is fine.

=A0

Some small number of people will violate it anyway for security or= paranoia reasons (and they probably know what they're doing), and most= people will be using some higher-level HTTP client that doesn't give t= hem options anyway and will probably just do the right thing.=

=A0

So changing the wording only aff= ects a small number of people who won't care to necessarily follow it a= nyway.

=A0

=A0

On Wed, Dec 19, 2012 at 6:39 PM, Pau= l E. Jones <p= aulej@packetizer.com> wrote:

Folks,

=A0

We=92re looking at text li= ke this related to redirection:

=A0=

WebFinger servers MAY red= irect a client using a redirection HTTP status code to another HTTPS URI, b= ut MUST NOT redirect a client to an HTTP URI.=A0 Further, clients MUST NOT = follow a redirection to an HTTP URI, but = SHOULD follow all server redirects to HTTPS URIs.

=A0

Note the= word =93SHOULD=94 on the client=92s requirement to follow redirects.=A0 Th= is softer requirement has been floated around on the list now for a week or= longer (e.g., see Sal=92s note on 12 Dec 2012), but the -07 version of the= document mandates that clients follow redirects.=A0 I cannot recall why th= is change was made, but it might have been out of security concerns.=

=A0

Now that= we are using HTTPS only, should we change that SHOULD back to a MUST as wa= s in the -07 draft?

=A0

Paul<= /u>

=A0

=A0=

=A0<= u>


_______________________________________________
webfinger mailing li= st
webfinger@iet= f.org
https://www.ietf.org/mailman/listinfo/webfinger<= u>

=A0=


--14dae9399429a40ab204d14ad217-- From nick@silverbucket.net Thu Dec 20 08:25:46 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1774E21F8908 for ; Thu, 20 Dec 2012 08:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo374uyYONm4 for ; Thu, 20 Dec 2012 08:25:38 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8021F8928 for ; Thu, 20 Dec 2012 08:25:37 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so3504209obc.13 for ; Thu, 20 Dec 2012 08:25:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=jzHIUpQb+ePHScRVczTnFXESJIQIJR62IrhjPL64twg=; b=kDyk1SPj2mO36PIAqDTPjfGPUUmWyjtpm0wu7uEmonP4NPA7vpcYs3d0UoQBEzXWO9 hYjfs8xr0h0PqagE2JT/87K5W7zNjKBTHfwUbFdVipRd5JVF9RtNDUaw050FvdJWoXgt FBAWVY9Xbr1lEqChvrRT0tKKrByp1ktmZX4MTGCgUXRzSwkYdWlmM/vN5nLB8M26KVDR e2rZw1thwEZGSegRBTN6uCv5rP3KxZ0+lo3txRw2jmyHjnPEg2Os/kvnkCeeD2/c/6AS yB/+Ea/7nRD9MRt//uxFcyY2oKZahDR853SOdXYfYINMmM93GeqZfMaMJKgTDUj/JKNS sTUA== X-Received: by 10.60.169.135 with SMTP id ae7mr8250777oec.82.1356020737307; Thu, 20 Dec 2012 08:25:37 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx.google.com with ESMTPS id u1sm6098021oee.8.2012.12.20.08.25.35 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:25:35 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id o6so3622828oag.11 for ; Thu, 20 Dec 2012 08:25:34 -0800 (PST) Received: by 10.182.17.66 with SMTP id m2mr8463060obd.86.1356020734467; Thu, 20 Dec 2012 08:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.92.66 with HTTP; Thu, 20 Dec 2012 08:25:04 -0800 (PST) In-Reply-To: References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> From: Nick Jennings Date: Thu, 20 Dec 2012 17:25:04 +0100 Message-ID: To: webfinger@googlegroups.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmYA0f7O+dT2OnnlTGDFsmXv+LgyldQZ8HCorD88urU01gFvFl0uMUc3DTIP54Xf97oiUki Cc: "Paul E. Jones" , Melvin Carvalho , "webfinger@ietf.org" Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:25:47 -0000 On Tue, Dec 18, 2012 at 11:19 PM, Goix Laurent Walter wrote: >> -----Messaggio originale----- >> Da: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] Per c= onto >> di Nick Jennings >> Inviato: marted=C3=AC 18 dicembre 2012 20.37 >> A: Paul E. Jones >> Cc: webfinger@googlegroups.com; webfinger@ietf.org; Melvin Carvalho >> Oggetto: Re: [webfinger] Possibly speeding up the RFC process >> >> On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones w= rote: >> > Nick, >> > >> >> > PEJ: WebFinger uses any URI scheme. The =E2=80=9Cacct=E2=80=9D sch= eme is just one of >> >> > them and is not core to the spec now, though there is a statement >> >> > recommending its use to identify accounts. That is its purpose and >> >> > the =E2=80=9Cacct=E2=80=9D URI, and it=E2=80=99s a valid purpose. = The one example I like to >> >> > give is =E2=80=9CHow do we identify an account at Twitter?=E2=80=9D= There is no >> >> > email, so =E2=80=9Cmailto=E2=80=9D is not the right URI. A user ha= s an account at any >> >> > service provider and the =E2=80=9Cacct=E2=80=9D URI would identify = the account, not >> >> > the particular service at the service provider (e.g., email, XMPP, = or >> >> whatever). >> >> > >> >> >> >> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm = not >> >> missing something. >> >> >> >> Maybe I don't fully understand the various use-cases, but it seems li= ke >> >> you are saying that when querying a 'resource', the value does NOT ne= ed >> >> to be prefixed with acct (or anything). I know there's the idea that = at >> >> some point another type of resource could be identified as relevant a= nd >> >> so that was the argument for having the 'acct' prefix. >> >> However your wording suggests that even 'acct' is not needed. So >> >> someone's WF service could accept 'resource=3Dbob' and not >> >> 'resource=3Dacct:bob@example.com' and it would still be a compliant W= F >> >> service? If true, it seems like there could be a lot of room for >> >> uncertainty in query format and client libraries would have to try a >> >> number of different value formats. >> > >> > What the spec says is that any URI may be queried. That's what I mean= t. >> The protocol is not designed to be used only with "acct:". One may quer= y WF >> using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" or >> "urn:". Obviously, URI schemes that do not have domain names present is= sues, >> but that it's certainly possible and I suspect there would be an agreed >> client/server relationship. >> > >> > My own server code actually will accept just "paulej@packetizer.com", = for >> example. If it sees that, it assumes the requestor wants >> "acct:paulej@packetizer.com" and returns the results from the database f= or the >> "acct:" URI. However, the "subject" is just the bare "paulej@packetizer= .com" >> and the "acct:" URI is inserted into the response as an alias. However,= none >> of that is in the spec. I did that long ago, because Blaine preferred t= o not >> require a URI scheme for user@domain forms. >> > >> >> Another thing, in regards to the twitter example you gave. What's to >> >> differentiate a user of twitter and an employee of twitter? >> >> >> >> There could be a user '@janice' and an employee 'janice@twitter.com', >> >> who may be different people. As I understand it, in your example, the= se >> >> different accounts would be queried in the same way. >> >> >> >> /.host-meta/webfinger?resource=3Dacct:janice@twitter.com >> > >> > Users and employees must have different values within the scope= of >> the domain (or sub-domain). Some time ago, somebody mentioned that they= have >> a domain with user accounts and employees where the user account names d= id >> clash with employee names. I don't have a solution for that. Personall= y, I >> think that's an unfortunate situation to be in. >> > >> > On my own web site, I run phpBB. There are user accounts. So, I can >> appreciate how people get into that situation. However, I placed the >> discussion forms at forums.packetizer.com and so if the phpBB software e= ver >> supported WebFinger (hmmmm... more holiday coding opportunities) then I = would >> expect it to respond only to acct:@forums.packetizer.com. That wo= uld be >> perfectly fine and would avoid the name clash. WF does not require quer= ies >> only to the domain. Queries can be sent to any appropriate host within = the >> domain. >> > >> >> Am I misunderstanding? Or does this create a problem. >> > >> > There are potential issues for domain owners who have allocated the sa= me >> user identifier to more than one person on the same domain or sub-domain= . >> Domain owners will have to address that before deploying WF. >> > >> >> Hi Paul, >> >> I've been giving this some more thought, if the person running the WF >> service can make up their own system of identifying users (whatever >> works for them), then in order to write a robust WF client, you're >> going to have to do a lot of second guessing. I don't understand why >> we have 'acct:' if (a) it's not required at all, and (b) it's >> suggested we use the full 'user@example.com' anyway, however (c) we >> also don't have to do that... >> >> In the case of that twitter example. If they wanted to solve this >> issue, they might impose a system like: >> >> /.host-meta/webfinger?resource=3Djanice@twitter.com >> >> ...that gets the record for the employee Janice >> >> /.host-meta/webfinger?resource=3Dacct:janice >> >> ...that gets the record for the user-account 'janice' >> >> In this case 'acct' prefix referring to just the 'webapp' accounts, >> and not 'admin/employee' accounts. >> >> I think a clarification of what to use as the resource value to >> signify whether we are, querying an email address (used by, for >> example, and email client, or blog comments). or a user account (used >> by, for example, phpBB, wordpress, twitter, etc.) would be really >> helpful. >> >> Otherwise we're going to have similar client complexity to the issues >> we've already discussed regarding using fallback methods. though maybe >> more complicated because we could have false positives if, for >> example, janice@twitter.com is queried for a user account but the >> profile for the employee is returned. >> >> Does anyone else see the ambiguity here as a potentially pretty bad prob= lem? > > I personally don't see the issue here. Facebook uses different domains fo= r their users vs their employess. It's unfortunate if titter do not does th= is but i twas said many times in the past on this list that acct: addresses= with the same value than mailto: addresses may actually not be related to = the same person. (although it would make sense, technically there is no bin= ding for this). > I wouldn't enter the debate of who's represented behind a specific URI. I= t is up to the domain admin to manage the account namespace. Could you bett= er clarify your issue here? > > Re the acct: URI scheme I do support Paul's view that at this stage there= is no URI-way of identifying *user accounts* globally. It is already widel= y used in federated social networks that will become a big consumer of webf= inger eventually and could easily reuse these "acct:" URIs in activity stre= ams in the actor/id field (normatively defined as anyURI). > > Third, wf was designed for supporting any URI including for example http:= , which are not in the form of user@domain. And in general I would recommen= d that an ietf spec formally define the "resource" parameter as anyURI inst= ead of a free-form string. > Hi Walter and Paul, I don't want to beat a dead horse, but so far I feel like either I'm missing something pretty major, or I'm not making myself clear. So I'll give it another shot: My concern is that there seems to me to be a BIG ambiguity problem which could create false positives during lookups, and different conventions could be made up by sites with emails & web accounts on the same server, that might require a WF client to use several different URIs to find a record (and there's not 100% sure way of knowing they got the right record). If there is a WF client in a mail-app, it's going to want to query against the email address. Not a website account. So, IMO there needs to be a way to specify you are querying for an email address, what that method is, I don't know, but the ambiguity of 'acct' is problematic for a client library that knows exactly what it's talking about (an email address). /.host-meta/webfinger?resource=3Dmailto:user@example.com This would make it clear to the server "I got an *email address* and would like any record associated with it. Whereas: /.host-meta/webfinger?resource=3Dacct:user@example.com OR /.host-meta/webfinger?resource=3Dhttp://example.com/users/user Would make it clear that you are querying 'user' from the sites user accounts. This could be the way of implying "whatever service you host, I need a record for a user of this name". If the WF server was an email server, then it could be one in the same as a mailto:user@example.com URI and the result would be the same no matter what. However if it's twitter (for example) or some other web service with accounts, it would know you mean the account 'user' of that web service. My point is that the context is only really going to be known by the client, and it will have no way of knowing if the result it got was for the right account because it has no way of being specific. IMO this is trivial to implement on the server side (by default, mailto and acct would be one in the same, but you could split the two if you needed) and would make things easy to clarify by the client when needed. -Nick From paulej@packetizer.com Thu Dec 20 08:28:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB421F895F for ; Thu, 20 Dec 2012 08:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zTmdq1TREQV for ; Thu, 20 Dec 2012 08:28:05 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23D21F8928 for ; Thu, 20 Dec 2012 08:27:58 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKGRull031579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 11:27:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356020877; bh=Q8weRrPSnP8w4Q63V87hVH0aJndjCVmColBUW9KZ698=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=QKlmrt94bYrh1KphHOjjlv8DZ1asgoM006XLGyeBYElDVeDeEu4Yeg5iqPwC9nfP/ s24/As9HIJ5A150H234nTGqmxcRJh2inl+W0bRgcWaDgv7tb+VqPjit7Sj7vsjAX1y 7IMtgDxbghUCSUbs15pjWa7VaU5ss3Ckx2Ia34ys= From: "Paul E. Jones" To: , Date: Thu, 20 Dec 2012 11:28:04 -0500 Message-ID: <044501cddece$fd045040$f70cf0c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0446_01CDDEA5.142E9660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ezrqCn0N7G4fYTMSGK1aRa6TeCQ== Content-Language: en-us Subject: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:28:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0446_01CDDEA5.142E9660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, We had this previously: "If the client queries the WebFinger server and provides a URI for which the server has no information, the server MUST return a 404 status code." Someone posted to the list that we should talk about positive replies and mention that a client might be rejected with a 401. So, I wrote this text to be appended to the end of that above paragraph: "If the server is able to provide information in response to a request, it MUST do so using an appropriate 2xx HTTP status code and including the requested representation in the body of the response. A server MAY also return other HTTP status codes, as appropriate, such as a 401 to indicate that the client is not authorized to issue a request to the server." Is this agreeable? Please suggest wording changes, if not. Paul ------=_NextPart_000_0446_01CDDEA5.142E9660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We had this = previously:

 

“If the client queries the WebFinger server and = provides a URI for which the server has no information, the server MUST = return a 404 status code.”

 

Someone = posted to the list that we should talk about positive replies and = mention that a client might be rejected with a 401.  So, I wrote = this text to be appended to the end of that above = paragraph:

 

“If the server is able to provide information in = response to a request, it MUST do so using an appropriate 2xx HTTP = status code and including the requested representation in the body of = the response.  A server MAY also return other HTTP status codes, as = appropriate, such as a 401 to indicate that the client is not authorized = to issue a request to the server.”

 

Is this = agreeable?  Please suggest wording changes, if = not.

 

Paul

 

 

------=_NextPart_000_0446_01CDDEA5.142E9660-- From paulej@packetizer.com Thu Dec 20 09:20:51 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465221F8953 for ; Thu, 20 Dec 2012 09:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cWkbg2+UmXq for ; Thu, 20 Dec 2012 09:20:50 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D051C21F8556 for ; Thu, 20 Dec 2012 09:20:40 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKHKaXn001761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 12:20:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356024039; bh=33VJtLrxXlyUsDxcffyv/YWTbD49EcryCeQELhnvG8A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rum1SUBB8A8dT8v3AmkHhidERxSYA95yZvMm6TyEbJhQnYtT8AWt68RBtkGYGQ430 40CkwO1zMo4+HvvKVs4Dxo4GTePQNIqi5zPa9AuyfROCI8YEb1XMamHh/uThpO9h8A 4i1FxURgwSrTegvL4BJIMkJzTFqhJHZL2jf7E7w0= From: "Paul E. Jones" To: "'Nick Jennings'" , References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 12:20:44 -0500 Message-ID: <047601cdded6$594c9090$0be5b1b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQHH/q7wmHqOPfA= Content-Language: en-us Cc: webfinger@ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:20:52 -0000 Nick, > I don't want to beat a dead horse, but so far I feel like either I'm > missing something pretty major, or I'm not making myself clear. So = I'll > give it another shot: >=20 > My concern is that there seems to me to be a BIG ambiguity problem = which > could create false positives during lookups, and different conventions > could be made up by sites with emails & web accounts on the same = server, > that might require a WF client to use several different URIs to find a > record (and there's not 100% sure way of knowing they got the right > record). That's what section 5.4 (next version will be 4.4) deal with. It is = recommended that we use the acct: URI when looking up information about = users if we're trying to find out something about their account. It goes on to say that mailto is not ideal for user accounts, but would = be useful for mail server configuration. If you want to see live = examples of the difference, see: curl https://packetizer.com/.well-known/webfinger? resource=3Dacct:paulej@packetizer.com vs. curl https://packetizer.com/.well-known/webfinger? resource=3Dmailto:paulej@packetizer.com The latter provides information about how my email client should = provision itself. =20 > If there is a WF client in a mail-app, it's going to want to query > against the email address. Not a website account. So, IMO there needs = to > be a way to specify you are querying for an email address, what that > method is, I don't know, but the ambiguity of 'acct' is problematic = for > a client library that knows exactly what it's talking about (an email > address). >=20 > /.host-meta/webfinger?resource=3Dmailto:user@example.com Yes, that's what is intended. =20 > This would make it clear to the server "I got an *email address* and > would like any record associated with it. >=20 > Whereas: >=20 > /.host-meta/webfinger?resource=3Dacct:user@example.com >=20 > OR >=20 > /.host-meta/webfinger?resource=3Dhttp://example.com/users/user >=20 > Would make it clear that you are querying 'user' from the sites user > accounts. This could be the way of implying "whatever service you = host, > I need a record for a user of this name". If the WF server was an = email > server, then it could be one in the same as a mailto:user@example.com > URI and the result would be the same no matter what. However if it's > twitter (for example) or some other web service with accounts, it = would > know you mean the account 'user' of that web service. If I were writing a client and saw an email address = "paulej@packetizer.com", I would assume the associated account URI is = acct:paulej@packetizer.com. Personally, I think that is a reasonable = thing to do. For a lot of reasons, I think having different user identifiers at the = same domain level is a bad idea and I don't know how people will deal = with that. They should not do that, really. People search for people = using these identifiers. It's an issue that extends beyond just WF. = Call it a part of "good domain hygiene". =20 > My point is that the context is only really going to be known by the > client, and it will have no way of knowing if the result it got was = for > the right account because it has no way of being specific. IMO this is > trivial to implement on the server side (by default, mailto and acct > would be one in the same, but you could split the two if you > needed) and would make things easy to clarify by the client when = needed. It would certainly be legitimate to have acct: and mailto: return the = same set of link relations. A client would likely be looking for only = certain "rel" values, anyway. However, I personally like to split them, = since they serve an entirely different purpose. If my XMPP client was = looking for how to configure itself, for example, I would expect it to = query like this: curl https://packetizer.com/.well-known/webfinger? resource=3Dxmpp:paulej@packetizer.com That will return a different set of results. There is only minimal = information there, since we have not actually defined the = auto-provisioning stuff. Again, this could all be returned as part of a = query to acct:, but I personally like the split. It could also be = possible that each of these URIs (acct:, mailto:, or xmpp:) are just = aliases of each other and, regardless of what the client queries, it = gets the same JRD. What I cannot fix are domains that have two people associated with a = given user identifier. Paul From jasnell@gmail.com Thu Dec 20 09:24:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4883821F8A5A for ; Thu, 20 Dec 2012 09:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.673 X-Spam-Level: X-Spam-Status: No, score=-3.673 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJosb4wtNYj for ; Thu, 20 Dec 2012 09:24:17 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 67C2C21F8A57 for ; Thu, 20 Dec 2012 09:24:17 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so4930237ieb.19 for ; Thu, 20 Dec 2012 09:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vy9Zx+kBBKNHDSbwEQKA0Z/EsPKtsdEwAIEMIz9I51c=; b=sg/PKxppvlrZzxED5G9RAfBDIJ8u5nERFIzJv4ak1xervi0nGTJZln8CmsSkNr2HBD EhpZ1Xl/5wac0zS9kCZskC8ZzZFqQUBdN8e54goCf6KacJpLv7Y0k3p7g9E0nVbX6Q4q 3Kyp1xoNe7dYhW+wNeFwMIxPtft3xUhiFI/0KdgfBrJKZSdZxF/LR5RUsdFFF8F5uR5R QgH7nsFkYqOTgmiyKNE82KmoG3uEAgHEU5CJM5p3u7rax423TyhvT3YA+Q/uUapT8o6V Yt0ZR54WFKKyeSCk8Xwt/fj47kDG7Ll1o2x31FxVLxshxGQSWdBvJSO8iymvq9zrg5gM /R7w== MIME-Version: 1.0 Received: by 10.50.178.10 with SMTP id cu10mr6344835igc.75.1356024249069; Thu, 20 Dec 2012 09:24:09 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 20 Dec 2012 09:24:08 -0800 (PST) Received: by 10.64.7.19 with HTTP; Thu, 20 Dec 2012 09:24:08 -0800 (PST) In-Reply-To: <044501cddece$fd045040$f70cf0c0$@packetizer.com> References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> Date: Thu, 20 Dec 2012 09:24:08 -0800 Message-ID: From: James M Snell To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f839ca1ac326704d14bffc2 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:24:21 -0000 --e89a8f839ca1ac326704d14bffc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This language is fine but the security considerations ought to recognize and briefly discuss the risk of returning 401's vs. 404's (as I had previously suggested). On Dec 20, 2012 8:28 AM, "Paul E. Jones" wrote: > Folks,**** > > ** ** > > We had this previously:**** > > ** ** > > =E2=80=9CIf the client queries the WebFinger server and provides a URI fo= r which > the server has no information, the server MUST return a 404 status code.= =E2=80=9D* > *** > > ** ** > > Someone posted to the list that we should talk about positive replies and > mention that a client might be rejected with a 401. So, I wrote this tex= t > to be appended to the end of that above paragraph:**** > > ** ** > > =E2=80=9CIf the server is able to provide information in response to a re= quest, it > MUST do so using an appropriate 2xx HTTP status code and including the > requested representation in the body of the response. A server MAY also > return other HTTP status codes, as appropriate, such as a 401 to indicate > that the client is not authorized to issue a request to the server.=E2=80= =9D**** > > ** ** > > Is this agreeable? Please suggest wording changes, if not.**** > > ** ** > > Paul**** > > ** ** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8f839ca1ac326704d14bffc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This language is fine but the security considerations ought = to recognize and briefly discuss the risk of returning 401's vs. 404= 9;s (as I had previously suggested).

On Dec 20, 2012 8:28 AM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:

Folks,

=C2=A0

=

We had this previously:

=C2=A0

=E2=80=9CIf the client queries the WebFinger server = and provides a URI for which the server has no information, the server MUST= return a 404 status code.=E2=80=9D

=C2=A0

Someone posted to the list that we should talk about= positive replies and mention that a client might be rejected with a 401.= =C2=A0 So, I wrote this text to be appended to the end of that above paragr= aph:

=C2=A0

=E2= =80=9CIf the server is able to provide information in response to a request= , it MUST do so using an appropriate 2xx HTTP status code and including the= requested representation in the body of the response.=C2=A0 A server MAY a= lso return other HTTP status codes, as appropriate, such as a 401 to indica= te that the client is not authorized to issue a request to the server.=E2= =80=9D

=C2=A0

Is th= is agreeable?=C2=A0 Please suggest wording changes, if not.

=C2=A0

Pau= l

=C2=A0

=C2=A0


________________________________________= _______
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--e89a8f839ca1ac326704d14bffc2-- From tbray@textuality.com Thu Dec 20 09:29:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22421F8449 for ; Thu, 20 Dec 2012 09:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zh+UCExIpr9 for ; Thu, 20 Dec 2012 09:29:38 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC821F8945 for ; Thu, 20 Dec 2012 09:29:37 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id uo13so3618374obb.36 for ; Thu, 20 Dec 2012 09:29:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=B4q6+/E+lYFreFQSoaG2SdkOqDziaUykFGK639OkKKM=; b=C4wM9XcpNF1OXGmhk1XE7DgBZ5bp7DtGohEyA9CRxMqCeBZBdFtoXM4F/vdu05Ctue +5ZxrnAhbnZQ1ey1OYFun/VDLJC0XLY4EHOvbfGdlZab91LhJXiznIJKvyWGjM2Sx771 C1M8BVHkCy6uZ8nEhFGJ1h/XFG+lvRexVDuT7ivOAXLFGFYLsbb1Sls4Ogc1DhpDtliT fM4fnDYeU4dwQ3Vtios0v/to5mYU0qO07v9lt/62bxwGKPjY0bO5Jw8Zm9ZQjoHGUVi0 MxKbIUIUZm9ohHemyo8oxBUeBY4vunrzpP8u1bbXe0kajUbP+zN+Hli1MamELFNrPc03 yiWQ== MIME-Version: 1.0 Received: by 10.60.32.200 with SMTP id l8mr8901217oei.43.1356024577002; Thu, 20 Dec 2012 09:29:37 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 20 Dec 2012 09:29:36 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <044501cddece$fd045040$f70cf0c0$@packetizer.com> References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> Date: Thu, 20 Dec 2012 09:29:36 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f5b0380e5204d14c1369 X-Gm-Message-State: ALoCoQlwcsyeanJO50qlKs1g5Z6HwB1mWkG4rOFjayFZfn0k4FN81WG+mIxjstQl3Gn3QMV4lsQF Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:29:38 -0000 --e89a8fb1f5b0380e5204d14c1369 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As in every other case where the WebFinger spec is merely re-iterating standard HTTP rules, I suggest just removing this language. -Tim On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > We had this previously:**** > > ** ** > > =93If the client queries the WebFinger server and provides a URI for whic= h > the server has no information, the server MUST return a 404 status code.= =94* > *** > > ** ** > > Someone posted to the list that we should talk about positive replies and > mention that a client might be rejected with a 401. So, I wrote this tex= t > to be appended to the end of that above paragraph:**** > > ** ** > > =93If the server is able to provide information in response to a request,= it > MUST do so using an appropriate 2xx HTTP status code and including the > requested representation in the body of the response. A server MAY also > return other HTTP status codes, as appropriate, such as a 401 to indicate > that the client is not authorized to issue a request to the server.=94***= * > > ** ** > > Is this agreeable? Please suggest wording changes, if not.**** > > ** ** > > Paul**** > > ** ** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8fb1f5b0380e5204d14c1369 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As in every other case where the WebFinger spec is merely re-iterating stan= dard HTTP rules, I suggest just removing this language. -Tim

On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones <pa= ulej@packetizer.com> wrote:

Folks,

=A0

We had this previously:

=A0

=93If the client qu= eries the WebFinger server and provides a URI for which the server has no i= nformation, the server MUST return a 404 status code.=94

=A0

Someone = posted to the list that we should talk about positive replies and mention t= hat a client might be rejected with a 401.=A0 So, I wrote this text to be a= ppended to the end of that above paragraph:

=A0

=93If th= e server is able to provide information in response to a request, it MUST d= o so using an appropriate 2xx HTTP status code and including the requested = representation in the body of the response.=A0 A server MAY also return oth= er HTTP status codes, as appropriate, such as a 401 to indicate that the cl= ient is not authorized to issue a request to the server.=94

=A0

Is this = agreeable?=A0 Please suggest wording changes, if not.

=A0

Paul

=A0

=A0


________________________________________= _______
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8fb1f5b0380e5204d14c1369-- From nick@silverbucket.net Thu Dec 20 09:33:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6721F88E1 for ; Thu, 20 Dec 2012 09:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-2KFs5VKib0 for ; Thu, 20 Dec 2012 09:33:09 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4E21F8830 for ; Thu, 20 Dec 2012 09:33:09 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id k1so3672620oag.30 for ; Thu, 20 Dec 2012 09:33:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=00ui/CeI9oVwo+RF3tE1+NAJI846CwPn0bTGCi0oSh4=; b=Dwu4xrdwG2igdQotq6k6zUMhr0SuxJoIipA+T1vUE2nEh2Ptt+3J4icmdVTnLRb7/r CZes0EJrUAQHYktAHUSSs5nx1HfbRxc48OsXhV5TcZbjkO9EyLvFx8EBUI+ZpGC0DXkS NUNN+WsV9GeyTV2ww2J36ckIbVa/Zh7O585Amj4ybdxWKSmy4MQPI7Tr6VpxW3Yip245 FPVbXAngp5bCrSJIPXNFRuv8wOuoBH0h9+90LNcBqdL0tI7s4d/Abbo9wfy9cH0JTJfR 3NSDJRAyM7WDuNAFpw+bRN6eiKnDIUnQ5OtkLz1l9gAde02/LabtMbAfIBejab6HBDfH C6lQ== X-Received: by 10.60.31.130 with SMTP id a2mr8802757oei.95.1356024789099; Thu, 20 Dec 2012 09:33:09 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx.google.com with ESMTPS id b3sm6114511obo.6.2012.12.20.09.33.07 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 09:33:08 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id k1so3656184oag.16 for ; Thu, 20 Dec 2012 09:33:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.150.72 with SMTP id ug8mr8495640obb.1.1356024786464; Thu, 20 Dec 2012 09:33:06 -0800 (PST) Received: by 10.76.92.66 with HTTP; Thu, 20 Dec 2012 09:33:06 -0800 (PST) Received: by 10.76.92.66 with HTTP; Thu, 20 Dec 2012 09:33:06 -0800 (PST) In-Reply-To: <047601cdded6$594c9090$0be5b1b0$@packetizer.com> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <047601cdded6$594c9090$0be5b1b0$@packetizer.com> Date: Thu, 20 Dec 2012 18:33:06 +0100 Message-ID: From: Nick Jennings To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d044469adb42ea104d14c1f95 X-Gm-Message-State: ALoCoQnYjx3SmMwOA7vl2JBpQSM56VB6yVfai+aGAusdfkh1nOMZDagDoiAXC1RZVbU7VybX1Vog Cc: webfinger@ietf.org, Melvin Carvalho Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:33:11 -0000 --f46d044469adb42ea104d14c1f95 Content-Type: text/plain; charset=UTF-8 Thanks for your patience Paul :) that cleared things up! On Dec 20, 2012 6:20 PM, "Paul E. Jones" wrote: > Nick, > > > I don't want to beat a dead horse, but so far I feel like either I'm > > missing something pretty major, or I'm not making myself clear. So I'll > > give it another shot: > > > > My concern is that there seems to me to be a BIG ambiguity problem which > > could create false positives during lookups, and different conventions > > could be made up by sites with emails & web accounts on the same server, > > that might require a WF client to use several different URIs to find a > > record (and there's not 100% sure way of knowing they got the right > > record). > > That's what section 5.4 (next version will be 4.4) deal with. It is > recommended that we use the acct: URI when looking up information about > users if we're trying to find out something about their account. > > It goes on to say that mailto is not ideal for user accounts, but would be > useful for mail server configuration. If you want to see live examples of > the difference, see: > > curl https://packetizer.com/.well-known/webfinger? > resource=acct:paulej@packetizer.com > > vs. > > curl https://packetizer.com/.well-known/webfinger? > resource=mailto:paulej@packetizer.com > > The latter provides information about how my email client should provision > itself. > > > If there is a WF client in a mail-app, it's going to want to query > > against the email address. Not a website account. So, IMO there needs to > > be a way to specify you are querying for an email address, what that > > method is, I don't know, but the ambiguity of 'acct' is problematic for > > a client library that knows exactly what it's talking about (an email > > address). > > > > /.host-meta/webfinger?resource=mailto:user@example.com > > Yes, that's what is intended. > > > This would make it clear to the server "I got an *email address* and > > would like any record associated with it. > > > > Whereas: > > > > /.host-meta/webfinger?resource=acct:user@example.com > > > > OR > > > > /.host-meta/webfinger?resource=http://example.com/users/user > > > > Would make it clear that you are querying 'user' from the sites user > > accounts. This could be the way of implying "whatever service you host, > > I need a record for a user of this name". If the WF server was an email > > server, then it could be one in the same as a mailto:user@example.com > > URI and the result would be the same no matter what. However if it's > > twitter (for example) or some other web service with accounts, it would > > know you mean the account 'user' of that web service. > > If I were writing a client and saw an email address "paulej@packetizer.com", > I would assume the associated account URI is acct:paulej@packetizer.com. > Personally, I think that is a reasonable thing to do. > > For a lot of reasons, I think having different user identifiers at the > same domain level is a bad idea and I don't know how people will deal with > that. They should not do that, really. People search for people using > these identifiers. It's an issue that extends beyond just WF. Call it a > part of "good domain hygiene". > > > My point is that the context is only really going to be known by the > > client, and it will have no way of knowing if the result it got was for > > the right account because it has no way of being specific. IMO this is > > trivial to implement on the server side (by default, mailto and acct > > would be one in the same, but you could split the two if you > > needed) and would make things easy to clarify by the client when needed. > > It would certainly be legitimate to have acct: and mailto: return the > same set of link relations. A client would likely be looking for only > certain "rel" values, anyway. However, I personally like to split them, > since they serve an entirely different purpose. If my XMPP client was > looking for how to configure itself, for example, I would expect it to > query like this: > > curl https://packetizer.com/.well-known/webfinger? > resource=xmpp:paulej@packetizer.com > > That will return a different set of results. There is only minimal > information there, since we have not actually defined the auto-provisioning > stuff. Again, this could all be returned as part of a query to acct:, but > I personally like the split. It could also be possible that each of these > URIs (acct:, mailto:, or xmpp:) are just aliases of each other and, > regardless of what the client queries, it gets the same JRD. > > What I cannot fix are domains that have two people associated with a given > user identifier. > > Paul > > > --f46d044469adb42ea104d14c1f95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for your patience Paul :) that cleared things up!

On Dec 20, 2012 6:20 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:
Nick,

> I don't want to beat a dead horse, but so far I feel like either I= 'm
> missing something pretty major, or I'm not making myself clear. So= I'll
> give it another shot:
>
> My concern is that there seems to me to be a BIG ambiguity problem whi= ch
> could create false positives during lookups, and different conventions=
> could be made up by sites with emails & web accounts on the same s= erver,
> that might require a WF client to use several different URIs to find a=
> record (and there's not 100% sure way of knowing they got the righ= t
> record).

That's what section 5.4 (next version will be 4.4) deal with. =C2=A0It = is recommended that we use the acct: URI when looking up information about = users if we're trying to find out something about their account.

It goes on to say that mailto is not ideal for user accounts, but would be = useful for mail server configuration. =C2=A0If you want to see live example= s of the difference, see:

curl https://packetizer.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dacct:paulej@packetizer.com

vs.

curl https://packetizer.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dmailto:paulej@packetizer.com

The latter provides information about how my email client should provision = itself.

> If there is a WF client in a mail-app, it's going to want to query=
> against the email address. Not a website account. So, IMO there needs = to
> be a way to specify you are querying for an email address, what that > method is, I don't know, but the ambiguity of 'acct' is pr= oblematic for
> a client library that knows exactly what it's talking about (an em= ail
> address).
>
> /.host-meta/webfinger?resource=3Dmailto:user@example.com

Yes, that's what is intended.

> This would make it clear to the server "I got an *email address* = and
> would like any record associated with it.
>
> Whereas:
>
> /.host-meta/webfinger?resource=3Dacct:user@example.com
>
> OR
>
> /.host-meta/webfinger?resource=3Dhttp://example.com/users/user
>
> Would make it clear that you are querying 'user' from the site= s user
> accounts. This could be the way of implying "whatever service you= host,
> I need a record for a user of this name". If the WF server was an= email
> server, then it could be one in the same as a mailto:user@example.com
> URI and the result would be the same no matter what. However if it'= ;s
> twitter (for example) or some other web service with accounts, it woul= d
> know you mean the account 'user' of that web service.

If I were writing a client and saw an email address "paulej@packetizer.com", I would assume the= associated account URI is = acct:paulej@packetizer.com. =C2=A0Personally, I think that is a reasona= ble thing to do.

For a lot of reasons, I think having different user identifiers at the same= domain level is a bad idea and I don't know how people will deal with = that. =C2=A0They should not do that, really. =C2=A0People search for people= using these identifiers. =C2=A0It's an issue that extends beyond just = WF. =C2=A0Call it a part of "good domain hygiene".

> My point is that the context is only really going to be known by the > client, and it will have no way of knowing if the result it got was fo= r
> the right account because it has no way of being specific. IMO this is=
> trivial to implement on the server side (by default, mailto and acct > would be one in the same, but you could split the two if you
> needed) and would make things easy to clarify by the client when neede= d.

It would certainly be legitimate to have acct: and mailto: return the same = set of link relations. =C2=A0A client would likely be looking for only cert= ain "rel" values, anyway. =C2=A0However, I personally like to spl= it them, since they serve an entirely different purpose. If my XMPP client = was looking for how to configure itself, for example, I would expect it to = query like this:

curl https://packetizer.com/.well-known/webfinger?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 resource=3Dxmpp:paulej@packetizer.com

That will return a different set of results. =C2=A0There is only minimal in= formation there, since we have not actually defined the auto-provisioning s= tuff. =C2=A0Again, this could all be returned as part of a query to acct:, = but I personally like the split. =C2=A0It could also be possible that each = of these URIs (acct:, mailto:, or xmpp:) are just aliases of each other and= , regardless of what the client queries, it gets the same JRD.

What I cannot fix are domains that have two people associated with a given = user identifier.

Paul


--f46d044469adb42ea104d14c1f95-- From paulej@packetizer.com Thu Dec 20 09:35:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C19721F8A0C for ; Thu, 20 Dec 2012 09:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jPrGldiQn7p for ; Thu, 20 Dec 2012 09:35:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F3FB021F89A6 for ; Thu, 20 Dec 2012 09:35:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKHZ8OI002591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 12:35:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356024909; bh=qqyOO0W1OozWQ2/v+Tm17oKKfqPuImt3dpKBYSFExho=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=bDPl4k2d/lHy1Zjqn+Wa70pe4ffu483q+Wum4TzNyV3e8lEdhRQnkdRfcNWOsYbxQ vRygi/6LzLK/UKND9VbzSScT/Jf73WPSdwR3iqADBKXoHhCSDVkrp5kg133UZwqigl pxEYWTpVpsT94Xh2kxmZBvpVB2jaMFvmzC6VG99Q= From: "Paul E. Jones" To: "'Tim Bray'" References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 12:35:16 -0500 Message-ID: <048401cdded8$605d6c90$211845b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0485_01CDDEAE.778827E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH37xPjZJRUcIsUNQeBWhT/3tk+XwJBmtyyl7vFM4A= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:35:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0485_01CDDEAE.778827E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 404 bit is needed, since the "webfinger" server was found. just not the resource being queried. That question absolutely will come up. The new stuff (401, 2xx), I agree: it's re-stating what HTTP does. If others agree, I'll not put that into the spec. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, December 20, 2012 12:30 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language As in every other case where the WebFinger spec is merely re-iterating standard HTTP rules, I suggest just removing this language. -Tim On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones wrote: Folks, We had this previously: "If the client queries the WebFinger server and provides a URI for which the server has no information, the server MUST return a 404 status code." Someone posted to the list that we should talk about positive replies and mention that a client might be rejected with a 401. So, I wrote this text to be appended to the end of that above paragraph: "If the server is able to provide information in response to a request, it MUST do so using an appropriate 2xx HTTP status code and including the requested representation in the body of the response. A server MAY also return other HTTP status codes, as appropriate, such as a 401 to indicate that the client is not authorized to issue a request to the server." Is this agreeable? Please suggest wording changes, if not. Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0485_01CDDEAE.778827E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 404 bit is needed, since the “webfinger” server was = found… just not the resource being queried.  That question = absolutely will come up.

 

The new stuff (401, 2xx), I agree: it’s re-stating what HTTP = does.

 

If others agree, I’ll not put that into the = spec.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = December 20, 2012 12:30 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Server Response language

 

As in every other case where the = WebFinger spec is merely re-iterating standard HTTP rules, I suggest = just removing this language. -Tim

On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

We had this = previously:

 <= /o:p>

“If = the client queries the WebFinger server and provides a URI for which the = server has no information, the server MUST return a 404 status = code.”

 <= /o:p>

Someone = posted to the list that we should talk about positive replies and = mention that a client might be rejected with a 401.  So, I wrote = this text to be appended to the end of that above = paragraph:

 <= /o:p>

“If = the server is able to provide information in response to a request, it = MUST do so using an appropriate 2xx HTTP status code and including the = requested representation in the body of the response.  A server MAY = also return other HTTP status codes, as appropriate, such as a 401 to = indicate that the client is not authorized to issue a request to the = server.”

 <= /o:p>

Is this = agreeable?  Please suggest wording changes, if = not.

 

Paul

 

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0485_01CDDEAE.778827E0-- From laurentwalter.goix@telecomitalia.it Thu Dec 20 09:36:10 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103EE21F8939 for ; Thu, 20 Dec 2012 09:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7B6A2b-ARVa for ; Thu, 20 Dec 2012 09:36:09 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id D313021F89A6 for ; Thu, 20 Dec 2012 09:36:08 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 20 Dec 2012 18:36:04 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 20 Dec 2012 18:36:04 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 20 Dec 2012 18:35:30 +0100 Thread-Topic: [webfinger] Possibly speeding up the RFC process Thread-Index: Ac3e2Hw2iMZKxff9TduWDAjFQORttA== Message-ID: <37396957-5580-40E5-AC27-B76E86CE95E9@telecomitalia.it> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , Melvin Carvalho , "webfinger@ietf.org" Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:36:10 -0000 Hello nick, Thank you indeed for rewording. My comments inline. > > > Hi Walter and Paul, > > I don't want to beat a dead horse, but so far I feel like either I'm > missing something pretty major, or I'm not making myself clear. So > I'll give it another shot: > > My concern is that there seems to me to be a BIG ambiguity problem > which could create false positives during lookups, and different > conventions could be made up by sites with emails & web accounts on > the same server, that might require a WF client to use several > different URIs to find a record (and there's not 100% sure way of > knowing they got the right record). > > If there is a WF client in a mail-app, it's going to want to query > against the email address. Not a website account. So, IMO there needs > to be a way to specify you are querying for an email address, what > that method is, I don't know, but the ambiguity of 'acct' is > problematic for a client library that knows exactly what it's talking > about (an email address). > > /.host-meta/webfinger?resource=3Dmailto:user@example.com > > This would make it clear to the server "I got an *email address* and > would like any record associated with it. Exactly. And this is a first very concrete and valid use case. > > Whereas: > > /.host-meta/webfinger?resource=3Dacct:user@example.com > > OR > > /.host-meta/webfinger?resource=3Dhttp://example.com/users/user > > Would make it clear that you are querying 'user' from the sites user > accounts. This could be the way of implying "whatever service you > host, I need a record for a user of this name". Not really "whatever" but truly specific to the uri that was queried. The s= erver will decide what to return based in the uri in input. The output coul= d be the same for both or not. The acct: uri is just another scheme to fill= a gap of representing those accounts that cannot be yet represented throug= h a uri. It may be valid in some contexts (eg social networks) but not in o= thers. As you said the client inserts the uri and de-facto solves the ambig= uity. Now, *if* a client library is open itself to ambiguity in authorizing= an app to insert a simple token say user@domain, then the client is buggy.= it may decide the scheme to prepend before issuing the query and "Acct:" c= ould probably make sense as a default, but it may not be always the case. A= n email app would probably always use mailto: when invoking a client librar= y for example to avoid these ambiguities. > If the WF server was > an email server, then it could be one in the same as a > mailto:user@example.com URI and the result would be the same no matter > what. However if it's twitter (for example) or some other web service > with accounts, it would know you mean the account 'user' of that web > service. > > > My point is that the context is only really going to be known by the > client, and it will have no way of knowing if the result it got was > for the right account because it has no way of being specific. The app, when invoking the client library, should provide the target uri wh= ich scheme will tell the server the "context" i.e. what is truly requested.= I don't see any ambiguity here. > IMO > this is trivial to implement on the server side (by default, mailto > and acct would be one in the same, but you could split the two if you > needed) and would make things easy to clarify by the client when > needed. I'm not sure I understand what is trivial to implement. Or if it is how to = handle different uri schemes for the same user@domain then I agree it is tr= ivial...and unambiguous :) Walter > > -Nick Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From paulej@packetizer.com Thu Dec 20 09:37:17 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87621F8945 for ; Thu, 20 Dec 2012 09:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJQUBxnDfPc2 for ; Thu, 20 Dec 2012 09:37:12 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DC6B221F8A51 for ; Thu, 20 Dec 2012 09:37:11 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKHbArh002719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 12:37:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356025030; bh=9ozRu/jTxh/SQY5owKHBtw1WV1x1WJfTirn02Od10lk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=A3fsAlXCBQ8413GI26bKSi6zwtZ4yl85MyoKtGLDW/jm6CWMsdMDkGvIOd8KDldNA xgMk0CPVaejQkiL4EHrFyVBM9N2i/6+jDb70tDEFrov32sgfaSefYLfK6AsjVUDvzF +rwR8LcDZLpDecys77w4SCVHYAM7VBNREBG4gm2U= From: "Paul E. Jones" To: "'James M Snell'" References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 12:37:18 -0500 Message-ID: <049101cdded8$a8db77f0$fa9267d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0492_01CDDEAE.C0063340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH37xPjZJRUcIsUNQeBWhT/3tk+XwFvFIDjl8JZ9pA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:37:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0492_01CDDEAE.C0063340 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I went through your items from before, but I didn=E2=80=99t add anything = related to 404. Exactly what text are you proposing again? =20 I want others to agree with the insertion. If I didn=E2=80=99t add it, = it meant I didn=E2=80=99t feel it was needed. (That might mean I = didn=E2=80=99t consider it carefully enough, I=E2=80=99ll admit.) =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Thursday, December 20, 2012 12:24 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language =20 This language is fine but the security considerations ought to recognize = and briefly discuss the risk of returning 401's vs. 404's (as I had = previously suggested).=20 On Dec 20, 2012 8:28 AM, "Paul E. Jones" wrote: Folks, =20 We had this previously: =20 =E2=80=9CIf the client queries the WebFinger server and provides a URI = for which the server has no information, the server MUST return a 404 = status code.=E2=80=9D =20 Someone posted to the list that we should talk about positive replies = and mention that a client might be rejected with a 401. So, I wrote = this text to be appended to the end of that above paragraph: =20 =E2=80=9CIf the server is able to provide information in response to a = request, it MUST do so using an appropriate 2xx HTTP status code and = including the requested representation in the body of the response. A = server MAY also return other HTTP status codes, as appropriate, such as = a 401 to indicate that the client is not authorized to issue a request = to the server.=E2=80=9D =20 Is this agreeable? Please suggest wording changes, if not. =20 Paul =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0492_01CDDEAE.C0063340 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I went through your items from before, but I didn=E2=80=99t add = anything related to 404.=C2=A0 Exactly what text are you proposing = again?

 

I want others to agree with the insertion.=C2=A0 If I didn=E2=80=99t = add it, it meant I didn=E2=80=99t feel it was needed.=C2=A0 (That might = mean I didn=E2=80=99t consider it carefully enough, I=E2=80=99ll = admit.)

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Thursday, = December 20, 2012 12:24 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Server Response language

 

This language is fine but the = security considerations ought to recognize and briefly discuss the risk = of returning 401's vs. 404's (as I had previously suggested). =

On Dec 20, 2012 8:28 AM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

We had this = previously:

 <= /o:p>

=E2=80=9CIf = the client queries the WebFinger server and provides a URI for which the = server has no information, the server MUST return a 404 status = code.=E2=80=9D

 <= /o:p>

Someone = posted to the list that we should talk about positive replies and = mention that a client might be rejected with a 401.  So, I wrote = this text to be appended to the end of that above = paragraph:

 <= /o:p>

=E2=80=9CIf = the server is able to provide information in response to a request, it = MUST do so using an appropriate 2xx HTTP status code and including the = requested representation in the body of the response.  A server MAY = also return other HTTP status codes, as appropriate, such as a 401 to = indicate that the client is not authorized to issue a request to the = server.=E2=80=9D

 <= /o:p>

Is this = agreeable?  Please suggest wording changes, if = not.

 <= /o:p>

Paul

 <= /o:p>

 <= /o:p>


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

------=_NextPart_000_0492_01CDDEAE.C0063340-- From laurentwalter.goix@telecomitalia.it Thu Dec 20 09:41:25 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1B21F8A42 for ; Thu, 20 Dec 2012 09:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3T78ZMPY5pH for ; Thu, 20 Dec 2012 09:41:25 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7666821F8A0D for ; Thu, 20 Dec 2012 09:41:24 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 20 Dec 2012 18:41:23 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Thu, 20 Dec 2012 18:41:23 +0100 From: Goix Laurent Walter To: "webfinger@googlegroups.com" Date: Thu, 20 Dec 2012 18:41:19 +0100 Thread-Topic: [webfinger] Possibly speeding up the RFC process Thread-Index: Ac3e2TotMkd9zz5bQzS/fdJsU6fT6g== Message-ID: <0C783CC2-F8C5-4520-9E9A-061B373A7CFA@telecomitalia.it> References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <047601cdded6$594c9090$0be5b1b0$@packetizer.com> In-Reply-To: <047601cdded6$594c9090$0be5b1b0$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Nick Jennings , "webfinger@googlegroups.com" , Melvin Carvalho Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:41:26 -0000 UGF1bCwNCg0KTGUgMjAgZMOpYy4gMjAxMiDDoCAxODoyMCwgIlBhdWwgRS4gSm9uZXMiIDxwYXVs ZWpAcGFja2V0aXplci5jb20+IGEgw6ljcml0IDoNCg0KPiBOaWNrLA0KPg0KPj4gSSBkb24ndCB3 YW50IHRvIGJlYXQgYSBkZWFkIGhvcnNlLCBidXQgc28gZmFyIEkgZmVlbCBsaWtlIGVpdGhlciBJ J20NCj4+IG1pc3Npbmcgc29tZXRoaW5nIHByZXR0eSBtYWpvciwgb3IgSSdtIG5vdCBtYWtpbmcg bXlzZWxmIGNsZWFyLiBTbyBJJ2xsDQo+PiBnaXZlIGl0IGFub3RoZXIgc2hvdDoNCj4+DQo+PiBN eSBjb25jZXJuIGlzIHRoYXQgdGhlcmUgc2VlbXMgdG8gbWUgdG8gYmUgYSBCSUcgYW1iaWd1aXR5 IHByb2JsZW0gd2hpY2gNCj4+IGNvdWxkIGNyZWF0ZSBmYWxzZSBwb3NpdGl2ZXMgZHVyaW5nIGxv b2t1cHMsIGFuZCBkaWZmZXJlbnQgY29udmVudGlvbnMNCj4+IGNvdWxkIGJlIG1hZGUgdXAgYnkg c2l0ZXMgd2l0aCBlbWFpbHMgJiB3ZWIgYWNjb3VudHMgb24gdGhlIHNhbWUgc2VydmVyLA0KPj4g dGhhdCBtaWdodCByZXF1aXJlIGEgV0YgY2xpZW50IHRvIHVzZSBzZXZlcmFsIGRpZmZlcmVudCBV UklzIHRvIGZpbmQgYQ0KPj4gcmVjb3JkIChhbmQgdGhlcmUncyBub3QgMTAwJSBzdXJlIHdheSBv ZiBrbm93aW5nIHRoZXkgZ290IHRoZSByaWdodA0KPj4gcmVjb3JkKS4NCj4NCj4gVGhhdCdzIHdo YXQgc2VjdGlvbiA1LjQgKG5leHQgdmVyc2lvbiB3aWxsIGJlIDQuNCkgZGVhbCB3aXRoLiAgSXQg aXMgcmVjb21tZW5kZWQgdGhhdCB3ZSB1c2UgdGhlIGFjY3Q6IFVSSSB3aGVuIGxvb2tpbmcgdXAg aW5mb3JtYXRpb24gYWJvdXQgdXNlcnMgaWYgd2UncmUgdHJ5aW5nIHRvIGZpbmQgb3V0IHNvbWV0 aGluZyBhYm91dCB0aGVpciBhY2NvdW50Lg0KPg0KPiBJdCBnb2VzIG9uIHRvIHNheSB0aGF0IG1h aWx0byBpcyBub3QgaWRlYWwgZm9yIHVzZXIgYWNjb3VudHMsIGJ1dCB3b3VsZCBiZSB1c2VmdWwg Zm9yIG1haWwgc2VydmVyIGNvbmZpZ3VyYXRpb24uICBJZiB5b3Ugd2FudCB0byBzZWUgbGl2ZSBl eGFtcGxlcyBvZiB0aGUgZGlmZmVyZW5jZSwgc2VlOg0KPg0KPiBjdXJsIGh0dHBzOi8vcGFja2V0 aXplci5jb20vLndlbGwta25vd24vd2ViZmluZ2VyPw0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZXNvdXJjZT1hY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbQ0KPg0KPiB2cy4NCj4NCj4g Y3VybCBodHRwczovL3BhY2tldGl6ZXIuY29tLy53ZWxsLWtub3duL3dlYmZpbmdlcj8NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgcmVzb3VyY2U9bWFpbHRvOnBhdWxlakBwYWNrZXRpemVy LmNvbQ0KPg0KPiBUaGUgbGF0dGVyIHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IGhvdyBteSBl bWFpbCBjbGllbnQgc2hvdWxkIHByb3Zpc2lvbiBpdHNlbGYuDQo+DQo+PiBJZiB0aGVyZSBpcyBh IFdGIGNsaWVudCBpbiBhIG1haWwtYXBwLCBpdCdzIGdvaW5nIHRvIHdhbnQgdG8gcXVlcnkNCj4+ IGFnYWluc3QgdGhlIGVtYWlsIGFkZHJlc3MuIE5vdCBhIHdlYnNpdGUgYWNjb3VudC4gU28sIElN TyB0aGVyZSBuZWVkcyB0bw0KPj4gYmUgYSB3YXkgdG8gc3BlY2lmeSB5b3UgYXJlIHF1ZXJ5aW5n IGZvciBhbiBlbWFpbCBhZGRyZXNzLCB3aGF0IHRoYXQNCj4+IG1ldGhvZCBpcywgSSBkb24ndCBr bm93LCBidXQgdGhlIGFtYmlndWl0eSBvZiAnYWNjdCcgaXMgcHJvYmxlbWF0aWMgZm9yDQo+PiBh IGNsaWVudCBsaWJyYXJ5IHRoYXQga25vd3MgZXhhY3RseSB3aGF0IGl0J3MgdGFsa2luZyBhYm91 dCAoYW4gZW1haWwNCj4+IGFkZHJlc3MpLg0KPj4NCj4+IC8uaG9zdC1tZXRhL3dlYmZpbmdlcj9y ZXNvdXJjZT1tYWlsdG86dXNlckBleGFtcGxlLmNvbQ0KPg0KPiBZZXMsIHRoYXQncyB3aGF0IGlz IGludGVuZGVkLg0KPg0KPj4gVGhpcyB3b3VsZCBtYWtlIGl0IGNsZWFyIHRvIHRoZSBzZXJ2ZXIg IkkgZ290IGFuICplbWFpbCBhZGRyZXNzKiBhbmQNCj4+IHdvdWxkIGxpa2UgYW55IHJlY29yZCBh c3NvY2lhdGVkIHdpdGggaXQuDQo+Pg0KPj4gV2hlcmVhczoNCj4+DQo+PiAvLmhvc3QtbWV0YS93 ZWJmaW5nZXI/cmVzb3VyY2U9YWNjdDp1c2VyQGV4YW1wbGUuY29tDQo+Pg0KPj4gT1INCj4+DQo+ PiAvLmhvc3QtbWV0YS93ZWJmaW5nZXI/cmVzb3VyY2U9aHR0cDovL2V4YW1wbGUuY29tL3VzZXJz L3VzZXINCj4+DQo+PiBXb3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgeW91IGFyZSBxdWVyeWluZyAn dXNlcicgZnJvbSB0aGUgc2l0ZXMgdXNlcg0KPj4gYWNjb3VudHMuIFRoaXMgY291bGQgYmUgdGhl IHdheSBvZiBpbXBseWluZyAid2hhdGV2ZXIgc2VydmljZSB5b3UgaG9zdCwNCj4+IEkgbmVlZCBh IHJlY29yZCBmb3IgYSB1c2VyIG9mIHRoaXMgbmFtZSIuIElmIHRoZSBXRiBzZXJ2ZXIgd2FzIGFu IGVtYWlsDQo+PiBzZXJ2ZXIsIHRoZW4gaXQgY291bGQgYmUgb25lIGluIHRoZSBzYW1lIGFzIGEg bWFpbHRvOnVzZXJAZXhhbXBsZS5jb20NCj4+IFVSSSBhbmQgdGhlIHJlc3VsdCB3b3VsZCBiZSB0 aGUgc2FtZSBubyBtYXR0ZXIgd2hhdC4gSG93ZXZlciBpZiBpdCdzDQo+PiB0d2l0dGVyIChmb3Ig ZXhhbXBsZSkgb3Igc29tZSBvdGhlciB3ZWIgc2VydmljZSB3aXRoIGFjY291bnRzLCBpdCB3b3Vs ZA0KPj4ga25vdyB5b3UgbWVhbiB0aGUgYWNjb3VudCAndXNlcicgb2YgdGhhdCB3ZWIgc2Vydmlj ZS4NCj4NCj4gSWYgSSB3ZXJlIHdyaXRpbmcgYSBjbGllbnQgYW5kIHNhdyBhbiBlbWFpbCBhZGRy ZXNzICJwYXVsZWpAcGFja2V0aXplci5jb20iLCBJIHdvdWxkIGFzc3VtZSB0aGUgYXNzb2NpYXRl ZCBhY2NvdW50IFVSSSBpcyBhY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbS4gIFBlcnNvbmFsbHks IEkgdGhpbmsgdGhhdCBpcyBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZG8uDQoNCkkgd291bGQgcmF0 aGVyIGV4cGVjdCB0aGF0IG5hdGl2ZWx5IHRoZSBlbWFpbCBjbGllbnQgcXVlcmllcyBmb3IgbWFp bHRvOiBhcyB0aGlzIGlzIHRoZSByZWFsIGlkZW50aWZpZXIgaXQga25vd3Mgb2YgKHRoZSBvbmVz IHVzZWQgaW4gZW1haWxzKSBhbmQgY29udmVydGluZyBpdCBpbnRvIGFjY3Q6IGlzIGp1c3QgYSBi ZXN0IGd1ZXNzLiBUaGUgdGFyZ2V0IHNlcnZlciBzaG91bGQgc3VyZWx5IGtub3dzIHRoYXQgbWFp bHRvOiBpZGVudGlmaWVyIHNpbmNlIGFuIGVtYWlsIHdhcyBwcm9iYWJseSByZWNlaXZlZCBmcm9t IHRoYXQgaWQsIHdoaWxzdCB0aGUgY29ycmVzcG9uZGluZyBhY2N0OiBpZGVudGlmaWVyIG1heSBu b3QgZXhpc3QuIERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQpXYWx0ZXINCj4NCj4gRm9yIGEgbG90 IG9mIHJlYXNvbnMsIEkgdGhpbmsgaGF2aW5nIGRpZmZlcmVudCB1c2VyIGlkZW50aWZpZXJzIGF0 IHRoZSBzYW1lIGRvbWFpbiBsZXZlbCBpcyBhIGJhZCBpZGVhIGFuZCBJIGRvbid0IGtub3cgaG93 IHBlb3BsZSB3aWxsIGRlYWwgd2l0aCB0aGF0LiAgVGhleSBzaG91bGQgbm90IGRvIHRoYXQsIHJl YWxseS4gIFBlb3BsZSBzZWFyY2ggZm9yIHBlb3BsZSB1c2luZyB0aGVzZSBpZGVudGlmaWVycy4g IEl0J3MgYW4gaXNzdWUgdGhhdCBleHRlbmRzIGJleW9uZCBqdXN0IFdGLiAgQ2FsbCBpdCBhIHBh cnQgb2YgImdvb2QgZG9tYWluIGh5Z2llbmUiLg0KPg0KPj4gTXkgcG9pbnQgaXMgdGhhdCB0aGUg Y29udGV4dCBpcyBvbmx5IHJlYWxseSBnb2luZyB0byBiZSBrbm93biBieSB0aGUNCj4+IGNsaWVu dCwgYW5kIGl0IHdpbGwgaGF2ZSBubyB3YXkgb2Yga25vd2luZyBpZiB0aGUgcmVzdWx0IGl0IGdv dCB3YXMgZm9yDQo+PiB0aGUgcmlnaHQgYWNjb3VudCBiZWNhdXNlIGl0IGhhcyBubyB3YXkgb2Yg YmVpbmcgc3BlY2lmaWMuIElNTyB0aGlzIGlzDQo+PiB0cml2aWFsIHRvIGltcGxlbWVudCBvbiB0 aGUgc2VydmVyIHNpZGUgKGJ5IGRlZmF1bHQsIG1haWx0byBhbmQgYWNjdA0KPj4gd291bGQgYmUg b25lIGluIHRoZSBzYW1lLCBidXQgeW91IGNvdWxkIHNwbGl0IHRoZSB0d28gaWYgeW91DQo+PiBu ZWVkZWQpIGFuZCB3b3VsZCBtYWtlIHRoaW5ncyBlYXN5IHRvIGNsYXJpZnkgYnkgdGhlIGNsaWVu dCB3aGVuIG5lZWRlZC4NCj4NCj4gSXQgd291bGQgY2VydGFpbmx5IGJlIGxlZ2l0aW1hdGUgdG8g aGF2ZSBhY2N0OiBhbmQgbWFpbHRvOiByZXR1cm4gdGhlIHNhbWUgc2V0IG9mIGxpbmsgcmVsYXRp b25zLiAgQSBjbGllbnQgd291bGQgbGlrZWx5IGJlIGxvb2tpbmcgZm9yIG9ubHkgY2VydGFpbiAi cmVsIiB2YWx1ZXMsIGFueXdheS4gIEhvd2V2ZXIsIEkgcGVyc29uYWxseSBsaWtlIHRvIHNwbGl0 IHRoZW0sIHNpbmNlIHRoZXkgc2VydmUgYW4gZW50aXJlbHkgZGlmZmVyZW50IHB1cnBvc2UuIElm IG15IFhNUFAgY2xpZW50IHdhcyBsb29raW5nIGZvciBob3cgdG8gY29uZmlndXJlIGl0c2VsZiwg Zm9yIGV4YW1wbGUsIEkgd291bGQgZXhwZWN0IGl0IHRvIHF1ZXJ5IGxpa2UgdGhpczoNCj4NCj4g Y3VybCBodHRwczovL3BhY2tldGl6ZXIuY29tLy53ZWxsLWtub3duL3dlYmZpbmdlcj8NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgcmVzb3VyY2U9eG1wcDpwYXVsZWpAcGFja2V0aXplci5j b20NCj4NCj4gVGhhdCB3aWxsIHJldHVybiBhIGRpZmZlcmVudCBzZXQgb2YgcmVzdWx0cy4gIFRo ZXJlIGlzIG9ubHkgbWluaW1hbCBpbmZvcm1hdGlvbiB0aGVyZSwgc2luY2Ugd2UgaGF2ZSBub3Qg YWN0dWFsbHkgZGVmaW5lZCB0aGUgYXV0by1wcm92aXNpb25pbmcgc3R1ZmYuICBBZ2FpbiwgdGhp cyBjb3VsZCBhbGwgYmUgcmV0dXJuZWQgYXMgcGFydCBvZiBhIHF1ZXJ5IHRvIGFjY3Q6LCBidXQg SSBwZXJzb25hbGx5IGxpa2UgdGhlIHNwbGl0LiAgSXQgY291bGQgYWxzbyBiZSBwb3NzaWJsZSB0 aGF0IGVhY2ggb2YgdGhlc2UgVVJJcyAoYWNjdDosIG1haWx0bzosIG9yIHhtcHA6KSBhcmUganVz dCBhbGlhc2VzIG9mIGVhY2ggb3RoZXIgYW5kLCByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGNsaWVu dCBxdWVyaWVzLCBpdCBnZXRzIHRoZSBzYW1lIEpSRC4NCj4NCj4gV2hhdCBJIGNhbm5vdCBmaXgg YXJlIGRvbWFpbnMgdGhhdCBoYXZlIHR3byBwZW9wbGUgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4g dXNlciBpZGVudGlmaWVyLg0KPg0KPiBQYXVsDQo+DQo+DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBp IHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNv bmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBp bnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5n LCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUt bWFpbCwgVGhhbmtzLg0KDQo= From tbray@textuality.com Thu Dec 20 09:52:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2C21F8A80 for ; Thu, 20 Dec 2012 09:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAcHtBOg2C-D for ; Thu, 20 Dec 2012 09:52:35 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8621F8931 for ; Thu, 20 Dec 2012 09:52:34 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so3646416obc.29 for ; Thu, 20 Dec 2012 09:52:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7ZTxDc08RbxSzehuVTCxiK6UepuB2oSBZhrR6rZASD0=; b=m0aENG5kcdUJCz0r1Vd1+riYMnICTSUSHtBfm802RMqwdHBDjQtTVk581eD7NLjNe7 zfMMigJKt77srJ2AaRr543a6ITRbqXbYiCr5Lw1XC501yTr1ZUnWvBj+WSxd3RP4+mOr bFPWBG5ULE2SuyePkrWJUU2sw8sHF+WXWMlt4TTpE1Kw+Gle+DVayBZE1RwP34mvgEdy +QymC75vIz9RVzR0HuvI41/oqQ76IrMpXYy4r8QhNy9KGTDRUJR4ckG7gApB83gUlHoI gCSHZaOqFfRibBJrtD72Iq0bjwY0EGGDjPFtG+2T5O7QYGyA7DhKJJdkiYE8INlApLKZ whDA== MIME-Version: 1.0 Received: by 10.60.23.200 with SMTP id o8mr8516895oef.48.1356025954057; Thu, 20 Dec 2012 09:52:34 -0800 (PST) Received: by 10.76.12.134 with HTTP; Thu, 20 Dec 2012 09:52:33 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <048401cdded8$605d6c90$211845b0$@packetizer.com> References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> <048401cdded8$605d6c90$211845b0$@packetizer.com> Date: Thu, 20 Dec 2012 09:52:33 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb206e44c3e2904d14c65e3 X-Gm-Message-State: ALoCoQnwaIQnqYICCjJG1xNUYJ5YFkYUT1IpWTIdFIKg4gfpgFEMozroUnymXA4dOfB4M6aS12Cj Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:52:43 -0000 --e89a8fb206e44c3e2904d14c65e3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That=92s what 404 is for; I quote RFC2616: 10.4.5 404 Not Found The server has not found anything matching the Request-URI. It=92s bad practice to incorporate referenced specifications by value not b= y reference. -T On Thu, Dec 20, 2012 at 9:35 AM, Paul E. Jones wrote= : > The 404 bit is needed, since the =93webfinger=94 server was found=85 just= not > the resource being queried. That question absolutely will come up.**** > > ** ** > > The new stuff (401, 2xx), I agree: it=92s re-stating what HTTP does.**** > > ** ** > > If others agree, I=92ll not put that into the spec.**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Thursday, December 20, 2012 12:30 PM > *To:* Paul E. Jones > *Cc:* webfinger@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [webfinger] Server Response language**** > > ** ** > > As in every other case where the WebFinger spec is merely re-iterating > standard HTTP rules, I suggest just removing this language. -Tim**** > > On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > We had this previously:**** > > **** > > =93If the client queries the WebFinger server and provides a URI for whic= h > the server has no information, the server MUST return a 404 status code.= =94* > *** > > **** > > Someone posted to the list that we should talk about positive replies and > mention that a client might be rejected with a 401. So, I wrote this tex= t > to be appended to the end of that above paragraph:**** > > **** > > =93If the server is able to provide information in response to a request,= it > MUST do so using an appropriate 2xx HTTP status code and including the > requested representation in the body of the response. A server MAY also > return other HTTP status codes, as appropriate, such as a 401 to indicate > that the client is not authorized to issue a request to the server.=94***= * > > **** > > Is this agreeable? Please suggest wording changes, if not.**** > > **** > > Paul**** > > **** > > **** > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --e89a8fb206e44c3e2904d14c65e3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That=92s what 404 is for; I quote RFC2616:

10.4.5 404 Not Found

   The server has not found anything matching the Request-URI.

It= =92s bad practice to incorporate referenced specifications by value not by = reference.=A0 -T

On Thu, Dec 20, 2012 at = 9:35 AM, Paul E. Jones <paulej@packetizer.com> wrote:

The 404 bit i= s needed, since the =93webfinger=94 server was found=85 just not the resour= ce being queried.=A0 That question absolutely will come up.

=A0<= /p>

The new stuff (401, 2x= x), I agree: it=92s re-stating what HTTP does.

=A0<= /p>

If others agree, I=92l= l not put that into the spec.

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, December 20, 2012 12:30 PM
To: Paul E. Jon= es
Cc: we= bfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: [webfinger] Server Response language

=A0<= u>

As in every= other case where the WebFinger spec is merely re-iterating standard HTTP r= ules, I suggest just removing this language. -Tim

On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones = <paulej@packe= tizer.com> wrote:

= Folks,

=A0

We had t= his previously:

=A0

=93If the client queries the WebFinger server and = provides a URI for which the server has no information, the server MUST ret= urn a 404 status code.=94

=A0

Someone = posted to the list that we should talk about positive replies and mention t= hat a client might be rejected with a 401.=A0 So, I wrote this text to be a= ppended to the end of that above paragraph:

=A0

=93If th= e server is able to provide information in response to a request, it MUST d= o so using an appropriate 2xx HTTP status code and including the requested = representation in the body of the response.=A0 A server MAY also return oth= er HTTP status codes, as appropriate, such as a 401 to indicate that the cl= ient is not authorized to issue a request to the server.=94

=A0

Is this = agreeable?=A0 Please suggest wording changes, if not.

=A0

Paul

=A0

=A0


_______________________________________________
webfinger mailing li= st
webfinger@iet= f.org
https://www.ietf.org/mailman/listinfo/webfinger<= u>

=A0

<= /div>

--e89a8fb206e44c3e2904d14c65e3-- From paulej@packetizer.com Thu Dec 20 09:56:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04D21F8A8B for ; Thu, 20 Dec 2012 09:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cX0Oh7ahHKc for ; Thu, 20 Dec 2012 09:56:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8807321F8A8A for ; Thu, 20 Dec 2012 09:56:33 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKHuVoL003675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 12:56:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356026192; bh=4ciuk8/BU8oUScMoIHr/r2zmvyG1LjKL4JULxFwJzKM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VJwMvOFvxvHWH4wI0hKSbZiYuCfrwO+ycRzbV7ees7mpV6/mErgMe1pIHvFDUrCrh Yir1+Z5LLEgKyC+hk6SN8Deei+hmJMqXEZY3SrxXRI1ZChi+sI2xwDOhAzIvxelIXv kTVx6DiMRztsvZeHHR3ZxsX7qm2xkSqsKCGr1dlo= From: "Paul E. Jones" To: "'Goix Laurent Walter'" , References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <047601cdded6$594c9090$0be5b1b0$@packetizer.com> <0C783CC2-F8C5-4520-9E9A-061B373A7CFA@telecomitalia.it> In-Reply-To: <0C783CC2-F8C5-4520-9E9A-061B373A7CFA@telecomitalia.it> Date: Thu, 20 Dec 2012 12:56:39 -0500 Message-ID: <04b001cddedb$5d36d0d0$17a47270$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQHH/q7wAodvYjICqq12z5hRErIw Content-Language: en-us Cc: webfinger@ietf.org, 'Nick Jennings' , webfinger@googlegroups.com, 'Melvin Carvalho' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:56:34 -0000 Walter, > > If I were writing a client and saw an email address > "paulej@packetizer.com", I would assume the associated account URI is > acct:paulej@packetizer.com. Personally, I think that is a reasonable > thing to do. >=20 > I would rather expect that natively the email client queries for = mailto: > as this is the real identifier it knows of (the ones used in emails) = and > converting it into acct: is just a best guess. The target server = should > surely knows that mailto: identifier since an email was probably > received from that id, whilst the corresponding acct: identifier may = not > exist. Does this make sense? Yes, which is one of the reasons I had previously proposed introducing = the "acct" link relation. Given a known URI like = "mailto:paulej@packetizer.com", the client could query the server like = this: I just added that to my database so you can see what it would look like: curl https://packetizer.com/.well-known/webfinger? resource=3Dmailto:paulej@packetizer.com That said, I think a "best guess" is actually pretty reasonable. = Consider that the email client actually NEVER gets a = "mailto:paulej@packetizer.com" from the SMTP server. Rather, it gets = this: From: "Paul E. Jones" This is an email address, but I would argue that it should be safe to = assume that acct:paulej@packetizer.com will identify the user's account = (vs. his email-related configuration information or whatever). So, as a way forward, we have a couple of options: 1) Allow the assumption to be made that the account for the above address is "acct:" 2) Don't allow the assumption and require a query to "mailto" and discover the "acct" URI Paul From laurentwalter.goix@telecomitalia.it Thu Dec 20 09:58:29 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33F921F8A78 for ; Thu, 20 Dec 2012 09:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQNJaEg2hOev for ; Thu, 20 Dec 2012 09:58:28 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 31BAA21F8A56 for ; Thu, 20 Dec 2012 09:58:28 -0800 (PST) Content-Type: multipart/mixed; boundary="_c75c2bc9-3f76-41b5-9293-6b8c05ce8c35_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 20 Dec 2012 18:58:24 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 20 Dec 2012 18:58:24 +0100 From: Goix Laurent Walter To: Tim Bray Date: Thu, 20 Dec 2012 18:58:18 +0100 Thread-Topic: [webfinger] Server Response language Thread-Index: Ac3e25qWfQnduRUGTKOvhIz1WPQT9Q== Message-ID: References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> <048401cdded8$605d6c90$211845b0$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "Paul E. Jones" , "webfinger@googlegroups.com" , "webfinger@ietf.org" Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:58:29 -0000 --_c75c2bc9-3f76-41b5-9293-6b8c05ce8c35_ Content-Type: multipart/alternative; boundary="_000_A2FC82BDA22C4063949BB9D4671B0245telecomitaliait_" --_000_A2FC82BDA22C4063949BB9D4671B0245telecomitaliait_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkxlIDIwIGTDqWMuIDIwMTIgw6AgMTg6NTMsICJUaW0gQnJheSIgPHRicmF5QHRleHR1YWxp dHkuY29tPG1haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNvbT4+IGEgw6ljcml0IDoNCg0KVGhhdOKA mXMgd2hhdCA0MDQgaXMgZm9yOyBJIHF1b3RlIFJGQzI2MTY6DQoNCg0KMTAuNC41IDQwNCBOb3Qg Rm91bmQNCg0KICAgVGhlIHNlcnZlciBoYXMgbm90IGZvdW5kIGFueXRoaW5nIG1hdGNoaW5nIHRo ZSBSZXF1ZXN0LVVSSS4NCg0KSXTigJlzIGJhZCBwcmFjdGljZSB0byBpbmNvcnBvcmF0ZSByZWZl cmVuY2VkIHNwZWNpZmljYXRpb25zIGJ5IHZhbHVlIG5vdCBieSByZWZlcmVuY2UuICAtVA0KDQpB Z3JlZWQuIEl0J3MgYSBwaXR5IHRoZSBzYW1lIHdhcyBub3QgYWRvcHRlZCBmb3IganJkIDspDQoN Ck9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDk6MzUgQU0sIFBhdWwgRS4gSm9uZXMgPHBhdWxlakBw YWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tPj4gd3JvdGU6DQpUaGUg NDA0IGJpdCBpcyBuZWVkZWQsIHNpbmNlIHRoZSDigJx3ZWJmaW5nZXLigJ0gc2VydmVyIHdhcyBm b3VuZOKApiBqdXN0IG5vdCB0aGUgcmVzb3VyY2UgYmVpbmcgcXVlcmllZC4gIFRoYXQgcXVlc3Rp b24gYWJzb2x1dGVseSB3aWxsIGNvbWUgdXAuDQoNClRoZSBuZXcgc3R1ZmYgKDQwMSwgMnh4KSwg SSBhZ3JlZTogaXTigJlzIHJlLXN0YXRpbmcgd2hhdCBIVFRQIGRvZXMuDQoNCklmIG90aGVycyBh Z3JlZSwgSeKAmWxsIG5vdCBwdXQgdGhhdCBpbnRvIHRoZSBzcGVjLg0KDQpQYXVsDQoNCkZyb206 IFRpbSBCcmF5IFttYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb208bWFpbHRvOnRicmF5QHRleHR1 YWxpdHkuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiAxMjozMCBQTQ0K VG86IFBhdWwgRS4gSm9uZXMNCkNjOiB3ZWJmaW5nZXJAaWV0Zi5vcmc8bWFpbHRvOndlYmZpbmdl ckBpZXRmLm9yZz47IHdlYmZpbmdlckBnb29nbGVncm91cHMuY29tPG1haWx0bzp3ZWJmaW5nZXJA Z29vZ2xlZ3JvdXBzLmNvbT4NClN1YmplY3Q6IFJlOiBbd2ViZmluZ2VyXSBTZXJ2ZXIgUmVzcG9u c2UgbGFuZ3VhZ2UNCg0KQXMgaW4gZXZlcnkgb3RoZXIgY2FzZSB3aGVyZSB0aGUgV2ViRmluZ2Vy IHNwZWMgaXMgbWVyZWx5IHJlLWl0ZXJhdGluZyBzdGFuZGFyZCBIVFRQIHJ1bGVzLCBJIHN1Z2dl c3QganVzdCByZW1vdmluZyB0aGlzIGxhbmd1YWdlLiAtVGltDQpPbiBUaHUsIERlYyAyMCwgMjAx MiBhdCA4OjI4IEFNLCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb208bWFpbHRv OnBhdWxlakBwYWNrZXRpemVyLmNvbT4+IHdyb3RlOg0KRm9sa3MsDQoNCldlIGhhZCB0aGlzIHBy ZXZpb3VzbHk6DQoNCuKAnElmIHRoZSBjbGllbnQgcXVlcmllcyB0aGUgV2ViRmluZ2VyIHNlcnZl ciBhbmQgcHJvdmlkZXMgYSBVUkkgZm9yIHdoaWNoIHRoZSBzZXJ2ZXIgaGFzIG5vIGluZm9ybWF0 aW9uLCB0aGUgc2VydmVyIE1VU1QgcmV0dXJuIGEgNDA0IHN0YXR1cyBjb2RlLuKAnQ0KDQpTb21l b25lIHBvc3RlZCB0byB0aGUgbGlzdCB0aGF0IHdlIHNob3VsZCB0YWxrIGFib3V0IHBvc2l0aXZl IHJlcGxpZXMgYW5kIG1lbnRpb24gdGhhdCBhIGNsaWVudCBtaWdodCBiZSByZWplY3RlZCB3aXRo IGEgNDAxLiAgU28sIEkgd3JvdGUgdGhpcyB0ZXh0IHRvIGJlIGFwcGVuZGVkIHRvIHRoZSBlbmQg b2YgdGhhdCBhYm92ZSBwYXJhZ3JhcGg6DQoNCuKAnElmIHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBw cm92aWRlIGluZm9ybWF0aW9uIGluIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCwgaXQgTVVTVCBkbyBz byB1c2luZyBhbiBhcHByb3ByaWF0ZSAyeHggSFRUUCBzdGF0dXMgY29kZSBhbmQgaW5jbHVkaW5n IHRoZSByZXF1ZXN0ZWQgcmVwcmVzZW50YXRpb24gaW4gdGhlIGJvZHkgb2YgdGhlIHJlc3BvbnNl LiAgQSBzZXJ2ZXIgTUFZIGFsc28gcmV0dXJuIG90aGVyIEhUVFAgc3RhdHVzIGNvZGVzLCBhcyBh cHByb3ByaWF0ZSwgc3VjaCBhcyBhIDQwMSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBjbGllbnQgaXMg bm90IGF1dGhvcml6ZWQgdG8gaXNzdWUgYSByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIu4oCdDQoNCklz IHRoaXMgYWdyZWVhYmxlPyAgUGxlYXNlIHN1Z2dlc3Qgd29yZGluZyBjaGFuZ2VzLCBpZiBub3Qu DQoNClBhdWwNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp3ZWJmaW5nZXIgbWFpbGluZyBsaXN0DQp3ZWJmaW5nZXJAaWV0Zi5vcmc8bWFpbHRv OndlYmZpbmdlckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vd2ViZmluZ2VyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCndlYmZpbmdlciBtYWlsaW5nIGxpc3QNCndlYmZpbmdlckBpZXRmLm9yZzxtYWls dG86d2ViZmluZ2VyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby93ZWJmaW5nZXINClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBp bmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1 c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29u b3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRl LiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNp ZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25l IGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll Lg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lk OjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEg bCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3Nhcmlv Lg0KDQo= --_000_A2FC82BDA22C4063949BB9D4671B0245telecomitaliait_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjxicj4NCkxlIDIwIGTDqWMuIDIwMTIgw6AgMTg6NTMsICZxdW90O1RpbSBCcmF5 JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb20iPnRicmF5QHRl eHR1YWxpdHkuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+VGhhdOKAmXMgd2hhdCA0MDQgaXMgZm9yOyBJ IHF1b3RlIFJGQzI2MTY6PGJyPg0KPGJyPg0KPHByZSBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d29yZC1zcGFjaW5nOjBweDt3b3Jk LXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+MTAuNC41IDQwNCBOb3QgRm91 bmQNCg0KICAgVGhlIHNlcnZlciBoYXMgbm90IGZvdW5kIGFueXRoaW5nIG1hdGNoaW5nIHRoZSBS ZXF1ZXN0LVVSSS48L3ByZT4NCjxicj4NCkl04oCZcyBiYWQgcHJhY3RpY2UgdG8gaW5jb3Jwb3Jh dGUgcmVmZXJlbmNlZCBzcGVjaWZpY2F0aW9ucyBieSB2YWx1ZSBub3QgYnkgcmVmZXJlbmNlLiZu YnNwOyAtVDxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCkFn cmVlZC4gSXQncyBhIHBpdHkgdGhlIHNhbWUgd2FzIG5vdCBhZG9wdGVkIGZvciBqcmQgOyk8YnI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPk9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDk6MzUgQU0sIFBhdWwgRS4gSm9uZXMgPHNw YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20i IHRhcmdldD0iX2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIGxhbmc9IkVOLVVTIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3 ZCI+VGhlIDQwNCBiaXQgaXMgbmVlZGVkLCBzaW5jZSB0aGUg4oCcd2ViZmluZ2Vy4oCdIHNlcnZl ciB3YXMgZm91bmTigKYganVzdCBub3QgdGhlIHJlc291cmNlIGJlaW5nIHF1ZXJpZWQuJm5ic3A7 IFRoYXQgcXVlc3Rpb24gYWJzb2x1dGVseSB3aWxsIGNvbWUgdXAuPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5U aGUgbmV3IHN0dWZmICg0MDEsIDJ4eCksIEkgYWdyZWU6IGl04oCZcyByZS1zdGF0aW5nIHdoYXQg SFRUUCBkb2VzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7 PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SWYgb3RoZXJzIGFncmVlLCBJ4oCZbGwgbm90IHB1 dCB0aGF0IGludG8gdGhlIHNwZWMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5QYXVsPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRpbSBCcmF5IFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGJyYXlA dGV4dHVhbGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJl ciAyMCwgMjAxMiAxMjozMCBQTTxicj4NCjxiPlRvOjwvYj4gUGF1bCBFLiBKb25lczxicj4NCjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOndlYmZpbmdlckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPndlYmZpbmdlckBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86d2ViZmluZ2VyQGdv b2dsZWdyb3Vwcy5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWJmaW5nZXJAZ29vZ2xlZ3JvdXBzLmNv bTwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt3ZWJmaW5nZXJdIFNlcnZlciBSZXNwb25z ZSBsYW5ndWFnZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkFzIGluIGV2ZXJ5IG90aGVyIGNhc2Ugd2hlcmUgdGhlIFdlYkZpbmdlciBzcGVjIGlzIG1l cmVseSByZS1pdGVyYXRpbmcgc3RhbmRhcmQgSFRUUCBydWxlcywgSSBzdWdnZXN0IGp1c3QgcmVt b3ZpbmcgdGhpcyBsYW5ndWFnZS4gLVRpbTx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDg6MjggQU0sIFBhdWwgRS4g Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iIHRhcmdldD0i X2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91 PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sa3MsPHU+PC91Pjx1 PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhZCB0aGlzIHByZXZpb3VzbHk6PHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnElmIHRoZSBjbGllbnQgcXVlcmllcyB0aGUgV2ViRmluZ2Vy IHNlcnZlciBhbmQgcHJvdmlkZXMgYSBVUkkgZm9yIHdoaWNoIHRoZSBzZXJ2ZXIgaGFzIG5vIGlu Zm9ybWF0aW9uLCB0aGUgc2VydmVyIE1VU1QgcmV0dXJuIGEgNDA0IHN0YXR1cyBjb2RlLuKAnTx1 PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lb25lIHBvc3RlZCB0byB0aGUgbGlzdCB0 aGF0IHdlIHNob3VsZCB0YWxrIGFib3V0IHBvc2l0aXZlIHJlcGxpZXMgYW5kIG1lbnRpb24gdGhh dCBhIGNsaWVudCBtaWdodCBiZSByZWplY3RlZCB3aXRoIGEgNDAxLiZuYnNwOyBTbywgSSB3cm90 ZSB0aGlzIHRleHQgdG8gYmUgYXBwZW5kZWQgdG8gdGhlIGVuZCBvZiB0aGF0IGFib3ZlIHBhcmFn cmFwaDo8dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1Pjwv dT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcSWYgdGhlIHNlcnZlciBpcyBh YmxlIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gaW4gcmVzcG9uc2UgdG8gYSByZXF1ZXN0LCBpdCBN VVNUIGRvIHNvIHVzaW5nIGFuIGFwcHJvcHJpYXRlIDJ4eCBIVFRQIHN0YXR1cyBjb2RlIGFuZCBp bmNsdWRpbmcgdGhlIHJlcXVlc3RlZCByZXByZXNlbnRhdGlvbiBpbiB0aGUgYm9keSBvZiB0aGUg cmVzcG9uc2UuJm5ic3A7IEEgc2VydmVyIE1BWSBhbHNvIHJldHVybiBvdGhlciBIVFRQDQogc3Rh dHVzIGNvZGVzLCBhcyBhcHByb3ByaWF0ZSwgc3VjaCBhcyBhIDQwMSB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBjbGllbnQgaXMgbm90IGF1dGhvcml6ZWQgdG8gaXNzdWUgYSByZXF1ZXN0IHRvIHRoZSBz ZXJ2ZXIu4oCdPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoaXMgYWdyZWVhYmxl PyZuYnNwOyBQbGVhc2Ugc3VnZ2VzdCB3b3JkaW5nIGNoYW5nZXMsIGlmIG5vdC48dT48L3U+PHU+ PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+UGF1bDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQp3ZWJmaW5nZXIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOndlYmZpbmdl ckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPndlYmZpbmdlckBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYmZpbmdlciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2Vi ZmluZ2VyPC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPndlYmZp bmdlciBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOndlYmZp bmdlckBpZXRmLm9yZyI+d2ViZmluZ2VyQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYmZpbmdlciI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJmaW5nZXI8L2E+PC9zcGFu Pjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwh LS0NCnNwYW4uR3JhbUUge21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi0t Pg0KPC9zdHlsZT4NCjx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCjx0Ym9keT4NCjx0cj4N Cjx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbDsgZm9u dC1zaXplOjEycHg7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUi Pg0KPGRpdiBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kg YWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5k aWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpDQogYWx0cmEgYXppb25lIGRl cml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdv cm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l bnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRp YXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp c3RydXppb25lLCBHcmF6aWUuDQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPHAgYWxpZ249Imp1c3Rp ZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxp bmUtaGVpZ2h0Om5vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50czwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6DQogIDcuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6VmVyZGFuYTttc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PHNwYW4gY2xh c3M9IkdyYW1FIj5pczwvc3Bhbj4mbmJzcDs8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hO21zby1hbnNp LWxhbmd1YWdlOkVOLUdCIj5jb25maWRlbnRpYWwNCiBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0 aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXINCiBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4NCjwvc3Bhbj48L3NwYW4+PC9wPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6VmVyZGFuYSI+ PGltZyBzcmM9ImNpZDowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM0BUSS5EaXNjbGFp bWVyIiBhbHQ9InJpc3BldHRhIGwnYW1iaWVudGUiIHdpZHRoPSIyNiIgaGVpZ2h0PSI0MCI+Umlz cGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNl c3NhcmlvLjwvc3Bhbj48L2I+DQo8cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A2FC82BDA22C4063949BB9D4671B0245telecomitaliait_-- --_c75c2bc9-3f76-41b5-9293-6b8c05ce8c35_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_c75c2bc9-3f76-41b5-9293-6b8c05ce8c35_-- From paulej@packetizer.com Thu Dec 20 10:02:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2AB21F8A99 for ; Thu, 20 Dec 2012 10:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpsXy-hFMp90 for ; Thu, 20 Dec 2012 10:02:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8B21F8A93 for ; Thu, 20 Dec 2012 10:02:53 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKI2pPF004005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 13:02:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356026572; bh=UdHVSLHOgnNfPjm94R/ZT0UKNDIiba2v0DhasveeFsQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ewfi9Ev+1JcCRjyVQBiQaFOWRlQy4bwxUCuBG5tzjsNFjjpXy2d5Wqzr1H9ObC1Mc XpcmeqGv9gT0XBMei3aaZ3bfmDqtpLTslWvkzbJY+mUXWmsNHR0XirxU7ZNxgjx4i2 EXQrVfg45BYxv2odwAX1cK5Bnj/0rrIHGk4XyH4k= From: "Paul E. Jones" To: "'Tim Bray'" References: <044501cddece$fd045040$f70cf0c0$@packetizer.com> <048401cdded8$605d6c90$211845b0$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 13:02:59 -0500 Message-ID: <04c701cddedc$3f996000$becc2000$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C8_01CDDEB2.56C46970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH37xPjZJRUcIsUNQeBWhT/3tk+XwJBmtyyAWDszUcCCDXr2pegg9+A Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:03:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04C8_01CDDEB2.56C46970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But there server did find something. It found the "webfinger" resource. The software that responds to the query has to then decided what it returns. It might be logical to some, but I'd argue we need to state this to avoid confusion. I don't think 2xx or 401 needs to be stated, though. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, December 20, 2012 12:53 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language That's what 404 is for; I quote RFC2616: 10.4.5 404 Not Found The server has not found anything matching the Request-URI. It's bad practice to incorporate referenced specifications by value not by reference. -T On Thu, Dec 20, 2012 at 9:35 AM, Paul E. Jones wrote: The 404 bit is needed, since the "webfinger" server was found. just not the resource being queried. That question absolutely will come up. The new stuff (401, 2xx), I agree: it's re-stating what HTTP does. If others agree, I'll not put that into the spec. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, December 20, 2012 12:30 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Server Response language As in every other case where the WebFinger spec is merely re-iterating standard HTTP rules, I suggest just removing this language. -Tim On Thu, Dec 20, 2012 at 8:28 AM, Paul E. Jones wrote: Folks, We had this previously: "If the client queries the WebFinger server and provides a URI for which the server has no information, the server MUST return a 404 status code." Someone posted to the list that we should talk about positive replies and mention that a client might be rejected with a 401. So, I wrote this text to be appended to the end of that above paragraph: "If the server is able to provide information in response to a request, it MUST do so using an appropriate 2xx HTTP status code and including the requested representation in the body of the response. A server MAY also return other HTTP status codes, as appropriate, such as a 401 to indicate that the client is not authorized to issue a request to the server." Is this agreeable? Please suggest wording changes, if not. Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_04C8_01CDDEB2.56C46970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But there server did find something.  It found the = “webfinger” resource.  The software that responds to = the query has to then decided what it returns.  It might be logical = to some, but I’d argue we need to state this to avoid = confusion.

 

I don’t think 2xx or 401 needs to be stated, = though.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = December 20, 2012 12:53 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Server Response language

 

That’s = what 404 is for; I quote RFC2616:


 
10.4.5 404 Not =
Found
 
   The server has not found anything =
matching the Request-URI.


It’s bad practice to = incorporate referenced specifications by value not by reference.  = -T

On Thu, Dec 20, 2012 at 9:35 = AM, Paul E. Jones <paulej@packetizer.com> = wrote:

The 404 bit is needed, since the “webfinger” server was = found… just not the resource being queried.  That question = absolutely will come up.

 

The new stuff (401, 2xx), I agree: it’s re-stating what HTTP = does.

 

If others agree, I’ll not put that into the = spec.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = December 20, 2012 12:30 PM
To: Paul E. Jones
Cc: webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Server Response = language

 <= /o:p>

As in every other = case where the WebFinger spec is merely re-iterating standard HTTP = rules, I suggest just removing this language. -Tim

On Thu, Dec = 20, 2012 at 8:28 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

We had this = previously:

 <= /o:p>

“If = the client queries the WebFinger server and provides a URI for which the = server has no information, the server MUST return a 404 status = code.”

 <= /o:p>

Someone = posted to the list that we should talk about positive replies and = mention that a client might be rejected with a 401.  So, I wrote = this text to be appended to the end of that above = paragraph:

 <= /o:p>

“If = the server is able to provide information in response to a request, it = MUST do so using an appropriate 2xx HTTP status code and including the = requested representation in the body of the response.  A server MAY = also return other HTTP status codes, as appropriate, such as a 401 to = indicate that the client is not authorized to issue a request to the = server.”

 <= /o:p>

Is this = agreeable?  Please suggest wording changes, if = not.

 

Paul

 

 


______________= _________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 <= /o:p>

 

------=_NextPart_000_04C8_01CDDEB2.56C46970-- From laurentwalter.goix@telecomitalia.it Thu Dec 20 10:04:53 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1EE21F8A77 for ; Thu, 20 Dec 2012 10:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCgy-ou+yPgZ for ; Thu, 20 Dec 2012 10:04:52 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB721F88C4 for ; Thu, 20 Dec 2012 10:04:51 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 20 Dec 2012 19:04:50 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 20 Dec 2012 19:04:49 +0100 From: Goix Laurent Walter To: "Paul E. Jones" Date: Thu, 20 Dec 2012 19:04:43 +0100 Thread-Topic: [webfinger] Possibly speeding up the RFC process Thread-Index: Ac3e3IA5ZOa/+w5gTeunqqZ9bzAgPg== Message-ID: References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <047601cdded6$594c9090$0be5b1b0$@packetizer.com> <0C783CC2-F8C5-4520-9E9A-061B373A7CFA@telecomitalia.it> <04b001cddedb$5d36d0d0$17a47270$@packetizer.com> In-Reply-To: <04b001cddedb$5d36d0d0$17a47270$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "webfinger@ietf.org" , Nick Jennings , "webfinger@googlegroups.com" , Melvin Carvalho Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:04:53 -0000 DQoNCkxlIDIwIGTDqWMuIDIwMTIgw6AgMTg6NTYsICJQYXVsIEUuIEpvbmVzIiA8cGF1bGVqQHBh Y2tldGl6ZXIuY29tPiBhIMOpY3JpdCA6DQoNCj4gV2FsdGVyLA0KPg0KPj4+IElmIEkgd2VyZSB3 cml0aW5nIGEgY2xpZW50IGFuZCBzYXcgYW4gZW1haWwgYWRkcmVzcw0KPj4gInBhdWxlakBwYWNr ZXRpemVyLmNvbSIsIEkgd291bGQgYXNzdW1lIHRoZSBhc3NvY2lhdGVkIGFjY291bnQgVVJJIGlz DQo+PiBhY2N0OnBhdWxlakBwYWNrZXRpemVyLmNvbS4gIFBlcnNvbmFsbHksIEkgdGhpbmsgdGhh dCBpcyBhIHJlYXNvbmFibGUNCj4+IHRoaW5nIHRvIGRvLg0KPj4NCj4+IEkgd291bGQgcmF0aGVy IGV4cGVjdCB0aGF0IG5hdGl2ZWx5IHRoZSBlbWFpbCBjbGllbnQgcXVlcmllcyBmb3IgbWFpbHRv Og0KPj4gYXMgdGhpcyBpcyB0aGUgcmVhbCBpZGVudGlmaWVyIGl0IGtub3dzIG9mICh0aGUgb25l cyB1c2VkIGluIGVtYWlscykgYW5kDQo+PiBjb252ZXJ0aW5nIGl0IGludG8gYWNjdDogaXMganVz dCBhIGJlc3QgZ3Vlc3MuIFRoZSB0YXJnZXQgc2VydmVyIHNob3VsZA0KPj4gc3VyZWx5IGtub3dz IHRoYXQgbWFpbHRvOiBpZGVudGlmaWVyIHNpbmNlIGFuIGVtYWlsIHdhcyBwcm9iYWJseQ0KPj4g cmVjZWl2ZWQgZnJvbSB0aGF0IGlkLCB3aGlsc3QgdGhlIGNvcnJlc3BvbmRpbmcgYWNjdDogaWRl bnRpZmllciBtYXkgbm90DQo+PiBleGlzdC4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+DQo+IFll cywgd2hpY2ggaXMgb25lIG9mIHRoZSByZWFzb25zIEkgaGFkIHByZXZpb3VzbHkgcHJvcG9zZWQg aW50cm9kdWNpbmcgdGhlICJhY2N0IiBsaW5rIHJlbGF0aW9uLiAgR2l2ZW4gYSBrbm93biBVUkkg bGlrZSAibWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbSIsIHRoZSBjbGllbnQgY291bGQgcXVl cnkgdGhlIHNlcnZlciBsaWtlIHRoaXM6DQo+DQo+IEkganVzdCBhZGRlZCB0aGF0IHRvIG15IGRh dGFiYXNlIHNvIHlvdSBjYW4gc2VlIHdoYXQgaXQgd291bGQgbG9vayBsaWtlOg0KPg0KPiBjdXJs IGh0dHBzOi8vcGFja2V0aXplci5jb20vLndlbGwta25vd24vd2ViZmluZ2VyPw0KPiAgICAgICAg ICAgICAgICAgICAgICByZXNvdXJjZT1tYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tDQo+DQo+ IFRoYXQgc2FpZCwgSSB0aGluayBhICJiZXN0IGd1ZXNzIiBpcyBhY3R1YWxseSBwcmV0dHkgcmVh c29uYWJsZS4gIENvbnNpZGVyIHRoYXQgdGhlIGVtYWlsIGNsaWVudCBhY3R1YWxseSBORVZFUiBn ZXRzIGEgIm1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iIGZyb20gdGhlIFNNVFAgc2VydmVy LiAgUmF0aGVyLCBpdCBnZXRzIHRoaXM6DQo+DQo+ICBGcm9tOiAiUGF1bCBFLiBKb25lcyIgPHBh dWxlakBwYWNrZXRpemVyLmNvbT4NCj4NCj4gVGhpcyBpcyBhbiBlbWFpbCBhZGRyZXNzLCBidXQg SSB3b3VsZCBhcmd1ZSB0aGF0IGl0IHNob3VsZCBiZSBzYWZlIHRvIGFzc3VtZSB0aGF0IGFjY3Q6 cGF1bGVqQHBhY2tldGl6ZXIuY29tIHdpbGwgaWRlbnRpZnkgdGhlIHVzZXIncyBhY2NvdW50ICh2 cy4gaGlzIGVtYWlsLXJlbGF0ZWQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBvciB3aGF0ZXZl cikuDQo+DQo+IFNvLCBhcyBhIHdheSBmb3J3YXJkLCB3ZSBoYXZlIGEgY291cGxlIG9mIG9wdGlv bnM6DQo+ICAgIDEpIEFsbG93IHRoZSBhc3N1bXB0aW9uIHRvIGJlIG1hZGUgdGhhdCB0aGUgYWNj b3VudCBmb3INCj4gICAgICAgdGhlIGFib3ZlIGFkZHJlc3MgaXMgImFjY3Q6Ig0KPiAgICAyKSBE b24ndCBhbGxvdyB0aGUgYXNzdW1wdGlvbiBhbmQgcmVxdWlyZSBhIHF1ZXJ5IHRvDQo+ICAgICAg ICJtYWlsdG8iIGFuZCBkaXNjb3ZlciB0aGUgImFjY3QiIFVSSQ0KDQpJIGFtIG5vdCBzdXJlIHdl IGhhdmUgdG8gc3RhbmRhcmRpemUgdGhhdCBzcGVjaWZpYyBiZWhhdmlvdXIuIEl0IHdvdWxkIGJl IGltcG9zc2libGUgdG8gZG8gZm9yIGFsbCB1c2UgY2FzZXMgd2l0aCBhIG5vcm1hdGl2ZSBsYW5n dWFnZS4gVGhhdCBzYWlkIGl0IGNvdWxkIGJlIGNsZWFybHkgbWVudGlvbmVkIGluIHRoZSBleGFt cGxlcyB0byBndWlkZSBpbXBsZW1lbnRvcnMuDQpNeSBwcmVmZXJyZWQgb3B0aW9uIGZvciB0aGUg ZXhhbXBsZSB3b3VsZCBiZSB3aXRoIG1haWx0bzogKG9wdGlvbmFsbHkgbWVudGlvbmluZyB0aGF0 IHRoZSBhbnN3ZXIgY291bGQgcHJvdmlkZSBhIHByb29mIG9mIGV4aXN0ZW5jZSBvZiB0aGUgZXF1 aXZhbGVudCBhY2N0OiB1cmkgdGhyb3VnaCBhbiBhY2N0IHJlbC4NCg0KV2FsdGVyDQoNCj4NCj4g UGF1bA0KPg0KPg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5k aXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4g UXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0 ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBh bCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4N Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K From paulej@packetizer.com Thu Dec 20 10:10:54 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AEF21F8A99 for ; Thu, 20 Dec 2012 10:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-7akhpYbPni for ; Thu, 20 Dec 2012 10:10:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4A21F8419 for ; Thu, 20 Dec 2012 10:10:53 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBKIAj0V004414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 13:10:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356027045; bh=TSA9lshMS0uRnym2gVeaPYhcIw9w+Mx5+M2SDry4MkI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y3T3tDUCDbyhIBmZZ7/9pujE/a15tMbmYdkpbKgdxewYe+pgI9iTMNnIIDb0QQN0N fW/v5QigUrvR4+ru/Bm2i00ga3NGqJRJclHGCYs1Ir7PG/jWZDXdE0zmagV4N8kvlm ZVbUJqN+oFM+yaXmcRSKMaBDSeg7KTvWVYy7NwAk= From: "Paul E. Jones" To: "'Goix Laurent Walter'" References: <004201cddbcb$3a003ab0$ae00b010$@packetizer.com> <008a01cddbd4$17834140$4689c3c0$@packetizer.com> <00c801cddbda$72cc7d90$586578b0$@packetizer.com> <02a501cddc95$6a740a80$3f5c1f80$@packetizer.com> <047601cdded6$594c9090$0be5b1b0$@packetizer.com> <0C783CC2-F8C5-4520-9E9A-061B373A7CFA@telecomitalia.it> <04b001cddedb$5d36d0d0$17a47270$@packetizer.com> In-Reply-To: Date: Thu, 20 Dec 2012 13:10:53 -0500 Message-ID: <04d401cddedd$5a15a8c0$0e40fa40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXXsdYIDFkRYF/cKUyX9w1YoKrkAICVkdlAm5m3hAB68knVQGk1LrlAZwlmmgCS5qz2AKIYVhrAUWuRZABCyCqMQHH/q7wAodvYjICqq12zwNxb+Q3AdUTiK+YJuTBwA== Content-Language: en-us Cc: webfinger@ietf.org, 'Nick Jennings' , webfinger@googlegroups.com, 'Melvin Carvalho' Subject: Re: [webfinger] Possibly speeding up the RFC process X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:10:55 -0000 Walter, > > So, as a way forward, we have a couple of options: > > 1) Allow the assumption to be made that the account for > > the above address is "acct:" > > 2) Don't allow the assumption and require a query to > > "mailto" and discover the "acct" URI >=20 > I am not sure we have to standardize that specific behaviour. It would > be impossible to do for all use cases with a normative language. That > said it could be clearly mentioned in the examples to guide = implementors. > My preferred option for the example would be with mailto: (optionally > mentioning that the answer could provide a proof of existence of the > equivalent acct: uri through an acct rel. My preference is that we leave the examples we have in the text as they = are and encourage use of the "acct" URI if a query relates to a user's = account. Concrete recommendations might also come about through a = little more real-world experience. I suspect the first major service = provider to support WF will dictate how it works. Paul From paulej@packetizer.com Fri Dec 21 09:38:24 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3221F8A49 for ; Fri, 21 Dec 2012 09:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dy-rX2RL5P3 for ; Fri, 21 Dec 2012 09:38:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B701D21F895C for ; Fri, 21 Dec 2012 09:38:23 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBLHcMfc003967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 12:38:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356111502; bh=zdGphY0yojFa+kWJ/+qKRBxfk8qh1jkgc2f53oOErxg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VIEq0DhzAW49AKIRakjT3vJYryP7ULXwhlQjgyrf86G4BkJG6IyDcIL+iS35kC6t2 IYXOraiSpLJ0cbUVzIVMDp/QxkPSFX0l7hiP5ubggg0XymeZNs1rxTKjycYmBiTkAr +Q0qOl79f+yaIQFPChdgZVjCMnkM5WnnPnumpQkY= From: "Paul E. Jones" To: , References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> In-Reply-To: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 12:38:24 -0500 Message-ID: <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMz7gWtxLgac+I1n0R+LgHWh9rv+ZVXY8hQ Content-Language: en-us Subject: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:38:24 -0000 Folks, I just posted a revised version of the WebFinger text. Highlights include: * Change all queries to require HTTPS only * Forbid server redirection to HTTP URIs * Merged the "Introduction" and "Overview" sections * Moved some references to the informative references section * Removed instructions for the server to return specific status codes (Tim successfully argued it was not needed) * Retained one statement, though, in section 4.2 that requires a server to return a 400. However, the text was changed to refer to behavior in RFC 2616. Same end result, though. * Moved section the "rel" parameter section before the JRD section. * Made edits to the JRD section as discussed on the list * Various editorial changes Please have a look at this text and suggest any changes we should make. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, December 21, 2012 12:21 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Joseph Smarr > Filename : draft-ietf-appsawg-webfinger-08.txt > Pages : 20 > Date : 2012-12-21 > > Abstract: > This specification defines the WebFinger protocol, which can be used > to discover information about people or other entities on the > Internet using standard HTTP methods. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From kidehen@openlinksw.com Fri Dec 21 13:09:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CD621F8472 for ; Fri, 21 Dec 2012 13:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8T46lQJc81a for ; Fri, 21 Dec 2012 13:09:13 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7FED821F845D for ; Fri, 21 Dec 2012 13:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Kdv3D9KA9xoL9uqmucXNx68USI6uFjZKMidgHdYfJrI=; b=A7Ous29u5ThlPq8m0o8f0ZTN0qU4USxYmWK9n55NlybzabRTtZRfY27mBxVwTqqqrvBuAiKM45oMMFzHnqBNqzV1LPedYSc5czLmMpc3qYqZCjGX/2fCm+trCxGFR92B; Received: from kidehen.vpn ([10.100.2.3] helo=Macintosh-96.local) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1Tm9q5-0001Yd-GN; Fri, 21 Dec 2012 16:09:05 -0500 Message-ID: <50D4CFEF.9030701@openlinksw.com> Date: Fri, 21 Dec 2012 16:09:03 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Paul E. Jones" References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> In-Reply-To: <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070705050205080202060008" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:09:14 -0000 This is a cryptographically signed message in MIME format. --------------ms070705050205080202060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/21/12 12:38 PM, Paul E. Jones wrote: > Folks, > > I just posted a revised version of the WebFinger text. Highlights incl= ude: > * Change all queries to require HTTPS only > * Forbid server redirection to HTTP URIs > * Merged the "Introduction" and "Overview" sections > * Moved some references to the informative references section > * Removed instructions for the server to return specific > status codes (Tim successfully argued it was not needed) > * Retained one statement, though, in section 4.2 that > requires a server to return a 400. However, the > text was changed to refer to behavior in RFC 2616. > Same end result, though. > * Moved section the "rel" parameter section before the > JRD section. > * Made edits to the JRD section as discussed on the list > * Various editorial changes > > Please have a look at this text and suggest any changes we should make.= > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Friday, December 21, 2012 12:21 PM >> To: i-d-announce@ietf.org >> Cc: apps-discuss@ietf.org >> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.tx= t >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Applications Area Working Group >> Working Group of the IETF. >> >> Title : WebFinger >> Author(s) : Paul E. Jones >> Gonzalo Salgueiro >> Joseph Smarr >> Filename : draft-ietf-appsawg-webfinger-08.txt >> Pages : 20 >> Date : 2012-12-21 >> >> Abstract: >> This specification defines the WebFinger protocol, which can be us= ed >> to discover information about people or other entities on the >> Internet using standard HTTP methods. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-08 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > Paul, Could this: WebFinger is used to discover information about people or other entities on the Internet that are identified by a URI [6] or IRI [7] using standard Hypertext Transfer Protocol (HTTP) [2] methods over a secure transport [14]. become: WebFinger is used to discover information about people or other entities on the Internet that are *denoted* by a URI [6] or IRI [7]. = Actual information retrieval uses standard Hypertext Transfer Protocol (HTTP) [2] methods over a secure transport [14]. --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms070705050205080202060008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjIxMjEwOTAzWjAjBgkqhkiG9w0BCQQxFgQU5GaFyUi74l/sGhQe SPLNGfwGTcgwVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAeDjJQ1h8hSy8 WT91wCHsjsIdztk9b4LyauR8fMGjnFtjo0+uqGUDWHzWoLdd1HlnYB+jqAKKET1CgnfqwxIz dFhiZNrOkMkCHyjlMOh4BM4nsOyDQute5I9jlwdVV3ErE3nsAiU5X+eO33uoF2Xw5zDzWFL+ H9mynHkHcFiNmmvO/E+rLuFH103DMjkCLkR/7VcQSbgIRsYYZ/QCuVg8vem+Fmym0Kwky63E 1eqF+O08I7Xtbi07XSF+F7Skknx6jEpx5rF9Qk4alwx+UnnAudfAKjI0aJS9ME8KZ9qaqo3q +lYG1nRsTjrHhy+NIvnwmTCDSzRr2nmG7NArng1eiQAAAAAAAA== --------------ms070705050205080202060008-- From tbray@textuality.com Fri Dec 21 13:38:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104AC21F87C6 for ; Fri, 21 Dec 2012 13:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ1BMABLb8cg for ; Fri, 21 Dec 2012 13:38:04 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4B21F85AB for ; Fri, 21 Dec 2012 13:38:04 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so5104233obc.1 for ; Fri, 21 Dec 2012 13:38:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Z13OhZKCXFQTmuJlEBqTWcMlsHEOVPftI5f9RsKQQX0=; b=Q6LEVWosQ2xeN/ZToGzvXS0uNu33lSffJIy+luMhZ/Tkz/KQ8j2Z+C5ZB82pF9rZVe pNVeLS5uJ9ndxANAM65+GXcpK6uAoqDskJgyQk6OrDrAAqJ9m0K9wMG4RlRGUzaftt2/ TpS0RZ4ZfVsYemmV74B7fBdMAfdqulyy8Xc9wC4Fday/GAJOhz14pX7ypqYeYGH2BaZC qAERA7eJnxR+L/q4+YtTAAMmfnzkOYKLHmSLOW0Kjpb8zwhCRX7ITNKfTTn9iAe3sbE+ hrdGGQUQA9lkEOIwdetf+YCVgjzrb9Q4+JH966rugi73RgoaL9KGewE2xJvcBhf5j8gy kBVg== MIME-Version: 1.0 Received: by 10.182.47.66 with SMTP id b2mr12052531obn.34.1356125883809; Fri, 21 Dec 2012 13:38:03 -0800 (PST) Received: by 10.76.12.134 with HTTP; Fri, 21 Dec 2012 13:38:03 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <50D4CFEF.9030701@openlinksw.com> References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> Date: Fri, 21 Dec 2012 13:38:03 -0800 Message-ID: From: Tim Bray To: Kingsley Idehen Content-Type: multipart/alternative; boundary=14dae93998cd933eec04d163a92d X-Gm-Message-State: ALoCoQkVcp5bJlDIH8N3CH5nhjNvUpAbDVKbBXhGWQhVDmw3CpfJ7+CcEp6woCYwzaLqvEvuzuVm Cc: "Paul E. Jones" , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:38:05 -0000 --14dae93998cd933eec04d163a92d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No. The I in URI stands for Identifier. URIs identify resources, that=92s what they=92re for. -T On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen wr= ote: > > Could this: > > WebFinger is used to discover information about people or other > entities on the Internet that are identified by a URI [6] or IRI [7] > using standard Hypertext Transfer Protocol (HTTP) [2] methods over a > secure transport [14]. > > become: > > WebFinger is used to discover information about people or other > entities on the Internet that are *denoted* by a URI [6] or IRI [7]. > Actual information retrieval uses > standard Hypertext Transfer Protocol (HTTP) [2] methods over a > secure transport [14]. > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/**blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/**112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/**kidehen > > > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93998cd933eec04d163a92d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No. The I in URI stands for Identifier. URIs identify resources, that=92s w= hat they=92re for. -T

On Fri, Dec 21, 201= 2 at 1:09 PM, Kingsley Idehen <kidehen@openlinksw.com> = wrote:

Could this:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are identified by a URI [6] or IRI [7]=
=A0 =A0using standard Hypertext Transfer Protocol (HTTP) [2] methods over a=
=A0 =A0secure transport [14].

become:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are *denoted* by a URI [6] or IRI [7].= Actual information retrieval uses
=A0 =A0standard Hypertext Transfer Protocol (HTTP) [2] methods over a
=A0 =A0secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http:/= /www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/11239976774050861835= 0/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--14dae93998cd933eec04d163a92d-- From ve7jtb@ve7jtb.com Fri Dec 21 14:06:27 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2840B21F8846 for ; Fri, 21 Dec 2012 14:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdVGmtCHw2gj for ; Fri, 21 Dec 2012 14:06:26 -0800 (PST) Received: from mail-gh0-f171.google.com (mail-gh0-f171.google.com [209.85.160.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34421F879E for ; Fri, 21 Dec 2012 14:06:25 -0800 (PST) Received: by mail-gh0-f171.google.com with SMTP id r17so401021ghr.16 for ; Fri, 21 Dec 2012 14:06:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=9z9IlikqZp0P1BWzMXvGkVz+ZdgWAnB6KtQTP836sYQ=; b=ipGSVD1qS64olKIjq2ugSbg3tCHennH1HaOJoMmfO++RmLzOIP4uj+CBML+XP7ScZE MMk+uv2/XpgsmxvjoGHtcemUexWLIL2MGftW32+yl2Y0CKGbKDf2TvJMDJ0waBJ2/usv UBiq4sTUnDcmiSrYeqar3C9ZU7I2cBRkG+R7b3x1DzdA70OP+LDUIKxo8ot2egLZcPPF RVGp5FKuss5X68gDMfmIrmqTOamq74eyTRl2kN4YDQBhfUthFK/IxebM6fjkeF3JYMH4 M6ueqtFh6RRIFlpBEb+G296IecASoXiQ48eHhWIOKP37Pxp81cogdhd4YfkiBcyiIMIF 4JhA== X-Received: by 10.101.3.8 with SMTP id f8mr4276246ani.36.1356127585484; Fri, 21 Dec 2012 14:06:25 -0800 (PST) Received: from [192.168.1.211] (190-20-31-168.baf.movistar.cl. [190.20.31.168]) by mx.google.com with ESMTPS id z1sm10865378anj.2.2012.12.21.14.06.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 14:06:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E4F203CC-BE91-4270-BF29-009C890E40BE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 21 Dec 2012 19:06:14 -0300 Message-Id: References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlOj8U3dByUW9mO96CNfTuoX6YhuDVyc3VmOmZyAGUXuRYhhQivJjGuzJJKLaCrvrHFoh5K Cc: "Paul E. Jones" , Kingsley Idehen , webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:06:27 -0000 --Apple-Mail=_E4F203CC-BE91-4270-BF29-009C890E40BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tim is correct. The URI or IRI is an identifier for a resource. =20 Where it gets slightly grey is with the acct: scheme. However I think = that the scheme is still identifying an account as the resource, even if = there is no default derefrencing. I think I understand Kingsley wanting to make the transitive link form a = identifier for a resource to having that resource denote a abstract = object.=20 However I think that is best left to philosophers and the W3C. I think the current text is fine. John B. On 2012-12-21, at 6:38 PM, Tim Bray wrote: > No. The I in URI stands for Identifier. URIs identify resources, = that=92s what they=92re for. -T >=20 > On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen = wrote: >=20 > Could this: >=20 > WebFinger is used to discover information about people or other > entities on the Internet that are identified by a URI [6] or IRI = [7] > using standard Hypertext Transfer Protocol (HTTP) [2] methods over = a > secure transport [14]. >=20 > become: >=20 > WebFinger is used to discover information about people or other > entities on the Internet that are *denoted* by a URI [6] or IRI = [7]. Actual information retrieval uses > standard Hypertext Transfer Protocol (HTTP) [2] methods over a > secure transport [14]. >=20 > --=20 >=20 > Regards, >=20 > Kingsley Idehen=20 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 --Apple-Mail=_E4F203CC-BE91-4270-BF29-009C890E40BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Tim = is correct.

The URI or IRI is an identifier for a = resource.  

Where it gets slightly grey is = with the acct: scheme.  However I think that the scheme is still = identifying an account as the resource, even if there is no default = derefrencing.

I think I understand Kingsley = wanting to make the transitive link form a identifier for a resource to = having that resource denote a abstract = object. 

However I think that is best left = to philosophers and the W3C.

I think the = current text is fine.

John B.
On = 2012-12-21, at 6:38 PM, Tim Bray <tbray@textuality.com> = wrote:

No. The I in URI stands for Identifier. URIs identify = resources, that=92s what they=92re for. -T

On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen = <kidehen@openlinksw.com> wrote:

Could this:

 WebFinger is used to discover information about people or = other
   entities on the Internet that are identified by a URI [6] = or IRI [7]
   using standard Hypertext Transfer Protocol (HTTP) [2] = methods over a
   secure transport [14].

become:

 WebFinger is used to discover information about people or = other
   entities on the Internet that are *denoted* by a URI [6] or = IRI [7]. Actual information retrieval uses
   standard Hypertext Transfer Protocol (HTTP) [2] methods = over a
   secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/abo= ut
LinkedIn Profile: http://www.linkedin.com/in/kidehen






_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



= --Apple-Mail=_E4F203CC-BE91-4270-BF29-009C890E40BE-- From kidehen@openlinksw.com Fri Dec 21 14:22:48 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40921F85AB for ; Fri, 21 Dec 2012 14:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXdig7rGv5wj for ; Fri, 21 Dec 2012 14:22:46 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0C74C21F859D for ; Fri, 21 Dec 2012 14:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=NvmWu6pKsIaSljAu02BddQK8ofcAVFmehDfCdLr38Cg=; b=bs++e+50gf1xd9FetXuybV1UTo+rILiYSA5NWZpoWpCUP23Wuv+iy3Lre/DEhLYIRfyHacCQE5/RcqZEyQ/c48sLFdkKZmw+h4fnJu2ILHDJCKhFgDT7qFh5XbRxAEC3; Received: from kidehen.vpn ([10.100.2.3] helo=Macintosh-96.local) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1TmAzM-00037c-61; Fri, 21 Dec 2012 17:22:44 -0500 Message-ID: <50D4E132.6070407@openlinksw.com> Date: Fri, 21 Dec 2012 17:22:42 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tim Bray References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080900070603050508080702" Cc: "Paul E. Jones" , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:22:48 -0000 This is a cryptographically signed message in MIME format. --------------ms080900070603050508080702 Content-Type: multipart/alternative; boundary="------------010403070202070603090201" This is a multi-part message in MIME format. --------------010403070202070603090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/21/12 4:38 PM, Tim Bray wrote: > No. The I in URI stands for Identifier. URIs identify resources,=20 > that's what they're for. -T I know the "I" stands for "Identifier" but these "Identifiers" are being = used to "denote" entities (things), in this context. This subtle tweak has also been adopted in the Semantic Web discourse=20 realm (note latest RDF specs [1]) as a mechanism for adding clarity to=20 the function or URIs. Links: 1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html -- = see how denotation with regards to the function of URIs . Kingsley > > On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen=20 > > wrote: > > > Could this: > > WebFinger is used to discover information about people or other > entities on the Internet that are identified by a URI [6] or > IRI [7] > using standard Hypertext Transfer Protocol (HTTP) [2] methods > over a > secure transport [14]. > > become: > > WebFinger is used to discover information about people or other > entities on the Internet that are *denoted* by a URI [6] or IRI > [7]. Actual information retrieval uses > standard Hypertext Transfer Protocol (HTTP) [2] methods over a > secure transport [14]. > > --=20 > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/abou= t > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------010403070202070603090201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 12/21/12 4:38 PM, Tim Bray wrote:
No. The I in URI stands for Identifier. URIs identify= resources, that’s what they’re for. -T

I know the "I" stands for "Identifier" but these "Identifiers" are being used to "denote" entities (things), in this context.

This subtle tweak has also been adopted in the Semantic Web discourse realm (note latest RDF specs [1]) as a mechanism for adding clarity to the function or URIs.

Links:

1. http://dvcs.w3.org/hg/rdf/raw-f= ile/default/rdf-concepts/index.html -- see how denotation with regards to the function of URIs .

Kingsley 


--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767=
740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
--------------010403070202070603090201-- --------------ms080900070603050508080702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjIxMjIyMjQyWjAjBgkqhkiG9w0BCQQxFgQUYOR5HZYokXyQHKKP 8Oc/GVUrz1YwVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAoGqQ0ympWwjw zPDBVGzyeTqiCKswxymWu9UUw2Yk3zW2X4Rt65l8ZX2t/a5ziWR5A+sV4yPvB7LPQKAZ+0q/ QWEtM5mAgqajjeKDKAiX8owdH7M+g1Bbf0juCx6oQtPJIhtPu5wDhGTKRsQSL8p0skWEIQ80 hQJaNgzD2ACkMjp+VURSDks4Q6TOBsli5fdTLuil/CPoRBnkJpLLRlKrw/84ffefoXO2JLmB pu41gSDMUJ0TnDHC8utxOgxQ0Rj7mlSiqG4ETguvG1uVrhKhzzJM24VsipIntRzc3IP5nKl/ XCk0nccFOtyP06tIrWol9iWcHbzE2FnIa00Sjpvx+QAAAAAAAA== --------------ms080900070603050508080702-- From kidehen@openlinksw.com Fri Dec 21 14:30:39 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC3821F84F5 for ; Fri, 21 Dec 2012 14:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiEv28LEVhtC for ; Fri, 21 Dec 2012 14:30:38 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7C21F84E2 for ; Fri, 21 Dec 2012 14:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=g2zfTscK/J96wMF4ogaCPH+xITsjrDIF/C/UlutjJzY=; b=dj8v2md/Be6sS1fdT46M0INVqYKIrtGEe/WGwSUMvlCZC5YdJCkiQegxLqdH6wmjV8+O6g338nCG5Sw/3wVVnes9ZgCzbNno/z4dw4VTSdXvZkir/GqAbjixdInXaHfl; Received: from kidehen.vpn ([10.100.2.3] helo=Macintosh-96.local) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1TmB6z-0003kW-Pc for webfinger@ietf.org; Fri, 21 Dec 2012 17:30:38 -0500 Message-ID: <50D4E30C.8050003@openlinksw.com> Date: Fri, 21 Dec 2012 17:30:36 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020001090309010907080502" Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:30:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020001090309010907080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/21/12 5:06 PM, John Bradley wrote: > Tim is correct. > > The URI or IRI is an identifier for a resource. > > Where it gets slightly grey is with the acct: scheme. However I think = > that the scheme is still identifying an account as the resource, even=20 > if there is no default derefrencing. > > I think I understand Kingsley wanting to make the transitive link form = > a identifier for a resource to having that resource denote a abstract=20 > object. > > However I think that is best left to philosophers and the W3C. > > I think the current text is fine. acct: and http: scheme URIs are both being used to denote something (an=20 entity in a discourse realm). These identifiers are also associated with = resources that bear information about their referents. Using "denote"=20 helps clarify what's going on. You have a Name that resolves to Data. Thereby have two identifiers that = resolve to the same Data. One route by Name and the other by Location=20 (Address). Thus, a URI can dually identify a real world entity while=20 also doing the same for a resource that bears data describing said entity= =2E My suggestion is motivated by a desire to reuse breakthroughs that have=20 solved similar problems elsewhere. Links: 1. http://bit.ly/UXZEYV -- a live demonstration of Web-Scale verifiable=20 identity and protected resource access controls (puts these matters into = practical context) --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms020001090309010907080502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjIxMjIzMDM2WjAjBgkqhkiG9w0BCQQxFgQUK6L/CDR7G2PMxQ/k nCMEhJBYHl4wVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAaazqJgbEXJyd KXDNhBTiaIRMsjccBFL4t8Jyz6a0QiYJzq5D21A7F3o+Ot3KtpqiM4BceMPwJ0JO70x2Qhrw vTHTXpVFH2I9tgRdr4Ky83oSVIG9uvgACmw+iK7GfYXEJhlmzJS6mbVrgkrnHJJsTPQnlT3a YiCxrqiIwbpIIXZFY9mD1mkNPq/WHfubfSHoadA7NVkovz3VWhI4EPMBgadkt9C8IkbPYyrb zLa5JTimN2A5aHGfmTb9s0Hp6bqX3skJht1X1+IrdzfXMah5ZHq7i3YrAX6kWFjofIc3uSzI NzbFcKVyOoKQOl4P9Sb+9uIjT9f/PGETBjUDzGj0+AAAAAAAAA== --------------ms020001090309010907080502-- From dick.hardt@gmail.com Fri Dec 21 15:19:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC421F8A40 for ; Fri, 21 Dec 2012 15:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD884aX713ch for ; Fri, 21 Dec 2012 15:19:09 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5E21F8997 for ; Fri, 21 Dec 2012 15:19:09 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id um15so3002056pbc.16 for ; Fri, 21 Dec 2012 15:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=AFBNBuTbtRPjnWXVWn6WlW8qVl5nuiOhtQIUu9F1jbU=; b=t+h+7bwmPKDKMf/A+fQGTaD1OS5ZJbKXO1M74r6Z4lZIPQnPxE0ci9CHbtPbRy82rq HUpk6Zyeo2nTQiPH9eid3CgpUdBOcGGkBA5w6kYMgN1MtscIO2bntkKqLkuME8sL7eTw FuE1dcvlM7Hie1XqoM38VSlqn/dxUuF47UZOJqyulutsyL7MgDd5XH/TWGoQpA4NiiQw YPTSek2Nr+G5wYajTyVm+pgunADemSIVsQS+Py5Po91rQDL2c6YaARUT5AmLeDMFziPY WvR3YpHgfSll+oHJZ0Z4ouPSdjgcZWe0izrf7O6ioAeA8awv57h/JGHRcV7bfnsjvwIP I6ug== X-Received: by 10.66.89.42 with SMTP id bl10mr41276193pab.2.1356131948666; Fri, 21 Dec 2012 15:19:08 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id bh9sm8134411pab.12.2012.12.21.15.19.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 15:19:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> Date: Fri, 21 Dec 2012 15:18:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 23:19:10 -0000 Paul First off, thanks for all the effort in pulling this together -- it is = much simpler and tighter than it was in the past. One aspect that jumped out at me as a client implementor is that I am = not sure what URI am supposed to query when I have an email address for = a user.=20 In 3.1 acct: is used, but then later there are mailto: and http: URIs = that seem equivalent. i.e.: 1) acct:bob@example.com is used in 3.1, 3.2=20 2) mailto:bob@example.com is used in 3.3 3) http://www.example.com/~bob/ in 3.1 As a mail client I can see that (3) may be a separate URI that has = slightly different meaning that (1) or (2) As a server implementor, would I need to support both (1) and (2)? As a client, can I query either (1) or (2)? Is (2) only for email configuration per 3.3? Did I miss a reference somewhere that would clarify? -- Dick On Dec 21, 2012, at 9:38 AM, Paul E. Jones = wrote: > Folks, >=20 > I just posted a revised version of the WebFinger text. Highlights = include: > * Change all queries to require HTTPS only > * Forbid server redirection to HTTP URIs > * Merged the "Introduction" and "Overview" sections > * Moved some references to the informative references section > * Removed instructions for the server to return specific > status codes (Tim successfully argued it was not needed) > * Retained one statement, though, in section 4.2 that > requires a server to return a 400. However, the=20 > text was changed to refer to behavior in RFC 2616. > Same end result, though. > * Moved section the "rel" parameter section before the > JRD section. > * Made edits to the JRD section as discussed on the list > * Various editorial changes >=20 > Please have a look at this text and suggest any changes we should = make. >=20 > Paul >=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Friday, December 21, 2012 12:21 PM >> To: i-d-announce@ietf.org >> Cc: apps-discuss@ietf.org >> Subject: [apps-discuss] I-D Action: = draft-ietf-appsawg-webfinger-08.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Applications Area Working Group >> Working Group of the IETF. >>=20 >> Title : WebFinger >> Author(s) : Paul E. Jones >> Gonzalo Salgueiro >> Joseph Smarr >> Filename : draft-ietf-appsawg-webfinger-08.txt >> Pages : 20 >> Date : 2012-12-21 >>=20 >> Abstract: >> This specification defines the WebFinger protocol, which can be = used >> to discover information about people or other entities on the >> Internet using standard HTTP methods. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-08 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From tbray@textuality.com Fri Dec 21 15:32:04 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA121F8996 for ; Fri, 21 Dec 2012 15:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCq7NVWYq6LO for ; Fri, 21 Dec 2012 15:32:03 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCB7521F8994 for ; Fri, 21 Dec 2012 15:32:03 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id k14so5304727oag.0 for ; Fri, 21 Dec 2012 15:32:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=D5DgKzcH4oIjqLK3SpDhdcFUaZ652bmVukH99awHrWU=; b=RqZMkARxnUZkLioC3MMwG8quy5Fw/8C1eP5qxWuAnxuxNPMGxB5eKNZQkNaejYPfKw kNF0xuzgj85vJX+vwOLFyHYn9KFE1kYynGpnH+cSwl3xe+VOtIhh7bL3YozEVsdGTeL3 +1xKSV/HN29IWE05vizn9pV+1V59Xtaj0IKpaW+OW9FQ0cq3mns91Vs8mgf4yBV8AhxS bz3ShKHqw/c3IQWvm4lMc4/5CJ3vcwEpZObiTqid+APAUJekt+qCCZLisTkYPt4N/+5z UQHmuBIzu6p8gzE6PrtxQzZtsTNec1FJsxxu7mMCj4ifI3LRSoWUaf5t6NCKq/uqrLr6 BB9g== MIME-Version: 1.0 Received: by 10.182.150.72 with SMTP id ug8mr12325388obb.1.1356132723231; Fri, 21 Dec 2012 15:32:03 -0800 (PST) Received: by 10.76.12.134 with HTTP; Fri, 21 Dec 2012 15:32:03 -0800 (PST) X-Originating-IP: [74.198.150.191] Received: by 10.76.12.134 with HTTP; Fri, 21 Dec 2012 15:32:03 -0800 (PST) In-Reply-To: <50D4E132.6070407@openlinksw.com> References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> <50D4E132.6070407@openlinksw.com> Date: Fri, 21 Dec 2012 15:32:03 -0800 Message-ID: From: Tim Bray To: Kingsley Idehen Content-Type: multipart/alternative; boundary=f46d044469ad3c8a6204d16541fd X-Gm-Message-State: ALoCoQkGhaJPtS/RHtSttwPDp2rU4H2BOEzdO5owGbfP6+G+BogrQV37AilGxTDZWdr1pN3u8dOS Cc: webfinger@ietf.org, webfinger@googlegroups.com, "Paul E. Jones" Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 23:32:05 -0000 --f46d044469ad3c8a6204d16541fd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer. A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required. On Dec 21, 2012 2:22 PM, "Kingsley Idehen" wrote: > On 12/21/12 4:38 PM, Tim Bray wrote: > > No. The I in URI stands for Identifier. URIs identify resources, that=92s > what they=92re for. -T > > > I know the "I" stands for "Identifier" but these "Identifiers" are being > used to "denote" entities (things), in this context. > > This subtle tweak has also been adopted in the Semantic Web discourse > realm (note latest RDF specs [1]) as a mechanism for adding clarity to th= e > function or URIs. > > Links: > > 1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html -- > see how denotation with regards to the function of URIs . > > Kingsley > > > On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen = wrote: > >> >> Could this: >> >> WebFinger is used to discover information about people or other >> entities on the Internet that are identified by a URI [6] or IRI [7] >> using standard Hypertext Transfer Protocol (HTTP) [2] methods over a >> secure transport [14]. >> >> become: >> >> WebFinger is used to discover information about people or other >> entities on the Internet that are *denoted* by a URI [6] or IRI [7]. >> Actual information retrieval uses >> standard Hypertext Transfer Protocol (HTTP) [2] methods over a >> secure transport [14]. >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> > > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/list= info/webfinger > > > > -- > > Regards, > > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > --f46d044469ad3c8a6204d16541fd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, th= ese are instances of URIs, whose function per rfc3986 is to Identify resour= ces. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web s= tuff. No semantic castles in the sky required.

On Dec 21, 2012 2:22 PM, "Kingsley Idehen&q= uot; <kidehen@openlinksw.com> wrote:
=20 =20 =20
On 12/21/12 4:38 PM, Tim Bray wrote:
No. The I in URI stands for Identifier. URIs = identify resources, that=92s what they=92re for. -T

I know the "I" stands for "Identifier" but these &q= uot;Identifiers" are being used to "denote" entities (things), in this context.
This subtle tweak has also been adopted in the Semantic Web discourse realm (note latest RDF specs [1]) as a mechanism for adding clarity to the function or URIs.

Links:

1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-co= ncepts/index.html -- see how denotation with regards to the function of URIs .

Kingsley

On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:

Could this:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are identified by a URI [6] or IRI [7]
=A0 =A0using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
=A0 =A0secure transport [14].

become:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are *denoted* by a URI [6] o= r IRI [7]. Actual information retrieval uses
=A0 =A0standard Hypertext Transfer Protocol (HTTP) [2] methods over a
=A0 =A0secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/1123997677405= 08618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






_______________________________________________
webfinger mailing list
webfinger= @ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen
--f46d044469ad3c8a6204d16541fd-- From melvincarvalho@gmail.com Fri Dec 21 19:22:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F42B1F0CF5 for ; Fri, 21 Dec 2012 19:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGAzF9gOhlF6 for ; Fri, 21 Dec 2012 19:22:35 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6A62C1F0CF9 for ; Fri, 21 Dec 2012 19:22:35 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so7265422ieb.9 for ; Fri, 21 Dec 2012 19:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jjk/pzu/0W5+CPYt4bUQCRljngq6voda+cGjhqvEMW4=; b=ki5uvz9tJVLWrofe6kKqvRdPWQphhRV7M1H2HHMXhBZffjw0LVpShwQmpRuS4Ixx/U 6g3es7iJ8EfS60MfKxfmFHbikEW2fBKmhcgAq0lTM7v0Q6ysIT+Kpb3VyiKyqMyXHM+A dQHT035fOH04nLa4ZGx/k3s5mx1sS4Dldm+NGlkFYK7PjeUFn7wCMrydvrJzlO51jOu/ hrTyVuxAhWNyjYyyMfHM3SnKzxv8PihsuP3o9ueTfnPInT3ruFids3DACG3eUeSgwTVu 956wJHR1VwOa7Fe3Of8wSyJXsmNElBY+15GmuypVQJwTT5OUD0bO5DtCfWlgra6zk/lB jssg== MIME-Version: 1.0 Received: by 10.50.77.230 with SMTP id v6mr15436326igw.11.1356146554735; Fri, 21 Dec 2012 19:22:34 -0800 (PST) Received: by 10.42.61.203 with HTTP; Fri, 21 Dec 2012 19:22:34 -0800 (PST) In-Reply-To: References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> <50D4E132.6070407@openlinksw.com> Date: Sat, 22 Dec 2012 04:22:34 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=e89a8f3ba87fa88bc504d168795a Cc: webfinger@ietf.org, Kingsley Idehen , "Paul E. Jones" Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:22:36 -0000 --e89a8f3ba87fa88bc504d168795a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 22 December 2012 00:32, Tim Bray wrote: > Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has > been repealed, these are instances of URIs, whose function per rfc3986 is > to Identify resources. I don't see how it could be any clearer. > > A good thing about WF is that it's just good basic Web stuff. No semantic > castles in the sky required. > Totally agree, but perhaps for a moment forget AWWW, which, in imho. is an incredible piece of work. A URI is simply a global variable. The benefit of a URI is that is it is constant between heterogeneous systems. Hence the Web. As Tim once said, "When you add global variables to some languages, they fall apart, when you add them to hypertext, you get The Web" There was one deep question discussed it the last decade, and that was: is it reasonably to divide a web page into a number of sections. And the decision (perhaps arbitrary) in AWWW, was, that yes it that would be reasonable. After much thought on the subject, I am also of the opinion that, that is a reasonably approach. Im not really sure it's about castles in the sky, but rather, that if different systems take an entitty/attribute/value approach with a global naming scheme (ie the URI) we can strongly foster interop, and grow the network effect for mutual benefit. > On Dec 21, 2012 2:22 PM, "Kingsley Idehen" wrote= : > >> On 12/21/12 4:38 PM, Tim Bray wrote: >> >> No. The I in URI stands for Identifier. URIs identify resources, that=92= s >> what they=92re for. -T >> >> >> I know the "I" stands for "Identifier" but these "Identifiers" are being >> used to "denote" entities (things), in this context. >> >> This subtle tweak has also been adopted in the Semantic Web discourse >> realm (note latest RDF specs [1]) as a mechanism for adding clarity to t= he >> function or URIs. >> >> Links: >> >> 1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html -- >> see how denotation with regards to the function of URIs . >> >> Kingsley >> >> >> On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen wrote: >> >>> >>> Could this: >>> >>> WebFinger is used to discover information about people or other >>> entities on the Internet that are identified by a URI [6] or IRI [7] >>> using standard Hypertext Transfer Protocol (HTTP) [2] methods over a >>> secure transport [14]. >>> >>> become: >>> >>> WebFinger is used to discover information about people or other >>> entities on the Internet that are *denoted* by a URI [6] or IRI [7]. >>> Actual information retrieval uses >>> standard Hypertext Transfer Protocol (HTTP) [2] methods over a >>> secure transport [14]. >>> >>> -- >>> >>> Regards, >>> >>> Kingsley Idehen >>> Founder & CEO >>> OpenLink Software >>> Company Web: http://www.openlinksw.com >>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >>> Twitter/Identi.ca handle: @kidehen >>> Google+ Profile: https://plus.google.com/112399767740508618350/about >>> LinkedIn Profile: http://www.linkedin.com/in/kidehen >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >> >> >> _______________________________________________ >> webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/lis= tinfo/webfinger >> >> >> >> -- >> >> Regards, >> >> Kingsley Idehen=09 >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> --e89a8f3ba87fa88bc504d168795a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 22 December 2012 00:32, Tim Bray <tbray@textuality.com> wrote:

Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has= been repealed, these are instances of URIs, whose function per rfc3986 is = to Identify resources. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web s= tuff. No semantic castles in the sky required.


Tot= ally agree, but perhaps for a moment forget AWWW, which, in imho. is an inc= redible piece of work.

A URI is simply a global variable.=A0 The benefit of a URI is that is i= t is constant between heterogeneous systems.=A0 Hence the Web.=A0 As Tim on= ce said, "When you add global variables to some languages, they fall a= part, when you add them to hypertext, you get The Web"

There was one deep question discussed it the last decade, and that was:= =A0 is it reasonably to divide a web page into a number of sections.=A0 And= the decision (perhaps arbitrary) in AWWW, was, that yes it that would be r= easonable. =A0 After much thought on the subject, I am also of the opinion = that, that is a reasonably approach.=A0

=A0Im not really sure it's about castles in the sky, but rather, th= at if different systems take an entitty/attribute/value approach with a glo= bal naming scheme (ie the URI) we can strongly foster interop, and grow the= network effect for mutual benefit.

=A0
On Dec 21, 2012 2:22 PM, "Kingsley Idehen&q= uot; <kidehe= n@openlinksw.com> wrote:
=20 =20 =20
On 12/21/12 4:38 PM, Tim Bray wrote:
No. The I in URI stands for Identifier. URIs = identify resources, that=92s what they=92re for. -T

I know the "I" stands for "Identifier" but these &q= uot;Identifiers" are being used to "denote" entities (things), in this context.
This subtle tweak has also been adopted in the Semantic Web discourse realm (note latest RDF specs [1]) as a mechanism for adding clarity to the function or URIs.

Links:

1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-co= ncepts/index.html -- see how denotation with regards to the function of URIs .

Kingsley

On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:

Could this:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are identified by a URI [6] or IRI [7]
=A0 =A0using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
=A0 =A0secure transport [14].

become:

=A0WebFinger is used to discover information about people or other
=A0 =A0entities on the Internet that are *denoted* by a URI [6] o= r IRI [7]. Actual information retrieval uses
=A0 =A0standard Hypertext Transfer Protocol (HTTP) [2] methods over a
=A0 =A0secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/1123997677405= 08618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen






_______________________________________________
webfinger mailing list
webfinger= @ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http:/=
/www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about=

LinkedIn Profile: http://www.linkedin.com/in/kidehen

--e89a8f3ba87fa88bc504d168795a-- From paulej@packetizer.com Fri Dec 21 19:30:08 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BA121E8030 for ; Fri, 21 Dec 2012 19:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 827JSGoqFWk4 for ; Fri, 21 Dec 2012 19:30:07 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD26821E8037 for ; Fri, 21 Dec 2012 19:30:07 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM3U4IO031434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 22:30:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356147005; bh=a0MLbxOWbbG2tf7DX5qJ5RzfDP5iGwJgNGwxYZDm/Ys=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=R4qoIlEtK2LCClqS0X1nemDXOzbA7DIeeEZvBEMupTA92CASY7sP911neiZJLpVzq f3g45/jCIonvWgV+ty4SVegJqgQbxwBbQlRmolgZeVMEa1CzhOOM0VBq2h7WEfecVp rEuunm2NEjqs/7SpA0P4qpn0tmwn5JXfUrQoUsPk= From: "Paul E. Jones" To: "'Dick Hardt'" , References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> In-Reply-To: Date: Fri, 21 Dec 2012 22:30:07 -0500 Message-ID: <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMz7gWtxLgac+I1n0R+LgHWh9rv+QCHcUCtAxnzVvKVOvj3EA== Content-Language: en-us Cc: webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:30:08 -0000 Dick, > First off, thanks for all the effort in pulling this together -- it is > much simpler and tighter than it was in the past. I just hope we're almost done... this is exhausting ;-) > One aspect that jumped out at me as a client implementor is that I am > not sure what URI am supposed to query when I have an email address for > a user. This is the topic I tried to cover in section 4.5: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5 I don't want to go so far as to dictate what URI schemes must be used for what purpose in this draft. I don't want to limit people's creativity. That said, we do need a means of identifying "paulej@packetizer.com". Several years ago, people argued over this and decided "acct:" was a reasonable solution for identifying user accounts. This is what is recommended in WebFinger. > In 3.1 acct: is used, but then later there are mailto: and http: URIs > that seem equivalent. i.e.: > > 1) acct:bob@example.com is used in 3.1, 3.2 > 2) mailto:bob@example.com is used in 3.3 > 3) http://www.example.com/~bob/ in 3.1 > > As a mail client I can see that (3) may be a separate URI that has > slightly different meaning that (1) or (2) I would expect email clients to always use "acct" if the purpose is to look up information about a user's account at some domain. It does not matter if it's an email client, web browser, FTP client, or whatever. The "acct" URI has a specific purpose. I would expect the mail client to query the server if it is looking for configuration information. So, when I enter my email address into my client, it goes out and discovered my SMTP and IMAP server and whatever server settings to use. (Now, what is documented presently is just an example. I'd like to see a more complete spec for how that should be done. Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.) > As a server implementor, would I need to support both (1) and (2)? Servers should just serve whatever is populated in the database. My database has a "resource" table populated with: acct:paulej@packetizer.com http://packetizer.com http://www.packetizer.com mailto:paulej@packetizer.com xmpp:paulej@packetizer.com The records in the resource table have a 1-to-n relationship with another table called "aliases". The "acct:paulej@packetizer.com" record, for example, has an alias called "h323:paulej@packetizer.com". If you query my server using either of those values, you will get more-or-less the same reply. What changes is the aliases array in the output. In my server, mailto: is its own "resource". I did this, because the usage I expect is entirely different from "acct". I expect mailto to be used by email clients for configuration, as I mentioned. So, why the "h323" URI in aliases? Well, that's there only because I needed something to test with. Like mailto and xmpp, an H.323 client would query the server and get data to help auto-provision. If H.323 did not already have the ability (which is does using SRV records), I could imagine that an H.323 URI might be used by an H.323 client (or Gatekeeper) to determine how to route a call. Same thing for email. If MX records did not exist, I could imagine using this to advertise the location of the mail server for the queried URI. (Note that I'm not at all suggesting we switch to WF rather than use established call routing or mail routing mechanisms.) Bottom line is that the server should not really care about what is queried. However, the server admin who populates the database will care what is going to be queried. Since all of the important stuff have unique "rel" values, I could merge acct:, xmpp:, mailto:, etc. and serve up one large JRD. I think the right answer as to what gets placed where should come with WF procedure specs. For example, if we define a mail client auto-provisioning spec, let's define the mailto usage there. For the moment, I'm strongly suggesting we converge on using "acct" for most things, especially if looking for "social" kinds of information. > As a client, can I query either (1) or (2)? The client should issue a query knowing what it's looking for. If it's looking for my avatar for me, it should query acct:paulej@packetizer.com. If it's looking for an avatar that represents my blog, it would query using http://www.packetizer.com/people/paulej/blog/. If the email client is looking for provisioning info for my email address, it uses mailto. Anyway, that's my opinion. Nothing in the foregoing is law. ;-) > Is (2) only for email configuration per 3.3? I would say "it is for nothing" until the mail configuration spec or other spec is defined that says use mailto for this. This and other specs need to be written. > Did I miss a reference somewhere that would clarify? Perhaps only section 4.5. There is more work to be done, but I don't want to clutter the core WF spec with specific things like mail configuration. I presented that as an example to show the possibilities. BTW, I do want to work on that mail config doc if Cyrus does not :-) Paul From dick.hardt@gmail.com Fri Dec 21 19:39:45 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19021E803A for ; Fri, 21 Dec 2012 19:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQqKo235TBdm for ; Fri, 21 Dec 2012 19:39:44 -0800 (PST) Received: from mail-da0-f51.google.com (mail-da0-f51.google.com [209.85.210.51]) by ietfa.amsl.com (Postfix) with ESMTP id 700A721E8037 for ; Fri, 21 Dec 2012 19:39:44 -0800 (PST) Received: by mail-da0-f51.google.com with SMTP id i30so2358490dad.38 for ; Fri, 21 Dec 2012 19:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=7U6iuunKCNZJAl6nl1LKx/8uaEkAt1YjhhNu8Eh5zxM=; b=K5NfnbUIu7MhAch9CE5gxT0pJyKd3Dz19n/C9a5mOKGAv4zShVrGg23Kw8ZcOXIuG3 g1abU7Pj+nB2vmeikeUXPjT2JRxzluyvjq4P9c4JgYziQ+A/pCnHRBKWSufp1qgzGI+q Ut0ZVpMjqeyNQSk1pmx73LW/D7xBf+fL4CCxZswlruM8jjzXjtLkouYKY33oAKT/agW5 fzkF7YPYlSyQlwvQlJpxp1zyZ2manPCTR1bLztbp8BFLipHdVPAPdGmVjD53qsSZzL/A YLRf3aOl4d+i28N6F9JSPOqGIOx/z1O4JiPb2woDXzHIakxInSM33b96OW2btkWAdZtb ZW3Q== X-Received: by 10.66.88.99 with SMTP id bf3mr42409008pab.62.1356147583690; Fri, 21 Dec 2012 19:39:43 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id d8sm8477734pax.23.2012.12.21.19.39.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 19:39:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> Date: Fri, 21 Dec 2012 19:39:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <536A4D03-C7C9-4F69-B56C-BB0FE0271243@gmail.com> References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:39:45 -0000 Thanks for the explanation Paul. I see that section 4.5 answers my question.=20 Perhaps a pointer to section 4.5 in section 3 would help when an = implementor is reading the spec? I agree that we don't want to dictate more than that. -- Dick On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" = wrote: > Dick, >=20 >> First off, thanks for all the effort in pulling this together -- it = is >> much simpler and tighter than it was in the past. >=20 > I just hope we're almost done... this is exhausting ;-) >=20 >> One aspect that jumped out at me as a client implementor is that I am >> not sure what URI am supposed to query when I have an email address = for >> a user. >=20 > This is the topic I tried to cover in section 4.5: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5 >=20 > I don't want to go so far as to dictate what URI schemes must be used = for > what purpose in this draft. I don't want to limit people's = creativity. > That said, we do need a means of identifying "paulej@packetizer.com". > Several years ago, people argued over this and decided "acct:" was a > reasonable solution for identifying user accounts. This is what is > recommended in WebFinger. >=20 >> In 3.1 acct: is used, but then later there are mailto: and http: URIs >> that seem equivalent. i.e.: >>=20 >> 1) acct:bob@example.com is used in 3.1, 3.2 >> 2) mailto:bob@example.com is used in 3.3 >> 3) http://www.example.com/~bob/ in 3.1 >>=20 >> As a mail client I can see that (3) may be a separate URI that has >> slightly different meaning that (1) or (2) >=20 > I would expect email clients to always use "acct" if the purpose is to = look > up information about a user's account at some domain. It does not = matter if > it's an email client, web browser, FTP client, or whatever. The = "acct" URI > has a specific purpose. >=20 > I would expect the mail client to query the server if it is looking = for > configuration information. So, when I enter my email address into my > client, it goes out and discovered my SMTP and IMAP server and = whatever > server settings to use. (Now, what is documented presently is just an > example. I'd like to see a more complete spec for how that should be = done. > Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.) >=20 >> As a server implementor, would I need to support both (1) and (2)? >=20 > Servers should just serve whatever is populated in the database. My > database has a "resource" table populated with: > acct:paulej@packetizer.com > http://packetizer.com > http://www.packetizer.com > mailto:paulej@packetizer.com > xmpp:paulej@packetizer.com >=20 > The records in the resource table have a 1-to-n relationship with = another > table called "aliases". The "acct:paulej@packetizer.com" record, for > example, has an alias called "h323:paulej@packetizer.com". If you = query my > server using either of those values, you will get more-or-less the = same > reply. What changes is the aliases array in the output. >=20 > In my server, mailto: is its own "resource". I did this, because the = usage > I expect is entirely different from "acct". I expect mailto to be = used by > email clients for configuration, as I mentioned. >=20 > So, why the "h323" URI in aliases? Well, that's there only because I = needed > something to test with. Like mailto and xmpp, an H.323 client would = query > the server and get data to help auto-provision. If H.323 did not = already > have the ability (which is does using SRV records), I could imagine = that an > H.323 URI might be used by an H.323 client (or Gatekeeper) to = determine how > to route a call. Same thing for email. If MX records did not exist, = I > could imagine using this to advertise the location of the mail server = for > the queried URI. (Note that I'm not at all suggesting we switch to WF = rather > than use established call routing or mail routing mechanisms.) >=20 > Bottom line is that the server should not really care about what is = queried. > However, the server admin who populates the database will care what is = going > to be queried. Since all of the important stuff have unique "rel" = values, I > could merge acct:, xmpp:, mailto:, etc. and serve up one large JRD. >=20 > I think the right answer as to what gets placed where should come with = WF > procedure specs. For example, if we define a mail client = auto-provisioning > spec, let's define the mailto usage there. >=20 > For the moment, I'm strongly suggesting we converge on using "acct" = for most > things, especially if looking for "social" kinds of information. >=20 >> As a client, can I query either (1) or (2)? >=20 > The client should issue a query knowing what it's looking for. If = it's > looking for my avatar for me, it should query = acct:paulej@packetizer.com. > If it's looking for an avatar that represents my blog, it would query = using > http://www.packetizer.com/people/paulej/blog/. If the email client is > looking for provisioning info for my email address, it uses mailto. >=20 > Anyway, that's my opinion. Nothing in the foregoing is law. ;-) >=20 >> Is (2) only for email configuration per 3.3? >=20 > I would say "it is for nothing" until the mail configuration spec or = other > spec is defined that says use mailto for this. This and other specs = need to > be written. >=20 >> Did I miss a reference somewhere that would clarify? >=20 > Perhaps only section 4.5. There is more work to be done, but I don't = want > to clutter the core WF spec with specific things like mail = configuration. I > presented that as an example to show the possibilities. >=20 > BTW, I do want to work on that mail config doc if Cyrus does not :-) >=20 > Paul >=20 >=20 From paulej@packetizer.com Fri Dec 21 19:43:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4E121E8037 for ; Fri, 21 Dec 2012 19:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP2H-lSbnp-7 for ; Fri, 21 Dec 2012 19:43:05 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9E821E8030 for ; Fri, 21 Dec 2012 19:43:05 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM3h3rb032003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 22:43:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356147784; bh=unWKK98+bh826TgpbZt1AZKknjStjTsTDzKYrbyVL6k=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HI5BVNz39YTLg3bjj270dVIr5DDyPLxo5pXnl5h9s+lZdazgXAOiWYq90BOWzLz40 MlBZ9M5xVIl15d3s2z5WuFz7AUpyYKzOfCUwUHtCfcON55t/bZH1x+OZMoiZZMpvHi 6uWhAU/zSMAsRk/AyoURzKL9AI9Mai0+lHvOGdiE= From: "Paul E. Jones" To: "'Dick Hardt'" References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> <536A4D03-C7C9-4F69-B56C-BB0FE0271243@gmail.com> In-Reply-To: <536A4D03-C7C9-4F69-B56C-BB0FE0271243@gmail.com> Date: Fri, 21 Dec 2012 22:43:06 -0500 Message-ID: <072a01cddff6$7465a620$5d30f260$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMz7gWtxLgac+I1n0R+LgHWh9rv+QCHcUCtAxnzVvIBLOY2GwFfgaxplSaiCkA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:43:06 -0000 Any suggested wording? My hands have been smacked so many times... Paul > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Friday, December 21, 2012 10:40 PM > To: Paul E. Jones > Cc: webfinger@ietf.org; webfinger@googlegroups.com > Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg- > webfinger-08.txt > > Thanks for the explanation Paul. > > I see that section 4.5 answers my question. > > Perhaps a pointer to section 4.5 in section 3 would help when an > implementor is reading the spec? > > I agree that we don't want to dictate more than that. > > -- Dick > > On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" > wrote: > > > Dick, > > > >> First off, thanks for all the effort in pulling this together -- it > >> is much simpler and tighter than it was in the past. > > > > I just hope we're almost done... this is exhausting ;-) > > > >> One aspect that jumped out at me as a client implementor is that I am > >> not sure what URI am supposed to query when I have an email address > >> for a user. > > > > This is the topic I tried to cover in section 4.5: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5 > > > > I don't want to go so far as to dictate what URI schemes must be used > > for what purpose in this draft. I don't want to limit people's > creativity. > > That said, we do need a means of identifying "paulej@packetizer.com". > > Several years ago, people argued over this and decided "acct:" was a > > reasonable solution for identifying user accounts. This is what is > > recommended in WebFinger. > > > >> In 3.1 acct: is used, but then later there are mailto: and http: URIs > >> that seem equivalent. i.e.: > >> > >> 1) acct:bob@example.com is used in 3.1, 3.2 > >> 2) mailto:bob@example.com is used in 3.3 > >> 3) http://www.example.com/~bob/ in 3.1 > >> > >> As a mail client I can see that (3) may be a separate URI that has > >> slightly different meaning that (1) or (2) > > > > I would expect email clients to always use "acct" if the purpose is to > > look up information about a user's account at some domain. It does > > not matter if it's an email client, web browser, FTP client, or > > whatever. The "acct" URI has a specific purpose. > > > > I would expect the mail client to query the server if it is looking > > for configuration information. So, when I enter my email address into > > my client, it goes out and discovered my SMTP and IMAP server and > > whatever server settings to use. (Now, what is documented presently > > is just an example. I'd like to see a more complete spec for how that > should be done. > > Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.) > > > >> As a server implementor, would I need to support both (1) and (2)? > > > > Servers should just serve whatever is populated in the database. My > > database has a "resource" table populated with: > > acct:paulej@packetizer.com > > http://packetizer.com > > http://www.packetizer.com > > mailto:paulej@packetizer.com > > xmpp:paulej@packetizer.com > > > > The records in the resource table have a 1-to-n relationship with > > another table called "aliases". The "acct:paulej@packetizer.com" > > record, for example, has an alias called "h323:paulej@packetizer.com". > > If you query my server using either of those values, you will get > > more-or-less the same reply. What changes is the aliases array in the > output. > > > > In my server, mailto: is its own "resource". I did this, because the > > usage I expect is entirely different from "acct". I expect mailto to > > be used by email clients for configuration, as I mentioned. > > > > So, why the "h323" URI in aliases? Well, that's there only because I > > needed something to test with. Like mailto and xmpp, an H.323 client > > would query the server and get data to help auto-provision. If H.323 > > did not already have the ability (which is does using SRV records), I > > could imagine that an > > H.323 URI might be used by an H.323 client (or Gatekeeper) to > > determine how to route a call. Same thing for email. If MX records > > did not exist, I could imagine using this to advertise the location of > > the mail server for the queried URI. (Note that I'm not at all > > suggesting we switch to WF rather than use established call routing or > > mail routing mechanisms.) > > > > Bottom line is that the server should not really care about what is > queried. > > However, the server admin who populates the database will care what is > > going to be queried. Since all of the important stuff have unique > > "rel" values, I could merge acct:, xmpp:, mailto:, etc. and serve up > one large JRD. > > > > I think the right answer as to what gets placed where should come with > > WF procedure specs. For example, if we define a mail client > > auto-provisioning spec, let's define the mailto usage there. > > > > For the moment, I'm strongly suggesting we converge on using "acct" > > for most things, especially if looking for "social" kinds of > information. > > > >> As a client, can I query either (1) or (2)? > > > > The client should issue a query knowing what it's looking for. If > > it's looking for my avatar for me, it should query > acct:paulej@packetizer.com. > > If it's looking for an avatar that represents my blog, it would query > > using http://www.packetizer.com/people/paulej/blog/. If the email > > client is looking for provisioning info for my email address, it uses > mailto. > > > > Anyway, that's my opinion. Nothing in the foregoing is law. ;-) > > > >> Is (2) only for email configuration per 3.3? > > > > I would say "it is for nothing" until the mail configuration spec or > > other spec is defined that says use mailto for this. This and other > > specs need to be written. > > > >> Did I miss a reference somewhere that would clarify? > > > > Perhaps only section 4.5. There is more work to be done, but I don't > > want to clutter the core WF spec with specific things like mail > > configuration. I presented that as an example to show the > possibilities. > > > > BTW, I do want to work on that mail config doc if Cyrus does not :-) > > > > Paul > > > > From dick.hardt@gmail.com Fri Dec 21 19:48:13 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DB21E803A for ; Fri, 21 Dec 2012 19:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBrLCRenX-xR for ; Fri, 21 Dec 2012 19:48:12 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9E21E8037 for ; Fri, 21 Dec 2012 19:48:11 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id fa10so3178197pad.34 for ; Fri, 21 Dec 2012 19:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=ayFlL+G3k8CDqzC2P8f9ajZthQeaIy7mPue5w47Wg+0=; b=jp11QNznOZAW98LB6uzBzCJJuMpQBS6Rn5pBIqWJsokN3W/W6lv7yYRyo7EREiDXoB /AbcKvR/mgVzDYWmTL9Hvu7GAgUT1qPrQSu8gGh8aU3sQdriUyMbx5KRZgdUtRBlCNeR oDsqZwjqOUZ1LGxD8BQ1ESPArwz3WYcMZGyc1EIMqxBDd4DAdwGHqYZqERDcLIvF170A 2PpLVF4cmHFwI7o0Uct2iLAajV1s7jMlhcvMRs2VJyeLkqIPzP/kGbxfdLANk2Yff3s0 87tR22tpSWOHSrEdSkkuMxDd9bujq0ckxG4aKJFXgJ+vCXu7O0nmLKIQt1mKveqolZnA 0iVg== X-Received: by 10.68.143.162 with SMTP id sf2mr45216063pbb.137.1356148091381; Fri, 21 Dec 2012 19:48:11 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id x2sm8496679paw.8.2012.12.21.19.48.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 19:48:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B8A34437-1C54-4BAC-815D-F532B8F0090B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <072a01cddff6$7465a620$5d30f260$@packetizer.com> Date: Fri, 21 Dec 2012 19:48:02 -0800 Message-Id: <0C314A47-A866-4464-9037-EA136FE50AAD@gmail.com> References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> <536A4D03-C7C9-4F69-B56C-BB0FE0271243@gmail.com> <072a01cddff6$7465a620$5d30f260$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, webfinger@googlegroups.com, 'Dick Hardt' Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:48:13 -0000 --Apple-Mail=_B8A34437-1C54-4BAC-815D-F532B8F0090B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Certainly, text changes were what you requested. I must learn to read = directions. I must learn to read directions. I must learn to read = directions. Change the following in 3.1 In the above example, an "acct" URI [8] is used in the query, though any valid alias for the user might also be used. to be: In the above example, an "acct" URI [8] is used in the query, though any valid alias for the user might also be used. See section 4.5 for more information on WebFinger and URIs.=20 On Dec 21, 2012, at 7:43 PM, "Paul E. Jones" = wrote: > Any suggested wording? >=20 > My hands have been smacked so many times... >=20 > Paul >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Friday, December 21, 2012 10:40 PM >> To: Paul E. Jones >> Cc: webfinger@ietf.org; webfinger@googlegroups.com >> Subject: Re: [webfinger] [apps-discuss] I-D Action: = draft-ietf-appsawg- >> webfinger-08.txt >>=20 >> Thanks for the explanation Paul. >>=20 >> I see that section 4.5 answers my question. >>=20 >> Perhaps a pointer to section 4.5 in section 3 would help when an >> implementor is reading the spec? >>=20 >> I agree that we don't want to dictate more than that. >>=20 >> -- Dick >>=20 >> On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" >> wrote: >>=20 >>> Dick, >>>=20 >>>> First off, thanks for all the effort in pulling this together -- it >>>> is much simpler and tighter than it was in the past. >>>=20 >>> I just hope we're almost done... this is exhausting ;-) >>>=20 >>>> One aspect that jumped out at me as a client implementor is that I = am >>>> not sure what URI am supposed to query when I have an email address >>>> for a user. >>>=20 >>> This is the topic I tried to cover in section 4.5: >>> = http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5 >>>=20 >>> I don't want to go so far as to dictate what URI schemes must be = used >>> for what purpose in this draft. I don't want to limit people's >> creativity. >>> That said, we do need a means of identifying = "paulej@packetizer.com". >>> Several years ago, people argued over this and decided "acct:" was a >>> reasonable solution for identifying user accounts. This is what is >>> recommended in WebFinger. >>>=20 >>>> In 3.1 acct: is used, but then later there are mailto: and http: = URIs >>>> that seem equivalent. i.e.: >>>>=20 >>>> 1) acct:bob@example.com is used in 3.1, 3.2 >>>> 2) mailto:bob@example.com is used in 3.3 >>>> 3) http://www.example.com/~bob/ in 3.1 >>>>=20 >>>> As a mail client I can see that (3) may be a separate URI that has >>>> slightly different meaning that (1) or (2) >>>=20 >>> I would expect email clients to always use "acct" if the purpose is = to >>> look up information about a user's account at some domain. It does >>> not matter if it's an email client, web browser, FTP client, or >>> whatever. The "acct" URI has a specific purpose. >>>=20 >>> I would expect the mail client to query the server if it is looking >>> for configuration information. So, when I enter my email address = into >>> my client, it goes out and discovered my SMTP and IMAP server and >>> whatever server settings to use. (Now, what is documented presently >>> is just an example. I'd like to see a more complete spec for how = that >> should be done. >>> Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.) >>>=20 >>>> As a server implementor, would I need to support both (1) and (2)? >>>=20 >>> Servers should just serve whatever is populated in the database. My >>> database has a "resource" table populated with: >>> acct:paulej@packetizer.com >>> http://packetizer.com >>> http://www.packetizer.com >>> mailto:paulej@packetizer.com >>> xmpp:paulej@packetizer.com >>>=20 >>> The records in the resource table have a 1-to-n relationship with >>> another table called "aliases". The "acct:paulej@packetizer.com" >>> record, for example, has an alias called = "h323:paulej@packetizer.com". >>> If you query my server using either of those values, you will get >>> more-or-less the same reply. What changes is the aliases array in = the >> output. >>>=20 >>> In my server, mailto: is its own "resource". I did this, because = the >>> usage I expect is entirely different from "acct". I expect mailto = to >>> be used by email clients for configuration, as I mentioned. >>>=20 >>> So, why the "h323" URI in aliases? Well, that's there only because = I >>> needed something to test with. Like mailto and xmpp, an H.323 = client >>> would query the server and get data to help auto-provision. If = H.323 >>> did not already have the ability (which is does using SRV records), = I >>> could imagine that an >>> H.323 URI might be used by an H.323 client (or Gatekeeper) to >>> determine how to route a call. Same thing for email. If MX records >>> did not exist, I could imagine using this to advertise the location = of >>> the mail server for the queried URI. (Note that I'm not at all >>> suggesting we switch to WF rather than use established call routing = or >>> mail routing mechanisms.) >>>=20 >>> Bottom line is that the server should not really care about what is >> queried. >>> However, the server admin who populates the database will care what = is >>> going to be queried. Since all of the important stuff have unique >>> "rel" values, I could merge acct:, xmpp:, mailto:, etc. and serve up >> one large JRD. >>>=20 >>> I think the right answer as to what gets placed where should come = with >>> WF procedure specs. For example, if we define a mail client >>> auto-provisioning spec, let's define the mailto usage there. >>>=20 >>> For the moment, I'm strongly suggesting we converge on using "acct" >>> for most things, especially if looking for "social" kinds of >> information. >>>=20 >>>> As a client, can I query either (1) or (2)? >>>=20 >>> The client should issue a query knowing what it's looking for. If >>> it's looking for my avatar for me, it should query >> acct:paulej@packetizer.com. >>> If it's looking for an avatar that represents my blog, it would = query >>> using http://www.packetizer.com/people/paulej/blog/. If the email >>> client is looking for provisioning info for my email address, it = uses >> mailto. >>>=20 >>> Anyway, that's my opinion. Nothing in the foregoing is law. ;-) >>>=20 >>>> Is (2) only for email configuration per 3.3? >>>=20 >>> I would say "it is for nothing" until the mail configuration spec or >>> other spec is defined that says use mailto for this. This and other >>> specs need to be written. >>>=20 >>>> Did I miss a reference somewhere that would clarify? >>>=20 >>> Perhaps only section 4.5. There is more work to be done, but I = don't >>> want to clutter the core WF spec with specific things like mail >>> configuration. I presented that as an example to show the >> possibilities. >>>=20 >>> BTW, I do want to work on that mail config doc if Cyrus does not :-) >>>=20 >>> Paul >>>=20 >>>=20 >=20 >=20 --Apple-Mail=_B8A34437-1C54-4BAC-815D-F532B8F0090B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
Certainly, text changes =
were what you requested. I must learn to read directions. I must learn =
to read directions. I must learn to read directions.


Change the following in =
3.1
   In the above =
example, an "acct" URI [8] is used in the query, =
though
   any valid alias for the user might also be =
used.

to be:
   In the above example, an "acct" URI [8] is used in the query, =
though
   any valid alias for the user might also be used. See section 4.5 =
for
   more =
information on WebFinger and URIs. 


On Dec 21, 2012, = at 7:43 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Any suggested wording?

My hands have been smacked = so many times...

Paul

-----Original Message-----
From: Dick Hardt = [mailto:dick.hardt@gmail.com]
Sent: = Friday, December 21, 2012 10:40 PM
To: Paul E. Jones
Cc: webfinger@ietf.org; webfinger@googlegroups.com<= br>Subject: Re: [webfinger] [apps-discuss] I-D Action: = draft-ietf-appsawg-
webfinger-08.txt

Thanks for the = explanation Paul.

I see that section 4.5 answers my = question.

Perhaps a pointer to section 4.5 in section 3 would = help when an
implementor is reading the spec?

I agree that we = don't want to dictate more than that.

-- Dick

On Dec 21, = 2012, at 7:30 PM, "Paul E. Jones" <paulej@packetizer.com>
wro= te:

Dick,

First off, thanks for all the effort in pulling this = together -- it
is much simpler and tighter than it was in the = past.

I just hope we're almost done... this is = exhausting ;-)

One aspect that jumped = out at me as a client implementor is that I am
not sure what URI am = supposed to query when I have an email address
for a = user.

This is the topic I tried to cover in section = 4.5:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4= .5

I don't want to go so far as to dictate what URI schemes = must be used
for what purpose in this draft.  I don't want to = limit people's
creativity.
That said, we do need a means of identifying "paulej@packetizer.com".
Sever= al years ago, people argued over this and decided "acct:" was = a
reasonable solution for identifying user accounts.  This is = what is
recommended in WebFinger.

In = 3.1 acct: is used, but then later there are mailto: and http: = URIs
that seem equivalent. i.e.:

1) acct:bob@example.com is used in 3.1, 3.2
2) mailto:bob@example.com is used in = 3.3
3) http://www.example.com/~bob/ = in 3.1

As a mail client I can see that (3) may be a separate URI = that has
slightly different meaning that (1) or = (2)

I would expect email clients to always use = "acct" if the purpose is to
look up information about a user's = account at some domain.  It does
not matter if it's an email = client, web browser, FTP client, or
whatever.  The "acct" URI = has a specific purpose.

I would expect the mail client to query = the server if it is looking
for configuration information.  So, = when I enter my email address into
my client, it goes out and = discovered my SMTP and IMAP server and
whatever server settings to = use.  (Now, what is documented presently
is just an example. =  I'd like to see a more complete spec for how = that
should be done.
Ditto = for other kinds of clients, including SIP, XMPP, H.323, = etc.)

As a server implementor, would I = need to support both (1) and (2)?

Servers should = just serve whatever is populated in the database.  My
database = has a "resource" table populated with:
  acct:paulej@packetizer.com
  http://packetizer.com
=   http://www.packetizer.com
=   mailto:paulej@packetizer.com
=   xmpp:paulej@packetizer.com

= The records in the resource table have a 1-to-n relationship = with
another table called "aliases".  The "acct:paulej@packetizer.com"
record, for = example, has an alias called "h323:paulej@packetizer.com".
If = you query my server using either of those values, you will = get
more-or-less the same reply.  What changes is the aliases = array in the
output.

In = my server, mailto: is its own "resource".  I did this, because = the
usage I expect is entirely different from "acct".  I expect = mailto to
be used by email clients for configuration, as I = mentioned.

So, why the "h323" URI in aliases?  Well, that's = there only because I
needed something to test with.  Like mailto = and xmpp, an H.323 client
would query the server and get data to help = auto-provision.  If H.323
did not already have the ability = (which is does using SRV records), I
could imagine that an
H.323 = URI might be used by an H.323 client (or Gatekeeper) to
determine how = to route a call.  Same thing for email.  If MX records
did = not exist, I could imagine using this to advertise the location = of
the mail server for the queried URI. (Note that I'm not at = all
suggesting we switch to WF rather than use established call = routing or
mail routing mechanisms.)

Bottom line is that the = server should not really care about what = is
queried.
However, the = server admin who populates the database will care what is
going to be = queried.  Since all of the important stuff have unique
"rel" = values, I could merge acct:, xmpp:, mailto:, etc. and serve = up
one large JRD.

I = think the right answer as to what gets placed where should come = with
WF procedure specs.  For example, if we define a mail = client
auto-provisioning spec, let's define the mailto usage = there.

For the moment, I'm strongly suggesting we converge on = using "acct"
for most things, especially if looking for "social" = kinds of
information.

As a client, can I query = either (1) or (2)?

The client should issue a query = knowing what it's looking for.  If
it's looking for my avatar = for me, it should query
acct:paulej@packetizer.com.
If it's looking for an avatar that represents my blog, it = would query
using http://www.packetiz= er.com/people/paulej/blog/.  If the email
client is looking = for provisioning info for my email address, it = uses
mailto.

Anyway, = that's my opinion.  Nothing in the foregoing is law. = ;-)

Is (2) only for email configuration = per 3.3?

I would say "it is for nothing" until the = mail configuration spec or
other spec is defined that says use mailto = for this.  This and other
specs need to be = written.

Did I miss a reference = somewhere that would clarify?

Perhaps only section = 4.5.  There is more work to be done, but I don't
want to clutter = the core WF spec with specific things like mail
configuration. =  I presented that as an example to show = the
possibilities.

BTW, = I do want to work on that mail config doc if Cyrus does not = :-)

Paul




=

= --Apple-Mail=_B8A34437-1C54-4BAC-815D-F532B8F0090B-- From paulej@packetizer.com Fri Dec 21 20:01:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4C21F85FD for ; Fri, 21 Dec 2012 20:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sFPA6nzozds for ; Fri, 21 Dec 2012 20:01:01 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 237EF21F85E2 for ; Fri, 21 Dec 2012 20:01:01 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM40w07032745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 23:00:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356148859; bh=gY/vwYkBap0VyaQOmPsvN1BN3F8x8Otc7JhFXSpOxFM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Eja2ul/+7sl/bi8wtcrvKmsPjBdy8J7gA+R43PLqvows/MqxjwiNUJz7syL8+rbWr uj5jdYiQhwejPmWWtsFFJJf9m4DAHfrL5CEWcEIzBJXTMJEXEEzfqQfkRZFTntkKoF SyrGgCOiP7MdnLXs6tueI4iTXnm8OABdlq16b8Bc= From: "Paul E. Jones" To: "'Dick Hardt'" References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <072501cddff4$a3fe03c0$ebfa0b40$@packetizer.com> <536A4D03-C7C9-4F69-B56C-BB0FE0271243@gmail.com> <072a01cddff6$7465a620$5d30f260$@packetizer.com> <0C314A47-A866-4464-9037-EA136FE50AAD@gmail.com> In-Reply-To: <0C314A47-A866-4464-9037-EA136FE50AAD@gmail.com> Date: Fri, 21 Dec 2012 23:01:01 -0500 Message-ID: <072f01cddff8$f52e2d20$df8a8760$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0730_01CDDFCF.0C59D2D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMz7gWtxLgac+I1n0R+LgHWh9rv+QCHcUCtAxnzVvIBLOY2GwFfgaxpAZ/rlPcBSmc6KZUPVKnA Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 04:01:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0730_01CDDFCF.0C59D2D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK. And I'll split the balance the paragraph at that point so that the "alias" text starts as a new paragraph. Paul From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Friday, December 21, 2012 10:48 PM To: Paul E. Jones Cc: 'Dick Hardt'; webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt Certainly, text changes were what you requested. I must learn to read directions. I must learn to read directions. I must learn to read directions. Change the following in 3.1 In the above example, an "acct" URI [8 ] is used in the query, though any valid alias for the user might also be used. to be: In the above example, an "acct" URI [8 ] is used in the query, though any valid alias for the user might also be used. See section 4.5 for more information on WebFinger and URIs. On Dec 21, 2012, at 7:43 PM, "Paul E. Jones" wrote: Any suggested wording? My hands have been smacked so many times... Paul -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Friday, December 21, 2012 10:40 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg- webfinger-08.txt Thanks for the explanation Paul. I see that section 4.5 answers my question. Perhaps a pointer to section 4.5 in section 3 would help when an implementor is reading the spec? I agree that we don't want to dictate more than that. -- Dick On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" wrote: Dick, First off, thanks for all the effort in pulling this together -- it is much simpler and tighter than it was in the past. I just hope we're almost done... this is exhausting ;-) One aspect that jumped out at me as a client implementor is that I am not sure what URI am supposed to query when I have an email address for a user. This is the topic I tried to cover in section 4.5: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5 I don't want to go so far as to dictate what URI schemes must be used for what purpose in this draft. I don't want to limit people's creativity. That said, we do need a means of identifying "paulej@packetizer.com". Several years ago, people argued over this and decided "acct:" was a reasonable solution for identifying user accounts. This is what is recommended in WebFinger. In 3.1 acct: is used, but then later there are mailto: and http: URIs that seem equivalent. i.e.: 1) acct:bob@example.com is used in 3.1, 3.2 2) mailto:bob@example.com is used in 3.3 3) http://www.example.com/~bob/ in 3.1 As a mail client I can see that (3) may be a separate URI that has slightly different meaning that (1) or (2) I would expect email clients to always use "acct" if the purpose is to look up information about a user's account at some domain. It does not matter if it's an email client, web browser, FTP client, or whatever. The "acct" URI has a specific purpose. I would expect the mail client to query the server if it is looking for configuration information. So, when I enter my email address into my client, it goes out and discovered my SMTP and IMAP server and whatever server settings to use. (Now, what is documented presently is just an example. I'd like to see a more complete spec for how that should be done. Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.) As a server implementor, would I need to support both (1) and (2)? Servers should just serve whatever is populated in the database. My database has a "resource" table populated with: acct:paulej@packetizer.com http://packetizer.com http://www.packetizer.com mailto:paulej@packetizer.com xmpp:paulej@packetizer.com The records in the resource table have a 1-to-n relationship with another table called "aliases". The "acct:paulej@packetizer.com" record, for example, has an alias called "h323:paulej@packetizer.com". If you query my server using either of those values, you will get more-or-less the same reply. What changes is the aliases array in the output. In my server, mailto: is its own "resource". I did this, because the usage I expect is entirely different from "acct". I expect mailto to be used by email clients for configuration, as I mentioned. So, why the "h323" URI in aliases? Well, that's there only because I needed something to test with. Like mailto and xmpp, an H.323 client would query the server and get data to help auto-provision. If H.323 did not already have the ability (which is does using SRV records), I could imagine that an H.323 URI might be used by an H.323 client (or Gatekeeper) to determine how to route a call. Same thing for email. If MX records did not exist, I could imagine using this to advertise the location of the mail server for the queried URI. (Note that I'm not at all suggesting we switch to WF rather than use established call routing or mail routing mechanisms.) Bottom line is that the server should not really care about what is queried. However, the server admin who populates the database will care what is going to be queried. Since all of the important stuff have unique "rel" values, I could merge acct:, xmpp:, mailto:, etc. and serve up one large JRD. I think the right answer as to what gets placed where should come with WF procedure specs. For example, if we define a mail client auto-provisioning spec, let's define the mailto usage there. For the moment, I'm strongly suggesting we converge on using "acct" for most things, especially if looking for "social" kinds of information. As a client, can I query either (1) or (2)? The client should issue a query knowing what it's looking for. If it's looking for my avatar for me, it should query acct:paulej@packetizer.com. If it's looking for an avatar that represents my blog, it would query using http://www.packetizer.com/people/paulej/blog/. If the email client is looking for provisioning info for my email address, it uses mailto. Anyway, that's my opinion. Nothing in the foregoing is law. ;-) Is (2) only for email configuration per 3.3? I would say "it is for nothing" until the mail configuration spec or other spec is defined that says use mailto for this. This and other specs need to be written. Did I miss a reference somewhere that would clarify? Perhaps only section 4.5. There is more work to be done, but I don't want to clutter the core WF spec with specific things like mail configuration. I presented that as an example to show the possibilities. BTW, I do want to work on that mail config doc if Cyrus does not :-) Paul ------=_NextPart_000_0730_01CDDFCF.0C59D2D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK.  And I’ll split the balance the paragraph at that = point so that the “alias” text starts as a new = paragraph.

 

Paul

 

From:= = Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Friday, = December 21, 2012 10:48 PM
To: Paul E. Jones
Cc: = 'Dick Hardt'; webfinger@ietf.org; = webfinger@googlegroups.com
Subject: Re: [webfinger] = [apps-discuss] I-D Action: = draft-ietf-appsawg-webfinger-08.txt

 

Certainly, text changes were what you =
requested. I must learn to read directions. I must learn to read =
directions. I must learn to read =
directions.


Change the following in =
3.1
   In the above example, an =
"acct" URI [8] is used in the =
query, though
   any valid alias for the user =
might also be used.

 

to be:

   In the above example, an =
"acct" URI [8] is used in the =
query, though
   any valid alias for the user =
might also be used. See section 4.5 for
   more information on WebFinger =
and URIs. 


On Dec = 21, 2012, at 7:43 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



Any suggested wording?

My hands have been = smacked so many times...

Paul


-----Original Message-----
From: Dick Hardt = [mailto:dick.hardt@gmail.com]
Sent: = Friday, December 21, 2012 10:40 PM
To: Paul E. Jones
Cc: webfinger@ietf.org; webfinger@googlegroups.com=
Subject: Re: [webfinger] [apps-discuss] I-D Action: = draft-ietf-appsawg-
webfinger-08.txt

Thanks for the = explanation Paul.

I see that section 4.5 answers my = question.

Perhaps a pointer to section 4.5 in section 3 would = help when an
implementor is reading the spec?

I agree that we = don't want to dictate more than that.

-- Dick

On Dec 21, = 2012, at 7:30 PM, "Paul E. Jones" <paulej@packetizer.com>
wr= ote:


Dick,


First off, thanks for all the effort in pulling this = together -- it
is much simpler and tighter than it was in the = past.


I just hope we're almost = done... this is exhausting ;-)


One aspect that jumped out at me as a client = implementor is that I am
not sure what URI am supposed to query when = I have an email address
for a user.


This is the topic I tried to cover in section = 4.5:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section= -4.5

I don't want to go so far as to dictate what URI schemes = must be used
for what purpose in this draft.  I don't want to = limit people's

creativity.

That said, we do need a means of identifying "paulej@packetizer.com".Several years ago, people argued over this and decided = "acct:" was a
reasonable solution for identifying user = accounts.  This is what is
recommended in = WebFinger.


In 3.1 acct: = is used, but then later there are mailto: and http: URIs
that seem = equivalent. i.e.:

1) acct:bob@example.com is used in 3.1, 3.2
2) mailto:bob@example.com is used in = 3.3
3) http://www.example.com/~bob/ = in 3.1

As a mail client I can see that (3) may be a separate URI = that has
slightly different meaning that (1) or (2)


I would expect email clients to always use = "acct" if the purpose is to
look up information about a = user's account at some domain.  It does
not matter if it's an = email client, web browser, FTP client, or
whatever.  The = "acct" URI has a specific purpose.

I would expect the = mail client to query the server if it is looking
for configuration = information.  So, when I enter my email address into
my client, = it goes out and discovered my SMTP and IMAP server and
whatever = server settings to use.  (Now, what is documented presently
is = just an example.  I'd like to see a more complete spec for how = that

should be = done.

Ditto for other kinds = of clients, including SIP, XMPP, H.323, = etc.)


As a server = implementor, would I need to support both (1) and (2)?


Servers should just serve whatever is populated in = the database.  My
database has a "resource" table = populated with:
  acct:paulej@packetizer.com
  http://packetizer.com
  <= a = href=3D"http://www.packetizer.com">http://www.packetizer.com
 = ; mailto:paulej@packetizer.com  xmpp:paulej@packetizer.com
The records in the resource table have a 1-to-n relationship = with
another table called "aliases".  The = "acct:paulej@packetizer.com"
record, for = example, has an alias called "h323:paulej@packetizer.com".If you query my server using either of those values, you will = get
more-or-less the same reply.  What changes is the aliases = array in the

output.


In my server, mailto: is its own = "resource".  I did this, because the
usage I expect is = entirely different from "acct".  I expect mailto to
be = used by email clients for configuration, as I mentioned.

So, why = the "h323" URI in aliases?  Well, that's there only = because I
needed something to test with.  Like mailto and xmpp, = an H.323 client
would query the server and get data to help = auto-provision.  If H.323
did not already have the ability = (which is does using SRV records), I
could imagine that an
H.323 = URI might be used by an H.323 client (or Gatekeeper) to
determine how = to route a call.  Same thing for email.  If MX records
did = not exist, I could imagine using this to advertise the location = of
the mail server for the queried URI. (Note that I'm not at = all
suggesting we switch to WF rather than use established call = routing or
mail routing mechanisms.)

Bottom line is that the = server should not really care about what is

queried.

However, the server admin who populates the database = will care what is
going to be queried.  Since all of the = important stuff have unique
"rel" values, I could merge = acct:, xmpp:, mailto:, etc. and serve up

one large JRD.


I think the right answer as to what gets placed = where should come with
WF procedure specs.  For example, if we = define a mail client
auto-provisioning spec, let's define the mailto = usage there.

For the moment, I'm strongly suggesting we converge = on using "acct"
for most things, especially if looking for = "social" kinds of

information.



As a = client, can I query either (1) or (2)?


The client should issue a query knowing what it's = looking for.  If
it's looking for my avatar for me, it should = query

acct:paulej@packetizer.com.

=

If it's looking for an avatar that represents my = blog, it would query
using http://www.packeti= zer.com/people/paulej/blog/.  If the email
client is looking = for provisioning info for my email address, it uses

mailto.


Anyway, that's my opinion.  Nothing in the = foregoing is law. ;-)


Is = (2) only for email configuration per 3.3?


I would say "it is for nothing" until = the mail configuration spec or
other spec is defined that says use = mailto for this.  This and other
specs need to be = written.


Did I miss a = reference somewhere that would clarify?


Perhaps only section 4.5.  There is more work = to be done, but I don't
want to clutter the core WF spec with = specific things like mail
configuration.  I presented that as an = example to show the

possibilities.


BTW, I do want to = work on that mail config doc if Cyrus does not = :-)

Paul

 

 

------=_NextPart_000_0730_01CDDFCF.0C59D2D0-- From matake@gmail.com Fri Dec 21 20:39:55 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B57021E8041 for ; Fri, 21 Dec 2012 20:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqh5wEB6k1Lc for ; Fri, 21 Dec 2012 20:39:54 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7E21E8040 for ; Fri, 21 Dec 2012 20:39:54 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id bi1so3192562pad.8 for ; Fri, 21 Dec 2012 20:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer; bh=iZrcp9UNPp+nSbUci+/JPBe2RCFrzPyYYmO4N3TF3K4=; b=yzXzzSowpntlS+2C87rSo1tL7vlRS8/ho80FSV3mh6SDJJfu5AqXt7a/rQ8OuxOaSW 1DvfvmojXsshpSS3ySq+2lS49EOeYaH9/jtM6SGVzepG/JFQrHFGS1Ro+di6KwGsRNDF 04qQzy93+rwnZcWPKaSec7amkBX+feVVSXeRIBIIwuUAj+dO3m4ylbYC7rbwlYP/ttl1 PIMCxCLoQXqV8H97jaEBill2Srg1ZnUfIUw8Mvd1CD+3lgA5JqckZlIZKgcjnqUF3CbM mT+MtQU4DuumMt9HHB1s/bVs/h9UbNWKPQ4Hc9xvZMIV/dgStd70c6G+QdEEmBFVaZSU 3piA== X-Received: by 10.68.227.97 with SMTP id rz1mr45739920pbc.54.1356151193889; Fri, 21 Dec 2012 20:39:53 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id ue7sm8136466pbc.53.2012.12.21.20.39.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 20:39:52 -0800 (PST) From: nov matake Content-Type: multipart/alternative; boundary="Apple-Mail=_C3EE3B2C-30A8-4869-9361-EED5B97FC7F9" Message-Id: Date: Sat, 22 Dec 2012 13:39:49 +0900 To: "webfinger@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 04:39:55 -0000 --Apple-Mail=_C3EE3B2C-30A8-4869-9361-EED5B97FC7F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I'm new to this ML. I'm writing a ruby webfinger library. https://rubygems.org/gems/webfinger After reading usecases in section 3, I have a question. In the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of discovery endpoint is = "example.com", not "p1.example.com". Is there any reason why these hosts are different? How did the client decide the host of the discovery endpoint from = resource URI? Thanks Nov Matake= --Apple-Mail=_C3EE3B2C-30A8-4869-9361-EED5B97FC7F9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

I'm new to this ML.

I'm writing a ruby webfinger library.
https://rubygems.org/gems/webfinger

After reading usecases in section 3, I have a question.

In the device info discovery example in section 3.4, resource is "device:p1.example.com" but the host of discovery endpoint is "example.com", not "p1.example.com".
Is there any reason why these hosts are different?
How did the client decide the host of the discovery endpoint from resource URI?

Thanks

Nov Matake --Apple-Mail=_C3EE3B2C-30A8-4869-9361-EED5B97FC7F9-- From matake@gmail.com Fri Dec 21 20:48:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D12021F84D9 for ; Fri, 21 Dec 2012 20:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5gLEH7A0lot for ; Fri, 21 Dec 2012 20:48:40 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 05BEE21F845F for ; Fri, 21 Dec 2012 20:48:39 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so2399167dan.23 for ; Fri, 21 Dec 2012 20:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=R0lAtRtXI3x/Uz48wTpTpNAhFi8bs0586MHWZjUmtdM=; b=p4c2dwuuFlz5L9u4INJIMIrv7BScQpFqqWcoNPoC1mfMfSKBxlXctK5qALZplQVUR0 DztiHfWtKbHS+wDi3PUHhbkUWXeUGXNEVaHWJ2CmarpWXnuxgP9EoOoyw7XgR35qQXNo LVq32244WbenRDcuBdcfnTDfDz3g0kRnzX/0aznhaTTt+HSLRelGtNwfFon9q19Qi1RL u65EKWrtSlfAO5qmLtnPdFgbo89W2zEqrMmA1NahwciWT3XikytL0S2HYRG3uD/hKAt8 UX50rKRR0vQJGgwA7kMp9dEkbS0U0ukJ2dyPNcRyquq76odxlV22ZXzpMG/f6eNRxz7k fd4g== X-Received: by 10.68.204.103 with SMTP id kx7mr46276932pbc.33.1356151719770; Fri, 21 Dec 2012 20:48:39 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id uk9sm8146792pbc.63.2012.12.21.20.48.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 20:48:38 -0800 (PST) From: nov matake Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> Date: Sat, 22 Dec 2012 13:48:37 +0900 To: "webfinger@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 04:48:40 -0000 Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need = to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in = rails. Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? Cheers, Nov Matake= From paulej@packetizer.com Fri Dec 21 20:57:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D1421F8920 for ; Fri, 21 Dec 2012 20:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMIrix-YMi9Z for ; Fri, 21 Dec 2012 20:57:20 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED2621F882D for ; Fri, 21 Dec 2012 20:57:20 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM4vGHu002994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 23:57:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356152237; bh=ZtEpJXECfp5zXYd9+enZaJTP/4h7cpB6k2eO+Yt8sls=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=oadiKDUEF4dCucEadQonLwMYb2/ACBzBI8ljUErWkFZvPc58vEZ0D7tGFxn5FIvX9 +5gh0f6UkksocSmT4oEPTx2JUm+qRwDMsawjDbMfzYZqRbpNb+hshKpkXBVhoVPHyh gqA2AhPxZfTvrptd/eSD0MXmuwqYLKO7qE/WE44Q= From: "Paul E. Jones" To: "'nov matake'" , References: In-Reply-To: Date: Fri, 21 Dec 2012 23:57:19 -0500 Message-ID: <075b01cde000$d283d790$778b86b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_075C_01CDDFD6.E9AE6BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeIapXe7gOJ5OOW00neyp/e43xx5eDvK1g Content-Language: en-us Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 04:57:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_075C_01CDDFD6.E9AE6BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nov, Keep in mind that this is an entirely fictional example. There isn't even a URI scheme called "device". The answer to your question would come from a document (if it existed, but does not) that describes the "device" URI and how to use it within the context of WebFinger. My thinking when I wrote this is that there are named devices on the network and one would query the parent domain to learn about the device. The parent in this case being example.com. It might be that there is a designated host that serves as the device info server called "devices.example.com" to which all queries are directed. In any case, this is completely unspecified and the example is there only to illustrate the range of use for WebFinger. It should not be viewed in any way as proper usage, though. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Friday, December 21, 2012 11:40 PM To: webfinger@ietf.org Subject: [webfinger] Question about device info discovery example. Hi all, I'm new to this ML. I'm writing a ruby webfinger library. https://rubygems.org/gems/webfinger After reading usecases in section 3, I have a question. In the device info discovery example in section 3.4, resource is "device:p1.example.com " but the host of discovery endpoint is "example.com ", not "p1.example.com ". Is there any reason why these hosts are different? How did the client decide the host of the discovery endpoint from resource URI? Thanks Nov Matake ------=_NextPart_000_075C_01CDDFD6.E9AE6BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nov,

 

Keep in mind that this is an entirely fictional example.  There = isn’t even a URI scheme called = “device”.

 

The answer to your question would come from a document (if it = existed, but does not) that describes the “device” URI and = how to use it within the context of WebFinger.

 

My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the = device.  The parent in this case being example.com.  It might = be that there is a designated host that serves as the device info server = called “devices.example.com” to which all queries are = directed.  In any case, this is completely unspecified and the = example is there only to illustrate the range of use for = WebFinger.  It should not be viewed in any way as proper usage, = though.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of nov matake
Sent: Friday, December 21, 2012 11:40 = PM
To: webfinger@ietf.org
Subject: [webfinger] = Question about device info discovery = example.

 

Hi = all,

I'm new to this ML.

I'm writing a ruby webfinger = library.
https://rubygems.org/gems/we= bfinger

After reading usecases in section 3, I have a = question.

In the device info discovery example in section 3.4, = resource is "device:p1.example.com" but the host of = discovery endpoint is "example.com", not "p1.example.com".
Is there = any reason why these hosts are different?
How did the client decide = the host of the discovery endpoint from resource = URI?

Thanks

Nov = Matake

------=_NextPart_000_075C_01CDDFD6.E9AE6BD0-- From matake@gmail.com Fri Dec 21 21:10:36 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F22121E8042 for ; Fri, 21 Dec 2012 21:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7-cLXI2e77K for ; Fri, 21 Dec 2012 21:10:30 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5121F84C9 for ; Fri, 21 Dec 2012 21:10:30 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so2387165dac.12 for ; Fri, 21 Dec 2012 21:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=wyqmSS5uT+3jLYz8t6TqDBNcgqYJmkwTSnxQAbIi8kQ=; b=RBi16VdXC7mL/tOZW9q+9tCfXJg3bDxNH0KtajyA3Jh0dWyuyuNE/JOQn5SJ2hhfln 9AS9WyHHnWwNYJzAqbmp310va2+jJuqDBEvuUf2GQdrJc/FFIeNRFl3K0mqIUqHMeeAg SA5x4+9B2ZMlInBxrt6IFqdNH9ItzXQjwzAaahRHiB5a1RrAzOFHnV8fAHPDhmAaDbyv eXhqHP5eATwOCPHlPraQ1dgV5S0fIawODteg3sihPLUVdLO2Hlg7eIT0Z+9+6blui9wP TxlziCt0psgkeeaXPiB1nuEpsUK9mEnDaaCDE6FKef48u8mmTh77NfCgOUPTBE+T8MZB jXyw== X-Received: by 10.66.82.35 with SMTP id f3mr42743346pay.49.1356153030283; Fri, 21 Dec 2012 21:10:30 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id d9sm8609226paw.33.2012.12.21.21.10.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 21:10:28 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6AAC6F1-B7A0-4DCE-83AC-62E898436AB7" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <075b01cde000$d283d790$778b86b0$@packetizer.com> Date: Sat, 22 Dec 2012 14:10:27 +0900 Message-Id: <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> References: <075b01cde000$d283d790$778b86b0$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:10:36 -0000 --Apple-Mail=_B6AAC6F1-B7A0-4DCE-83AC-62E898436AB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp OK, Then basically webfinger clients MUST use the host of resource parameter = (at least when using acct, mailto, http and https schema), but extension spec MAY define another rule and in that case, client MUST = follow the extension's rule. Is it right? Or webfinger itself doesn't specify anything for host usage? (It just define path "/.well-known/webfinger" and schema "https", but = not host?) On 2012/12/22, at 13:57, Paul E. Jones wrote: > Nov, > =20 > Keep in mind that this is an entirely fictional example. There = isn=1B$B!G=1B(Bt even a URI scheme called =1B$B!H=1B(Bdevice=1B$B!I=1B(B. > =20 > The answer to your question would come from a document (if it existed, = but does not) that describes the =1B$B!H=1B(Bdevice=1B$B!I=1B(B URI and = how to use it within the context of WebFinger. > =20 > My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the device. = The parent in this case beingexample.com. It might be that there is a = designated host that serves as the device info server called = =1B$B!H=1B(Bdevices.example.com=1B$B!I=1B(B to which all queries are = directed. In any case, this is completely unspecified and the example = is there only to illustrate the range of use for WebFinger. It should = not be viewed in any way as proper usage, though. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Friday, December 21, 2012 11:40 PM > To: webfinger@ietf.org > Subject: [webfinger] Question about device info discovery example. > =20 > Hi all, >=20 > I'm new to this ML. >=20 > I'm writing a ruby webfinger library. > https://rubygems.org/gems/webfinger >=20 > After reading usecases in section 3, I have a question. >=20 > In the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of discovery endpoint is = "example.com", not "p1.example.com". > Is there any reason why these hosts are different? > How did the client decide the host of the discovery endpoint from = resource URI? >=20 > Thanks >=20 > Nov Matake --Apple-Mail=_B6AAC6F1-B7A0-4DCE-83AC-62E898436AB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp OK,

Then = basically webfinger clients MUST use the host of resource parameter (at = least when using acct, mailto, http and https schema),
but = extension spec MAY define another rule and in that case, client MUST = follow the extension's rule.

Is it = right?

Or webfinger itself doesn't specify = anything for host usage?
(It just define path = "/.well-known/webfinger" and schema "https", but not = host?)

On 2012/12/22, at 13:57, Paul E. Jones = <paulej@packetizer.com>= wrote:

 
Keep in mind that this is an entirely = fictional example.  There isn=1B$B!G=1B(Bt even a URI scheme called = =1B$B!H=1B(Bdevice=1B$B!I=1B(B.
 
The answer to your = question would come from a document (if it existed, but does not) that = describes the =1B$B!H=1B(Bdevice=1B$B!I=1B(B URI and how to use it = within the context of WebFinger.
 
My thinking when I wrote = this is that there are named devices on the network and one would query = the parent domain to learn about the device.  The parent in this = case beingexample.com.  It might be that = there is a designated host that serves as the device info server called = =1B$B!H=1B(Bdevices.example.com=1B$B!I=1B(B = to which all queries are directed.  In any case, this is completely = unspecified and the example is there only to illustrate the range of use = for WebFinger.  It should not be viewed in any way as proper usage, = though.
 
Paul
 
From: webfinger-bounces@ietf.org = [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Friday, December 21, 2012 = 11:40 PM
To: webfinger@ietf.org
Subject: [webfinger] = Question about device info discovery = example.
Hi = all,

I'm new to this ML.

I'm writing a ruby webfinger = library.
example.com" but the host of discovery endpoint is "example.com", not "Is there any reason why these hosts are = different?
How did the client decide the host of the discovery = endpoint from resource URI?

Thanks

Nov = Matake

On 19 December 2012 05:58, Paul E. Jones= <paulej@packetizer.com> wrote:

Melvin,

=A0

Here=92s an example:

=A0<= /p>

=A0 curl 'https://packetizer.com/.well-known/webfinger= ?resource=3Dhttp://www.packetizer.com/'

=A0<= /p>

This does not return m= uch useful information, but I return a user-friendly =93Name=94 for the URI= .=A0 I could include a URL to a site policy document, have a link relation = to a copyright statement, etc.


I see what you are doing here and it'= s a neat implementation.=A0 I think that if http discovery is in scope of w= ebfinger, then data returned should be consistent with HTTP GET, which is c= urrently the best practice for http discovery, imho.=A0 Otherwise there is = the potential danger, for things getting out of sync, depending on which di= scovery method is used.

Does that make sense?
=A0

=A0<= /p>

Paul

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Tuesday, December 18, 2012 9:10 PM
To: Goix Laurent = Walter
Cc: webfinger@googlegroups.com; Paul E. Jones; webfinger@ietf.org
Subject: Re: [webfinger] Possibly speeding up the RFC process=

=A0

=A0

On 18 December 2012 23:19, Goix Laurent Walter = <laurentwalter.goix@telecomitalia.it> wrote:

> -----Messaggio originale-----
> Da: webfinger@googlegroups.com [mailto:= webfinger@g= ooglegroups.com] Per conto
> di Nick Jennings
> Inviato: marted=EC 18 dicembre 2012 20.37
= > A: Paul E. Jones
> Cc: webfinger@googlegroups.com; webfinger@ietf.org; Melvin Carvalho=
> Oggetto: Re: [webfinger] Possibly speeding up the RFC process

&g= t;
> On Mon, Dec 17, 2012 at 9:30 PM, Paul E. Jones <paulej@packetizer.com>= wrote:
> > Nick,
> >
> >> > PEJ: WebFinger uses any = URI scheme. =A0The =93acct=94 scheme is just one of
> >> > t= hem and is not core to the spec now, though there is a statement
> &g= t;> > recommending its use to identify accounts. =A0That is its purpo= se and
> >> > the =93acct=94 URI, and it=92s a valid purpose. =A0The o= ne example I like to
> >> > give is =93How do we identify an= account at Twitter?=94 =A0There is no
> >> > email, so =93m= ailto=94 is not the right URI. =A0A user has an account at any
> >> > service provider and the =93acct=94 URI would identify t= he account, not
> >> > the particular service at the service= provider (e.g., email, XMPP, or
> >> whatever).
> >&g= t; >
> >>
> >> Hi Paul, I just wanted to run a few thoughts= by you to make sure I'm not
> >> missing something.
>= ; >>
> >> Maybe I don't fully understand the various = use-cases, but it seems like
> >> you are saying that when querying a 'resource', the v= alue does NOT need
> >> to be prefixed with acct (or anything).= I know there's the idea that at
> >> some point another ty= pe of resource could be identified as relevant and
> >> so that was the argument for having the 'acct' prefix= .
> >> However your wording suggests that even 'acct' i= s not needed. So
> >> someone's WF service could accept = 9;resource=3Dbob' and not
> >> 'resource=3Dacct:bob@example.com' and it would still be a compli= ant WF
> >> service? If true, it seems like there could be a lo= t of room for
> >> uncertainty in query format and client libraries would have t= o try a
> >> number of different value formats.
> >> > What the spec says is that any URI may be queried. =A0That's= what I meant.
> The protocol is not designed to be used only with "acct:". = =A0One may query WF
> using "http:" (e.g., "http://www.paulej.com/"= ) or "mailto:" or "tel:" or
> "urn:". =A0Obviously, URI schemes that do not have domain na= mes present issues,
> but that it's certainly possible and I susp= ect there would be an agreed
> client/server relationship.
> &g= t;
> > My own server code actually will accept just "paulej@packetizer.com"= ;, for
> example. =A0If it sees that, it assumes the requestor wants<= br> > "acct:paulej@packetizer.com" and returns the results from the dat= abase for the
> "acct:" URI. =A0However, the "subject&= quot; is just the bare "paulej@packetizer.com"
> and the "acct:" URI is inserted into the response as an alia= s. =A0However, none
> of that is in the spec. =A0I did that long ago,= because Blaine preferred to not
> require a URI scheme for user@doma= in forms.
> >
> >> Another thing, in regards to the twitter example= you gave. What's to
> >> differentiate a user of twitter a= nd an employee of twitter?
> >>
> >> There could be= a user '@janice' and an employee 'janice@twitter.com',
> >> who may be different people. As I understand it, in your exam= ple, these
> >> different accounts would be queried in the same= way.
> >>
> >> /.host-meta/webfinger?resource=3Dacct:janice@tw= itter.com
> >
> > Users and employees must have different <user>= values within the scope of
> the domain (or sub-domain). =A0Some tim= e ago, somebody mentioned that they have
> a domain with user account= s and employees where the user account names did
> clash with employee names. =A0I don't have a solution for that. = =A0Personally, I
> think that's an unfortunate situation to be in= .
> >
> > On my own web site, I run phpBB. =A0There are u= ser accounts. =A0So, I can
> appreciate how people get into that situation. =A0However, I placed th= e
> discussion forms at forums.packetizer.com and so if the phpBB software ever > supported WebFinger (hmmmm... more holiday coding opportunities) then = I would
> expect it to respond only to acct:<user>@forums.packetizer.com. = =A0That would be
> perfectly fine and would avoid the name clash. =A0WF does not require = queries
> only to the domain. =A0Queries can be sent to any appropria= te host within the
> domain.
> >
> >> Am I misun= derstanding? Or does this create a problem.
> >
> > There are potential issues for domain owners who hav= e allocated the same
> user identifier to more than one person on the= same domain or sub-domain.
> Domain owners will have to address that= before deploying WF.
> >
>
> Hi Paul,
>
> I've been giving thi= s some more thought, if the person running the WF
> service can make = up their own system of identifying users (whatever
> works for them),= then in order to write a robust WF client, you're
> going to have to do a lot of second guessing. I don't understand w= hy
> we have 'acct:' if (a) it's not required at all, and= (b) it's
> suggested we use the full 'user@example.com' =A0anyway, howeve= r (c) we
> also don't have to do that...
>
> In the case of that = twitter example. If they wanted to solve this
> issue, they might imp= ose a system like:
>
> /.host-meta/webfinger?resource=3Djanice@twitter.com
>
> ...that gets the record for the employee Janice
>
>= ; /.host-meta/webfinger?resource=3Dacct:janice
>
> ...that gets= the record for the user-account 'janice'
>
> In this c= ase 'acct' prefix referring to just the 'webapp' accounts,<= br> > and not 'admin/employee' accounts.
>
> I think a c= larification of what to use as the resource value to
> signify whethe= r we are, querying an email address (used by, for
> example, and emai= l client, or blog comments). or a user account (used
> by, for example, phpBB, wordpress, twitter, etc.) would be really
&= gt; helpful.
>
> Otherwise we're going to have similar clie= nt complexity to the issues
> we've already discussed regarding u= sing fallback methods. though maybe
> more complicated because we could have false positives if, for
>= example, janice@tw= itter.com is queried for a user account but the
> profile for the= employee is returned.
>
> Does anyone else see the ambiguity here as a potentially prett= y bad problem?

I person= ally don't see the issue here. Facebook uses different domains for thei= r users vs their employess. It's unfortunate if titter do not does this= but i twas said many times in the past on this list that acct: addresses w= ith the same value than mailto: addresses may actually not be related to th= e same person. (although it would make sense, technically there is no bindi= ng for this).
I wouldn't enter the debate of who's represented behind a specific = URI. It is up to the domain admin to manage the account namespace. Could yo= u better clarify your issue here?

Re the acct: URI scheme I do suppo= rt Paul's view that at this stage there is no URI-way of identifying *u= ser accounts* globally. It is already widely used in federated social netwo= rks that will become a big consumer of webfinger eventually and could easil= y reuse these "acct:" URIs in activity streams in the actor/id fi= eld (normatively defined as anyURI).

Third, wf was designed for supporting any URI including for example htt= p:, which are not in the form of user@domain. And in general I would recomm= end that an ietf spec formally define the "resource" parameter as= anyURI instead of a free-form string.


Taking your example of http:, how might thi= s work?
=A0


walter

>= ; -nick

Questo messaggio e i suoi allegati sono indirizzati esclusiv= amente alle persone indicate. La diffusione, copia o qualsiasi altra azione= derivante dalla conoscenza di queste informazioni sono rigorosamente vieta= te. Qualora abbiate ricevuto questo documento per errore siete cortesemente= pregati di darne immediata comunicazione al mittente e di provvedere alla = sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privile= ged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intend= ed recipient, please delete this message and any attachments and advise the= sender by return e-mail, Thanks.

=A0

=

On Fri, Dec 21, 2012 at 1:09 PM, Kingsle= y Idehen <kide= hen@openlinksw.com> wrote:

Could this:

 WebFinger is used to discover information about people or= other
   entities on the Internet that are identified by a = URI [6] or IRI [7]
   using standard Hypertext Transfer Protocol (HTTP) = [2] methods over a
   secure transport [14].

become:

 WebFinger is used to discover information about people or= other
   entities on the Internet that are *denoted* by a U= RI [6] or IRI [7]. Actual information retrieval uses
   standard Hypertext Transfer Protocol (HTTP) [2] me= thods over a
   secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http= ://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen=
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508= 618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen<= br>





_______________________________________________
webfinger mailing list
= webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfi= nger




_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger
= --Apple-Mail=_B6AAC6F1-B7A0-4DCE-83AC-62E898436AB7-- From paulej@packetizer.com Fri Dec 21 21:18:11 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E361C21E8040 for ; Fri, 21 Dec 2012 21:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6kyl5PpTJcg for ; Fri, 21 Dec 2012 21:18:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D593321F8514 for ; Fri, 21 Dec 2012 21:18:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM5I8lj003886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 00:18:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356153488; bh=UecSwiWlc/TMye5UhUcjDiZftvMJbgS3KMly3dCihx8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=afGm3eSRl8sGwEkiHESKuMgy/d+UF4vLEgoKAc2faA+um+Hux/1nFG6Qs0m5t2e1U 01AG2cew8OgEE9whbWi/LHUlZ6OlsQ9UTj1XXSZ8mHxRy1HFP72mUqy3ZmWU05szKB NwCd7Ag0TBJ75qPfwRbeu9+/r7jKibDX9lf+NpG8= From: "Paul E. Jones" To: "'nov matake'" , References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> In-Reply-To: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> Date: Sat, 22 Dec 2012 00:18:10 -0500 Message-ID: <077401cde003$bc74fe40$355efac0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLo5fwAtmw Content-Language: en-us Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:18:11 -0000 Nov, It used to base space-delimited in the -02 draft: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-5.3 We had a debate over this and, as usual, I lost. :-) Some people expressed concerns that there might be spaces in the URL, so taking two URLs like this: http://example.com/this one http://example.com/that one And then putting them into the "rel" parameter like this: http%3A%2F%2Fexample.com%2Fthis%20one%20http%3A%2F%2Fexample.com%2Fthat%20on e ^^^ ^^^ The ^^^ denotes the problem. Unescaping and splitting on spaces would give you 4 values. So, one has to do this: encodeURIComponent( encodeURIComponent ("http://example.com/this one") + " " + encodeURIComponent ("http://example.com/that one") ) And put that into the "rel" parameter. That can get a bit ugly. I personally preferred the single rel parameter, though. I was overruled. Perhaps you might be more persuasive than I was. Paul > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On > Behalf Of nov matake > Sent: Friday, December 21, 2012 11:49 PM > To: webfinger@ietf.org > Subject: [webfinger] feedback for multiple "rel" > > Hi, > > I have a comment for they way to specify multiple "rel" values. > > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will need > to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in > rails. > > Is the multiple "rel" case can be a space-delimitered (or some other > character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? > > Cheers, > > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Fri Dec 21 21:26:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E021E8044 for ; Fri, 21 Dec 2012 21:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Bl5f0SsTawc for ; Fri, 21 Dec 2012 21:26:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6921E8042 for ; Fri, 21 Dec 2012 21:26:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM5Q4wb004208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 00:26:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356153965; bh=t7OZ+3+afMZs8ZZJ1kUgBi54uOBlR/UNCZSinJmdork=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=UpCOoMPdi/n4NhTjECCpTyXzUJZPhdtGta+xvtxXJ42/qlxHHeuMYO0Y+gQLWz1TA wJKcx9bo282Gj6z3YeZAgw7fg2odRrvRsYL7xBNZdUqveQJo0Ks12rx6V0yqKjKurY t79QDTiBsxZ4NURNQ1tYmx4+AsIao3kzhLsTAFZE= From: "Paul E. Jones" To: "'nov matake'" References: <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> In-Reply-To: <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> Date: Sat, 22 Dec 2012 00:26:07 -0500 Message-ID: <077601cde004$d8ae8760$8a0b9620$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0777_01CDDFDA.EFD9B7E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeIapXe7gOJ5OOW00neyp/e43xxwISwboRAW9vMOSXZ7LXYA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:26:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0777_01CDDFDA.EFD9B7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nov, The host to query for the acct URI should be the host portion following the @. For example, if one's email ID is "user@nc.example.com" then the host to be queried would be nc.example.com. That would be true for mailto, also. For http(s): URIs like "http://www.example.com/some/path/", there are one of two possibilities. In the examples, I've suggested that to one would query the host "example.com". However, it probably isn't the right place. In the case of an http: URI, perhaps queries should be directed to the host itself (in this case www.example.com). We need to answer that question: do we direct queries to the parent "host" (as I have it in the examples) or to the named host in the URI? Paul From: nov matake [mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 12:10 AM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. OK, Then basically webfinger clients MUST use the host of resource parameter (at least when using acct, mailto, http and https schema), but extension spec MAY define another rule and in that case, client MUST follow the extension's rule. Is it right? Or webfinger itself doesn't specify anything for host usage? (It just define path "/.well-known/webfinger" and schema "https", but not host?) On 2012/12/22, at 13:57, Paul E. Jones wrote: Nov, Keep in mind that this is an entirely fictional example. There isn't even a URI scheme called "device". The answer to your question would come from a document (if it existed, but does not) that describes the "device" URI and how to use it within the context of WebFinger. My thinking when I wrote this is that there are named devices on the network and one would query the parent domain to learn about the device. The parent in this case being example.com. It might be that there is a designated host that serves as the device info server called " devices.example.com" to which all queries are directed. In any case, this is completely unspecified and the example is there only to illustrate the range of use for WebFinger. It should not be viewed in any way as proper usage, though. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Friday, December 21, 2012 11:40 PM To: webfinger@ietf.org Subject: [webfinger] Question about device info discovery example. Hi all, I'm new to this ML. I'm writing a ruby webfinger library. https://rubygems.org/gems/webfinger After reading usecases in section 3, I have a question. In the device info discovery example in section 3.4, resource is "device:p1. example.com" but the host of discovery endpoint is " example.com", not " p1.example.com". Is there any reason why these hosts are different? How did the client decide the host of the discovery endpoint from resource URI? Thanks Nov Matake ------=_NextPart_000_0777_01CDDFDA.EFD9B7E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nov,

 

The host to query for the acct URI should be the host portion = following the @.  For example, if one’s email ID is = “user@nc.example.com” then the host to be queried would be = nc.example.com.  That would be true for mailto, = also.

 

For http(s): URIs like = “http://www.example.com/some/path/”, there are one of two = possibilities.  In the examples, I’ve suggested that to one = would query the host “example.com”.  However, it = probably isn’t the right place.  In the case of an http: URI, = perhaps queries should be directed to the host itself (in this case = www.example.com).  We need to answer that question: do we direct = queries to the parent “host” (as I have it in the examples) = or to the named host in the URI?

 

Paul

 

From:= = nov matake [mailto:matake@gmail.com]
Sent: Saturday, December = 22, 2012 12:10 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] Question about = device info discovery example.

 

OK,

 

Then basically webfinger clients MUST use the host of = resource parameter (at least when using acct, mailto, http and https = schema),

but extension = spec MAY define another rule and in that case, client MUST follow the = extension's rule.

 

Is it right?

 

Or webfinger itself doesn't specify anything for host = usage?

(It just define = path "/.well-known/webfinger" and schema "https", = but not host?)

 



Nov,

 

Keep in mind that this is an entirely fictional example.  There = isn’t even a URI scheme called “device”.

 

The answer to your question would come from a document (if it = existed, but does not) that describes the “device” URI and = how to use it within the context of WebFinger.

 

My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the = device.  The parent in this case beingexample.com.  It might be that = there is a designated host that serves as the device info server called = “devices.example.com” to which = all queries are directed.  In any case, this is completely = unspecified and the example is there only to illustrate the range of use = for WebFinger.  It should not be viewed in any way as proper usage, = though.

 

Paul

 

From:=  webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Friday, December 21, 2012 = 11:40 PM
To: webfinger@ietf.org
Subject:<= /b> [webfinger] Question = about device info discovery example.

 

Hi all,

I'm new to this ML.

I'm writing a = ruby webfinger library.
https://rubygems.org/gems/webfinger
=
After reading usecases in section 3, I have a question.

In = the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of = discovery endpoint is "example.com", not "p1.example.com".
Is there any = reason why these hosts are different?
How did the client decide the = host of the discovery endpoint from resource = URI?

Thanks

Nov = Matake

 

------=_NextPart_000_0777_01CDDFDA.EFD9B7E0-- From matake@gmail.com Fri Dec 21 21:36:02 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0079C21E8042 for ; Fri, 21 Dec 2012 21:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWOXJwvxkSSd for ; Fri, 21 Dec 2012 21:36:01 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 617D621E8037 for ; Fri, 21 Dec 2012 21:36:01 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id fa10so3202534pad.20 for ; Fri, 21 Dec 2012 21:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=FspJ3sflyVpjPl4B+EuC9ERAuGecDn2oPGAKbTu0eB4=; b=uSNHLb2d3E6KF9PeqW1SGQpIOrBer7jaNQyxSkM+3nYUpAmeoG2f5FyN7dr+RrDeql HgNpVcVqET1jXXU3tVsgLp+BFhkSBsPrZ8njW/e3tdUJrMtjjSylB0Ln/1+K/fZNsPuf +JZFt4Y15wYGhfHBLTWGOXyRdxQKpATV6PQPKI7GImNodpocEB97SNuEqKMyD0tibCJB BaE8IZknysySzCNeRYcvZk1MTfyp3WUVqeYiAkhcFV5wO9jNKaZHvEdXjSjSxBfxvOGm cmCzIuir1T4s2o5s6n81v4GQMSL37cMi4zy1qXKYd+/1egdLfhbi87e1rpj8MCQFHpZG Ru+A== X-Received: by 10.66.81.198 with SMTP id c6mr43088446pay.50.1356154561197; Fri, 21 Dec 2012 21:36:01 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id vk5sm8224370pbc.34.2012.12.21.21.35.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 21:36:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <077401cde003$bc74fe40$355efac0$@packetizer.com> Date: Sat, 22 Dec 2012 14:35:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3B2DA5C2-0868-4738-ABB0-5D33D920EB37@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <077401cde003$bc74fe40$355efac0$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:36:02 -0000 Understood. I saw the same debate in OAuth2 ML and saw opposite result :p I, as a ruby library developer, prefer single "rel" because parsing = double encoded values in library is easier than modifying developer's = application framework. But at same time, as OpenID Connect library developer, it's probably too = late to change webfinger spec ... :( On 2012/12/22, at 14:18, Paul E. Jones wrote: > Nov, >=20 > It used to base space-delimited in the -02 draft: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-5.3 >=20 > We had a debate over this and, as usual, I lost. :-) >=20 > Some people expressed concerns that there might be spaces in the URL, = so > taking two URLs like this: >=20 > http://example.com/this one > http://example.com/that one >=20 > And then putting them into the "rel" parameter like this: >=20 > = http%3A%2F%2Fexample.com%2Fthis%20one%20http%3A%2F%2Fexample.com%2Fthat%20= on > e > ^^^ ^^^ >=20 > The ^^^ denotes the problem. >=20 > Unescaping and splitting on spaces would give you 4 values. >=20 > So, one has to do this: > encodeURIComponent( > encodeURIComponent ("http://example.com/this one") + " " + > encodeURIComponent ("http://example.com/that one") ) >=20 > And put that into the "rel" parameter. >=20 > That can get a bit ugly. I personally preferred the single rel = parameter, > though. I was overruled. >=20 > Perhaps you might be more persuasive than I was. >=20 > Paul >=20 >> -----Original Message----- >> From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On >> Behalf Of nov matake >> Sent: Friday, December 21, 2012 11:49 PM >> To: webfinger@ietf.org >> Subject: [webfinger] feedback for multiple "rel" >>=20 >> Hi, >>=20 >> I have a comment for they way to specify multiple "rel" values. >>=20 >> As a ruby library developer, my main target is rails developers. >> Since rails can't handle multiple same query keys, developers will = need >> to hack query params parser in rails middleware layer. >> I can easily imagine it'll be an annoying part to support webfinger = in >> rails. >>=20 >> Is the multiple "rel" case can be a space-delimitered (or some other >> character) strings like multiple redirect_uri in OAuth2? >> Or any reason for putting multiple same keys in query parameters? >>=20 >> Cheers, >>=20 >> Nov Matake >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >=20 From paulej@packetizer.com Fri Dec 21 21:39:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1021E8042 for ; Fri, 21 Dec 2012 21:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYHMyP3qPzQu for ; Fri, 21 Dec 2012 21:39:38 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8521E8037 for ; Fri, 21 Dec 2012 21:39:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM5daKU004767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 00:39:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356154777; bh=nDyRPhlXM8ErcPyTgQ2QHexLIi5vAvW5/96YvofYiOw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Bqb69/v+9ia2ifYugA4YrS1ck+zcbM2lCBk/n5ee4iC9eAoLoMr4CcOsnoC1uHIPp T2Y9BG7VLiHkNJPNJyKUp2LNBXomUkwLawCtbPLadrvLaRIP/6wRf6eB3Y95/lKhAF RTMXSOFCqmNfk2+m+LElooAcs7lgbjEWqUhUgLmY= From: "Paul E. Jones" To: "'nov matake'" References: <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> <077601cde004$d8ae8760$8a0b9620$@packetizer.com> In-Reply-To: <077601cde004$d8ae8760$8a0b9620$@packetizer.com> Date: Sat, 22 Dec 2012 00:39:39 -0500 Message-ID: <078901cde006$bc9724e0$35c56ea0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_078A_01CDDFDC.D3C2CA90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeIapXe7gOJ5OOW00neyp/e43xxwISwboRAW9vMOQCCvx/RZdXX1rA Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:39:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_078A_01CDDFDC.D3C2CA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nov, As I quickly looked at the text, I think we really should be consistent in using the hostname that immediately follows http(s):// or device:. So, I'm going to change the WF draft accordingly. So, the end of section 3.1 now looks like this: An alias is a URI that is different from the "subject" URI that identifies the same entity. In the above example, there is one "http" alias returned, though there might have been more than one. Had the "http:" URI shown as an alias been used to query for information about Bob, the query would have appeared as: GET /.well-known/webfinger? resource=http%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1 Host: www.example.com Note that the host queried changed in this example, since the URI refers to a different host. Either this host would provide a response, or it would redirect the client to another host (e.g., example.com). Either way, the response would have been substantially the same, with the subject and alias information changed as necessary. Other information, such as the expiration time might also change, but the set of link relations and properties would be the same with either response. I also put "p1.example.com" as the host for the device: URI. I do think the particular host to query is something we'll have to take up on a URI-by-URI basis, but a very logical assumption with no other guidance is to query the host that is in the "hostname" position of the URI (if there is one). For URIs like "tel", the WF client would just have to be provisioned to know where to go query. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Saturday, December 22, 2012 12:26 AM To: 'nov matake' Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. Nov, The host to query for the acct URI should be the host portion following the @. For example, if one's email ID is "user@nc.example.com" then the host to be queried would be nc.example.com. That would be true for mailto, also. For http(s): URIs like "http://www.example.com/some/path/", there are one of two possibilities. In the examples, I've suggested that to one would query the host "example.com". However, it probably isn't the right place. In the case of an http: URI, perhaps queries should be directed to the host itself (in this case www.example.com). We need to answer that question: do we direct queries to the parent "host" (as I have it in the examples) or to the named host in the URI? Paul From: nov matake [mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 12:10 AM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. OK, Then basically webfinger clients MUST use the host of resource parameter (at least when using acct, mailto, http and https schema), but extension spec MAY define another rule and in that case, client MUST follow the extension's rule. Is it right? Or webfinger itself doesn't specify anything for host usage? (It just define path "/.well-known/webfinger" and schema "https", but not host?) On 2012/12/22, at 13:57, Paul E. Jones wrote: Nov, Keep in mind that this is an entirely fictional example. There isn't even a URI scheme called "device". The answer to your question would come from a document (if it existed, but does not) that describes the "device" URI and how to use it within the context of WebFinger. My thinking when I wrote this is that there are named devices on the network and one would query the parent domain to learn about the device. The parent in this case being example.com. It might be that there is a designated host that serves as the device info server called " devices.example.com" to which all queries are directed. In any case, this is completely unspecified and the example is there only to illustrate the range of use for WebFinger. It should not be viewed in any way as proper usage, though. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Friday, December 21, 2012 11:40 PM To: webfinger@ietf.org Subject: [webfinger] Question about device info discovery example. Hi all, I'm new to this ML. I'm writing a ruby webfinger library. https://rubygems.org/gems/webfinger After reading usecases in section 3, I have a question. In the device info discovery example in section 3.4, resource is "device:p1. example.com" but the host of discovery endpoint is " example.com", not " p1.example.com". Is there any reason why these hosts are different? How did the client decide the host of the discovery endpoint from resource URI? Thanks Nov Matake ------=_NextPart_000_078A_01CDDFDC.D3C2CA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nov,

 

As I quickly looked at the text, I think we really should be = consistent in using the hostname that immediately follows http(s):// or = device:.  So, I’m going to change the WF draft = accordingly.

 

So, the end of section 3.1 now looks like = this:

 

An alias is a URI that is different from the “subject” = URI that identifies the same entity.  In the above example, there = is one “http” alias returned, though there might have been = more than one.  Had the “http:” URI shown as an alias = been used to query for information about Bob, the query would have = appeared as:

 

  = GET /.well-known/webfinger?

         = ;  resource=3Dhttp%3A%2F%2Fwww.example.com%2F~bob%2F = HTTP/1.1

  = Host: www.example.com

 

N= ote that the host queried changed in this example, since the URI refers = to a different host.  Either this host would provide a response, or = it would redirect the client to another host (e.g., example.com).  = Either way, the response would have been substantially the same, with the subject = and alias information changed as necessary.  Other information, = such as the expiration time might also change, but the set of link = relations and properties would be the same with either = response.

 

I also put “p1.example.com” as the host for the device: = URI.  I do think the particular host to query is something = we’ll have to take up on a URI-by-URI basis, but a very logical = assumption with no other guidance is to query the host that is in the = “hostname” position of the URI (if there is = one).

 

For URIs like “tel”, the WF client would just have to be = provisioned to know where to go query.

 

Paul

 

From: webfinger-bounces@ietf.org = [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Saturday, December 22, 2012 12:26 AM
To: = 'nov matake'
Cc: webfinger@ietf.org
Subject: Re: = [webfinger] Question about device info discovery = example.

 

Nov,

 

The host to query for the acct URI should be the host portion = following the @.  For example, if one’s email ID is “user@nc.example.com” then = the host to be queried would be nc.example.com.  That would be true = for mailto, also.

 

For http(s): URIs like “http://www.example.com/some/pa= th/”, there are one of two possibilities.  In the = examples, I’ve suggested that to one would query the host = “example.com”.  However, it probably isn’t the = right place.  In the case of an http: URI, perhaps queries should = be directed to the host itself (in this case www.example.com).  We need to = answer that question: do we direct queries to the parent = “host” (as I have it in the examples) or to the named host = in the URI?

 

Paul

 

From:= = nov matake [mailto:matake@gmail.com] =
Sent: Saturday, December 22, 2012 12:10 AM
To: Paul = E. Jones
Cc: webfinger@ietf.org
Subject:<= /b> Re: [webfinger] Question about device info discovery = example.

 

OK,

 

Then basically webfinger clients MUST use the host of = resource parameter (at least when using acct, mailto, http and https = schema),

but extension = spec MAY define another rule and in that case, client MUST follow the = extension's rule.

 

Is it right?

 

Or webfinger itself doesn't specify anything for host = usage?

(It just define = path "/.well-known/webfinger" and schema "https", = but not host?)

 

On = 2012/12/22, at 13:57, Paul E. Jones <paulej@packetizer.com> = wrote:

 

Nov,

 

Keep in mind that this is an entirely fictional example.  There = isn’t even a URI scheme called “device”.

 

The answer to your question would come from a document (if it = existed, but does not) that describes the “device” URI and = how to use it within the context of WebFinger.

 

My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the = device.  The parent in this case beingexample.com.  It might be that = there is a designated host that serves as the device info server called = “devices.example.com” to which = all queries are directed.  In any case, this is completely = unspecified and the example is there only to illustrate the range of use = for WebFinger.  It should not be viewed in any way as proper usage, = though.

 

Paul

 

From:=  webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Friday, December 21, 2012 = 11:40 PM
To: webfinger@ietf.org
Subject:<= /b> [webfinger] Question = about device info discovery example.

 

Hi all,

I'm new to this ML.

I'm writing a = ruby webfinger library.
https://rubygems.org/gems/webfinger
=
After reading usecases in section 3, I have a question.

In = the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of = discovery endpoint is "example.com", not "p1.example.com".
Is there any = reason why these hosts are different?
How did the client decide the = host of the discovery endpoint from resource = URI?

Thanks

Nov = Matake

 

------=_NextPart_000_078A_01CDDFDC.D3C2CA90-- From matake@gmail.com Fri Dec 21 21:43:37 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41B921E8037 for ; Fri, 21 Dec 2012 21:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 172JbZUoVby2 for ; Fri, 21 Dec 2012 21:43:35 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id B8FBA21F81FF for ; Fri, 21 Dec 2012 21:43:35 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so2415830dak.30 for ; Fri, 21 Dec 2012 21:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=k0fcwR5xHt7AJS/zq8p2vcY/Cx7ZF0IAiGkV3O5odVs=; b=UOxPwctGkQQDkqjpbV8P2FLN18RHQN6qIwqkcSdltdcRGr79wwncr9rku4cYwo9vjv BTU98eL8xQpu+CF+omeGUiQKkgX4qRhHBxEK3KBwHo2j/b/qx908tdS7Hi/RHLk+CmlS yPuPMBsz4UmuXIoVts9RsxmGGlLfokSkaF5/gGAZjzjER6aYsbPxe+TilQd+xyE6Srbp GruElWHsSUikGdDnBybgN803++oZIUfUftO6AsF61M4d1Mc8ze6prm4QzCg5Nl59NZj5 +ew3kXOSklSwxzaPvHBOZKnfexiiSqX7cdimhUaJ/IhdQ7WetV2ebgzHCWlNtt/0Do/h 84Rw== X-Received: by 10.66.81.166 with SMTP id b6mr43213115pay.7.1356155015535; Fri, 21 Dec 2012 21:43:35 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id f10sm5111915pav.18.2012.12.21.21.43.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 21:43:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DAA76AA5-B251-4A8C-ADDE-461520B3EE47" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <078901cde006$bc9724e0$35c56ea0$@packetizer.com> Date: Sat, 22 Dec 2012 14:43:32 +0900 Message-Id: References: <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> <077601cde004$d8ae8760$8a0b9620$@packetizer.com> <078901cde006$bc9724e0$35c56ea0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:43:37 -0000 --Apple-Mail=_DAA76AA5-B251-4A8C-ADDE-461520B3EE47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Thanks, I'm happy with the change :-) On 2012/12/22, at 14:39, "Paul E. Jones" wrote: > Nov, > =20 > As I quickly looked at the text, I think we really should be = consistent in using the hostname that immediately follows http(s):// or = device:. So, I=1B$B!G=1B(Bm going to change the WF draft accordingly. > =20 > So, the end of section 3.1 now looks like this: > =20 > An alias is a URI that is different from the =1B$B!H=1B(Bsubject=1B$B!I=1B= (B URI that identifies the same entity. In the above example, there is = one =1B$B!H=1B(Bhttp=1B$B!I=1B(B alias returned, though there might have = been more than one. Had the =1B$B!H=1B(Bhttp:=1B$B!I=1B(B URI shown as = an alias been used to query for information about Bob, the query would = have appeared as: > =20 > GET /.well-known/webfinger? > resource=3Dhttp%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1 > Host: www.example.com > =20 > Note that the host queried changed in this example, since the URI = refers to a different host. Either this host would provide a response, = or it would redirect the client to another host (e.g., example.com). = Either way, the response would have been substantially the same, with = the subject and alias information changed as necessary. Other = information, such as the expiration time might also change, but the set = of link relations and properties would be the same with either response. > =20 > I also put =1B$B!H=1B(Bp1.example.com=1B$B!I=1B(B as the host for the = device: URI. I do think the particular host to query is something = we=1B$B!G=1B(Bll have to take up on a URI-by-URI basis, but a very = logical assumption with no other guidance is to query the host that is = in the =1B$B!H=1B(Bhostname=1B$B!I=1B(B position of the URI (if there is = one). > =20 > For URIs like =1B$B!H=1B(Btel=1B$B!I=1B(B, the WF client would just = have to be provisioned to know where to go query. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Paul E. Jones > Sent: Saturday, December 22, 2012 12:26 AM > To: 'nov matake' > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Question about device info discovery example. > =20 > Nov, > =20 > The host to query for the acct URI should be the host portion = following the @. For example, if one=1B$B!G=1B(Bs email ID is = =1B$B!H=1B(Buser@nc.example.com=1B$B!I=1B(B then the host to be queried = would be nc.example.com. That would be true for mailto, also. > =20 > For http(s): URIs like = =1B$B!H=1B(Bhttp://www.example.com/some/path/=1B$B!I=1B(B, there are one = of two possibilities. In the examples, I=1B$B!G=1B(Bve suggested that = to one would query the host =1B$B!H=1B(Bexample.com=1B$B!I=1B(B. = However, it probably isn=1B$B!G=1B(Bt the right place. In the case of = an http: URI, perhaps queries should be directed to the host itself (in = this case www.example.com). We need to answer that question: do we = direct queries to the parent =1B$B!H=1B(Bhost=1B$B!I=1B(B (as I have it = in the examples) or to the named host in the URI? > =20 > Paul > =20 > From: nov matake [mailto:matake@gmail.com]=20 > Sent: Saturday, December 22, 2012 12:10 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Question about device info discovery example. > =20 > OK, > =20 > Then basically webfinger clients MUST use the host of resource = parameter (at least when using acct, mailto, http and https schema), > but extension spec MAY define another rule and in that case, client = MUST follow the extension's rule. > =20 > Is it right? > =20 > Or webfinger itself doesn't specify anything for host usage? > (It just define path "/.well-known/webfinger" and schema "https", but = not host?) > =20 > On 2012/12/22, at 13:57, Paul E. Jones wrote: > =20 >=20 > Nov, > =20 > Keep in mind that this is an entirely fictional example. There = isn=1B$B!G=1B(Bt even a URI scheme called =1B$B!H=1B(Bdevice=1B$B!I=1B(B. > =20 > The answer to your question would come from a document (if it existed, = but does not) that describes the =1B$B!H=1B(Bdevice=1B$B!I=1B(B URI and = how to use it within the context of WebFinger. > =20 > My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the device. = The parent in this case beingexample.com. It might be that there is a = designated host that serves as the device info server called = =1B$B!H=1B(Bdevices.example.com=1B$B!I=1B(B to which all queries are = directed. In any case, this is completely unspecified and the example = is there only to illustrate the range of use for WebFinger. It should = not be viewed in any way as proper usage, though. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Friday, December 21, 2012 11:40 PM > To: webfinger@ietf.org > Subject: [webfinger] Question about device info discovery example. > =20 > Hi all, >=20 > I'm new to this ML. >=20 > I'm writing a ruby webfinger library. > https://rubygems.org/gems/webfinger >=20 > After reading usecases in section 3, I have a question. >=20 > In the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of discovery endpoint is = "example.com", not "p1.example.com". > Is there any reason why these hosts are different? > How did the client decide the host of the discovery endpoint from = resource URI? >=20 > Thanks >=20 > Nov Matake --Apple-Mail=_DAA76AA5-B251-4A8C-ADDE-461520B3EE47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Thanks, I'm happy with the = change :-)

On 2012/12/22, at 14:39, "Paul E. Jones" = <paulej@packetizer.com>= wrote:

 
As I quickly looked at the text, I think we = really should be consistent in using the hostname that immediately = follows http(s):// or device:.  So, I=1B$B!G=1B(Bm going to change = the WF draft accordingly.
 
So, the end of section = 3.1 now looks like this:
 
An alias is a URI that = is different from the =1B$B!H=1B(Bsubject=1B$B!I=1B(B URI that = identifies the same entity.  In the above example, there is one = =1B$B!H=1B(Bhttp=1B$B!I=1B(B alias returned, though there might have = been more than one.  Had the =1B$B!H=1B(Bhttp:=1B$B!I=1B(B URI = shown as an alias been used to query for information about Bob, the = query would have appeared as:
 
  GET = /.well-known/webfinger?
2Fwww.example.com%2F~bob%2F = HTTP/1.1
  Host: www.example.com
 
Note that the host = queried changed in this example, since the URI refers to a different = host.  Either this host would provide a response, or it would = redirect the client to another host (e.g., example.com).  Either way, the response would have been substantially the same, = with the subject and alias information changed as necessary.  Other = information, such as the expiration time might also change, but the set = of link relations and properties would be the same with either = response.
 
I also put =1B$B!H=1B(Bp1.example.com=1B$B!I=1B(B as the host for the device: = URI.  I do think the particular host to query is something = we=1B$B!G=1B(Bll have to take up on a URI-by-URI basis, but a very = logical assumption with no other guidance is to query the host that is = in the =1B$B!H=1B(Bhostname=1B$B!I=1B(B position of the URI (if there is = one).
 
For URIs like =1B$B!H=1B(Btel=1B$B!I=1B(B, = the WF client would just have to be provisioned to know where to go = query.
 
Paul
 
From: webfinger-bounces@ietf.org = [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Saturday, December 22, 2012 = 12:26 AM
To: 'nov = matake'
Cc: webfinger@ietf.org
Subject: Re: [webfinger] = Question about device info discovery = example.
Nov,
 
The host to query for = the acct URI should be the host portion following the @.  For = example, if one=1B$B!G=1B(Bs email ID is =1B$B!H=1B(Buser@nc.example.com=1B$B!I=1B(B then = the host to be queried would be nc.example.com.  That would be = true for mailto, also.
 
For http(s): URIs like =1B$B!H=1B(Bexample.com=1B$B!I=1B(B.  However, = it probably isn=1B$B!G=1B(Bt the right place.  In the case of an = http: URI, perhaps queries should be directed to the host itself (in = this case www.example.com).  We need to answer that = question: do we direct queries to the parent =1B$B!H=1B(Bhost=1B$B!I=1B(B = (as I have it in the examples) or to the named host in the = URI?
 
Paul
 

Nov,

 Keep in mind that this is an entirely = fictional example.  There isn=1B$B!G=1B(Bt even a URI scheme called = =1B$B!H=1B(Bdevice=1B$B!I=1B(B.
 The answer to your question would come from a = document (if it existed, but does not) that describes the = =1B$B!H=1B(Bdevice=1B$B!I=1B(B URI and how to use it within the context = of WebFinger.
 
My thinking when I wrote = this is that there are named devices on the network and one would query = the parent domain to learn about the device.  The parent in this = case being 

To: "'nov matake'" , "'Brad Fitzpatrick'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <077401cde003$bc74fe40$355efac0$@packetizer.com> <3B2DA5C2-0868-4738-ABB0-5D33D920EB37@gmail.com> In-Reply-To: <3B2DA5C2-0868-4738-ABB0-5D33D920EB37@gmail.com> Date: Sat, 22 Dec 2012 00:44:09 -0500 Message-ID: <079f01cde007$5d817310$18845930$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowIzcdlqAlXgG7KXy8ThMA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:44:10 -0000 Not if you shout loudly. :) We could change it back. I think Brad was the main proponent for this change. Brad, what is your take? Paul > -----Original Message----- > From: nov matake [mailto:matake@gmail.com] > Sent: Saturday, December 22, 2012 12:36 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > > Understood. > I saw the same debate in OAuth2 ML and saw opposite result :p > > I, as a ruby library developer, prefer single "rel" because parsing > double encoded values in library is easier than modifying developer's > application framework. > But at same time, as OpenID Connect library developer, it's probably too > late to change webfinger spec ... :( > > On 2012/12/22, at 14:18, Paul E. Jones wrote: > > > Nov, > > > > It used to base space-delimited in the -02 draft: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-5.3 > > > > We had a debate over this and, as usual, I lost. :-) > > > > Some people expressed concerns that there might be spaces in the URL, > > so taking two URLs like this: > > > > http://example.com/this one > > http://example.com/that one > > > > And then putting them into the "rel" parameter like this: > > > > http%3A%2F%2Fexample.com%2Fthis%20one%20http%3A%2F%2Fexample.com%2Ftha > > t%20on > > e > > ^^^ ^^^ > > > > The ^^^ denotes the problem. > > > > Unescaping and splitting on spaces would give you 4 values. > > > > So, one has to do this: > > encodeURIComponent( > > encodeURIComponent ("http://example.com/this one") + " " + > > encodeURIComponent ("http://example.com/that one") ) > > > > And put that into the "rel" parameter. > > > > That can get a bit ugly. I personally preferred the single rel > > parameter, though. I was overruled. > > > > Perhaps you might be more persuasive than I was. > > > > Paul > > > >> -----Original Message----- > >> From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] > >> On Behalf Of nov matake > >> Sent: Friday, December 21, 2012 11:49 PM > >> To: webfinger@ietf.org > >> Subject: [webfinger] feedback for multiple "rel" > >> > >> Hi, > >> > >> I have a comment for they way to specify multiple "rel" values. > >> > >> As a ruby library developer, my main target is rails developers. > >> Since rails can't handle multiple same query keys, developers will > >> need to hack query params parser in rails middleware layer. > >> I can easily imagine it'll be an annoying part to support webfinger > >> in rails. > >> > >> Is the multiple "rel" case can be a space-delimitered (or some other > >> character) strings like multiple redirect_uri in OAuth2? > >> Or any reason for putting multiple same keys in query parameters? > >> > >> Cheers, > >> > >> Nov Matake > >> _______________________________________________ > >> webfinger mailing list > >> webfinger@ietf.org > >> https://www.ietf.org/mailman/listinfo/webfinger > > From paulej@packetizer.com Fri Dec 21 21:48:42 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF91421F84DD for ; Fri, 21 Dec 2012 21:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL03ePU0Pf1n for ; Fri, 21 Dec 2012 21:48:39 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ED9AE21F84DB for ; Fri, 21 Dec 2012 21:48:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBM5mbdD005202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 00:48:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356155317; bh=axM0p8o3IFAwlOzjQfdhf3WjyIBRFr98S9Zxw5tpYas=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QweI+uUIwvPjupAYOwqnOunv9lqTj0227ViFULYGIPu+Vv8ic56rtK5Dyh7UPGVTg 5M1DBQAIsPeDgcqAJ0GhRzJTkL8H+6sCG7uXCOQi8JBkvsz/RJ9Rgi1dBHnjWOY1D8 3NnBlrc1EtEOV8UCW+FxzVTgOCwKDWPlRU53TaEg= From: "Paul E. Jones" To: "'nov matake'" References: <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> <077601cde004$d8ae8760$8a0b9620$@packetizer.com> <078901cde006$bc9724e0$35c56ea0$@packetizer.com> In-Reply-To: Date: Sat, 22 Dec 2012 00:48:40 -0500 Message-ID: <07b101cde007$feba5670$fc2f0350$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B2_01CDDFDE.15E69860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeIapXe7gOJ5OOW00neyp/e43xxwISwboRAW9vMOQCCvx/RQGvphy9AmVSMcuXNrsx8A== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:48:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07B2_01CDDFDE.15E69860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not. :-) Wordsmithing. how about this: Note that the host queried in this example is different than for the acct URI example, since the URI refers to a different host. Either this host would provide a response, or it would redirect the client to another host (e.g., redirect back to example.com). Either way, ... I'm trying to make it clearer. I think the last version was not so clear. Paul From: nov matake [mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 12:44 AM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. Thanks, I'm happy with the change :-) On 2012/12/22, at 14:39, "Paul E. Jones" wrote: Nov, As I quickly looked at the text, I think we really should be consistent in using the hostname that immediately follows http(s):// or device:. So, I'm going to change the WF draft accordingly. So, the end of section 3.1 now looks like this: An alias is a URI that is different from the "subject" URI that identifies the same entity. In the above example, there is one "http" alias returned, though there might have been more than one. Had the "http:" URI shown as an alias been used to query for information about Bob, the query would have appeared as: GET /.well-known/webfinger? resource=http%3A%2F% 2Fwww.example.com%2F~bob%2F HTTP/1.1 Host: www. example.com Note that the host queried changed in this example, since the URI refers to a different host. Either this host would provide a response, or it would redirect the client to another host (e.g., example.com). Either way, the response would have been substantially the same, with the subject and alias information changed as necessary. Other information, such as the expiration time might also change, but the set of link relations and properties would be the same with either response. I also put " p1.example.com" as the host for the device: URI. I do think the particular host to query is something we'll have to take up on a URI-by-URI basis, but a very logical assumption with no other guidance is to query the host that is in the "hostname" position of the URI (if there is one). For URIs like "tel", the WF client would just have to be provisioned to know where to go query. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Saturday, December 22, 2012 12:26 AM To: 'nov matake' Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. Nov, The host to query for the acct URI should be the host portion following the @. For example, if one's email ID is " user@nc.example.com" then the host to be queried would be nc.example.com. That would be true for mailto, also. For http(s): URIs like " http://www.example.com/some/path/", there are one of two possibilities. In the examples, I've suggested that to one would query the host "example.com". However, it probably isn't the right place. In the case of an http: URI, perhaps queries should be directed to the host itself (in this case www.example.com). We need to answer that question: do we direct queries to the parent "host" (as I have it in the examples) or to the named host in the URI? Paul From: nov matake [ mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 12:10 AM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. OK, Then basically webfinger clients MUST use the host of resource parameter (at least when using acct, mailto, http and https schema), but extension spec MAY define another rule and in that case, client MUST follow the extension's rule. Is it right? Or webfinger itself doesn't specify anything for host usage? (It just define path "/.well-known/webfinger" and schema "https", but not host?) On 2012/12/22, at 13:57, Paul E. Jones < paulej@packetizer.com> wrote: Nov, Keep in mind that this is an entirely fictional example. There isn't even a URI scheme called "device". The answer to your question would come from a document (if it existed, but does not) that describes the "device" URI and how to use it within the context of WebFinger. My thinking when I wrote this is that there are named devices on the network and one would query the parent domain to learn about the device. The parent in this case being example.com. It might be that there is a designated host that serves as the device info server called " devices.example.com" to which all queries are directed. In any case, this is completely unspecified and the example is there only to illustrate the range of use for WebFinger. It should not be viewed in any way as proper usage, though. Paul From: webfinger-bounces@ietf.org [mailto:webfinger- bounces@ietf.org] On Behalf Of nov matake Sent: Friday, December 21, 2012 11:40 PM To: webfinger@ietf.org Subject: [webfinger] Question about device info discovery example. Hi all, I'm new to this ML. I'm writing a ruby webfinger library. https://rubygems.org/gems/webfinger After reading usecases in section 3, I have a question. In the device info discovery example in section 3.4, resource is "device:p1. example.com" but the host of discovery endpoint is " example.com", not " p1.example.com". Is there any reason why these hosts are different? How did the client decide the host of the discovery endpoint from resource URI? Thanks Nov Matake ------=_NextPart_000_07B2_01CDDFDE.15E69860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not. :-)

 

Wordsmithing… how about this:

 

Note that the host queried in this example is different than for the = acct URI example, since the URI refers to a different host.  Either = this host would provide a response, or it would redirect the client to = another host (e.g., redirect back to example.com).  Either way, = ...

 

I’m trying to make it clearer. I think the last version was not = so clear.

 

Paul

 

 

Thanks, I'm = happy with the change :-)

 



Nov,

 

As I quickly looked at the text, I think we really should be = consistent in using the hostname that immediately follows http(s):// or = device:.  So, I’m going to change the WF draft = accordingly.

 

So, the end of section 3.1 now looks like = this:

 

An alias is a URI that is different from the “subject” = URI that identifies the same entity.  In the above example, there = is one “http” alias returned, though there might have been = more than one.  Had the “http:” URI shown as an alias = been used to query for information about Bob, the query would have = appeared as:

 

  GET = /.well-known/webfinger?

         = ;  resource=3Dhttp%3A%2F%2Fwww.example.com%2F~bob%2F = HTTP/1.1

  Host: www.example.com

=

 

N= ote that the host queried changed in this example, since the URI refers = to a different host.  Either this host would provide a response, or = it would redirect the client to another host (e.g., example.com).  Either way, the response would have been substantially the same, with the subject = and alias information changed as necessary.  Other information, = such as the expiration time might also change, but the set of link = relations and properties would be the same with either = response.

 

I also put “p1.example.com” as the host for = the device: URI.  I do think the particular host to query is = something we’ll have to take up on a URI-by-URI basis, but a very = logical assumption with no other guidance is to query the host that is = in the “hostname” position of the URI (if there is = one).

 

For URIs like “tel”, the WF client would just have to be = provisioned to know where to go = query.

 

Paul

 

From:=  webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Saturday, December 22, 2012 = 12:26 AM
To: 'nov = matake'
Cc: webfinger@ietf.org
Subject:<= /b> Re: [webfinger] = Question about device info discovery = example.

 

Nov,

 

The host to query for the acct URI should be the host portion = following the @.  For example, if one’s email ID is “user@nc.example.com” then the = host to be queried would be nc.example.com.  That would be = true for mailto, also.

 

For http(s): URIs like “http://www.example.com/some/path/”= ;, there are one of two possibilities.  In the examples, I’ve = suggested that to one would query the host “example.com”.  However, it = probably isn’t the right place.  In the case of an http: URI, = perhaps queries should be directed to the host itself (in this case www.example.com).  We need to = answer that question: do we direct queries to the parent = “host” (as I have it in the examples) or to the named host = in the URI?

 

Paul

 

From:=  nov matake = [mailto:matake@gmail.com] 
Sent: Saturday, December 22, 2012 = 12:10 AM
To: Paul E. = Jones
Cc: webfinger@ietf.org
Subject: Re: [webfinger] Question = about device info discovery = example.

 

OK,

 

Then basically webfinger clients MUST use the host of = resource parameter (at least when using acct, mailto, http and https = schema),

but = extension spec MAY define another rule and in that case, client MUST = follow the extension's rule.

 

Is it right?

 

Or webfinger itself doesn't specify anything for host = usage?

(It just = define path "/.well-known/webfinger" and schema = "https", but not host?)

 

On 2012/12/22, at 13:57, Paul E. Jones <paulej@packetizer.com> = wrote:

 

Nov,

 

Keep in mind that this is an entirely fictional example.  There = isn’t even a URI scheme called = “device”.

 

The answer to your question would come from a document (if it = existed, but does not) that describes the “device” URI and = how to use it within the context of = WebFinger.

 

My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the = device.  The parent in this case beingexample.com.  It might be that = there is a designated host that serves as the device info server called = “devices.example.com” to which = all queries are directed.  In any case, this is completely = unspecified and the example is there only to illustrate the range of use = for WebFinger.  It should not be viewed in any way as proper usage, = though.

 

Paul

 

From:=  webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Friday, December 21, 2012 = 11:40 PM
To: webfinger@ietf.org
Subject: [webfinger] Question = about device info discovery = example.

 

Hi all,

I'm new to this ML.

I'm writing a = ruby webfinger library.
https://rubygems.org/gems/webfinger
=
After reading usecases in section 3, I have a question.

In = the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of = discovery endpoint is "example.com", not "p1.example.com".
Is there any = reason why these hosts are different?
How did the client decide the = host of the discovery endpoint from resource = URI?

Thanks

Nov = Matake

 

------=_NextPart_000_07B2_01CDDFDE.15E69860-- From matake@gmail.com Fri Dec 21 21:53:21 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6004D21F88BE for ; Fri, 21 Dec 2012 21:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPBgZsWpUZog for ; Fri, 21 Dec 2012 21:53:19 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id D747B21F881A for ; Fri, 21 Dec 2012 21:53:19 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id bi1so3215717pad.8 for ; Fri, 21 Dec 2012 21:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=mlTzFIIqX5anBnVqYzth+CJ248zC5QKelZPy+RoiWbk=; b=0Kf7/CBh4OSzpCF9/Gl9E9L9l+JwdM2P5Iao1MPInX0a169LSKwrPuSlbM3UkOOwtM keKwpA7gc7E+BPDLC60ochxBKRWsOVVUWXFwiJgPYyzHxbGaQ9cDcHQi9jINUWr7e5cm 4x/rihuLHfzYWUfRzjgg5fKvG69TlpyoB4RRQvaHmcqEqSw2qAhTvhkM6Ne2aazy4kUJ VDC9QP+8RyIDUmNrfsfxzSo63PtusbQ2EHbNb49CrpES5vrOQA0dPrGDfTUOB8uH1xm3 tu7U/An0oSXTcu6LGpt1SiqQbm9W1bV4IiBp5DPdIQRkU3rX+JXSr94K2RgtxxhLBnQm udPA== X-Received: by 10.66.73.105 with SMTP id k9mr43257365pav.37.1356155599566; Fri, 21 Dec 2012 21:53:19 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id kc4sm8252993pbc.23.2012.12.21.21.53.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 21:53:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D710BE96-824A-447F-A9F8-67026E06A930" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <07b101cde007$feba5670$fc2f0350$@packetizer.com> Date: Sat, 22 Dec 2012 14:53:17 +0900 Message-Id: References: <075b01cde000$d283d790$778b86b0$@packetizer.com> <1B7C31D3-E41E-4DF2-910F-AC43340C62D6@gmail.com> <077601cde004$d8ae8760$8a0b9620$@packetizer.com> <078901cde006$bc9724e0$35c56ea0$@packetizer.com> <07b101cde007$feba5670$fc2f0350$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] Question about device info discovery example. X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 05:53:21 -0000 --Apple-Mail=_D710BE96-824A-447F-A9F8-67026E06A930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Cleaner :) On 2012/12/22, at 14:48, "Paul E. Jones" wrote: > I=1B$B!G=1B(Bm not. :-) > =20 > Wordsmithing=1B$B!D=1B(B how about this: > =20 > Note that the host queried in this example is different than for the = acct URI example, since the URI refers to a different host. Either this = host would provide a response, or it would redirect the client to = another host (e.g., redirect back to example.com). Either way, ... > =20 > I=1B$B!G=1B(Bm trying to make it clearer. I think the last version was = not so clear. > =20 > Paul > =20 > From: nov matake [mailto:matake@gmail.com]=20 > Sent: Saturday, December 22, 2012 12:44 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Question about device info discovery example. > =20 > Thanks, I'm happy with the change :-) > =20 > On 2012/12/22, at 14:39, "Paul E. Jones" = wrote: >=20 >=20 > Nov, > =20 > As I quickly looked at the text, I think we really should be = consistent in using the hostname that immediately follows http(s):// or = device:. So, I=1B$B!G=1B(Bm going to change the WF draft accordingly. > =20 > So, the end of section 3.1 now looks like this: > =20 > An alias is a URI that is different from the =1B$B!H=1B(Bsubject=1B$B!I=1B= (B URI that identifies the same entity. In the above example, there is = one =1B$B!H=1B(Bhttp=1B$B!I=1B(B alias returned, though there might have = been more than one. Had the =1B$B!H=1B(Bhttp:=1B$B!I=1B(B URI shown as = an alias been used to query for information about Bob, the query would = have appeared as: > =20 > GET /.well-known/webfinger? > resource=3Dhttp%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1 > Host: www.example.com > =20 > Note that the host queried changed in this example, since the URI = refers to a different host. Either this host would provide a response, = or it would redirect the client to another host (e.g., example.com). = Either way, the response would have been substantially the same, with = the subject and alias information changed as necessary. Other = information, such as the expiration time might also change, but the set = of link relations and properties would be the same with either response. > =20 > I also put =1B$B!H=1B(Bp1.example.com=1B$B!I=1B(B as the host for the = device: URI. I do think the particular host to query is something = we=1B$B!G=1B(Bll have to take up on a URI-by-URI basis, but a very = logical assumption with no other guidance is to query the host that is = in the =1B$B!H=1B(Bhostname=1B$B!I=1B(B position of the URI (if there is = one). > =20 > For URIs like =1B$B!H=1B(Btel=1B$B!I=1B(B, the WF client would just = have to be provisioned to know where to go query. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Paul E. Jones > Sent: Saturday, December 22, 2012 12:26 AM > To: 'nov matake' > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Question about device info discovery example. > =20 > Nov, > =20 > The host to query for the acct URI should be the host portion = following the @. For example, if one=1B$B!G=1B(Bs email ID is = =1B$B!H=1B(Buser@nc.example.com=1B$B!I=1B(B then the host to be queried = would be nc.example.com. That would be true for mailto, also. > =20 > For http(s): URIs like = =1B$B!H=1B(Bhttp://www.example.com/some/path/=1B$B!I=1B(B, there are one = of two possibilities. In the examples, I=1B$B!G=1B(Bve suggested that = to one would query the host =1B$B!H=1B(Bexample.com=1B$B!I=1B(B. = However, it probably isn=1B$B!G=1B(Bt the right place. In the case of = an http: URI, perhaps queries should be directed to the host itself (in = this case www.example.com). We need to answer that question: do we = direct queries to the parent =1B$B!H=1B(Bhost=1B$B!I=1B(B (as I have it = in the examples) or to the named host in the URI? > =20 > Paul > =20 > From: nov matake [mailto:matake@gmail.com]=20 > Sent: Saturday, December 22, 2012 12:10 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Question about device info discovery example. > =20 > OK, > =20 > Then basically webfinger clients MUST use the host of resource = parameter (at least when using acct, mailto, http and https schema), > but extension spec MAY define another rule and in that case, client = MUST follow the extension's rule. > =20 > Is it right? > =20 > Or webfinger itself doesn't specify anything for host usage? > (It just define path "/.well-known/webfinger" and schema "https", but = not host?) > =20 > On 2012/12/22, at 13:57, Paul E. Jones wrote: > =20 >=20 > Nov, > =20 > Keep in mind that this is an entirely fictional example. There = isn=1B$B!G=1B(Bt even a URI scheme called =1B$B!H=1B(Bdevice=1B$B!I=1B(B. > =20 > The answer to your question would come from a document (if it existed, = but does not) that describes the =1B$B!H=1B(Bdevice=1B$B!I=1B(B URI and = how to use it within the context of WebFinger. > =20 > My thinking when I wrote this is that there are named devices on the = network and one would query the parent domain to learn about the device. = The parent in this case beingexample.com. It might be that there is a = designated host that serves as the device info server called = =1B$B!H=1B(Bdevices.example.com=1B$B!I=1B(B to which all queries are = directed. In any case, this is completely unspecified and the example = is there only to illustrate the range of use for WebFinger. It should = not be viewed in any way as proper usage, though. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Friday, December 21, 2012 11:40 PM > To: webfinger@ietf.org > Subject: [webfinger] Question about device info discovery example. > =20 > Hi all, >=20 > I'm new to this ML. >=20 > I'm writing a ruby webfinger library. > https://rubygems.org/gems/webfinger >=20 > After reading usecases in section 3, I have a question. >=20 > In the device info discovery example in section 3.4, resource is = "device:p1.example.com" but the host of discovery endpoint is = "example.com", not "p1.example.com". > Is there any reason why these hosts are different? > How did the client decide the host of the discovery endpoint from = resource URI? >=20 > Thanks >=20 > Nov Matake --Apple-Mail=_D710BE96-824A-447F-A9F8-67026E06A930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Cleaner = :)

On 2012/12/22, at 14:48, "Paul E. Jones" = <paulej@packetizer.com>= wrote:

I=1B$B!G=1B(Bm not. = :-)
 
Wordsmithing=1B$B!D=1B(B how about = this:
 
Note that the host queried in this example is = different than for the acct URI example, since the URI refers to a = different host.  Either this host would provide a response, or it = would redirect the client to another host (e.g., redirect back to example.com).  Either way, = ...
 
I=1B$B!G=1B(Bm trying to make it clearer. I = think the last version was not so clear.
 
 
 nov = matake [mailto:matake@gmail.com] 
Sent: Saturday, December 22, 2012 = 12:44 AM
To: Paul E. = Jones
Cc: webfinger@ietf.org
Subject: Re: [webfinger] = Question about device info discovery = example.
Thanks, I'm = happy with the change :-)
On = 2012/12/22, at 14:39, "Paul E. Jones" <paulej@packetizer.com> = wrote:
Nov,
As I quickly looked at the text, I think we = really should be consistent in using the hostname that immediately = follows http(s):// or device:.  So, I=1B$B!G=1B(Bm going to change = the WF draft accordingly.
So, the end of section 3.1 now looks like = this:
An alias is a URI that = is different from the =1B$B!H=1B(Bsubject=1B$B!I=1B(B URI that = identifies the same entity.  In the above example, there is one = =1B$B!H=1B(Bhttp=1B$B!I=1B(B alias returned, though there might have = been more than one.  Had the =1B$B!H=1B(Bhttp:=1B$B!I=1B(B URI = shown as an alias been used to query for information about Bob, the = query would have appeared as:
 
  GET = /.well-known/webfinger?
           = resource=3Dhttp%3A%2F%  Host: 
 
From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Saturday, December 22, 2012 = 12:26 AM
To: 'nov = matake'
Cc:  Re: [webfinger] Question = about device info discovery = example.
 
 
The host to query for = the acct URI should be the host portion following the @.  For = example, if one=1B$B!G=1B(Bs email ID is =1B$B!H=1B(B nc.example.com.  That would be true for mailto, = also.
 
For http(s): URIs like = =1B$B!H=1B(Bexample.com=1B$B!I=1B(B.  However, it probably = isn=1B$B!G=1B(Bt the right place.  In the case of an http: URI, = perhaps queries should be directed to the host itself (in this case  

* Moved some references to the informative references section > * Removed instructions for the server to return specific > status codes (Tim successfully argued it was not needed) > * Retained one statement, though, in section 4.2 that > requires a server to return a 400. However, the > text was changed to refer to behavior in RFC 2616. > Same end result, though. > * Moved section the "rel" parameter section before the > JRD section. > * Made edits to the JRD section as discussed on the list > * Various editorial changes > > Please have a look at this text and suggest any changes we should make. > This actually looks pretty good! Re: The media type used for the JSON Resource Descriptor (JRD) is "application/= json" Doesnt JRD have it's own content type? See Eran's comment: http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-81= 22 "For now I=92m using application/json, but application/xrd+json is also possible." Maybe something like application/jrd+json would be best? > > Paul > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: Friday, December 21, 2012 12:21 PM > > To: i-d-announce@ietf.org > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Applications Area Working Group > > Working Group of the IETF. > > > > Title : WebFinger > > Author(s) : Paul E. Jones > > Gonzalo Salgueiro > > Joseph Smarr > > Filename : draft-ietf-appsawg-webfinger-08.txt > > Pages : 20 > > Date : 2012-12-21 > > > > Abstract: > > This specification defines the WebFinger protocol, which can be used > > to discover information about people or other entities on the > > Internet using standard HTTP methods. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-08 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae93409012ef61304d1725d7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 21 December 2012 18:38, Paul E. Jones= <paulej@packetizer.com> wrote:
Folks,

I just posted a revised version of the WebFinger text. =A0Highlights includ= e:
=A0* Change all queries to require HTTPS only
=A0* Forbid server redirection to HTTP URIs
=A0* Merged the "Introduction" and "Overview" sections<= br> =A0* Moved some references to the informative references section
=A0* Removed instructions for the server to return specific
=A0 =A0status codes (Tim successfully argued it was not needed)
=A0 =A0 * Retained one statement, though, in section 4.2 that
=A0 =A0 =A0 requires a server to return a 400. =A0However, the
=A0 =A0 =A0 text was changed to refer to behavior in RFC 2616.
=A0 =A0 =A0 Same end result, though.
=A0* Moved section the "rel" parameter section before the
=A0 =A0JRD section.
=A0* Made edits to the JRD section as discussed on the list
=A0* Various editorial changes

Please have a look at this text and suggest any changes we should make.
=

This actually looks pretty good!

Re:
T=
he media type used for the JSON Resource Descriptor (JRD) is "applicat=
ion/json"
Doesnt JRD have it's own content type?

See Eran's comment:
http://hueniverse.com/2010/05/jrd-the-other-resource-d= escriptor/#comment-8122

"For now I=92m using application/json, but application/xrd+json is= also possible."

Maybe something like application/jrd+json woul= d be best?
=A0

Paul

> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Friday, December 21, 2012 12:21 PM
> To: i-d-announce@ietf.org=
> Cc: apps-discuss@ietf.org=
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.tx= t
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =A0This draft is a work item of the Applications Area Working Group > Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : WebFinger
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joseph Smarr
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-webfinger-08.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-12-21
>
> Abstract:
> =A0 =A0This specification defines the WebFinger protocol, which can be= used
> =A0 =A0to discover information about people or other entities on the > =A0 =A0Internet using standard HTTP methods.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-w= ebfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-08
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae93409012ef61304d1725d7a-- From melvincarvalho@gmail.com Sat Dec 22 07:17:05 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7407421F8B69 for ; Sat, 22 Dec 2012 07:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw5KGCq2yFol for ; Sat, 22 Dec 2012 07:17:04 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7530F21F8B68 for ; Sat, 22 Dec 2012 07:17:04 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e13so7526049iej.4 for ; Sat, 22 Dec 2012 07:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aZ7pxTootGNKA4gGxjqdUjoxwbqgRQIxJGX/9ZDDMu8=; b=eVUG/euSDvEUFAyjZS/6A2SFmh5YJgbHPAe2eRwNKrEWBncmdKKa9Nhau2J8FJ9U90 FJO1+w99MnkzBvNem3vdLjby/kW0WkzuYUJbb0LYmDFKRrqriDBZUoskZxXRFq+jsrlY wtFLWHvDRafn2ySGXJhxKD1LR+wNPYaAXZyuATc3fM0E3XycfMLmnOl5+P0MKgRDqa/x fnm2hyKbWrNU+553q792/dXQEKyRyiHScK9NgOPkyBkCcVIuWGAUQ8XcpdYan1KwB/sO UzbBcW8fgtiX7KAEJLRjnLkx7rQX9uFz9FtHWhZEbXqI08D1Nn4Wy3niPBa7dm+3fNjK oOZg== MIME-Version: 1.0 Received: by 10.50.51.231 with SMTP id n7mr11305071igo.85.1356189424105; Sat, 22 Dec 2012 07:17:04 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sat, 22 Dec 2012 07:17:03 -0800 (PST) In-Reply-To: <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> Date: Sat, 22 Dec 2012 16:17:03 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9340f0fdf388304d1727473 Cc: webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 15:17:05 -0000 --14dae9340f0fdf388304d1727473 Content-Type: text/plain; charset=ISO-8859-1 On 21 December 2012 18:38, Paul E. Jones wrote: > Folks, > > I just posted a revised version of the WebFinger text. Highlights include: > * Change all queries to require HTTPS only > * Forbid server redirection to HTTP URIs > * Merged the "Introduction" and "Overview" sections > * Moved some references to the informative references section > * Removed instructions for the server to return specific > status codes (Tim successfully argued it was not needed) > * Retained one statement, though, in section 4.2 that > requires a server to return a 400. However, the > text was changed to refer to behavior in RFC 2616. > Same end result, though. > * Moved section the "rel" parameter section before the > JRD section. > * Made edits to the JRD section as discussed on the list > * Various editorial changes > > Please have a look at this text and suggest any changes we should make. > I've also just realized that webfinger can also have 100s or even 1000s of extra deployments via SPARQL endpoints using mod_rewrite. For those that done know, SPARQL is a general purpose query language for the Web currently at REC status. Webfinger amounts to a named SPARQL query with a shorthand syntax. As such you can translate between the two using a simple mod rewrite rule in your .htaccess. The query would amount to something like: SELECT * FROM { $attribute $value } Which actually can be URI encoded. Ive proposed /.well-known/sparql as of today which could facilitate 100s of extra webfinger deployments with a few lines of code. > > Paul > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: Friday, December 21, 2012 12:21 PM > > To: i-d-announce@ietf.org > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Applications Area Working Group > > Working Group of the IETF. > > > > Title : WebFinger > > Author(s) : Paul E. Jones > > Gonzalo Salgueiro > > Joseph Smarr > > Filename : draft-ietf-appsawg-webfinger-08.txt > > Pages : 20 > > Date : 2012-12-21 > > > > Abstract: > > This specification defines the WebFinger protocol, which can be used > > to discover information about people or other entities on the > > Internet using standard HTTP methods. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-08 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > --14dae9340f0fdf388304d1727473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 21 December 2012 18:38, Paul E. Jones= <paulej@packetizer.com> wrote:
Folks,

I just posted a revised version of the WebFinger text. =A0Highlights includ= e:
=A0* Change all queries to require HTTPS only
=A0* Forbid server redirection to HTTP URIs
=A0* Merged the "Introduction" and "Overview" sections<= br> =A0* Moved some references to the informative references section
=A0* Removed instructions for the server to return specific
=A0 =A0status codes (Tim successfully argued it was not needed)
=A0 =A0 * Retained one statement, though, in section 4.2 that
=A0 =A0 =A0 requires a server to return a 400. =A0However, the
=A0 =A0 =A0 text was changed to refer to behavior in RFC 2616.
=A0 =A0 =A0 Same end result, though.
=A0* Moved section the "rel" parameter section before the
=A0 =A0JRD section.
=A0* Made edits to the JRD section as discussed on the list
=A0* Various editorial changes

Please have a look at this text and suggest any changes we should make.
=

I've also just realized that webfinger can also h= ave 100s or even 1000s of extra deployments via SPARQL endpoints using mod_= rewrite.

For those that done know, SPARQL is a general purpose query language fo= r the Web currently at REC status.

Webfinger amounts to a named SPAR= QL query with a shorthand syntax.=A0 As such you can translate between the = two using a simple mod rewrite rule in your .htaccess.

The query would amount to something like:

SELECT * FROM { <re= source> $attribute $value }

Which actually can be URI encoded.=A0= Ive proposed /.well-known/sparql as of today which could facilitate 100s o= f extra webfinger deployments with a few lines of code.
=A0

Paul

> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Friday, December 21, 2012 12:21 PM
> To: i-d-announce@ietf.org=
> Cc: apps-discuss@ietf.org=
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.tx= t
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =A0This draft is a work item of the Applications Area Working Group > Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : WebFinger
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joseph Smarr
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-webfinger-08.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-12-21
>
> Abstract:
> =A0 =A0This specification defines the WebFinger protocol, which can be= used
> =A0 =A0to discover information about people or other entities on the > =A0 =A0Internet using standard HTTP methods.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-w= ebfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-08
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae9340f0fdf388304d1727473-- From melvincarvalho@gmail.com Sat Dec 22 07:44:40 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0F21F8B43 for ; Sat, 22 Dec 2012 07:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYcPMlJjlV5j for ; Sat, 22 Dec 2012 07:44:40 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 009A221F8B2B for ; Sat, 22 Dec 2012 07:44:39 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so7460776ieb.25 for ; Sat, 22 Dec 2012 07:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QtByLi6b0mSJTNaOdiHD9GW0TCE9O+hnKKtoRtHm4z4=; b=QHX6qBHHR7I3iFA3oec7iUwXUKAL40WJwEHWE3zhR/X2i+BkWjmiXN1rnnqdE3Y6at gr4L9aSLFI93GAUx1jRzecdLjyRA2BYlcIaxgpFRf2YAM7uwo21ojyd1ygvjUj6fYn4f 9NH1ggM/l7X5aoTWDG4JNKssKy6nxff8ZmQqiKcvhn6QnzNSyOMPg/Ip4Mk0uBGBSST2 caEXyejjyRTOFhayh2zmnPkoPxn07GcvHSCjwAkT8HYGxFWAzWjgXGKeuoV2FG+/NXEV 30lGDMTiAY80KaR+cl4sBFTdxElhq00LPr3YGrGY775fOg6+Qlm54cfPxnTxbB3HJN7l Do4A== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr16312344igk.41.1356191079401; Sat, 22 Dec 2012 07:44:39 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sat, 22 Dec 2012 07:44:39 -0800 (PST) In-Reply-To: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> Date: Sat, 22 Dec 2012 16:44:39 +0100 Message-ID: From: Melvin Carvalho To: nov matake Content-Type: multipart/alternative; boundary=14dae9340901890a3404d172d7ce Cc: "webfinger@ietf.org" Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 15:44:40 -0000 --14dae9340901890a3404d172d7ce Content-Type: text/plain; charset=ISO-8859-1 On 22 December 2012 05:48, nov matake wrote: > Hi, > > I have a comment for they way to specify multiple "rel" values. > > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will need to > hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in > rails. > > Is the multiple "rel" case can be a space-delimitered (or some other > character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? > each time you delimit a list, you have to be able to escape the delimiter, which can be a pain and also leads to problems with things like canonical urls and search engines can you use mod_rewrite? > > Cheers, > > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > --14dae9340901890a3404d172d7ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 22 December 2012 05:48, nov matake <m= atake@gmail.com> wrote:
Hi,

I have a comment for they way to specify multiple "rel" values.
As a ruby library developer, my main target is rails developers.
Since rails can't handle multiple same query keys, developers will need= to hack query params parser in rails middleware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimitered (or some ot= her character) strings like multiple redirect_uri in OAuth2?
Or any reason for putting multiple same keys in query parameters?

each time you delimit a list, you have to be able to escape= the delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines

can you use mod_rewrite?
=A0

Cheers,

Nov Matake
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

--14dae9340901890a3404d172d7ce-- From matake@gmail.com Sat Dec 22 08:02:23 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3BE21F8B43 for ; Sat, 22 Dec 2012 08:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqVsQOcemUKE for ; Sat, 22 Dec 2012 08:02:17 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id DDB6521F8ACA for ; Sat, 22 Dec 2012 08:02:17 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so3397792pad.12 for ; Sat, 22 Dec 2012 08:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=fUB+B1Yxzre/r/iohBeD9GxjVy+M7OmZxyNYiBNGdi4=; b=V85ya/bepaR6uWWu/K0FT4+UTyX2VU6wr+aQRlPr0eUdS6bzNM+JgFnDXMj++KMpld Mtu254t9eDj8i6JDv+9U8HQqDPgAfjcAfNL8IzapdrAt1PrNQz7JyDeBXge1ziVz1UPd poRAAS7/pkbkrSN7S8GNMzZHme93yvPmj6ZwE/sbmYov+EEyaRSqboa47dqxhIbyMEVp n7Y6aOVZH75z5Iydqnf+HTHVGwp0E0i452TYsHK2wEHmN18l2FwavrV1I8gvZ4Cnl07r pleXb59g9rF9vE217YRtO1I+F7N+OXADVgwINHzB/jH5DLTKj+P+MnDSx9DiXb5t1j8n VJEw== X-Received: by 10.66.79.195 with SMTP id l3mr46744366pax.82.1356192137604; Sat, 22 Dec 2012 08:02:17 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id z5sm9464890pax.9.2012.12.22.08.02.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 08:02:16 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_93345626-3B5F-42FF-ADC2-1070DAB597CB" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: Date: Sun, 23 Dec 2012 01:02:13 +0900 Message-Id: <4D3FE0C5-A4A7-4857-85DD-82568B526EA9@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:02:24 -0000 --Apple-Mail=_93345626-3B5F-42FF-ADC2-1070DAB597CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I understand double encoding issue. Same discussion was in OAuth/OpenID Connect ML. However, for library developer, handling double encoding value is easier = than handling duplicated query keys, at least in rails case. Of course, developers who use my ruby library can use mod_rewrite. But I don't want to provide/use a library which requires specific = rewrite rule :( On 2012/12/23, at 0:44, Melvin Carvalho = wrote: >=20 >=20 > On 22 December 2012 05:48, nov matake wrote: > Hi, >=20 > I have a comment for they way to specify multiple "rel" values. >=20 > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will = need to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in = rails. >=20 > Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? >=20 > each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines >=20 > can you use mod_rewrite? > =20 >=20 > Cheers, >=20 > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 --Apple-Mail=_93345626-3B5F-42FF-ADC2-1070DAB597CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 melvincarvalho@gmail.com> = wrote:



On 22 December 2012 = 05:48, nov matake <matake@gmail.com> wrote:
Hi,

I have a comment for they way to specify multiple "rel" values.

As a ruby library developer, my main target is rails developers.
Since rails can't handle multiple same query keys, developers will need = to hack query params parser in rails middleware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2?
Or any reason for putting multiple same keys in query = parameters?

each time you delimit a list, you = have to be able to escape the delimiter, which can be a pain and also = leads to problems with things like canonical urls and search engines

can you use mod_rewrite?
 

Cheers,

Nov Matake
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


= --Apple-Mail=_93345626-3B5F-42FF-ADC2-1070DAB597CB-- From matake@gmail.com Sat Dec 22 08:12:18 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8221F8A57 for ; Sat, 22 Dec 2012 08:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYrr3XznQ3bW for ; Sat, 22 Dec 2012 08:12:18 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE521F8A4B for ; Sat, 22 Dec 2012 08:12:18 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so3427738pad.23 for ; Sat, 22 Dec 2012 08:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=cSe14uhqk67Kq/DAY1j6o//oJ1ArFGIeW1mq9cS9Xqo=; b=0lSvi0efzHa13tXGbVgnSTByltmpZh7CS3f8TSObxqVfylerI/NZxESxaYBN45EDIa zsRu9c97BXhFee/Z5rTRfuJQigPbak3pYDNZzUGrdxNnfpn1hwyrpiw1W3kJxI1feiEJ l499z+nLurZW8C97nxv51alB9dMMQ29PQYuMXseM5RyT+lq8c5ACPNWe3YSYfYIMbvxv O3EkVbTv4lcr3cXBieiSQfMVolxL54g9BiPkX9yFyx3tiwe3DE3vuOubgkK2jwn+iZTt qAv8MJJShN92xJh0ogb02ftV6kPHl0THzeEVtUXS9vs4G2g0XhHtgB+7/ra2RPkotgk1 bRig== X-Received: by 10.66.89.9 with SMTP id bk9mr46851357pab.67.1356192737834; Sat, 22 Dec 2012 08:12:17 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id o11sm9030909pby.8.2012.12.22.08.12.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 08:12:16 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_62242E8F-4613-478C-842C-D9DA6C9CE250" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: Date: Sun, 23 Dec 2012 01:12:13 +0900 Message-Id: <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:12:19 -0000 --Apple-Mail=_62242E8F-4613-478C-842C-D9DA6C9CE250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 BTW, why double encoding lead "problems with things like canonical urls = and search engines"? Can you provide more details? If 2 rel included, the response would be different than when only 1 rel = given. So I feel those 2 are not the same, and can be indexed as 2 resources.. On 2012/12/23, at 0:44, Melvin Carvalho = wrote: >=20 >=20 > On 22 December 2012 05:48, nov matake wrote: > Hi, >=20 > I have a comment for they way to specify multiple "rel" values. >=20 > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will = need to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in = rails. >=20 > Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? >=20 > each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines >=20 > can you use mod_rewrite? > =20 >=20 > Cheers, >=20 > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 --Apple-Mail=_62242E8F-4613-478C-842C-D9DA6C9CE250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 BTW, = why double encoding lead "problems with things like canonical urls and = search engines"?
Can you provide more = details?

If 2 rel included, the response would = be different than when only 1 rel given.
So I feel those 2 are = not the same, and can be indexed as 2 = resources..

On 2012/12/23, at 0:44, Melvin = Carvalho <melvincarvalho@gmail.com> = wrote:



On 22 December 2012 = 05:48, nov matake <matake@gmail.com> wrote:
Hi,

I have a comment for they way to specify multiple "rel" values.

As a ruby library developer, my main target is rails developers.
Since rails can't handle multiple same query keys, developers will need = to hack query params parser in rails middleware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2?
Or any reason for putting multiple same keys in query = parameters?

each time you delimit a list, you = have to be able to escape the delimiter, which can be a pain and also = leads to problems with things like canonical urls and search engines

can you use mod_rewrite?
 

Cheers,

Nov Matake
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


= --Apple-Mail=_62242E8F-4613-478C-842C-D9DA6C9CE250-- From melvincarvalho@gmail.com Sat Dec 22 08:39:43 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6D821F8ABA for ; Sat, 22 Dec 2012 08:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82tUNycmQjxL for ; Sat, 22 Dec 2012 08:39:42 -0800 (PST) Received: from mail-ia0-f179.google.com (mail-ia0-f179.google.com [209.85.210.179]) by ietfa.amsl.com (Postfix) with ESMTP id 74EB821F8A8A for ; Sat, 22 Dec 2012 08:39:42 -0800 (PST) Received: by mail-ia0-f179.google.com with SMTP id o25so4939880iad.10 for ; Sat, 22 Dec 2012 08:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbHTneHwmw9+DcKq4TX2pisJIsQS23wRp7Yhb6HR0wg=; b=TOmKmlDwF4+0WWJ8uEl4EgV63bn0HsiMXs9Pe90kzhwfhNKgb3zF3ZMGJnzzYSKTYT oh5PikBqiUQzwXtb/pme/srExlVDqjZ3ZDG/NOIgFERylIkSF6xcw5xq/JOTvMxSTqBV qCu0QS1Thw1/8a145OqJaX8cKMFeR6bA1z8wmG8sHcN0lOeNcxVAcxatTYhlcxPjGTXj 4BtejEnyzJqIOMOs2eADfi1bUiU4HaOwlJCHB1Se0vlRISJfOi1YaZNguJnhVK5860jR qDO4hcG4xJ48MFfsnuGadNU5dMgOpg/noJR0GCaJpwNwp8pCXMKlQmyuaxn/iSksqCuO QD7A== MIME-Version: 1.0 Received: by 10.50.40.138 with SMTP id x10mr16408413igk.41.1356194381973; Sat, 22 Dec 2012 08:39:41 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sat, 22 Dec 2012 08:39:41 -0800 (PST) In-Reply-To: <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> Date: Sat, 22 Dec 2012 17:39:41 +0100 Message-ID: From: Melvin Carvalho To: nov matake Content-Type: multipart/alternative; boundary=14dae9340901624a2e04d1739c86 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:39:43 -0000 --14dae9340901624a2e04d1739c86 Content-Type: text/plain; charset=ISO-8859-1 On 22 December 2012 17:12, nov matake wrote: > BTW, why double encoding lead "problems with things like canonical urls > and search engines"? > Can you provide more details? > Not easily, no. You could perhaps ignore that comment. However I've had situations where I've had to escape delimiters to create a URL in the past. It leads to the question of whether the escaped character should be part of the canonical url. Maybe it was just me, but I found it a bit fiddly... > > If 2 rel included, the response would be different than when only 1 rel > given. > So I feel those 2 are not the same, and can be indexed as 2 resources.. > > On 2012/12/23, at 0:44, Melvin Carvalho wrote: > > > > On 22 December 2012 05:48, nov matake wrote: > >> Hi, >> >> I have a comment for they way to specify multiple "rel" values. >> >> As a ruby library developer, my main target is rails developers. >> Since rails can't handle multiple same query keys, developers will need >> to hack query params parser in rails middleware layer. >> I can easily imagine it'll be an annoying part to support webfinger in >> rails. >> >> Is the multiple "rel" case can be a space-delimitered (or some other >> character) strings like multiple redirect_uri in OAuth2? >> Or any reason for putting multiple same keys in query parameters? >> > > each time you delimit a list, you have to be able to escape the delimiter, > which can be a pain and also leads to problems with things like canonical > urls and search engines > > can you use mod_rewrite? > > >> >> Cheers, >> >> Nov Matake >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> > > > --14dae9340901624a2e04d1739c86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 22 December 2012 17:12, nov matake <m= atake@gmail.com> wrote:
BTW, why double encoding lead "pro= blems with things like canonical urls and search engines"?
Can you= provide more details?

Not easily, no.=A0 = You could perhaps ignore that comment.

However I've had situations where I've had to escape delimiters= to create a URL in the past.=A0 It leads to the question of whether the es= caped character should be part of the canonical url.=A0 Maybe it was just m= e, but I found it a bit fiddly...
=A0

If 2 rel included, the response would be different tha= n when only 1 rel given.
So I feel those 2 are not the same, and can be indexed as 2 resources.= .

On 2012/12/23, at 0:44, Melvin = Carvalho <= melvincarvalho@gmail.com> wrote:



On 22 December 2012 05:48, nov matake = <matake@gmail.com<= /a>> wrote:
Hi,

I have a comment for they way to specify multiple "rel" values.
As a ruby library developer, my main target is rails developers.
Since rails can't handle multiple same query keys, developers will need= to hack query params parser in rails middleware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimitered (or some ot= her character) strings like multiple redirect_uri in OAuth2?
Or any reason for putting multiple same keys in query parameters?

each time you delimit a list, you have to be able to escape= the delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines

can you use mod_rewrite?
=A0

Cheers,

Nov Matake
_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



--14dae9340901624a2e04d1739c86-- From tbray@textuality.com Sat Dec 22 08:52:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF0421F8B43 for ; Sat, 22 Dec 2012 08:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF4xB3gaCe+I for ; Sat, 22 Dec 2012 08:52:58 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6C21F8B48 for ; Sat, 22 Dec 2012 08:52:57 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id oi10so5482552obb.40 for ; Sat, 22 Dec 2012 08:52:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GKZjTqlG+/FHhKm472JCYthoBH85bsLVs93ZMvhpzFk=; b=DHQQAFA8n/iBPUMiO2yGaPuLsxLCW6tnUi3WWbSulPXGfT/i3x447SkOvYzzKoyJUd t2yRmHIqeUudLw2FzUi6eBPb0TirHUwXeu/O6CDNic+34HcrRnUsnM/v8C4mq4ZRBzcW HraeE9fMijc1xiI3QyZ9h2VjveV8jbvuIPQCoHBY5L+mA9BzZghPLtmYS8YsNwJz4y73 cVMzu4yUUtOpQBy2kQr8WtfT6CQc5FIHOKNVivwSCzMI6IbcZFZB8DwI4V5swgG4iqRd LwgAtlGUywfoqDQdOj6+zcLFdojtMeAwE3b7Egqgz5nsBGuqewltKdpQvOHnCeg1+v6k D8oQ== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr2085884oeb.24.1356195176628; Sat, 22 Dec 2012 08:52:56 -0800 (PST) Received: by 10.76.12.134 with HTTP; Sat, 22 Dec 2012 08:52:56 -0800 (PST) X-Originating-IP: [74.198.150.161] In-Reply-To: References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> Date: Sat, 22 Dec 2012 08:52:56 -0800 Message-ID: From: Tim Bray To: Melvin Carvalho Content-Type: multipart/alternative; boundary=e89a8fb1f418bfbfd704d173cbf4 X-Gm-Message-State: ALoCoQmbb2h1Ptu4TIbxI5ZhdI8FSsEqC1+1w8SDNm8FRmSBUqx0Ko50pHHSTRiPeoHXKKJp3RJ9 Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:53:00 -0000 --e89a8fb1f418bfbfd704d173cbf4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've also wondered why we don't have application/webfinger+json; seems to me that having your own media-type is a strong Web best practice. Has this been discussed? -T On Sat, Dec 22, 2012 at 7:10 AM, Melvin Carvalho wrote: > > > On 21 December 2012 18:38, Paul E. Jones wrote: > >> Folks, >> >> I just posted a revised version of the WebFinger text. Highlights >> include: >> * Change all queries to require HTTPS only >> * Forbid server redirection to HTTP URIs >> * Merged the "Introduction" and "Overview" sections >> * Moved some references to the informative references section >> * Removed instructions for the server to return specific >> status codes (Tim successfully argued it was not needed) >> * Retained one statement, though, in section 4.2 that >> requires a server to return a 400. However, the >> text was changed to refer to behavior in RFC 2616. >> Same end result, though. >> * Moved section the "rel" parameter section before the >> JRD section. >> * Made edits to the JRD section as discussed on the list >> * Various editorial changes >> >> Please have a look at this text and suggest any changes we should make. >> > > This actually looks pretty good! > > Re: > > The media type used for the JSON Resource Descriptor (JRD) is "applicatio= n/json" > > Doesnt JRD have it's own content type? > > See Eran's comment: > > > http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-= 8122 > > "For now I=92m using application/json, but application/xrd+json is also > possible." > > Maybe something like application/jrd+json would be best? > > >> >> Paul >> >> > -----Original Message----- >> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> > Sent: Friday, December 21, 2012 12:21 PM >> > To: i-d-announce@ietf.org >> > Cc: apps-discuss@ietf.org >> > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.tx= t >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > This draft is a work item of the Applications Area Working Group >> > Working Group of the IETF. >> > >> > Title : WebFinger >> > Author(s) : Paul E. Jones >> > Gonzalo Salgueiro >> > Joseph Smarr >> > Filename : draft-ietf-appsawg-webfinger-08.txt >> > Pages : 20 >> > Date : 2012-12-21 >> > >> > Abstract: >> > This specification defines the WebFinger protocol, which can be use= d >> > to discover information about people or other entities on the >> > Internet using standard HTTP methods. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-08 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8fb1f418bfbfd704d173cbf4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've also wondered why we don't have application/webfinger+json; se= ems to me that having your own media-type is a strong Web best practice.=A0= Has this been discussed?=A0 -T

On Sat, D= ec 22, 2012 at 7:10 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:


On 21 Dec= ember 2012 18:38, Paul E. Jones <paulej@packetizer.com> = wrote:
Folks,

I just posted a revised version of the WebFinger text. =A0Highlights includ= e:
=A0* Change all queries to require HTTPS only
=A0* Forbid server redirection to HTTP URIs
=A0* Merged the "Introduction" and "Overview" sections<= br> =A0* Moved some references to the informative references section
=A0* Removed instructions for the server to return specific
=A0 =A0status codes (Tim successfully argued it was not needed)
=A0 =A0 * Retained one statement, though, in section 4.2 that
=A0 =A0 =A0 requires a server to return a 400. =A0However, the
=A0 =A0 =A0 text was changed to refer to behavior in RFC 2616.
=A0 =A0 =A0 Same end result, though.
=A0* Moved section the "rel" parameter section before the
=A0 =A0JRD section.
=A0* Made edits to the JRD section as discussed on the list
=A0* Various editorial changes

Please have a look at this text and suggest any changes we should make.
=

This actually looks pretty good!

Re:
T=
he media type used for the JSON Resource Descriptor (JRD) is "applicat=
ion/json"
Doesnt JRD have it's own content type?

See Eran's comment:
http://hueniverse.com/2010/05/jrd-th= e-other-resource-descriptor/#comment-8122

"For now I=92m using application/json, but application/xrd+json is= also possible."

Maybe something like application/jrd+json woul= d be best?
=A0

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org
> Sent: Friday, December 21, 2012 12:21 PM
> To: i-d-ann= ounce@ietf.org
> Cc: apps-di= scuss@ietf.org
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.tx= t
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =A0This draft is a work item of the Applications Area Working Group > Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : WebFinger
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joseph Smarr
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-webfinger-08.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-12-21
>
> Abstract:
> =A0 =A0This specification defines the WebFinger protocol, which can be= used
> =A0 =A0to discover information about people or other entities on the > =A0 =A0Internet using standard HTTP methods.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-w= ebfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-08
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8fb1f418bfbfd704d173cbf4-- From kidehen@openlinksw.com Sat Dec 22 10:46:38 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400D21F858C for ; Sat, 22 Dec 2012 10:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.983 X-Spam-Level: X-Spam-Status: No, score=0.983 tagged_above=-999 required=5 tests=[AWL=2.290, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgOCtUN-3wER for ; Sat, 22 Dec 2012 10:46:38 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id B63E121F84E3 for ; Sat, 22 Dec 2012 10:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:MIME-Version:From:Date:Message-ID; bh=NEgVO2jN76DqNsjecroHpHpQLmIDH4O4lPOxfCPiy0s=; b=mpJVoiCPbjxRvLRFURW+BTyMKSHn59TfPxfw0sqV4xNY9raE4RllWgg0KhLwh/tujmJhTHP3ZnvkrIxW67ibMyFM52n+9W6q4W+NcRXS6o/GZ+Ydz7Qj97BeYzVbnYO3; Received: from pool-173-48-165-129.bstnma.fios.verizon.net ([173.48.165.129] helo=macintosh-96.home) by mail.openlinksw.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1TmU5f-0003D2-SM; Sat, 22 Dec 2012 13:46:31 -0500 Message-ID: <50D60006.4050809@openlinksw.com> Date: Sat, 22 Dec 2012 13:46:30 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> <50D4E132.6070407@openlinksw.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090002030509070500090608" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 18:46:38 -0000 This is a cryptographically signed message in MIME format. --------------ms090002030509070500090608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/21/12 6:32 PM, Tim Bray wrote: > > Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/)=20 > has been repealed, these are instances of URIs, whose function per=20 > rfc3986 is to Identify resources. I don't see how it could be any clear= er. > > A good thing about WF is that it's just good basic Web stuff. No=20 > semantic castles in the sky required. > Look, we've long implemented Webfinger, Linked Data (see: DBpedia and=20 the LOD cloud), and very sophisticated stuff via those "semantic=20 castles". And guess what, it's all driven by a clear understanding that=20 URIs denote things. Anyway, I thought to share some guidance from our real world experience=20 re. service development and deployment, that's it. Other than that, we=20 already have Webfinger working in ways that simply amplify the=20 virtuosity of AWWW. --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms090002030509070500090608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjIyMTg0NjMwWjAjBgkqhkiG9w0BCQQxFgQU+1pL6iA+nkbKQdYQ FpEacmsjV1AwVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAN9aoGq3/Xp7g PUXYz2JgQ5fiQUqlPsezgCzXE61mp+8zbj087ZgWepKq6ruXXeMmZZAdw5zo0eeFVQh5+quP lom9KOoKKQSTkCTDw6p0XfodRpE5iDx3h6IENyMMDpT1aGRj7TN2zIFkSw3XUGlxdSw2aHM6 47okmOinnHHOG0qZd7eMIkjg+4534Fjg7wz3YqCaYE9LodyQyJGpGiMYBlOM67fIZjkibLia ohiQ6rXX6S3WR0Ok3+h2uDzW/iZy8WTqWGYWGdddW6OIofNe34mtmPoT0VtpfIup5EEFr265 GcIIAsw1Bj+3VbQG1U9HdtMxZcI2CiqzgFNdG+0TrgAAAAAAAA== --------------ms090002030509070500090608-- From kidehen@openlinksw.com Sat Dec 22 15:17:51 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEFD21F88C3 for ; Sat, 22 Dec 2012 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.697 X-Spam-Level: * X-Spam-Status: No, score=1.697 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnsjdLsZyP+f for ; Sat, 22 Dec 2012 15:17:49 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id B032F21F85C8 for ; Sat, 22 Dec 2012 15:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:MIME-Version:From:Date:Message-ID; bh=1+iTkM6D7vQkPKPwKAAIlnNNx0RDAM13IboWnzf+vZA=; b=ZUxmZ7k8UE3sK5xjr6UfJakCrY0XnCesmyR/Qrx1d1HqOl9b2hTWnW/UhH9j4o8N+SWYbv5eqKNUPiOGaYtFRCI6otTWAQv2pmfaNVXd3rF5aL0fvATVGG6fNyaD8nkx; Received: from pool-173-48-165-129.bstnma.fios.verizon.net ([173.48.165.129] helo=macintosh-96.home) by mail.openlinksw.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1TmYKB-00043b-IX; Sat, 22 Dec 2012 18:17:47 -0500 Message-ID: <50D63F9A.2000003@openlinksw.com> Date: Sat, 22 Dec 2012 18:17:46 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> <50D4CFEF.9030701@openlinksw.com> <50D4E132.6070407@openlinksw.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060300030006070209090609" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 23:17:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060300030006070209090609 Content-Type: multipart/alternative; boundary="------------000402090106030805040205" This is a multi-part message in MIME format. --------------000402090106030805040205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12/21/12 10:22 PM, Melvin Carvalho wrote: > > > On 22 December 2012 00:32, Tim Bray > wrote: > > Unless the Architecture of the WWW ( > http://www.w3.org/TR/webarch/) has been repealed, these are > instances of URIs, whose function per rfc3986 is to Identify > resources. I don't see how it could be any clearer. > > A good thing about WF is that it's just good basic Web stuff. No > semantic castles in the sky required. > > > Totally agree, but perhaps for a moment forget AWWW, which, in imho.=20 > is an incredible piece of work. > > A URI is simply a global variable. The benefit of a URI is that is it = > is constant between heterogeneous systems. Hence the Web. As Tim=20 > once said, "When you add global variables to some languages, they fall = > apart, when you add them to hypertext, you get The Web" > > There was one deep question discussed it the last decade, and that=20 > was: is it reasonably to divide a web page into a number of=20 > sections. And the decision (perhaps arbitrary) in AWWW, was, that yes = > it that would be reasonable. After much thought on the subject, I am = > also of the opinion that, that is a reasonably approach. > > Im not really sure it's about castles in the sky, but rather, that if = > different systems take an entitty/attribute/value approach with a=20 > global naming scheme (ie the URI) we can strongly foster interop, and=20 > grow the network effect for mutual benefit. Exactly! Thank You! Kingsley > > On Dec 21, 2012 2:22 PM, "Kingsley Idehen" > wrote: > > On 12/21/12 4:38 PM, Tim Bray wrote: >> No. The I in URI stands for Identifier. URIs identify >> resources, that's what they're for. -T > > I know the "I" stands for "Identifier" but these "Identifiers" > are being used to "denote" entities (things), in this context. > > This subtle tweak has also been adopted in the Semantic Web > discourse realm (note latest RDF specs [1]) as a mechanism for > adding clarity to the function or URIs. > > Links: > > 1. > http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.h= tml > -- see how denotation with regards to the function of URIs . > > Kingsley >> >> On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen >> > wrote= : >> >> >> Could this: >> >> WebFinger is used to discover information about people >> or other >> entities on the Internet that are identified by a URI >> [6] or IRI [7] >> using standard Hypertext Transfer Protocol (HTTP) [2] >> methods over a >> secure transport [14]. >> >> become: >> >> WebFinger is used to discover information about people >> or other >> entities on the Internet that are *denoted* by a URI >> [6] or IRI [7]. Actual information retrieval uses >> standard Hypertext Transfer Protocol (HTTP) [2] >> methods over a >> secure transport [14]. >> >> --=20 >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: >> https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> >> >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > > > --=20 > > Regards, > > Kingsley Idehen=09 > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/a= bout > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------000402090106030805040205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 12/21/12 10:22 PM, Melvin Carvalho wrote:


On 22 December 2012 00:32, Tim Bray <tbray@= textuality.com> wrote:

Unless the Architecture of the WWW ( ht= tp://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.

=

Totally agree, but perhaps for a moment forget AWWW, which, in imho. is an incredible piece of work.

A URI is simply a global variable.  The benefit of a URI i= s that is it is constant between heterogeneous systems.  Hen= ce the Web.  As Tim once said, "When you add global variables= to some languages, they fall apart, when you add them to hypertext, you get The Web"

There was one deep question discussed it the last decade, and that was:  is it reasonably to divide a web page into a nu= mber of sections.  And the decision (perhaps arbitrary) in AWWW= , was, that yes it that would be reasonable.   After much thought on the subject, I am also of the opinion that, that is a reasonably approach. 

 Im not really sure it's about castles in the sky, but rat= her, that if different systems take an entitty/attribute/value approach with a global naming scheme (ie the URI) we can strongly foster interop, and grow the network effect for mutual benefit.

Exactly!

Thank You!

Kingsley

 
On Dec 21, 2012 2:22 PM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
On 12/21/12 4:38 PM, Tim Bray wrote:
No. The I in URI stands for= Identifier. URIs identify resources, that’s w= hat they’re for. -T

I know the "I" stands for "Identifier" but these "Identifiers" are being used to "denote" entities (things), in this context.

This subtle tweak has also been adopted in the Semantic Web discourse realm (note latest RDF specs [1]) as a mechanism for adding clarity to the function or URIs.

Links:

1. http://dvcs.w3.org/hg/rdf/raw-fil= e/default/rdf-concepts/index.html -- see how denotation with regards to the function of URIs .

Kingsley

On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen <kidehen@openlinksw.com&= gt; wrote:

Could this:

 WebFinger is used to discover information= about people or other
   entities on the Internet that are identified by a URI [6] or IRI [7]
   using standard Hypertext Transfer = Protocol (HTTP) [2] methods over a
   secure transport [14].

become:

 WebFinger is used to discover information= about people or other
   entities on the Internet that are = *denoted* by a URI [6] or IRI [7]. Actual information retrieval uses
   standard Hypertext Transfer Protoc= ol (HTTP) [2] methods over a
   secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.c= om
Personal Weblog: http://www.openlinksw.c= om/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com= /112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com= /in/kidehen






_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailma= n/listinfo/webfinger




______________________________________________=
_
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfi=
nger



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~=
kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.co=
m/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen








_______________________________________________
webfinger mailing list
=
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger



--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767=
740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
--------------000402090106030805040205-- --------------ms060300030006070209090609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTIxMjIyMjMxNzQ2WjAjBgkqhkiG9w0BCQQxFgQUB+LG+DCQQih4+mkT lnLizb85ypcwVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZFUkl7nrprUA WtIHGGldguI9J0XdK2ff7K5wPUyLHq9co/OcbZLXY118u8eASbe1e4H8crv5lleBYQn1O1iI poC5mghV0yMMZkcigIzaMXBAEAk6j/cRLrvkS9BdzXIXy95RQKLkEG4r5xL/F4xk5bPsC2L2 usO/AUFfLcOxcTtxnhO4iAAfTfo5OPjGnCBQvWJUievfeedhJJCYDPhgpAlreEqp04aZIZmg MpJF3pf6rkEKn3HI2+AypzZAoiqdsNuKJ8ZhKB7C9PmytgM8YGJADiEGrFlr+ubHl6COh341 4VPsiQWhoNBJqtz2G3+YT9oQWdaT2wNQEL3gYZlbeQAAAAAAAA== --------------ms060300030006070209090609-- From paulej@packetizer.com Sat Dec 22 16:00:19 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F3221F894C for ; Sat, 22 Dec 2012 16:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxHStMenxzeo for ; Sat, 22 Dec 2012 16:00:17 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA3421F856C for ; Sat, 22 Dec 2012 16:00:16 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBN00Egn021546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 19:00:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356220815; bh=GL7IH9nQxu73Pow3lCD1FYgeFhCs8//PfhKNUwWY6ec=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=U910+U/+nc8Ro6L7va/bHlHBF8/dR/XjcZY6s1bRC4fE6XrC4Wy3VMhh4PbG4J9jh RUfNag/9Bwt/rgMQpMhUa703Ph+oCE+Lkh3dOjx8fvtbJ62Ek+GHw0dlaXMbIpFO8z ubXZYNE0bwAHq8/9K7w89P0CMRovu+NObvYFD6R4= From: "Paul E. Jones" To: "'nov matake'" , "'Melvin Carvalho'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> In-Reply-To: <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> Date: Sat, 22 Dec 2012 19:00:20 -0500 Message-ID: <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CDE076.97045A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowJLSGqcAkS0TYOXzMH2YA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 00:00:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01CDE076.97045A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If we made it a requirement that "rel" values have no spaces (which I would argue is a damn good thing for many reasons) then we would not have to double-encode. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" BTW, why double encoding lead "problems with things like canonical urls and search engines"? Can you provide more details? If 2 rel included, the response would be different than when only 1 rel given. So I feel those 2 are not the same, and can be indexed as 2 resources.. On 2012/12/23, at 0:44, Melvin Carvalho wrote: On 22 December 2012 05:48, nov matake wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in rails. Is the multiple "rel" case can be a space-delimitered (or some other character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the delimiter, which can be a pain and also leads to problems with things like canonical urls and search engines can you use mod_rewrite? Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0012_01CDE076.97045A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If we made it a requirement that “rel” values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of nov matake
Sent: Saturday, December 22, 2012 = 11:12 AM
To: Melvin Carvalho
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] feedback for = multiple "rel"

 

BTW, why = double encoding lead "problems with things like canonical urls and = search engines"?

Can you = provide more details?

 

If 2 rel included, the response would be different = than when only 1 rel given.

So I feel those 2 are not the same, and can be indexed = as 2 resources..

 

On = 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com>= wrote:



 

On 22 December 2012 05:48, nov matake <matake@gmail.com> wrote:

Hi,

I have a comment for they way to specify = multiple "rel" values.

As a ruby library developer, my = main target is rails developers.
Since rails can't handle multiple = same query keys, developers will need to hack query params parser in = rails middleware layer.
I can easily imagine it'll be an annoying = part to support webfinger in rails.

Is the multiple = "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2?
Or any = reason for putting multiple same keys in query = parameters?


each time you = delimit a list, you have to be able to escape the delimiter, which can = be a pain and also leads to problems with things like canonical urls and = search engines

can you use = mod_rewrite?
 


Cheers,

Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

 

------=_NextPart_000_0012_01CDE076.97045A20-- From paulej@packetizer.com Sat Dec 22 16:01:14 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFE921F894C for ; Sat, 22 Dec 2012 16:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSd5ZIT0s0TD for ; Sat, 22 Dec 2012 16:01:13 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 621A421F856C for ; Sat, 22 Dec 2012 16:01:13 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBN01BAW021616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 19:01:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356220872; bh=r08+gycZE56/zy/TK3agZ6hLOBJ84jPB8GTQ+isG7Sc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=RZ+zUIVQD8jGPTvjvgVGD8GcHgq9mZuqIrqAq5sYQtitravizfEbrqBXyKgQmVc0u FEvNObaIXtWNQ+K6OrMcGW4AWNPv4nJv6gSkUMhy9Jfr8WhAPTv3nNSxN4zv1RubqL PTTyDdYfrKCm4pOevZ9CXgRrDpN/uQdIKiTn/fEU= From: "Paul E. Jones" To: "'Melvin Carvalho'" , References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> In-Reply-To: Date: Sat, 22 Dec 2012 19:01:16 -0500 Message-ID: <001e01cde0a0$a1bbc8c0$e5335a40$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CDE076.B8E5C0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMz7gWtxLgac+I1n0R+LgHWh9rv+QCHcUCtAYIzeSmVSRQMAA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 00:01:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01CDE076.B8E5C0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, This actually looks pretty good! PEJ: Great! Re: The media type used for the JSON Resource Descriptor (JRD) is "application/json" Doesnt JRD have it's own content type? See Eran's comment: http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-812 2 "For now I'm using application/json, but application/xrd+json is also possible." Maybe something like application/jrd+json would be best? PEJ: Nothing has ever been defined and RFC 6415 says JRD is "application/json". Should somebody (note "somebody") define something specific for JRD? I didn't see any other +json definitions and I know people expressed concern with that previously (not related to WF). If we defined such a thing, it should either be application/jrd or application/jrd+json. Paul ------=_NextPart_000_001F_01CDE076.B8E5C0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

 

This actually looks pretty = good!

PEJ: Great!


Re:

The media type used for the =
JSON Resource Descriptor (JRD) is =
"application/json"

Doesnt = JRD have it's own content type?

See Eran's comment:

http://hueniverse.com/2010/05/jrd-the-other-resource-descri= ptor/#comment-8122

"For now I’m using = application/json, but application/xrd+json is also = possible."

Maybe something like application/jrd+json would = be best?

 

PEJ: Nothing has ever been defined and RFC 6415 says JRD is = “application/json”.  Should somebody (note = “somebody”) define something specific for JRD?  I = didn’t see any other +json definitions and I know people expressed = concern with that previously (not related to WF).  If we defined = such a thing, it should either be application/jrd or = application/jrd+json.

 

Paul

 

------=_NextPart_000_001F_01CDE076.B8E5C0C0-- From jasnell@gmail.com Sat Dec 22 16:51:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0894921F8A6A for ; Sat, 22 Dec 2012 16:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.672 X-Spam-Level: X-Spam-Status: No, score=-3.672 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqW0wwJjbKFg for ; Sat, 22 Dec 2012 16:51:25 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7721F8A64 for ; Sat, 22 Dec 2012 16:51:25 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so4990994iak.26 for ; Sat, 22 Dec 2012 16:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N8zWKnrzWMnp0zq1vNgfM3jetdKJqe9jBZRyKPSw1Sc=; b=Vx3Bk5A6nPX2+5GElvyhPHJnHxU8BLzJwrJlz4l0zxk2PI1btMCXl4xZ7V8Pu2KrN0 W8nhJL1QaO6hdTa/mzSZdguBgGMubYxfrYxWh8mvXUR249i9A3Kq+SB1pP7bD9FucdQ2 oXuvc5pi3s6CKXDhlc7mTKLwn7i3nuhgbdtFqfrM6eB+Y4TYtumkU9njlyuEM7nFFjX7 ikyYIDndxqUu+5AS6VxUpXtL4UrGBinMNwH6/EpZOLFUNEuIryOeeW7MkM4M6JWyd3sI C3BK+MaYuU9dz1DEo6LG4yQ7bymEAqiXu49n/aLgNsNX1KN614kGhDggFgTQvOvY5IpE rDQw== Received: by 10.42.58.202 with SMTP id j10mr14537334ich.39.1356223884692; Sat, 22 Dec 2012 16:51:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sat, 22 Dec 2012 16:51:04 -0800 (PST) In-Reply-To: <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> From: James M Snell Date: Sat, 22 Dec 2012 16:51:04 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf30334613e20c9c04d17a7ac2 Cc: "webfinger@ietf.org" , nov matake , Melvin Carvalho Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 00:51:26 -0000 --20cf30334613e20c9c04d17a7ac2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Spaces in rel values are already illegal.. specifically, spaces are disallowed in registered link relations and non-escaped spaces are disallowed in absolute IRI's.. A comma delimited list of rel's is better than multiple individual parameters.. even with the potential need for double encoding. On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones wrote= : > If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no spa= ces (which I > would argue is a damn good thing for many reasons) then we would not have > to double-encode.**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *nov matake > *Sent:* Saturday, December 22, 2012 11:12 AM > *To:* Melvin Carvalho > > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] feedback for multiple "rel"**** > > ** ** > > BTW, why double encoding lead "problems with things like canonical urls > and search engines"?**** > > Can you provide more details?**** > > ** ** > > If 2 rel included, the response would be different than when only 1 rel > given.**** > > So I feel those 2 are not the same, and can be indexed as 2 resources..**= * > * > > ** ** > > On 2012/12/23, at 0:44, Melvin Carvalho wrote:= * > *** > > > > **** > > ** ** > > On 22 December 2012 05:48, nov matake wrote:**** > > Hi, > > I have a comment for they way to specify multiple "rel" values. > > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will need t= o > hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in > rails. > > Is the multiple "rel" case can be a space-delimitered (or some other > character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters?**** > > > each time you delimit a list, you have to be able to escape the delimiter= , > which can be a pain and also leads to problems with things like canonical > urls and search engines > > can you use mod_rewrite? > **** > > > Cheers, > > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --20cf30334613e20c9c04d17a7ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Spaces in rel values= are already illegal.. specifically, spaces are disallowed in registered li= nk relations and non-escaped spaces are disallowed in absolute IRI's.. = A comma delimited list of rel's is better than multiple individual para= meters.. even with the potential need for double encoding.



On Sat, Dec 22, 2012 at 4:00 PM, Paul E. J= ones <paulej@packetizer.com> wrote:

If we made it= a requirement that =E2=80=9Crel=E2=80=9D values have no spaces (which I wo= uld argue is a damn good thing for many reasons) then we would not have to = double-encode.

=C2=A0

Paul<= /span>

=C2=A0

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = nov matake
Sent: Saturday, December 22, 2012 11:12 AM
To: Melvin Carv= alho


Cc: webfinger@ietf.org
Subject: Re: = [webfinger] feedback for multiple "rel"

=C2=A0

BTW, why double encoding lead "problems with things lik= e canonical urls and search engines"?

Can you provide more details?

=

=C2=A0

If 2 rel included, the response would be different than wh= en only 1 rel given.

So I feel those 2 are not the same, and c= an be indexed as 2 resources..

=C2=A0

On 2012/12/= 23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> wrote:



=C2=A0

On 22 December 2012 05:48, nov matake <matake@gmail.com> wrote:

Hi,

I have a comment for they way to specify = multiple "rel" values.

As a ruby library developer, my mai= n target is rails developers.
Since rails can't handle multiple same= query keys, developers will need to hack query params parser in rails midd= leware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimiter= ed (or some other character) strings like multiple redirect_uri in OAuth2?<= br> Or any reason for putting multiple same keys in query parameters?=


each time you delimit a list, you h= ave to be able to escape the delimiter, which can be a pain and also leads = to problems with things like canonical urls and search engines

can you use mod_rewrite?
=C2=A0


Cheers,
Nov Matake
_______________________________________________
webfinger = mailing list
web= finger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

=C2=A0

=C2=A0

<= /div>
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--20cf30334613e20c9c04d17a7ac2-- From paulej@packetizer.com Sat Dec 22 17:30:26 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4899521F8A7B for ; Sat, 22 Dec 2012 17:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdRTdTyDIC5i for ; Sat, 22 Dec 2012 17:30:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2905221F8886 for ; Sat, 22 Dec 2012 17:30:25 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBN1UMN2025274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 20:30:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356226223; bh=ZQpfSZdTjwr/oK1DdBSAQYdP+kEtqsOfBiB4ZlxRSJ4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=BODEUqz63+vvdmEPJ/6G6uagBMiSn2c7VMMppf0lez79w/dd+wf3DsrLKvMY3hEPr /Xbw3uBt91yQVMpP4w2VmPvAMb/5Cgfxyc7KUcXQBnwSkhM/LJDZmKj8Bontoyo+ND MaROtst8RTPeR6KEzyFjTdiqpPi2I5a6gVNTIEYw= From: "Paul E. Jones" To: "'James M Snell'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> In-Reply-To: Date: Sat, 22 Dec 2012 20:30:28 -0500 Message-ID: <004d01cde0ad$175b5d00$46121700$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01CDE083.2E868D80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowJLSGqcAkS0TYMBZO3SKgEqx9Vtl7hZJoA= Content-Language: en-us Cc: webfinger@ietf.org, 'nov matake' , 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 01:30:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004E_01CDE083.2E868D80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That depends on where they=E2=80=99re used. If I tell you the = =E2=80=9Crel=E2=80=9D value is =E2=80=9Chttp://example.com/first = one=E2=80=9D, I don=E2=80=99t escape that as I write it. Or are you = saying there is text somewhere that already makes that, as written, = illegal? =20 I=E2=80=99m quite favorable to a space-separated list of rel values in a = single rel parameter, too. I was concerned before that spaces would = present an issue, but figured we could either we make spaces illegal in = rel values (which we can do since those are fabricated things!) or we = double-escape. My preference is a single escape and a single rel = parameter and spaces are illegal in the =E2=80=9Crel=E2=80=9D values = themselves. =20 But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the = day, it makes no difference to me since I just need to know which way to = deal with it. =20 So Ruby can really only support only a single parameter with a given = name? It will not collect those into an array or anything? =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Saturday, December 22, 2012 7:51 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" =20 Spaces in rel values are already illegal.. specifically, spaces are = disallowed in registered link relations and non-escaped spaces are = disallowed in absolute IRI's.. A comma delimited list of rel's is better = than multiple individual parameters.. even with the potential need for = double encoding. =20 =20 =20 On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones = wrote: If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" =20 BTW, why double encoding lead "problems with things like canonical urls = and search engines"? Can you provide more details? =20 If 2 rel included, the response would be different than when only 1 rel = given. So I feel those 2 are not the same, and can be indexed as 2 resources.. =20 On 2012/12/23, at 0:44, Melvin Carvalho = wrote: =20 =20 On 22 December 2012 05:48, nov matake wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need = to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in = rails. Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines can you use mod_rewrite? =20 Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 ------=_NextPart_000_004E_01CDE083.2E868D80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

That depends on where they=E2=80=99re used.=C2=A0 If I tell you the = =E2=80=9Crel=E2=80=9D value is =E2=80=9Chttp://example.com/first = one=E2=80=9D, I don=E2=80=99t escape that as I write it.=C2=A0 Or are = you saying there is text somewhere that already makes that, as written, = illegal?

 

I=E2=80=99m quite favorable to a space-separated list of rel values = in a single rel parameter, too.=C2=A0 I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape.=C2=A0 My preference is a single escape and = a single rel parameter and spaces are illegal in the = =E2=80=9Crel=E2=80=9D values themselves.

 

But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2.=C2=A0 = At the end of the day, it makes no difference to me since I just need to = know which way to deal with it.

 

So Ruby can really only support only a single parameter with a given = name?=C2=A0 It will not collect those into an array or = anything?

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, = December 22, 2012 7:51 PM
To: Paul E. Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org
Subject: Re: = [webfinger] feedback for multiple = "rel"

 

Spaces in rel values are already = illegal.. specifically, spaces are disallowed in registered link = relations and non-escaped spaces are disallowed in absolute IRI's.. A = comma delimited list of rel's is better than multiple individual = parameters.. even with the potential need for double = encoding.

 

 

 

On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = nov matake
Sent: Saturday, December 22, 2012 11:12 = AM
To: Melvin Carvalho


Cc: webfinger@ietf.org
Subject: Re: = [webfinger] feedback for multiple = "rel"

 <= /o:p>

BTW, why = double encoding lead "problems with things like canonical urls and = search engines"?

Can you = provide more details?

 <= /o:p>

If 2 rel = included, the response would be different than when only 1 rel = given.

So I feel = those 2 are not the same, and can be indexed as 2 = resources..

 <= /o:p>

On = 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:

 <= /p>

 <= /p>

On 22 = December 2012 05:48, nov matake <matake@gmail.com> wrote:

Hi,

I= have a comment for they way to specify multiple "rel" = values.

As a ruby library developer, my main target is rails = developers.
Since rails can't handle multiple same query keys, = developers will need to hack query params parser in rails middleware = layer.
I can easily imagine it'll be an annoying part to support = webfinger in rails.

Is the multiple "rel" case can be a = space-delimitered (or some other character) strings like multiple = redirect_uri in OAuth2?
Or any reason for putting multiple same keys = in query parameters?


each = time you delimit a list, you have to be able to escape the delimiter, = which can be a pain and also leads to problems with things like = canonical urls and search engines

can you use = mod_rewrite?
 


Cheers,<= br>
Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 <= /o:p>

 <= /o:p>


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_004E_01CDE083.2E868D80-- From dick.hardt@gmail.com Sat Dec 22 17:39:58 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CB21F8802 for ; Sat, 22 Dec 2012 17:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBXgCBkQEh54 for ; Sat, 22 Dec 2012 17:39:58 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5B21F8797 for ; Sat, 22 Dec 2012 17:39:57 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id um15so3418139pbc.16 for ; Sat, 22 Dec 2012 17:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=F1waLTLovyXOxApsUapWBAMAOG2MjlosVSSS6LWJy1Q=; b=Df4UDZSY/B7qhUwUnOSbZcHBi5A4bpetErrBhhWif3b/JVghmNp+pAQ4b5ZgFtZVFT IHRT6ShazRSw+OwFAn8RDLGvcpXKG1NvsjzGk+KZ0vPdaeHyUvnT3JB6S5NTy2F5ukM7 PKfkvRxjqu5Mx8wbfXattQ+mHPzqbW5EBly4ZikxuF6/VCRF2fii8LHsxwftMsn/Lqd+ NWe0nphHdnzTd1AuIfErE7T/+CDt7AAkaBECYGQUoGhzktydV30SDqsLx+lyfLWWJEg2 yBsnLOazBKGlnJo9oknMH19kNqIcGTsgw3ij70RRPURqYPokgIboMkbb0SQXx8OWzCCs bjJw== X-Received: by 10.66.78.168 with SMTP id c8mr50466194pax.16.1356226794029; Sat, 22 Dec 2012 17:39:54 -0800 (PST) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rq7sm9651325pbc.69.2012.12.22.17.39.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 17:39:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED55068D-24CA-4B2D-9091-058D82CD29CF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <004d01cde0ad$175b5d00$46121700$@packetizer.com> Date: Sat, 22 Dec 2012 17:39:49 -0800 Message-Id: <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, 'James M Snell' , 'nov matake' , 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 01:39:59 -0000 --Apple-Mail=_ED55068D-24CA-4B2D-9091-058D82CD29CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI: multiple query string params with the same name are turned into = arrays or parsed into arrays in node.js the following script: var querystring =3D require('querystring') console.log( querystring.parse( 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) = ) console.log( querystring.stringify( = {'foo':'bar','rel':['token1','token2']} ) ) outputs: { foo: 'bar', rel: [ 'token1', 'token2' ] } foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2 Perhaps Ruby devs should just move to the next cool language? :-) Seriously though, what does the query string parser do in Ruby? -- Dick On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" = wrote: > That depends on where they=92re used. If I tell you the =93rel=94 = value is =93http://example.com/first one=94, I don=92t escape that as I = write it. Or are you saying there is text somewhere that already makes = that, as written, illegal? > =20 > I=92m quite favorable to a space-separated list of rel values in a = single rel parameter, too. I was concerned before that spaces would = present an issue, but figured we could either we make spaces illegal in = rel values (which we can do since those are fabricated things!) or we = double-escape. My preference is a single escape and a single rel = parameter and spaces are illegal in the =93rel=94 values themselves. > =20 > But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the = day, it makes no difference to me since I just need to know which way to = deal with it. > =20 > So Ruby can really only support only a single parameter with a given = name? It will not collect those into an array or anything? > =20 > Paul > =20 > From: James M Snell [mailto:jasnell@gmail.com]=20 > Sent: Saturday, December 22, 2012 7:51 PM > To: Paul E. Jones > Cc: nov matake; Melvin Carvalho; webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > Spaces in rel values are already illegal.. specifically, spaces are = disallowed in registered link relations and non-escaped spaces are = disallowed in absolute IRI's.. A comma delimited list of rel's is better = than multiple individual parameters.. even with the potential need for = double encoding. > =20 > =20 > =20 >=20 > On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones = wrote: > If we made it a requirement that =93rel=94 values have no spaces = (which I would argue is a damn good thing for many reasons) then we = would not have to double-encode. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Saturday, December 22, 2012 11:12 AM > To: Melvin Carvalho >=20 > Cc: webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > BTW, why double encoding lead "problems with things like canonical = urls and search engines"? > Can you provide more details? > =20 > If 2 rel included, the response would be different than when only 1 = rel given. > So I feel those 2 are not the same, and can be indexed as 2 = resources.. > =20 > On 2012/12/23, at 0:44, Melvin Carvalho = wrote: > =20 >=20 > =20 >=20 > On 22 December 2012 05:48, nov matake wrote: > Hi, >=20 > I have a comment for they way to specify multiple "rel" values. >=20 > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will = need to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in = rails. >=20 > Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? >=20 > each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines >=20 > can you use mod_rewrite? > =20 >=20 > Cheers, >=20 > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > =20 > =20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_ED55068D-24CA-4B2D-9091-058D82CD29CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 FYI: multiple query string = params with the same name are turned into arrays or parsed into arrays = in node.js

the following = script:

var querystring =3D = require('querystring')
console.log( querystring.parse( = 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) )
console.log( = querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) = )

outputs:

{ foo: = 'bar', rel: [ 'token1', 'token2' ] = }
foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2
Perhaps Ruby devs should just move to the next cool = language? :-)
Seriously though, what does the query string = parser do in Ruby?

-- = Dick

On Dec 22, 2012, at 5:30 PM, "Paul E. = Jones" <paulej@packetizer.com> = wrote:

That depends on where = they=92re used.  If I tell you the =93rel=94 value is =93http://example.com/first one=94, I don=92t escape = that as I write it.  Or are you saying there is text somewhere that = already makes that, as written, illegal?
 
I=92m quite favorable to = a space-separated list of rel values in a single rel parameter, = too.  I was concerned before that spaces would present an issue, = but figured we could either we make spaces illegal in rel values (which = we can do since those are fabricated things!) or we double-escape.  = My preference is a single escape and a single rel parameter and spaces = are illegal in the =93rel=94 values = themselves.
 
But, the forces that be pushed pretty hard to = change from &rel=3Dtoken1%20token to = &rel=3Dtoken1&rel=3Dtoken2.  At the end of the day, it = makes no difference to me since I just need to know which way to deal = with it.
 
So Ruby can really only support only a single = parameter with a given name?  It will not collect those into an = array or anything?
 
Paul
 
From: James M Snell = [mailto:jasnell@gmail.com] 
Sent: Saturday, December 22, 2012 = 7:51 PM
To: Paul E. = Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org
Subject: Re: [webfinger] = feedback for multiple "rel"
 
Spaces in rel = values are already illegal.. specifically, spaces are disallowed in = registered link relations and non-escaped spaces are disallowed in = absolute IRI's.. A comma delimited list of rel's is better than multiple = individual parameters.. even with the potential need for double = encoding.
 

On = Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> = wrote:
If we made it a requirement that =93rel=94 values = have no spaces (which I would argue is a damn good thing for many = reasons) then we would not have to = double-encode.
 
 

On 22 December = 2012 05:48, nov matake <Hi,

I have a comment for they way to specify multiple = "rel" values.

As a ruby library developer, my main target is = rails developers.
Since rails can't handle multiple same query keys, = developers will need to hack query params parser in rails middleware = layer.
I can easily imagine it'll be an annoying part to support = webfinger in rails.

Is the multiple "rel" case can be a = space-delimitered (or some other character) strings like multiple = redirect_uri in OAuth2?
Or any reason for putting multiple same keys = in query parameters?


= --Apple-Mail=_ED55068D-24CA-4B2D-9091-058D82CD29CF-- From jasnell@gmail.com Sat Dec 22 17:43:09 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066D821F8797 for ; Sat, 22 Dec 2012 17:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk+hZ1CQ-OTr for ; Sat, 22 Dec 2012 17:43:07 -0800 (PST) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0021F8802 for ; Sat, 22 Dec 2012 17:43:07 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id r4so5195737iaj.0 for ; Sat, 22 Dec 2012 17:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zzJFGsjy3JfcIxugUyAI2prxSKM+PHprm06D+FES3UU=; b=NbMCiMaKTqJx8hNOE98OqYEScmmskQ0/65ljHCdEBbtoRILGDjYV+/rnIn5vkWyGO8 SaKS02FPASESXj8N9mjIe0J2CnZUs4YBigDG/cz9lXqHUDR9ZfMUwDlsEK2nzWuLUF5y X0CiUaEsWc7G5sCw+0cKJgwOL8gRHPm8K3MP7fcVesFAQCPcL3ADray9iLRZrRoFNSil JUkKp7VnkQv+WyQ0TOIa2FYRNyFQGY9H2oX0JOa3jbvRsSwR6R9sEKAV3Mi/GtMY29i/ UYqY8M8o6qFMiI48uhdsv1JlildtzkwQ697Ox0SCRXBAZa9UnDVNUp8t+tnai7/F4u5u MjNw== Received: by 10.42.32.71 with SMTP id c7mr15029510icd.35.1356226986987; Sat, 22 Dec 2012 17:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sat, 22 Dec 2012 17:42:46 -0800 (PST) In-Reply-To: <004d01cde0ad$175b5d00$46121700$@packetizer.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> From: James M Snell Date: Sat, 22 Dec 2012 17:42:46 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec517cda8cb51a904d17b3398 Cc: "webfinger@ietf.org" , nov matake , Melvin Carvalho Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 01:43:09 -0000 --bcaec517cda8cb51a904d17b3398 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2012 at 5:30 PM, Paul E. Jones wrote= : > That depends on where they=E2=80=99re used. If I tell you the =E2=80=9Cr= el=E2=80=9D value is =E2=80=9C > http://example.com/first one=E2=80=9D, I don=E2=80=99t escape that as I w= rite it. Or are > you saying there is text somewhere that already makes that, as written, > illegal?**** > > ** > Yes. RFC 3987. That is, so long as the character separating the "first" and the "one" is an ASCII Space (0x20). IRI's allow for a range of space-like characters, such as a nonbreaking space (0xA0) but strongly recommends that those be pct-encoded. Whitespace of any type is explicitly disallowed in URI's. > ** > > I=E2=80=99m quite favorable to a space-separated list of rel values in a = single > rel parameter, too. I was concerned before that spaces would present an > issue, but figured we could either we make spaces illegal in rel values > (which we can do since those are fabricated things!) or we double-escape. > My preference is a single escape and a single rel parameter and spaces ar= e > illegal in the =E2=80=9Crel=E2=80=9D values themselves. > Double-escaping is really a separate issue, as there may be lots of reasons why escaping is used, not just whitespace. Best to just treat that as a separate issue. Just say that the link rels are a list of 0x20 separated values and that the 0x20 must be pct-encoded, and go with that.. e.g. http://example.org/.well-known/webfinger?resource=3Dacct:foo&rel=3Dabc%20de= f%20http://example.org/foo Would be rel=3D["abc","def","http://example.org/foo"] All done. - James > **** > > ** ** > > But, the forces that be pushed pretty hard to change from > &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the d= ay, it > makes no difference to me since I just need to know which way to deal wit= h > it.**** > > ** ** > > So Ruby can really only support only a single parameter with a given > name? It will not collect those into an array or anything?**** > > ** ** > > Paul**** > > ** ** > > *From:* James M Snell [mailto:jasnell@gmail.com] > *Sent:* Saturday, December 22, 2012 7:51 PM > *To:* Paul E. Jones > *Cc:* nov matake; Melvin Carvalho; webfinger@ietf.org > > *Subject:* Re: [webfinger] feedback for multiple "rel"**** > > ** ** > > Spaces in rel values are already illegal.. specifically, spaces are > disallowed in registered link relations and non-escaped spaces are > disallowed in absolute IRI's.. A comma delimited list of rel's is better > than multiple individual parameters.. even with the potential need for > double encoding.**** > > ** ** > > ** ** > > ** ** > > On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones > wrote:**** > > If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no spa= ces (which I > would argue is a damn good thing for many reasons) then we would not have > to double-encode.**** > > **** > > Paul**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *nov matake > *Sent:* Saturday, December 22, 2012 11:12 AM > *To:* Melvin Carvalho**** > > > *Cc:* webfinger@ietf.org > *Subject:* Re: [webfinger] feedback for multiple "rel"**** > > **** > > BTW, why double encoding lead "problems with things like canonical urls > and search engines"?**** > > Can you provide more details?**** > > **** > > If 2 rel included, the response would be different than when only 1 rel > given.**** > > So I feel those 2 are not the same, and can be indexed as 2 resources..**= * > * > > **** > > On 2012/12/23, at 0:44, Melvin Carvalho wrote:= * > *** > > ** ** > > **** > > On 22 December 2012 05:48, nov matake wrote:**** > > Hi, > > I have a comment for they way to specify multiple "rel" values. > > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will need t= o > hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in > rails. > > Is the multiple "rel" case can be a space-delimitered (or some other > character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters?**** > > > each time you delimit a list, you have to be able to escape the delimiter= , > which can be a pain and also leads to problems with things like canonical > urls and search engines > > can you use mod_rewrite? > **** > > > Cheers, > > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > **** > > **** > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --bcaec517cda8cb51a904d17b3398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Dec 22, 2012 at= 5:30 PM, Paul E. Jones <paulej@packetizer.com> wrote:

That depends = on where they=E2=80=99re used.=C2=A0 If I tell you the =E2=80=9Crel=E2=80= =9D value is =E2=80=9Chttp://example.com/first one=E2=80=9D, I don=E2=80=99t escape that as= I write it.=C2=A0 Or are you saying there is text somewhere that already m= akes that, as written, illegal?

=C2=A0

<= /div>

Yes. RFC 3987. That is, s= o long as the character separating the "first" and the "one&= quot; is an ASCII Space (0x20). IRI's allow for a range of space-like c= haracters, such as a nonbreaking space (0xA0) but strongly recommends that = those be pct-encoded. Whitespace of any type is explicitly disallowed in UR= I's.
=C2=A0

I=E2=80=99m quite favorab= le to a space-separated list of rel values in a single rel parameter, too.= =C2=A0 I was concerned before that spaces would present an issue, but figur= ed we could either we make spaces illegal in rel values (which we can do si= nce those are fabricated things!) or we double-escape.=C2=A0 My preference = is a single escape and a single rel parameter and spaces are illegal in the= =E2=80=9Crel=E2=80=9D values themselves.


Double-escaping is reall= y a separate issue, as there may be lots of reasons why escaping is used, n= ot just whitespace. Best to just treat that as a separate issue. Just say t= hat the link rels are a list of 0x20 separated values and that the 0x20 mus= t be pct-encoded, and go with that.. e.g.=C2=A0


Would be rel=3D["abc","def&q= uot;,"http://example.org/foo&qu= ot;]

All done.

- James
=C2=A0

=C2=A0

But, the forces tha= t be pushed pretty hard to change from &rel=3Dtoken1%20token to &re= l=3Dtoken1&rel=3Dtoken2.=C2=A0 At the end of the day, it makes no diffe= rence to me since I just need to know which way to deal with it.<= /u>

=C2=A0

So Ruby can really = only support only a single parameter with a given name?=C2=A0 It will not c= ollect those into an array or anything?

=C2=A0

Paul<= /span>

=C2=A0

From: James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, December 22, 2012 7:51 PM
To: Paul E. Jone= s
Cc: nov matake; Melvin Carvalho; webfinger@ietf.org


Subject: Re: [webfinger] feedback for multiple "rel"

=C2=A0

Spaces in rel values are alread= y illegal.. specifically, spaces are disallowed in registered link relation= s and non-escaped spaces are disallowed in absolute IRI's.. A comma del= imited list of rel's is better than multiple individual parameters.. ev= en with the potential need for double encoding.

=C2=A0

=C2=A0

=C2=A0

On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> wr= ote:

If we made it a= requirement that =E2=80=9Crel=E2=80=9D values have no spaces (which I woul= d argue is a damn good thing for many reasons) then we would not have to do= uble-encode.

=C2=A0

Paul<= u>

=C2=A0

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = nov matake
Sent: Saturday, December 22, 2012 11:12 AM
To: Melvin Carv= alho


Cc: webfinger@ietf.org=
Subject: Re: [webfinger] feedback for multiple "rel"

=C2=A0

BTW, why double encoding lead "problems with = things like canonical urls and search engines"?

Can you provide more details?<= u>

=C2=A0

<= div>

If 2 rel included, the response would be differe= nt than when only 1 rel given.

So I feel those 2 are not the same, and c= an be indexed as 2 resources..

=C2=A0

On 2012/12/= 23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

=C2=A0

=C2=A0

On 22 December 2012 05:48, nov mata= ke <matake@gmail.c= om> wrote:

Hi,

I have a comment for they way to specify = multiple "rel" values.

As a ruby library developer, my mai= n target is rails developers.
Since rails can't handle multiple same= query keys, developers will need to hack query params parser in rails midd= leware layer.
I can easily imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimiter= ed (or some other character) strings like multiple redirect_uri in OAuth2?<= br> Or any reason for putting multiple same keys in query parameters?=


each time you delimit a list, you h= ave to be able to escape the delimiter, which can be a pain and also leads = to problems with things like canonical urls and search engines

can you use mod_rewrite?
=C2=A0


Cheers,

Nov Matake
__________________________________________= _____
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/l= istinfo/webfinger

=C2=A0

=C2=A0

<= /div>


____________= ___________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/w= ebfinger

=C2=A0


--bcaec517cda8cb51a904d17b3398-- From paulej@packetizer.com Sat Dec 22 18:13:59 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAB421F8555 for ; Sat, 22 Dec 2012 18:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDNVaPi46j6L for ; Sat, 22 Dec 2012 18:13:56 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE2121F84F5 for ; Sat, 22 Dec 2012 18:13:56 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBN2DrZU027012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 21:13:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356228834; bh=cszupNXxCxrBHJCO5vw3CY2wncxhcxgugR2TzS0N/vs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Z+XEg11/UQHb1tUfmwVrEPAYSG4QcSoyvVHN9mSvijb7mpJnZIiKl9PuSqu6T8ise EJ6wg8zGhUvo8sYtHGWvrN1FcNxdo4qmpbWH5yiCyvfYiWX7q9H8Z1Fm+1VnGXXt09 2i0gZJF1TfI2d5Ql0UYqH0ZRBg7DFN0otbImRSAc= From: "Paul E. Jones" To: "'Dick Hardt'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> In-Reply-To: <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> Date: Sat, 22 Dec 2012 21:13:59 -0500 Message-ID: <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01CDE089.42E64120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowJLSGqcAkS0TYMBZO3SKgEqx9VtAUuOMU8BofJMGJeg/AdA Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , 'nov matake' , 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 02:13:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01CDE089.42E64120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dick, Nov, I've never written a Ruby program before, but I was quite curious as to whether it was or was not possible to access multiple "rel" parameters. It appears that is. Here's my first Ruby program (and my apologies to the developers of Ruby): #!/bin/ruby require 'cgi' cgi = CGI.new params = cgi.params # Following appears to show an associative array with values that are arrays puts params; # Grab the 'rel' array rels = params['rel']; # Display the array puts rels; # How many items are in the "rel" array? count = rels.size print "Number of rel params: ", count, "\n"; # Can I access each one? for i in 0..(count-1) print "Item ", i, ": ", rels[i], "\n" end Here's what I get: $ ./test "rel=rel1&c=d&rel=rel2&e=f" {"rel"=>["rel1", "rel2"], "c"=>["d"], "e"=>["f"]} rel1 rel2 Number of rel params: 2 Item 0: rel1 Item 1: rel2 So, it looks like it works to me. Is the issue only with Rails? I'm not going to venture down that path to see what the issue is, but if Ruby can access the data, can't it provide it to Rails in a form that it likes? Paul From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Saturday, December 22, 2012 8:40 PM To: Paul E. Jones Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" FYI: multiple query string params with the same name are turned into arrays or parsed into arrays in node.js the following script: var querystring = require('querystring') console.log( querystring.parse( 'foo=bar&rel=token1&rel=token2' ) ) console.log( querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) ) outputs: { foo: 'bar', rel: [ 'token1', 'token2' ] } foo=bar&rel=token1&rel=token2 Perhaps Ruby devs should just move to the next cool language? :-) Seriously though, what does the query string parser do in Ruby? -- Dick On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" wrote: That depends on where they're used. If I tell you the "rel" value is " http://example.com/first one", I don't escape that as I write it. Or are you saying there is text somewhere that already makes that, as written, illegal? I'm quite favorable to a space-separated list of rel values in a single rel parameter, too. I was concerned before that spaces would present an issue, but figured we could either we make spaces illegal in rel values (which we can do since those are fabricated things!) or we double-escape. My preference is a single escape and a single rel parameter and spaces are illegal in the "rel" values themselves. But, the forces that be pushed pretty hard to change from &rel=token1%20token to &rel=token1&rel=token2. At the end of the day, it makes no difference to me since I just need to know which way to deal with it. So Ruby can really only support only a single parameter with a given name? It will not collect those into an array or anything? Paul From: James M Snell [mailto:jasnell@gmail.com] Sent: Saturday, December 22, 2012 7:51 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" Spaces in rel values are already illegal.. specifically, spaces are disallowed in registered link relations and non-escaped spaces are disallowed in absolute IRI's.. A comma delimited list of rel's is better than multiple individual parameters.. even with the potential need for double encoding. On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones < paulej@packetizer.com> wrote: If we made it a requirement that "rel" values have no spaces (which I would argue is a damn good thing for many reasons) then we would not have to double-encode. Paul From: webfinger-bounces@ietf.org [mailto: webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" BTW, why double encoding lead "problems with things like canonical urls and search engines"? Can you provide more details? If 2 rel included, the response would be different than when only 1 rel given. So I feel those 2 are not the same, and can be indexed as 2 resources.. On 2012/12/23, at 0:44, Melvin Carvalho < melvincarvalho@gmail.com> wrote: On 22 December 2012 05:48, nov matake < matake@gmail.com> wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in rails. Is the multiple "rel" case can be a space-delimitered (or some other character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the delimiter, which can be a pain and also leads to problems with things like canonical urls and search engines can you use mod_rewrite? Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0067_01CDE089.42E64120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dick, Nov,

 

I’ve never written a Ruby program before, but I was quite = curious as to whether it was or was not possible to access multiple = “rel” parameters.  It appears that is.  = Here’s my first Ruby program (and my apologies to the developers = of Ruby):

 

#!/bin/ruby

 

require 'cgi'

 

cgi = =3D CGI.new

 

params = =3D cgi.params

 

# = Following appears to show an associative array with values that are = arrays

puts = params;

 

# Grab = the 'rel' array

rels = =3D params['rel'];

 

# = Display the array

puts = rels;

 

# How = many items are in the "rel" array?

count = =3D rels.size

print = "Number of rel params: ", count, = "\n";

 

# Can = I access each one?

for i = in 0..(count-1)

   print "Item ", i, ": = ", rels[i], "\n"

end

 

Here’s what I get:

 

$ = ./test = "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df"

{"rel"=3D>["rel1", = "rel2"], "c"=3D>["d"], = "e"=3D>["f"]}

rel1

rel2

Number = of rel params: 2

Item = 0: rel1

Item = 1: rel2

 

So, it looks like it works to me.  Is the issue only with = Rails?  I’m not going to venture down that path to see what = the issue is, but if Ruby can access the data, can’t it provide it = to Rails in a form that it likes?

 

Paul

 

From:= = Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Saturday, = December 22, 2012 8:40 PM
To: Paul E. Jones
Cc: = 'James M Snell'; webfinger@ietf.org; 'nov matake'; 'Melvin = Carvalho'
Subject: Re: [webfinger] feedback for multiple = "rel"

 

FYI: = multiple query string params with the same name are turned into arrays = or parsed into arrays in node.js

 

the following script:

 

var querystring =3D = require('querystring')

console.log( querystring.parse( = 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) = )

console.log( = querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) = )

 

outputs:

 

{ foo: 'bar', rel: [ 'token1', 'token2' ] = }

foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2<= /p>

 

Perhaps Ruby devs should just move to the next cool = language? :-)

Seriously = though, what does the query string parser do in = Ruby?

 

-- Dick

 

On = Dec 22, 2012, at 5:30 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:



That depends on where they’re used.  If I tell you the = “rel” value is “http://example.com/first one”, I don’t = escape that as I write it.  Or are you saying there is text = somewhere that already makes that, as written, = illegal?

 

I’m quite favorable to a space-separated list of rel values in = a single rel parameter, too.  I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape.  My preference is a single escape and = a single rel parameter and spaces are illegal in the “rel” = values themselves.

 

But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2.  = At the end of the day, it makes no difference to me since I just need to = know which way to deal with it.

 

So Ruby can really only support only a single parameter with a given = name?  It will not collect those into an array or = anything?

 

Paul

 

From:=  James M = Snell [mailto:jasnell@gmail.com] 
Sent: Saturday, December 22, 2012 = 7:51 PM
To: Paul E. = Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org
Subject:<= /b> Re: [webfinger] = feedback for multiple = "rel"

 

Spaces in = rel values are already illegal.. specifically, spaces are disallowed in = registered link relations and non-escaped spaces are disallowed in = absolute IRI's.. A comma delimited list of rel's is better than multiple = individual parameters.. even with the potential need for double = encoding.

 

 

 

On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

If we made it a requirement that “rel” values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode.

 

Paul

 

From:=  webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Saturday, December 22, 2012 = 11:12 AM
To: Melvin = Carvalho


Cc: webfinger@ietf.org
Subject: Re: [webfinger] feedback = for multiple = "rel"

 

BTW, why double encoding lead "problems with = things like canonical urls and search = engines"?

Can you provide more = details?

 

If 2 rel included, the response would be different = than when only 1 rel given.

So I feel those 2 are not the same, and can be indexed = as 2 resources..

 

On 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:

 

 

On 22 December 2012 05:48, nov matake <matake@gmail.com> = wrote:

Hi,

I have a = comment for they way to specify multiple "rel" = values.

As a ruby library developer, my main target is rails = developers.
Since rails can't handle multiple same query keys, = developers will need to hack query params parser in rails middleware = layer.
I can easily imagine it'll be an annoying part to support = webfinger in rails.

Is the multiple "rel" case can be a = space-delimitered (or some other character) strings like multiple = redirect_uri in OAuth2?
Or any reason for putting multiple same keys = in query parameters?


each time you delimit a list, you have to be able = to escape the delimiter, which can be a pain and also leads to problems = with things like canonical urls and search engines

can you use = mod_rewrite?
 


Cheers,

Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

_________= ______________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf= .org/mailman/listinfo/webfinger

 

------=_NextPart_000_0067_01CDE089.42E64120-- From paulej@packetizer.com Sat Dec 22 18:32:35 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A2D21F8A92 for ; Sat, 22 Dec 2012 18:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyG-euazOiGr for ; Sat, 22 Dec 2012 18:32:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A51DA21F8A8C for ; Sat, 22 Dec 2012 18:32:33 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qBN2WVgZ027790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Dec 2012 21:32:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1356229952; bh=+zj3VgvuUPixkfEFGux7vjCwp4T6c0TM6bCrOmcm4aQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=hqhMazyjZuUNAof+khUv+nM6YmsZMckOdmu753DQozHAp8zDBKZyFZkqgrYOew1y8 YB2q1k8bGxAa/IXLC0bOFbd5LWlGeIvDHA4bvvEwqbCNMbhAy6oFxNwlHyk2km4pOt oPi7xT6yCTpqPHr3igtdBFG5Z1if5orxeDVt4dM0= From: "Paul E. Jones" To: "'James M Snell'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> In-Reply-To: Date: Sat, 22 Dec 2012 21:32:36 -0500 Message-ID: <007901cde0b5$c5c88e50$5159aaf0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01CDE08B.DCF43400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowJLSGqcAkS0TYMBZO3SKgEqx9VtAUuOMU8C2FEmM5eXTt5A Content-Language: en-us Cc: webfinger@ietf.org, 'nov matake' , 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 02:32:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007A_01CDE08B.DCF43400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Indeed=E2=80=A6 RFC 3986 also shows that spaces must be percent-encoded = before they are considered a valid URI. =20 Anyway, I=E2=80=99m open to going either way. The -02 draft said = described a single =E2=80=9Crel=E2=80=9D parameters as = =E2=80=9Cspace-separated list of link relations=E2=80=9D. Of course, = that would be escaped before being put into a GET=E2=80=A6 that goes = without saying, really. =20 Which way do folks want it? I recall arguing to keep it this way = before, but I was successfully pushed to change it. =20 We might have to wait a bit for folks to reply given this is the weekend = and a holiday weekend, at that. =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Saturday, December 22, 2012 8:43 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" =20 =20 =20 On Sat, Dec 22, 2012 at 5:30 PM, Paul E. Jones = wrote: That depends on where they=E2=80=99re used. If I tell you the = =E2=80=9Crel=E2=80=9D value is =E2=80=9Chttp://example.com/first = one=E2=80=9D, I don=E2=80=99t escape that as I write it. Or are you = saying there is text somewhere that already makes that, as written, = illegal? =20 =20 Yes. RFC 3987. That is, so long as the character separating the "first" = and the "one" is an ASCII Space (0x20). IRI's allow for a range of = space-like characters, such as a nonbreaking space (0xA0) but strongly = recommends that those be pct-encoded. Whitespace of any type is = explicitly disallowed in URI's. =20 I=E2=80=99m quite favorable to a space-separated list of rel values in a = single rel parameter, too. I was concerned before that spaces would = present an issue, but figured we could either we make spaces illegal in = rel values (which we can do since those are fabricated things!) or we = double-escape. My preference is a single escape and a single rel = parameter and spaces are illegal in the =E2=80=9Crel=E2=80=9D values = themselves. =20 Double-escaping is really a separate issue, as there may be lots of = reasons why escaping is used, not just whitespace. Best to just treat = that as a separate issue. Just say that the link rels are a list of 0x20 = separated values and that the 0x20 must be pct-encoded, and go with = that.. e.g.=20 =20 http://example.org/.well-known/webfinger?resource=3Dacct:foo = &rel=3Dabc%20def%20http://example.org/foo =20 Would be rel=3D["abc","def","http://example.org/foo"] =20 All done. =20 - James =20 =20 But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the = day, it makes no difference to me since I just need to know which way to = deal with it. =20 So Ruby can really only support only a single parameter with a given = name? It will not collect those into an array or anything? =20 Paul =20 From: James M Snell [mailto:jasnell@gmail.com]=20 Sent: Saturday, December 22, 2012 7:51 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" =20 Spaces in rel values are already illegal.. specifically, spaces are = disallowed in registered link relations and non-escaped spaces are = disallowed in absolute IRI's.. A comma delimited list of rel's is better = than multiple individual parameters.. even with the potential need for = double encoding. =20 =20 =20 On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones = wrote: If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode. =20 Paul =20 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" =20 BTW, why double encoding lead "problems with things like canonical urls = and search engines"? Can you provide more details? =20 If 2 rel included, the response would be different than when only 1 rel = given. So I feel those 2 are not the same, and can be indexed as 2 resources.. =20 On 2012/12/23, at 0:44, Melvin Carvalho = wrote: =20 =20 On 22 December 2012 05:48, nov matake wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need = to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in = rails. Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines can you use mod_rewrite? =20 Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 =20 ------=_NextPart_000_007A_01CDE08B.DCF43400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Indeed=E2=80=A6 RFC 3986 also shows that spaces must be = percent-encoded before they are considered a valid = URI.

 

Anyway, I=E2=80=99m open to going either way.=C2=A0 The -02 draft = said described a single =E2=80=9Crel=E2=80=9D parameters as = =E2=80=9Cspace-separated list of link relations=E2=80=9D.=C2=A0 Of = course, that would be escaped before being put into a GET=E2=80=A6 that = goes without saying, really.

 

Which way do folks want it?=C2=A0 I recall arguing to keep it this = way before, but I was successfully pushed to change = it.

 

We might have to wait a bit for folks to reply given this is the = weekend and a holiday weekend, at that.

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, = December 22, 2012 8:43 PM
To: Paul E. Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org
Subject: Re: = [webfinger] feedback for multiple = "rel"

 

 

 

On Sat, Dec 22, 2012 at 5:30 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

That depends on where they=E2=80=99re used.  If I tell you the = =E2=80=9Crel=E2=80=9D value is =E2=80=9Chttp://example.com/first one=E2=80=9D, I = don=E2=80=99t escape that as I write it.  Or are you saying there = is text somewhere that already makes that, as written, = illegal?

 

 

Yes. RFC 3987. That is, so long as the character = separating the "first" and the "one" is an ASCII = Space (0x20). IRI's allow for a range of space-like characters, such as = a nonbreaking space (0xA0) but strongly recommends that those be = pct-encoded. Whitespace of any type is explicitly disallowed in = URI's.

 

I=E2=80=99m quite favorable to a space-separated list of rel values = in a single rel parameter, too.  I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape.  My preference is a single escape and = a single rel parameter and spaces are illegal in the = =E2=80=9Crel=E2=80=9D values = themselves.

 

Double-escaping is really a separate issue, as there = may be lots of reasons why escaping is used, not just whitespace. Best = to just treat that as a separate issue. Just say that the link rels are = a list of 0x20 separated values and that the 0x20 must be pct-encoded, = and go with that.. e.g. 

 

 

Would be = rel=3D["abc","def","http://example.org/foo"]

 

All done.

 

- = James

 

 

But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2.  = At the end of the day, it makes no difference to me since I just need to = know which way to deal with it.

 

So Ruby can really only support only a single parameter with a given = name?  It will not collect those into an array or = anything?

 

Paul

 

From:= = James M Snell [mailto:jasnell@gmail.com]
Sent: Saturday, = December 22, 2012 7:51 PM
To: Paul E. Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org

<= p class=3DMsoNormal>
Subject: Re: [webfinger] feedback for = multiple = "rel"

 <= /o:p>

Spaces in rel values are already = illegal.. specifically, spaces are disallowed in registered link = relations and non-escaped spaces are disallowed in absolute IRI's.. A = comma delimited list of rel's is better than multiple individual = parameters.. even with the potential need for double = encoding.

 <= /o:p>

 <= /o:p>

 <= /p>

On Sat, Dec = 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

If we made it a requirement that =E2=80=9Crel=E2=80=9D values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode.

 

Paul

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = nov matake
Sent: Saturday, December 22, 2012 11:12 = AM
To: Melvin Carvalho


Cc: webfinger@ietf.org
Subject: Re: = [webfinger] feedback for multiple = "rel"

 <= /o:p>

BTW, why = double encoding lead "problems with things like canonical urls and = search engines"?

Can you = provide more details?

 <= /o:p>

If 2 rel = included, the response would be different than when only 1 rel = given.

So I feel = those 2 are not the same, and can be indexed as 2 = resources..

 <= /o:p>

On = 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:

 <= /p>

 <= /p>

On 22 = December 2012 05:48, nov matake <matake@gmail.com> wrote:

Hi,

I= have a comment for they way to specify multiple "rel" = values.

As a ruby library developer, my main target is rails = developers.
Since rails can't handle multiple same query keys, = developers will need to hack query params parser in rails middleware = layer.
I can easily imagine it'll be an annoying part to support = webfinger in rails.

Is the multiple "rel" case can be a = space-delimitered (or some other character) strings like multiple = redirect_uri in OAuth2?
Or any reason for putting multiple same keys = in query parameters?


each = time you delimit a list, you have to be able to escape the delimiter, = which can be a pain and also leads to problems with things like = canonical urls and search engines

can you use = mod_rewrite?
 


Cheers,<= br>
Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 <= /o:p>

 <= /o:p>


______________= _________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 <= /o:p>

 

------=_NextPart_000_007A_01CDE08B.DCF43400-- From joseph@josephholsten.com Sat Dec 22 19:32:34 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93721F8971 for ; Sat, 22 Dec 2012 19:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7nWaKWfnVwl for ; Sat, 22 Dec 2012 19:32:32 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id F005621F891C for ; Sat, 22 Dec 2012 19:32:29 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 2F537AB83; Sat, 22 Dec 2012 22:32:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=references :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id:cc:from:subject:date:to; s=sasl; bh=QzLNsdhGiPbhQTYy 0kwNn9xigq8=; b=dVs5/GsSsDvdeSzu6oeOX8TtSMgDuasHekv1O44p7QN8xkLb pJKvgFDiHydp2UllmYgDmvEcKw2ewXsPmxL43paaMOf+V79xd+LhzDx4r8dbZ2hs fXiUK9bpUMgYwzwDbBcInSK9Ouq+pepzTQdbeydhep3+j8LYbIi6/zaPUAU= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 1CF93AB82; Sat, 22 Dec 2012 22:32:27 -0500 (EST) Received: from [10.0.1.3] (unknown [76.28.212.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 5BC1FAB81; Sat, 22 Dec 2012 22:32:26 -0500 (EST) References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: <004d01cde0ad$175b5d00$46121700$@packetizer.com> Content-Type: multipart/alternative; boundary=Apple-Mail-50DF1E61-566E-453C-99FE-508477EF1C15 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A523) From: Joseph Holsten Date: Sat, 22 Dec 2012 19:32:52 -0800 To: "Paul E. Jones" X-Pobox-Relay-ID: 5F26E47C-4CB1-11E2-89CD-F0CE2E706CDE-15777318!b-pb-sasl-quonix.pobox.com Cc: "webfinger@ietf.org" , James M Snell , nov matake , Melvin Carvalho Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 03:32:34 -0000 --Apple-Mail-50DF1E61-566E-453C-99FE-508477EF1C15 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Dec 22, 2012, at 17:30, "Paul E. Jones" wrote: > That depends on where they=A1=AFre used. If I tell you the =A1=B0rel=A1=B1= value is =A1=B0http://example.com/first one=A1=B1, I don=A1=AFt escape that= as I write it.=20 That is an IRI, which must be converted to a URI before it can be a valid re= l. Yay encoding canonicalization, another one of the bottomless pits of stan= dardization!=20 -- http://josephholsten.com= --Apple-Mail-50DF1E61-566E-453C-99FE-508477EF1C15 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Dec 22, 2012, at 17:30, "Paul E. Jo= nes" <paulej@packetizer.com&= gt; wrote:

That depends on where they=E2=80=99re use= d.  If I tell you the =E2=80=9Crel=E2=80=9D value is =E2=80=9Chttp://example.com/first one=E2=80=9D, I don=E2= =80=99t escape that as I write it. 


That is an IRI, which must be converted to a URI before it can be a valid= rel. Yay encoding canonicalization, another one of the bottomless pits of s= tandardization! 

--
<= a href=3D"http://josephholsten.com">http://josephholsten.com
= = --Apple-Mail-50DF1E61-566E-453C-99FE-508477EF1C15-- From matake@gmail.com Sat Dec 22 20:16:12 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3965021F8A85 for ; Sat, 22 Dec 2012 20:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.911, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oejnrWfS4Hmt for ; Sat, 22 Dec 2012 20:16:09 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0EC21F8982 for ; Sat, 22 Dec 2012 20:16:09 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fb10so3544421pad.2 for ; Sat, 22 Dec 2012 20:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=ECLzBgsmmIjFiwIHZH4CHgDEaQ8RENLhELSrZPg9VwQ=; b=ie+7oO/uQHrtKAdcNisD6azSLa2kLffJvwREvdcvZe0fQW6SlobrQVPFe1vQPzumtS qYONR2m2CNiu3p0O/uXWZyoYhmzX0Aoae0t3mUGUPu84+yfM23JdEbGJrzWcNsSLjsCm 5m57xAeOCN/LHv9gvfE9eEbXVjdzk4wsmnxkMQhyRqS/gEWakRRE1QZMcx00/qbGKka3 qnDfhT1ZGFPEPAUUrHpk/KBfaVqReEHvCcU004DR31XH1vPBF7rgMDdeyYtc3dujfy4e CDP/pMbSqhpdESwNjYRgLiQZzb9gvroL9blSGnx2y3fTL/qDrBJ0tOqHWeQ18jyCv+We 6gLw== X-Received: by 10.68.223.35 with SMTP id qr3mr54981761pbc.27.1356236168988; Sat, 22 Dec 2012 20:16:08 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id n11sm9852403pby.67.2012.12.22.20.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 20:16:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_293486EC-66DD-4F1F-9247-6A4DF981E300" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> Date: Sun, 23 Dec 2012 13:15:59 +0900 Message-Id: <9D326871-8C8D-41A7-A6E0-A4E45FA75E09@gmail.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, 'James M Snell' , 'Melvin Carvalho' , 'Dick Hardt' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 04:16:12 -0000 --Apple-Mail=_293486EC-66DD-4F1F-9247-6A4DF981E300 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp CGI library handle it well. It returns query values as array even when it's a single value though. So the issue is Rails (actually it uses Rack::Utils.parse_nested_query) = only. It takes only the last "rel" value. > require 'rack' > Rack::Utils.parse_nested_query "rel=3Da&rel=3Db" =3D> {"rel"=3D>"b"}=20 On 2012/12/23, at 11:13, "Paul E. Jones" wrote: > Dick, Nov, > =20 > I=1B$B!G=1B(Bve never written a Ruby program before, but I was quite = curious as to whether it was or was not possible to access multiple = =1B$B!H=1B(Brel=1B$B!I=1B(B parameters. It appears that is. = Here=1B$B!G=1B(Bs my first Ruby program (and my apologies to the = developers of Ruby): > =20 > #!/bin/ruby > =20 > require 'cgi' > =20 > cgi =3D CGI.new > =20 > params =3D cgi.params > =20 > # Following appears to show an associative array with values that are = arrays > puts params; > =20 > # Grab the 'rel' array > rels =3D params['rel']; > =20 > # Display the array > puts rels; > =20 > # How many items are in the "rel" array? > count =3D rels.size > print "Number of rel params: ", count, "\n"; > =20 > # Can I access each one? > for i in 0..(count-1) > print "Item ", i, ": ", rels[i], "\n" > end > =20 > Here=1B$B!G=1B(Bs what I get: > =20 > $ ./test "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df" > {"rel"=3D>["rel1", "rel2"], "c"=3D>["d"], "e"=3D>["f"]} > rel1 > rel2 > Number of rel params: 2 > Item 0: rel1 > Item 1: rel2 > =20 > So, it looks like it works to me. Is the issue only with Rails? = I=1B$B!G=1B(Bm not going to venture down that path to see what the issue = is, but if Ruby can access the data, can=1B$B!G=1B(Bt it provide it to = Rails in a form that it likes? > =20 > Paul > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Saturday, December 22, 2012 8:40 PM > To: Paul E. Jones > Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; 'Melvin = Carvalho' > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > FYI: multiple query string params with the same name are turned into = arrays or parsed into arrays in node.js > =20 > the following script: > =20 > var querystring =3D require('querystring') > console.log( querystring.parse( 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' = ) ) > console.log( querystring.stringify( = {'foo':'bar','rel':['token1','token2']} ) ) > =20 > outputs: > =20 > { foo: 'bar', rel: [ 'token1', 'token2' ] } > foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2 > =20 > Perhaps Ruby devs should just move to the next cool language? :-) > Seriously though, what does the query string parser do in Ruby? > =20 > -- Dick > =20 > On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" = wrote: >=20 >=20 > That depends on where they=1B$B!G=1B(Bre used. If I tell you the = =1B$B!H=1B(Brel=1B$B!I=1B(B value is =1B$B!H=1B(Bhttp://example.com/first = one=1B$B!I=1B(B, I don=1B$B!G=1B(Bt escape that as I write it. Or are = you saying there is text somewhere that already makes that, as written, = illegal? > =20 > I=1B$B!G=1B(Bm quite favorable to a space-separated list of rel values = in a single rel parameter, too. I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape. My preference is a single escape and a = single rel parameter and spaces are illegal in the =1B$B!H=1B(Brel=1B$B!I=1B= (B values themselves. > =20 > But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the = day, it makes no difference to me since I just need to know which way to = deal with it. > =20 > So Ruby can really only support only a single parameter with a given = name? It will not collect those into an array or anything? > =20 > Paul > =20 > From: James M Snell [mailto:jasnell@gmail.com]=20 > Sent: Saturday, December 22, 2012 7:51 PM > To: Paul E. Jones > Cc: nov matake; Melvin Carvalho; webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > Spaces in rel values are already illegal.. specifically, spaces are = disallowed in registered link relations and non-escaped spaces are = disallowed in absolute IRI's.. A comma delimited list of rel's is better = than multiple individual parameters.. even with the potential need for = double encoding. > =20 > =20 > =20 >=20 > On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones = wrote: > If we made it a requirement that =1B$B!H=1B(Brel=1B$B!I=1B(B values = have no spaces (which I would argue is a damn good thing for many = reasons) then we would not have to double-encode. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Saturday, December 22, 2012 11:12 AM > To: Melvin Carvalho >=20 > Cc: webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > BTW, why double encoding lead "problems with things like canonical = urls and search engines"? > Can you provide more details? > =20 > If 2 rel included, the response would be different than when only 1 = rel given. > So I feel those 2 are not the same, and can be indexed as 2 = resources.. > =20 > On 2012/12/23, at 0:44, Melvin Carvalho = wrote: > =20 >=20 > =20 >=20 > On 22 December 2012 05:48, nov matake wrote: > Hi, >=20 > I have a comment for they way to specify multiple "rel" values. >=20 > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will = need to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in = rails. >=20 > Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? >=20 > each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines >=20 > can you use mod_rewrite? > =20 >=20 > Cheers, >=20 > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > =20 > =20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_293486EC-66DD-4F1F-9247-6A4DF981E300 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp CGI library handle it = well.
It returns query values as array even when it's a single value = though.

So the issue is Rails (actually it uses = Rack::Utils.parse_nested_query) only.
It takes only the last = "rel" value.

> require = 'rack'
> Rack::Utils.parse_nested_query = "rel=3Da&rel=3Db"
=3D> = {"rel"=3D>"b"} 


On = 2012/12/23, at 11:13, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Dick, = Nov,
 
I=1B$B!G=1B(Bve never written a Ruby program = before, but I was quite curious as to whether it was or was not possible = to access multiple =1B$B!H=1B(Brel=1B$B!I=1B(B parameters.  It = appears that is.  Here=1B$B!G=1B(Bs my first Ruby program (and my = apologies to the developers of Ruby):
 
 
require 'cgi'
 
cgi =3D = CGI.new
 
params =3D cgi.params
 
# Following appears to show an associative = array with values that are arrays
puts = params;
 
# Grab the 'rel' array
rels =3D = params['rel'];
 
# Display the array
puts = rels;
 
# How many items are in the "rel" = array?
count =3D rels.size
print "Number of rel params: ", count, = "\n";
 
# Can I access each one?
for i in = 0..(count-1)
   print "Item ", i, ": ", rels[i], = "\n"
end
 
Here=1B$B!G=1B(Bs what I = get:
 
$ ./test = "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df"
{"rel"=3D>["rel1", "rel2"], = "c"=3D>["d"], "e"=3D>["f"]}
rel2
Number of rel params: 2
Item 0: = rel1
Item 1: rel2 
So, it looks like it works to me.  Is = the issue only with Rails?  I=1B$B!G=1B(Bm not going to venture = down that path to see what the issue is, but if Ruby can access the = data, can=1B$B!G=1B(Bt it provide it to Rails in a form that it = likes?
 
Paul
 
From: Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent: Saturday, December 22, 2012 = 8:40 PM
To: Paul E. = Jones
Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; = 'Melvin Carvalho'
Subject: Re: [webfinger] feedback = for multiple "rel"
 
 
the following = script:
var = querystring =3D require('querystring')
console.log( querystring.parse( = 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) = )
console.log( = querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) = )
{ = foo: 'bar', rel: [ 'token1', 'token2' ] = }
Seriously = though, what does the query string parser do in = Ruby?
-- = Dick
On = Dec 22, 2012, at 5:30 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:
That depends on where they=1B$B!G=1B(Bre = used.  If I tell you the =1B$B!H=1B(Brel=1B$B!I=1B(B value is = =1B$B!H=1B(B one=1B$B!I=1B(B, I = don=1B$B!G=1B(Bt escape that as I write it.  Or are you saying = there is text somewhere that already makes that, as written, = illegal?
From: James M = Snell [mailto:jasnell@gmail.com] 
Sent: Saturday, December 22, 2012 = 7:51 PM
To: Paul E. = Jones
Cc: nov = matake; Melvin Carvalho;  Re: [webfinger] feedback = for multiple "rel"
 

 [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Saturday, December 22, 2012 = 11:12 AM
To: Melvin = Carvalho

As a ruby library developer, my main target is rails = developers.
Since rails can't handle multiple same query keys, = developers will need to hack query params parser in rails middleware = layer.
I can easily imagine it'll be an annoying part to support = webfinger in rails.

Is the multiple "rel" case can be a = space-delimitered (or some other character) strings like multiple = redirect_uri in OAuth2?
Or any reason for putting multiple same keys = in query parameters?

each time you delimit a list, you have to be able to escape = the delimiter, which can be a pain and also leads to problems with = things like canonical urls and search engines

can you use = mod_rewrite?
 

Cheers,

Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
webfinger@ietf.org
To: "'nov matake'" References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> <9D326871-8C8D-41A7-A6E0-A4E45FA75E09@gmail.com> In-Reply-To: <9D326871-8C8D-41A7-A6E0-A4E45FA75E09@gmail.com> Date: Sat, 22 Dec 2012 23:25:36 -0500 Message-ID: <00a501cde0c5$8fb5d510$af217f30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01CDE09B.A6E30160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHn/3n6mr+8L0+iRGJmLFJlw0GLowJLSGqcAkS0TYMBZO3SKgEqx9VtAUuOMU8BofJMGAII9k0pAqwi6aCXe3i5YA== Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' , 'Melvin Carvalho' , 'Dick Hardt' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 04:25:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A6_01CDE09B.A6E30160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nov, Do you absolutely need to use that particular function? It appears that it returns an associative array where the values are not array (unlike the "cgi" code). So, if using it is required, this will certainly present a challenge. I would assume WF is not the first thing to use multiple parameters with the same name. This has not been encountered before? Paul From: nov matake [mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 11:16 PM To: Paul E. Jones Cc: 'Dick Hardt'; 'James M Snell'; webfinger@ietf.org; 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" CGI library handle it well. It returns query values as array even when it's a single value though. So the issue is Rails (actually it uses Rack::Utils.parse_nested_query) only. It takes only the last "rel" value. > require 'rack' > Rack::Utils.parse_nested_query "rel=a&rel=b" => {"rel"=>"b"} On 2012/12/23, at 11:13, "Paul E. Jones" wrote: Dick, Nov, I've never written a Ruby program before, but I was quite curious as to whether it was or was not possible to access multiple "rel" parameters. It appears that is. Here's my first Ruby program (and my apologies to the developers of Ruby): #!/bin/ruby require 'cgi' cgi = CGI.new params = cgi.params # Following appears to show an associative array with values that are arrays puts params; # Grab the 'rel' array rels = params['rel']; # Display the array puts rels; # How many items are in the "rel" array? count = rels.size print "Number of rel params: ", count, "\n"; # Can I access each one? for i in 0..(count-1) print "Item ", i, ": ", rels[i], "\n" end Here's what I get: $ ./test "rel=rel1&c=d&rel=rel2&e=f" {"rel"=>["rel1", "rel2"], "c"=>["d"], "e"=>["f"]} rel1 rel2 Number of rel params: 2 Item 0: rel1 Item 1: rel2 So, it looks like it works to me. Is the issue only with Rails? I'm not going to venture down that path to see what the issue is, but if Ruby can access the data, can't it provide it to Rails in a form that it likes? Paul From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Saturday, December 22, 2012 8:40 PM To: Paul E. Jones Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" FYI: multiple query string params with the same name are turned into arrays or parsed into arrays in node.js the following script: var querystring = require('querystring') console.log( querystring.parse( 'foo=bar&rel=token1&rel=token2' ) ) console.log( querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) ) outputs: { foo: 'bar', rel: [ 'token1', 'token2' ] } foo=bar&rel=token1&rel=token2 Perhaps Ruby devs should just move to the next cool language? :-) Seriously though, what does the query string parser do in Ruby? -- Dick On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" < paulej@packetizer.com> wrote: That depends on where they're used. If I tell you the "rel" value is " http://example.com/first one", I don't escape that as I write it. Or are you saying there is text somewhere that already makes that, as written, illegal? I'm quite favorable to a space-separated list of rel values in a single rel parameter, too. I was concerned before that spaces would present an issue, but figured we could either we make spaces illegal in rel values (which we can do since those are fabricated things!) or we double-escape. My preference is a single escape and a single rel parameter and spaces are illegal in the "rel" values themselves. But, the forces that be pushed pretty hard to change from &rel=token1%20token to &rel=token1&rel=token2. At the end of the day, it makes no difference to me since I just need to know which way to deal with it. So Ruby can really only support only a single parameter with a given name? It will not collect those into an array or anything? Paul From: James M Snell [mailto:jasnell@ gmail.com] Sent: Saturday, December 22, 2012 7:51 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" Spaces in rel values are already illegal.. specifically, spaces are disallowed in registered link relations and non-escaped spaces are disallowed in absolute IRI's.. A comma delimited list of rel's is better than multiple individual parameters.. even with the potential need for double encoding. On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones < paulej@packetizer.com> wrote: If we made it a requirement that "rel" values have no spaces (which I would argue is a damn good thing for many reasons) then we would not have to double-encode. Paul From: webfinger-bounces@ietf.org [mailto: webfinger-bounces@ietf.org] On Behalf Of nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" BTW, why double encoding lead "problems with things like canonical urls and search engines"? Can you provide more details? If 2 rel included, the response would be different than when only 1 rel given. So I feel those 2 are not the same, and can be indexed as 2 resources.. On 2012/12/23, at 0:44, Melvin Carvalho < melvincarvalho@gmail.com> wrote: On 22 December 2012 05:48, nov matake < matake@gmail.com> wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need to hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in rails. Is the multiple "rel" case can be a space-delimitered (or some other character) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the delimiter, which can be a pain and also leads to problems with things like canonical urls and search engines can you use mod_rewrite? Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_00A6_01CDE09B.A6E30160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nov,

 

Do you absolutely need to use that particular function?  It = appears that it returns an associative array where the values are not = array (unlike the “cgi” code).  So, if using it is = required, this will certainly present a = challenge.

 

I would assume WF is not the first thing to use multiple parameters = with the same name.  This has not been encountered = before?

 

Paul

 

From:= = nov matake [mailto:matake@gmail.com]
Sent: Saturday, December = 22, 2012 11:16 PM
To: Paul E. Jones
Cc: 'Dick = Hardt'; 'James M Snell'; webfinger@ietf.org; 'Melvin = Carvalho'
Subject: Re: [webfinger] feedback for multiple = "rel"

 

CGI library = handle it well.

It returns query = values as array even when it's a single value = though.

 

So the issue is Rails (actually it uses = Rack::Utils.parse_nested_query) only.

It takes only the last "rel" = value.

 

> require 'rack'

> Rack::Utils.parse_nested_query = "rel=3Da&rel=3Db"

=3D> = {"rel"=3D>"b"} 

 

 



Dick, Nov,

 

I’ve never written a Ruby program before, but I was quite = curious as to whether it was or was not possible to access multiple = “rel” parameters.  It appears that is.  = Here’s my first Ruby program (and my apologies to the developers = of Ruby):

 

#!/bin/ruby

 

require 'cgi'

 

cgi = =3D CGI.new

 

params = =3D cgi.params

 

# = Following appears to show an associative array with values that are = arrays

puts = params;

 

# Grab = the 'rel' array

rels = =3D params['rel'];

 

# = Display the array

puts = rels;

 

# How = many items are in the "rel" array?

count = =3D rels.size

print = "Number of rel params: ", count, "\n";

 

# Can = I access each one?

for i = in 0..(count-1)

   print "Item ", i, ": = ", rels[i], "\n"

end

 

Here’s what I get:

 

$ = ./test = "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df"

{"rel"=3D>["rel1", = "rel2"], "c"=3D>["d"], = "e"=3D>["f"]}

rel1

rel2

Number = of rel params: 2

Item = 0: rel1

Item = 1: rel2

 

So, it looks like it works to me.  Is the issue only with = Rails?  I’m not going to venture down that path to see what = the issue is, but if Ruby can access the data, can’t it provide it = to Rails in a form that it likes?

 

Paul

 

From:=  Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent: Saturday, December 22, 2012 = 8:40 PM
To: Paul E. = Jones
Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; = 'Melvin Carvalho'
Subject: Re: [webfinger] feedback for = multiple "rel"

 

FYI: multiple query string params with the same name are = turned into arrays or parsed into arrays in = node.js

 

the following = script:

 

var querystring =3D = require('querystring')

console.log( querystring.parse( = 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) = )

console.log( = querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) = )

 

outputs:

 

{ foo: 'bar', rel: [ 'token1', 'token2' ] = }

foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2

 

Perhaps Ruby devs should just move to the next cool = language? :-)

Seriously though, what does the query string parser do = in Ruby?

 

-- Dick

 

On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" = <paulej@packetizer.com> = wrote:




That depends on where they’re used.  If I tell you the = “rel” value is “http://example.com/first one”, I don’t = escape that as I write it.  Or are you saying there is text = somewhere that already makes that, as written, illegal?

 

I’m quite favorable to a space-separated list of rel values in = a single rel parameter, too.  I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape.  My preference is a single escape and = a single rel parameter and spaces are illegal in the “rel” = values themselves.

 

But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2.  = At the end of the day, it makes no difference to me since I just need to = know which way to deal with it.

 

So Ruby can really only support only a single parameter with a given = name?  It will not collect those into an array or = anything?

 

Paul

 

From:=  James M = Snell [mailto:jasnell@gmail.com] 
Sent: Saturday, December 22, 2012 = 7:51 PM
To: Paul E. = Jones
Cc: nov = matake; Melvin Carvalho; webfinger@ietf.org
Subject: Re: [webfinger] feedback = for multiple "rel"

 

Spaces in = rel values are already illegal.. specifically, spaces are disallowed in = registered link relations and non-escaped spaces are disallowed in = absolute IRI's.. A comma delimited list of rel's is better than multiple = individual parameters.. even with the potential need for double = encoding.

 

 

 

On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

If we made it a requirement that “rel” values have no = spaces (which I would argue is a damn good thing for many reasons) then = we would not have to double-encode.

 

Paul

 

From:=  webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Saturday, December 22, 2012 = 11:12 AM
To: Melvin Carvalho


Cc: webfinger@ietf.org
Subject: Re: [webfinger] feedback = for multiple = "rel"

 

BTW, why double encoding lead "problems with things = like canonical urls and search = engines"?

Can you provide more = details?

 

If 2 rel included, the response would be different than = when only 1 rel given.

So I feel those 2 are not the same, and can be indexed = as 2 resources..

 

On 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:

 

 

On 22 December 2012 05:48, nov matake <matake@gmail.com> = wrote:

Hi,

I have a comment for they way to specify = multiple "rel" values.

As a ruby library developer, my = main target is rails developers.
Since rails can't handle multiple = same query keys, developers will need to hack query params parser in = rails middleware layer.
I can easily imagine it'll be an annoying = part to support webfinger in rails.

Is the multiple = "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2?
Or any = reason for putting multiple same keys in query = parameters?


each time you delimit a list, you have to be able to = escape the delimiter, which can be a pain and also leads to problems = with things like canonical urls and search engines

can you use = mod_rewrite?
 


Cheers,

Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

<= p class=3DMsoNormal> 


_______________________________________________
we= bfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

=

_________= ______________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_00A6_01CDE09B.A6E30160-- From matake@gmail.com Sat Dec 22 20:35:06 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703F921F87B1 for ; Sat, 22 Dec 2012 20:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[AWL=-1.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDOPRWYVh3IR for ; Sat, 22 Dec 2012 20:35:05 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id E467721F8781 for ; Sat, 22 Dec 2012 20:35:04 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rq13so3444007pbb.35 for ; Sat, 22 Dec 2012 20:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=j0UnLbi62ieXyK7oqM4YLxgZxmzQec6H0Pf4bHUXF78=; b=l6fezA+7rRToOMjrsvA437tpDPuDp67iQc9g5LWeDiu2huovjiV6q0EQrgXuI80xNE SWNhDIbSj04pBcTQixPAJgzrsH4eFNl9BcSlntt1p9DeH/AbknNP5EiBSNQ4NoOAKuk3 CW8cYLwISzQwhNUVa5y/DkphZ5offTeiyAvLOnpxmjHja/6vVC+tet2Hgy07jnXTwtRZ UCKRYN+Pi+7kfYSO0xHQAteX9dKJ8O8UEZDfuiJ2RYz5CkegDoUuWHyXD7R668RaZMYE DqZUDz3zubKonzzATqHFsqxVv0QqTYs6qgyEAZ81c/9t0o7dSs7KyngsZDJAV6ku8saA TYvA== X-Received: by 10.66.73.138 with SMTP id l10mr51257664pav.44.1356237299986; Sat, 22 Dec 2012 20:34:59 -0800 (PST) Received: from [192.168.1.6] (z195031.dynamic.ppp.asahi-net.or.jp. [110.4.195.31]) by mx.google.com with ESMTPS id yi9sm9883737pbc.39.2012.12.22.20.34.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 20:34:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4281F691-499F-472C-9F7D-EAA2D369ED84" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <00a501cde0c5$8fb5d510$af217f30$@packetizer.com> Date: Sun, 23 Dec 2012 13:34:54 +0900 Message-Id: References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> <9D326871-8C8D-41A7-A6E0-A4E45FA75E09@gmail.com> <00a501cde0c5$8fb5d510$af217f30$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, 'James M Snell' , 'Melvin Carvalho' , 'Dick Hardt' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 04:35:06 -0000 --Apple-Mail=_4281F691-499F-472C-9F7D-EAA2D369ED84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Developers who uses my library in their rails project would use that = function. I can't stop them. Of course, I can ask developers to give raw request object (which = includes raw requested url, cookies etc) to my library. But developers will feel weird to give raw request object only for = multiple rel case, I think. =3D=3D=3D=3D # put raw request object WebFinger.discover @request # put resource & rel only (I prefer this one) WebFinger.discover params[:resource], params[:rel] =3D=3D=3D=3D On 2012/12/23, at 13:25, Paul E. Jones wrote: > Nov, > =20 > Do you absolutely need to use that particular function? It appears = that it returns an associative array where the values are not array = (unlike the =1B$B!H=1B(Bcgi=1B$B!I=1B(B code). So, if using it is = required, this will certainly present a challenge. > =20 > I would assume WF is not the first thing to use multiple parameters = with the same name. This has not been encountered before? > =20 > Paul > =20 > From: nov matake [mailto:matake@gmail.com]=20 > Sent: Saturday, December 22, 2012 11:16 PM > To: Paul E. Jones > Cc: 'Dick Hardt'; 'James M Snell'; webfinger@ietf.org; 'Melvin = Carvalho' > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > CGI library handle it well. > It returns query values as array even when it's a single value though. > =20 > So the issue is Rails (actually it uses = Rack::Utils.parse_nested_query) only. > It takes only the last "rel" value. > =20 > > require 'rack' > > Rack::Utils.parse_nested_query "rel=3Da&rel=3Db" > =3D> {"rel"=3D>"b"}=20 > =20 > =20 > On 2012/12/23, at 11:13, "Paul E. Jones" = wrote: >=20 >=20 > Dick, Nov, > =20 > I=1B$B!G=1B(Bve never written a Ruby program before, but I was quite = curious as to whether it was or was not possible to access multiple = =1B$B!H=1B(Brel=1B$B!I=1B(B parameters. It appears that is. = Here=1B$B!G=1B(Bs my first Ruby program (and my apologies to the = developers of Ruby): > =20 > #!/bin/ruby > =20 > require 'cgi' > =20 > cgi =3D CGI.new > =20 > params =3D cgi.params > =20 > # Following appears to show an associative array with values that are = arrays > puts params; > =20 > # Grab the 'rel' array > rels =3D params['rel']; > =20 > # Display the array > puts rels; > =20 > # How many items are in the "rel" array? > count =3D rels.size > print "Number of rel params: ", count, "\n"; > =20 > # Can I access each one? > for i in 0..(count-1) > print "Item ", i, ": ", rels[i], "\n" > end > =20 > Here=1B$B!G=1B(Bs what I get: > =20 > $ ./test "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df" > {"rel"=3D>["rel1", "rel2"], "c"=3D>["d"], "e"=3D>["f"]} > rel1 > rel2 > Number of rel params: 2 > Item 0: rel1 > Item 1: rel2 > =20 > So, it looks like it works to me. Is the issue only with Rails? = I=1B$B!G=1B(Bm not going to venture down that path to see what the issue = is, but if Ruby can access the data, can=1B$B!G=1B(Bt it provide it to = Rails in a form that it likes? > =20 > Paul > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Saturday, December 22, 2012 8:40 PM > To: Paul E. Jones > Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; 'Melvin = Carvalho' > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > FYI: multiple query string params with the same name are turned into = arrays or parsed into arrays in node.js > =20 > the following script: > =20 > var querystring =3D require('querystring') > console.log( querystring.parse( 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' = ) ) > console.log( querystring.stringify( = {'foo':'bar','rel':['token1','token2']} ) ) > =20 > outputs: > =20 > { foo: 'bar', rel: [ 'token1', 'token2' ] } > foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2 > =20 > Perhaps Ruby devs should just move to the next cool language? :-) > Seriously though, what does the query string parser do in Ruby? > =20 > -- Dick > =20 > On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" = wrote: >=20 >=20 >=20 > That depends on where they=1B$B!G=1B(Bre used. If I tell you the = =1B$B!H=1B(Brel=1B$B!I=1B(B value is =1B$B!H=1B(Bhttp://example.com/first = one=1B$B!I=1B(B, I don=1B$B!G=1B(Bt escape that as I write it. Or are = you saying there is text somewhere that already makes that, as written, = illegal? > =20 > I=1B$B!G=1B(Bm quite favorable to a space-separated list of rel values = in a single rel parameter, too. I was concerned before that spaces = would present an issue, but figured we could either we make spaces = illegal in rel values (which we can do since those are fabricated = things!) or we double-escape. My preference is a single escape and a = single rel parameter and spaces are illegal in the =1B$B!H=1B(Brel=1B$B!I=1B= (B values themselves. > =20 > But, the forces that be pushed pretty hard to change from = &rel=3Dtoken1%20token to &rel=3Dtoken1&rel=3Dtoken2. At the end of the = day, it makes no difference to me since I just need to know which way to = deal with it. > =20 > So Ruby can really only support only a single parameter with a given = name? It will not collect those into an array or anything? > =20 > Paul > =20 > From: James M Snell [mailto:jasnell@gmail.com]=20 > Sent: Saturday, December 22, 2012 7:51 PM > To: Paul E. Jones > Cc: nov matake; Melvin Carvalho; webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > Spaces in rel values are already illegal.. specifically, spaces are = disallowed in registered link relations and non-escaped spaces are = disallowed in absolute IRI's.. A comma delimited list of rel's is better = than multiple individual parameters.. even with the potential need for = double encoding. > =20 > =20 > =20 >=20 > On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones = wrote: > If we made it a requirement that =1B$B!H=1B(Brel=1B$B!I=1B(B values = have no spaces (which I would argue is a damn good thing for many = reasons) then we would not have to double-encode. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of nov matake > Sent: Saturday, December 22, 2012 11:12 AM > To: Melvin Carvalho >=20 > Cc: webfinger@ietf.org > Subject: Re: [webfinger] feedback for multiple "rel" > =20 > BTW, why double encoding lead "problems with things like canonical = urls and search engines"? > Can you provide more details? > =20 > If 2 rel included, the response would be different than when only 1 = rel given. > So I feel those 2 are not the same, and can be indexed as 2 = resources.. > =20 > On 2012/12/23, at 0:44, Melvin Carvalho = wrote: > =20 >=20 > =20 >=20 > On 22 December 2012 05:48, nov matake wrote: > Hi, >=20 > I have a comment for they way to specify multiple "rel" values. >=20 > As a ruby library developer, my main target is rails developers. > Since rails can't handle multiple same query keys, developers will = need to hack query params parser in rails middleware layer. > I can easily imagine it'll be an annoying part to support webfinger in = rails. >=20 > Is the multiple "rel" case can be a space-delimitered (or some other = character) strings like multiple redirect_uri in OAuth2? > Or any reason for putting multiple same keys in query parameters? >=20 > each time you delimit a list, you have to be able to escape the = delimiter, which can be a pain and also leads to problems with things = like canonical urls and search engines >=20 > can you use mod_rewrite? > =20 >=20 > Cheers, >=20 > Nov Matake > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > =20 > =20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_4281F691-499F-472C-9F7D-EAA2D369ED84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp
Developers who uses my = library in their rails project would use that function.
I = can't stop them.

Of course, I can ask developers to = give raw request object (which includes raw requested url, cookies = etc) to my library.
But developers will feel weird to give raw = request object only for multiple rel case, I = think.

=3D=3D=3D=3D
# put raw request = object
WebFinger.discover @request

# = put resource & rel only (I prefer this = one)
WebFinger.discover params[:resource], = params[:rel]
=3D=3D=3D=3D

On = 2012/12/23, at 13:25, Paul E. Jones <paulej@packetizer.com> = wrote:

 
Do you absolutely need to use that particular = function?  It appears that it returns an associative array where = the values are not array (unlike the =1B$B!H=1B(Bcgi=1B$B!I=1B(B = code).  So, if using it is required, this will certainly present a = challenge.
 
I would assume WF is not the first thing to = use multiple parameters with the same name.  This has not been = encountered before?
 
Paul
 
From: nov matake = [mailto:matake@gmail.com] 
Sent: Saturday, December 22, 2012 = 11:16 PM
To: Paul E. = Jones
Cc: 'Dick Hardt'; 'James M = Snell'; webfinger@ietf.org; = 'Melvin Carvalho'
Subject: Re: [webfinger] feedback = for multiple "rel"
 
It returns query values as array even when it's a single = value though.
So = the issue is Rails (actually it uses Rack::Utils.parse_nested_query) = only.
It takes only = the last "rel" value.
 
> require 'rack'
> Rack::Utils.parse_nested_query = "rel=3Da&rel=3Db"
=3D> = {"rel"=3D>"b"} 
 
 
paulej@packetizer.com> = wrote:
Dick, Nov,
 I=1B$B!G=1B(Bve never written a Ruby program = before, but I was quite curious as to whether it was or was not possible = to access multiple =1B$B!H=1B(Brel=1B$B!I=1B(B parameters.  It = appears that is.  Here=1B$B!G=1B(Bs my first Ruby program (and my = apologies to the developers of Ruby):
 
#!/bin/ruby
 
require 'cgi'
 
cgi =3D CGI.new
 
params =3D = cgi.params
 
# Following appears to show an = associative array with values that are arrays
puts params;
 
# Grab the 'rel' = array
rels =3D = params['rel'];
 
# Display the = array
puts rels;
 
# How many items are in the = "rel" array?
count =3D = rels.size
print "Number of rel params: = ", count, "\n";
 
# Can I access each = one?
for i in = 0..(count-1)
   print "Item ", i, = ": ", rels[i], "\n"
end 
Here=1B$B!G=1B(Bs what I = get: 
$ ./test "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df"
{"rel"=3D>["rel1", "rel2"], = "c"=3D>["d"], "e"=3D>["f"]}
rel1
rel2
Number of rel params: = 2
Item 0: rel1
Item 1: rel2 
So, it looks like it = works to me.  Is the issue only with Rails?  I=1B$B!G=1B(Bm = not going to venture down that path to see what the issue is, but if = Ruby can access the data, can=1B$B!G=1B(Bt it provide it to Rails in a = form that it likes?
 
Paul 
From: Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent: Saturday, December 22, 2012 = 8:40 PM
To: Paul E. = Jones
Cc: 'James M Snell'; webfinger@ietf.org; 'nov matake'; = 'Melvin Carvalho'
Subject: Re: [webfinger] feedback = for multiple "rel"
FYI: multiple = query string params with the same name are turned into arrays or parsed = into arrays in node.js
 
 
console.log( querystring.parse( = 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) = )
console.log( = querystring.stringify( {'foo':'bar','rel':['token1','token2']} ) = )
{ = foo: 'bar', rel: [ 'token1', 'token2' ] = }
Perhaps Ruby = devs should just move to the next cool language? = :-)
Seriously = though, what does the query string parser do in = Ruby?
-- = Dick
On = Dec 22, 2012, at 5:30 PM, "Paul E. Jones" <That depends on where = they=1B$B!G=1B(Bre used.  If I tell you the =1B$B!H=1B(Brel=1B$B!I=1B= (B value is =1B$B!H=1B(Bhttp://example.com/first one=1B$B!I=1B(B, I = don=1B$B!G=1B(Bt escape that as I write it.  Or are you saying = there is text somewhere that already makes that, as written, = illegal? 
I=1B$B!G=1B(Bm quite = favorable to a space-separated list of rel values in a single rel = parameter, too.  I was concerned before that spaces would present = an issue, but figured we could either we make spaces illegal in rel = values (which we can do since those are fabricated things!) or we = double-escape.  My preference is a single escape and a single rel = parameter and spaces are illegal in the =1B$B!H=1B(Brel=1B$B!I=1B(B = values themselves.
 
But, the forces that be = pushed pretty hard to change from &rel=3Dtoken1%20token to = &rel=3Dtoken1&rel=3Dtoken2.  At the end of the day, it = makes no difference to me since I just need to know which way to deal = with it. 
So Ruby can really only = support only a single parameter with a given name?  It will not = collect those into an array or anything?
 Paul
 
Spaces in rel = values are already illegal.. specifically, spaces are disallowed in = registered link relations and non-escaped spaces are disallowed in = absolute IRI's.. A comma delimited list of rel's is better than multiple = individual parameters.. even with the potential need for double = encoding. 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov = matake
Sent: Saturday, December 22, 2012 = 11:12 AM
To: Melvin Carvalho  Re: [webfinger] feedback = for multiple "rel"
On = 2012/12/23, at 0:44, Melvin Carvalho < 

 

Hi,

I = have a comment for they way to specify multiple "rel" values.

As = a ruby library developer, my main target is rails developers.
Since = rails can't handle multiple same query keys, developers will need to = hack query params parser in rails middleware layer.
I can easily = imagine it'll be an annoying part to support webfinger in = rails.

Is the multiple "rel" case can be a space-delimitered (or = some other character) strings like multiple redirect_uri in = OAuth2?
Or any reason for putting multiple same keys in query = parameters?

each time = you delimit a list, you have to be able to escape the delimiter, which = can be a pain and also leads to problems with things like canonical urls = and search engines

can you use = mod_rewrite?
 

Cheers,

Nov = Matake
_______________________________________________
webfinger = mailing list
webfinger@ietf.org
X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13621F8AA3 for ; Sun, 23 Dec 2012 08:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81-Kp3pitO1F for ; Sun, 23 Dec 2012 08:43:02 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0017421F8A8C for ; Sun, 23 Dec 2012 08:43:01 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so5426907ial.36 for ; Sun, 23 Dec 2012 08:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0IB6I7xRDZRDokjNDzIt/Bv6ScZ9PHDPTO0+NOK+zgk=; b=peW0pjcCS5LyWy0eU1BvyCiwwI+nwfEA7pwOM+s0NSAfMvHHqlAGq5it+ATqquXhoM d6OGfqnYv3NL5vjEo0h93k+T31gwIqpeWwPrQomTRIjgat1EEQo/ZI4FR3N899KrVXUh 1Q7LVNVChYAkLNP0WX3RiS3TEIBnd0jf2SmCP5Mi75GiPq2ssuOQk+Ox3Mf0TdR4jOaS F1bvQFzthjFsClTWrsOaRXc5WJToLVBsrY8iTz0wykkjCeMflyje4zcy3mmKjwUV2asV FILH7BrNQTz5Bj1gpeB0SHuwjnLtlOtZPbW/nirhAGlcljs4j+smbU57uW9rpkgl5cJa aMNg== Received: by 10.42.51.142 with SMTP id e14mr16045398icg.2.1356280980437; Sun, 23 Dec 2012 08:43:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.19 with HTTP; Sun, 23 Dec 2012 08:42:40 -0800 (PST) In-Reply-To: References: <20121221172032.28253.90788.idtracker@ietfa.amsl.com> <065701cddfa1$fa73bc70$ef5b3550$@packetizer.com> From: James M Snell Date: Sun, 23 Dec 2012 08:42:40 -0800 Message-ID: To: chris.dent@gmail.com Content-Type: multipart/alternative; boundary=20cf302239990df8c604d187c69c Cc: "webfinger@ietf.org" Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 16:43:03 -0000 --20cf302239990df8c604d187c69c Content-Type: text/plain; charset=UTF-8 When it comes to JSON, because we don't have anything similar to a namespace to key off of when parsing, a specific media type really does help to determine if the server returned the right kind of JSON-based thing in response to the query. I don't see a specific media type as being critical in any way for WebFinger but it can be helpful if provided. On Sun, Dec 23, 2012 at 7:54 AM, wrote: > On Sat, 22 Dec 2012, Tim Bray wrote: > > I've also wondered why we don't have application/webfinger+json; seems to >> me that having your own media-type is a strong Web best practice. Has >> this >> been discussed? -T >> > > Can you point me to references to _why_ that is "best practice"? > > It's something I find quite annoying. It's application/json, being > used in a webfinger context. In some other context it could be used > for something else. > > In both contexts it is a JSON representation, you use JSON tools to > process it. > > Having another media-type seems to just make things more noisy. Is the > point to have some little agent sitting around being all smart because > it can trigger imporant decision based merely on the media-type of its > input? If that's so, I'm not sure I buy it: We wouldn't have gone to > this resource in the first place if we weren't hoping to get webfinger > info back. > > Help me understand. > > Thanks. > > -- > Chris Dent http://burningchrome.com/ > [...] > > ______________________________**_________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/**listinfo/webfinger > --20cf302239990df8c604d187c69c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When it comes to JSON= , because we don't have anything similar to a namespace to key off of w= hen parsing, a specific media type really does help to determine if the ser= ver returned the right kind of JSON-based thing in response to the query. I= don't see a specific media type as being critical in any way for WebFi= nger but it can be helpful if provided.


On Sun, Dec 2= 3, 2012 at 7:54 AM, <chris.dent@gmail.com> wrote:
On Sat, 22 Dec 2012, Tim Bray wrote:

I've also wondered why we don't have application/webfinger+json; se= ems to
me that having your own media-type is a strong Web best practice. =C2=A0Has= this
been discussed? =C2=A0-T

Can you point me to references to _why_ that is "best practice"?<= br>
It's something I find quite annoying. It's application/json, being<= br> used in a webfinger context. In some other context it could be used
for something else.

In both contexts it is a JSON representation, you use JSON tools to
process it.

Having another media-type seems to just make things more noisy. Is the
point to have some little agent sitting around being all smart because
it can trigger imporant decision based merely on the media-type of its
input? If that's so, I'm not sure I buy it: We wouldn't have go= ne to
this resource in the first place if we weren't hoping to get webfinger<= br> info back.

Help me understand.

Thanks.

--
Chris Dent =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://burningchrome.com/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger

--20cf302239990df8c604d187c69c-- From Michael.Jones@microsoft.com Sun Dec 23 16:58:47 2012 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9406821F8432 for ; Sun, 23 Dec 2012 16:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tt4jcYSqq0d for ; Sun, 23 Dec 2012 16:58:42 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5692221F84A1 for ; Sun, 23 Dec 2012 16:58:42 -0800 (PST) Received: from BL2FFO11FD013.protection.gbl (10.173.161.201) by BL2FFO11HUB006.protection.gbl (10.173.160.226) with Microsoft SMTP Server (TLS) id 15.0.586.12; Mon, 24 Dec 2012 00:58:38 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Mon, 24 Dec 2012 00:58:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 24 Dec 2012 00:58:37 +0000 From: Mike Jones To: nov matake , Paul E.Jones Thread-Topic: [webfinger] feedback for multiple "rel" Thread-Index: AQHN3/+eSie8sTWSRUKfpZnUR5r31Zgk9oGAgAAHtICAAILKAIAADi0AgAALAgCAAAKdgIAACYuAgAAiF4CAAAKvAIAAApoAgAFTkDA= Date: Mon, 24 Dec 2012 00:58:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436699FA11@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <58036BAD-2161-4420-A724-343883F627B7@gmail.com> <7E9916BF-8D64-4F61-A40F-3A74533AEFD2@gmail.com> <001101cde0a0$7fda6220$7f8f2660$@packetizer.com> <004d01cde0ad$175b5d00$46121700$@packetizer.com> <57CE8BD9-286D-460E-92D8-E4E64C3377D0@gmail.com> <006601cde0b3$2bb9ff30$832dfd90$@packetizer.com> <9D326871-8C8D-41A7-A6E0-A4E45FA75E09@gmail.com> <00a501cde0c5$8fb5d510$af217f30$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436699FA11TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(69234002)(377454001)(479174001)(47446002)(59766001)(33656001)(74662001)(51856001)(56816002)(49866001)(4396001)(15202345001)(74502001)(31966008)(46102001)(54316002)(56776001)(16236675001)(512954001)(5343635001)(5343655001)(50986001)(44976002)(16406001)(15395725002)(16601075001)(47976001)(77982001)(76482001)(550184003)(53806001)(54356001)(47736001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB006; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0705EB1700 Cc: "webfinger@ietf.org" , 'James M Snell' , 'Melvin Carvalho' , 'Dick Hardt' Subject: Re: [webfinger] feedback for multiple "rel" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 00:58:47 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436699FA11TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few thoughts after reading this thread. First, while space-separating va= lues worked for OAuth scopes (because scope values were a new thing and we = could just prohibit them from containing spaces) it wouldn't work as well f= or "rel" values, since URIs are not a new thing and we can't prohibit them = from containing spaces (when represented as %20). So I believe that the ch= ange to use multiple "rel" parameter instead was a good one, and one well s= upported by the reasoning in the earlier thread on this topic. To Nov's particular issue, a few thoughts come to mind. First "rel" is an = optimization. It's legal for a server to ignore all "rel" values and just = return everything. That would be a very simple, if inelegant, solution to = the Rails issue you're facing, Nov. Second, if the work you're doing is scoped to just supporting OpenID Connec= t discovery, you will never have to support multiple "rel" values. You'll = only be receiving requests without "rel" or with a single "rel" parameter o= f the form rel=3Dhttp%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer. = If you're never going to receive multiple "rel" parameters, you can ignore= the Rails issue. Again - inelegant, but practically workable. Cheers, -- Mike From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of nov matake Sent: Saturday, December 22, 2012 8:35 PM To: Paul E.Jones Cc: webfinger@ietf.org; 'James M Snell'; 'Melvin Carvalho'; 'Dick Hardt' Subject: Re: [webfinger] feedback for multiple "rel" Developers who uses my library in their rails project would use that functi= on. I can't stop them. Of course, I can ask developers to give raw request object (which includes = raw requested url, cookies etc) to my library. But developers will feel weird to give raw request object only for multiple= rel case, I think. =3D=3D=3D=3D # put raw request object WebFinger.discover @request # put resource & rel only (I prefer this one) WebFinger.discover params[:resource], params[:rel] =3D=3D=3D=3D On 2012/12/23, at 13:25, Paul E. Jones > wrote: Nov, Do you absolutely need to use that particular function? It appears that it= returns an associative array where the values are not array (unlike the "c= gi" code). So, if using it is required, this will certainly present a chal= lenge. I would assume WF is not the first thing to use multiple parameters with th= e same name. This has not been encountered before? Paul From: nov matake [mailto:matake@gmail.com] Sent: Saturday, December 22, 2012 11:16 PM To: Paul E. Jones Cc: 'Dick Hardt'; 'James M Snell'; webfinger@ietf.org; 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" CGI library handle it well. It returns query values as array even when it's a single value though. So the issue is Rails (actually it uses Rack::Utils.parse_nested_query) onl= y. It takes only the last "rel" value. > require 'rack' > Rack::Utils.parse_nested_query "rel=3Da&rel=3Db" =3D> {"rel"=3D>"b"} On 2012/12/23, at 11:13, "Paul E. Jones" > wrote: Dick, Nov, I've never written a Ruby program before, but I was quite curious as to whe= ther it was or was not possible to access multiple "rel" parameters. It ap= pears that is. Here's my first Ruby program (and my apologies to the devel= opers of Ruby): #!/bin/ruby require 'cgi' cgi =3D CGI.new params =3D cgi.params # Following appears to show an associative array with values that are array= s puts params; # Grab the 'rel' array rels =3D params['rel']; # Display the array puts rels; # How many items are in the "rel" array? count =3D rels.size print "Number of rel params: ", count, "\n"; # Can I access each one? for i in 0..(count-1) print "Item ", i, ": ", rels[i], "\n" end Here's what I get: $ ./test "rel=3Drel1&c=3Dd&rel=3Drel2&e=3Df" {"rel"=3D>["rel1", "rel2"], "c"=3D>["d"], "e"=3D>["f"]} rel1 rel2 Number of rel params: 2 Item 0: rel1 Item 1: rel2 So, it looks like it works to me. Is the issue only with Rails? I'm not g= oing to venture down that path to see what the issue is, but if Ruby can ac= cess the data, can't it provide it to Rails in a form that it likes? Paul From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Saturday, December 22, 2012 8:40 PM To: Paul E. Jones Cc: 'James M Snell'; webfinger@ietf.org; 'nov ma= take'; 'Melvin Carvalho' Subject: Re: [webfinger] feedback for multiple "rel" FYI: multiple query string params with the same name are turned into arrays= or parsed into arrays in node.js the following script: var querystring =3D require('querystring') console.log( querystring.parse( 'foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2' ) ) console.log( querystring.stringify( {'foo':'bar','rel':['token1','token2']}= ) ) outputs: { foo: 'bar', rel: [ 'token1', 'token2' ] } foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2 Perhaps Ruby devs should just move to the next cool language? :-) Seriously though, what does the query string parser do in Ruby? -- Dick On Dec 22, 2012, at 5:30 PM, "Paul E. Jones" > wrote: That depends on where they're used. If I tell you the "rel" value is "http= ://example.com/first one", I don't escape that as I write it. Or are you s= aying there is text somewhere that already makes that, as written, illegal? I'm quite favorable to a space-separated list of rel values in a single rel= parameter, too. I was concerned before that spaces would present an issue= , but figured we could either we make spaces illegal in rel values (which w= e can do since those are fabricated things!) or we double-escape. My prefe= rence is a single escape and a single rel parameter and spaces are illegal = in the "rel" values themselves. But, the forces that be pushed pretty hard to change from &rel=3Dtoken1%20t= oken to &rel=3Dtoken1&rel=3Dtoken2. At the end of the day, it makes no dif= ference to me since I just need to know which way to deal with it. So Ruby can really only support only a single parameter with a given name? = It will not collect those into an array or anything? Paul From: James M Snell [mailto:jasnell@gmail.com] Sent: Saturday, December 22, 2012 7:51 PM To: Paul E. Jones Cc: nov matake; Melvin Carvalho; webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" Spaces in rel values are already illegal.. specifically, spaces are disallo= wed in registered link relations and non-escaped spaces are disallowed in a= bsolute IRI's.. A comma delimited list of rel's is better than multiple ind= ividual parameters.. even with the potential need for double encoding. On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones > wrote: If we made it a requirement that "rel" values have no spaces (which I would= argue is a damn good thing for many reasons) then we would not have to dou= ble-encode. Paul From: webfinger-bounces@ietf.org [mailto= :webfinger-bounces@ietf.org] On Behalf O= f nov matake Sent: Saturday, December 22, 2012 11:12 AM To: Melvin Carvalho Cc: webfinger@ietf.org Subject: Re: [webfinger] feedback for multiple "rel" BTW, why double encoding lead "problems with things like canonical urls and= search engines"? Can you provide more details? If 2 rel included, the response would be different than when only 1 rel giv= en. So I feel those 2 are not the same, and can be indexed as 2 resources.. On 2012/12/23, at 0:44, Melvin Carvalho > wrote: On 22 December 2012 05:48, nov matake > wrote: Hi, I have a comment for they way to specify multiple "rel" values. As a ruby library developer, my main target is rails developers. Since rails can't handle multiple same query keys, developers will need to = hack query params parser in rails middleware layer. I can easily imagine it'll be an annoying part to support webfinger in rail= s. Is the multiple "rel" case can be a space-delimitered (or some other charac= ter) strings like multiple redirect_uri in OAuth2? Or any reason for putting multiple same keys in query parameters? each time you delimit a list, you have to be able to escape the delimiter, = which can be a pain and also leads to problems with things like canonical u= rls and search engines can you use mod_rewrite? Cheers, Nov Matake _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_000_4E1F6AAD24975D4BA5B16804296739436699FA11TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few thoughts after read= ing this thread.  First, while space-separating values worked for OAut= h scopes (because scope values were a new thing and we could just prohibit them from containing spaces) it wouldn’t work as well = for “rel” values, since URIs are not a new thing and we canR= 17;t prohibit them from containing spaces (when represented as %20).  = So I believe that the change to use multiple “rel” parameter instead was a good one, and one well supported by the reasoning in the ear= lier thread on this topic.

 <= /p>

To Nov’s particular= issue, a few thoughts come to mind.  First “rel” is an op= timization.  It’s legal for a server to ignore all “rel= 221; values and just return everything.  That would be a very simple, if inelegant, solution to t= he Rails issue you’re facing, Nov.

 <= /p>

Second, if the work you&#= 8217;re doing is scoped to just supporting OpenID Connect discovery, you wi= ll never have to support multiple “rel” values.  You’= ;ll only be receiving requests without “rel” or with a single “rel&#= 8221; parameter of the form rel=3Dhttp%3A%2F%2Fopenid.net%= 2Fspecs%2Fconnect%2F1.0%2Fissuer.  I= f you’re never going to receive multiple “rel” parameters= , you can ignore the Rails issue.  Again – inelegant, but practically wor= kable.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: webfinge= r-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake
Sent: Saturday, December 22, 2012 8:35 PM
To: Paul E.Jones
Cc: webfinger@ietf.org; 'James M Snell'; 'Melvin Carvalho'; 'Dick Ha= rdt'
Subject: Re: [webfinger] feedback for multiple "rel"<= /o:p>

 

Developers who uses my library in their rails projec= t would use that function.

I can't stop them.

 

Of course, I can ask developers to give raw request = object (which includes raw requested url, cookies etc) to my library.<= o:p>

But developers will feel weird to give raw request o= bject only for multiple rel case, I think.

 

=3D=3D=3D=3D

# put raw request object

WebFinger.discover @request

 

# put resource & rel only (I prefer this one)

WebFinger.discover params[:resource], params[:rel]

=3D=3D=3D=3D

 

On 2012/12/23, at 13:25, Paul E. Jones <paulej@packetizer.com> wrote:=



Nov,

 <= /p>

Do you absolutely need to= use that particular function?  It appears that it returns an associat= ive array where the values are not array (unlike the “cgi” code= ).  So, if using it is required, this will certainly present a challenge.

 <= /p>

I would assume WF is not = the first thing to use multiple parameters with the same name.  This h= as not been encountered before?

 <= /p>

Paul

 <= /p>

From: nov matake [mailto:matake@gmail.com] 
Sent: Saturday, De= cember 22, 2012 11:16 PM
To: Paul E. Jones<= br> Cc: 'Dick Hardt'; = 'James M Snell'; webfinger@ietf.org; 'Melvin Carva= lho'
Subject: Re: [webf= inger] feedback for multiple "rel"

 

CGI library handle it well.

It returns query values as array even when it's a si= ngle value though.

 

So the issue is Rails (actually it uses Rack::Utils.= parse_nested_query) only.

It takes only the last "rel" value.

 

> require 'rack'

> Rack::Utils.parse_nested_query "rel= =3Da&rel=3Db"

=3D> {"rel"=3D>"b"} <= o:p>

 

 

On 2012/12/23, at 11:13, "Paul E. Jones" &= lt;pa= ulej@packetizer.com> wrote:




Dick, Nov,

 <= /p>

I’ve never written = a Ruby program before, but I was quite curious as to whether it was or was = not possible to access multiple “rel” parameters.  It appe= ars that is.  Here’s my first Ruby program (and my apologies to the= developers of Ruby):

 <= /p>

#!/bin/ruby

 

require 'cgi'

 

cgi =3D CGI.new

 

params =3D cgi.params

 

# Following appears to show an associative ar= ray with values that are arrays

puts params;

 

# Grab the 'rel' array

rels =3D params['rel'];

 

# Display the array

puts rels;

 

# How many items are in the "rel" a= rray?

count =3D rels.size

print "Number of rel params: ", cou= nt, "\n";

 

# Can I access each one?

for i in 0..(count-1)

   print "Item ", i, &quo= t;: ", rels[i], "\n"

end

 <= /p>

Here’s what I get:<= /span>

 <= /p>

$ ./test "rel=3Drel1&c=3Dd&rel= =3Drel2&e=3Df"

{"rel"=3D>["rel1", &qu= ot;rel2"], "c"=3D>["d"], "e"=3D>[&= quot;f"]}

rel1

rel2

Number of rel params: 2

Item 0: rel1

Item 1: rel2

 <= /p>

So, it looks like it work= s to me.  Is the issue only with Rails?  I’m not going to v= enture down that path to see what the issue is, but if Ruby can access the data, can’t it provide it to Rails in a form that it likes?

 <= /p>

Paul

 <= /p>

From: Dick Hardt [mailto:dick.hardt@gmail.com] <= /span>
Sent: Saturday, De= cember 22, 2012 8:40 PM
To: Paul E. Jones<= br> Cc: 'James M Snell= '; webfinger@ietf.org;= 'nov matake'; 'Melvin Carvalho'
Subject: Re: [webf= inger] feedback for multiple "rel"

 

FYI: multiple query string params with the same name = are turned into arrays or parsed into arrays in node.js

 

the following script:

 

var querystring =3D require('querystring')

console.log( querystring.parse( 'foo=3Dbar&rel=3D= token1&rel=3Dtoken2' ) )

console.log( querystring.stringify( {'foo':'bar','rel= ':['token1','token2']} ) )

 

outputs:

 

{ foo: 'bar', rel: [ 'token1', 'token2' ] }

foo=3Dbar&rel=3Dtoken1&rel=3Dtoken2

 

Perhaps Ruby devs should just move to the next cool l= anguage? :-)

Seriously though, what does the query string parser d= o in Ruby?

 

-- Dick

 

On Dec 22, 2012, at 5:30 PM, "Paul E. Jones"= ; <paulej@packetizer.com> wrote:





That depends on where the= y’re used.  If I tell you the “rel” value is “= http://ex= ample.com/first one”, I don’t escape that as I write it.  Or are you saying there is = text somewhere that already makes that, as written, illegal?

 <= /p>

I’m quite favorable= to a space-separated list of rel values in a single rel parameter, too.&nb= sp; I was concerned before that spaces would present an issue, but figured we could either we make spaces illegal in rel values (which we can= do since those are fabricated things!) or we double-escape.  My prefe= rence is a single escape and a single rel parameter and spaces are illegal = in the “rel” values themselves.

 <= /p>

But, the forces that be p= ushed pretty hard to change from &rel=3Dtoken1%20token to &rel=3Dto= ken1&rel=3Dtoken2.  At the end of the day, it makes no difference = to me since I just need to know which way to deal with it.

 <= /p>

So Ruby can really only s= upport only a single parameter with a given name?  It will not collect= those into an array or anything?

 <= /p>

Paul

 <= /p>

From: James M Snell [mailto:jasnell@gmail.com] 
Sent: Saturday, De= cember 22, 2012 7:51 PM
To: Paul E. Jones<= br> Cc: nov matake; Me= lvin Carvalho; webfinger@ietf.org=
Subject: Re: [webf= inger] feedback for multiple "rel"

 

= Spaces in rel values are already illegal.. specifically, spaces are disallo= wed in registered link relations and non-escaped spaces are disallowed in a= bsolute IRI's.. A comma delimited list of rel's is better than multiple individual parameters.. even with the potential ne= ed for double encoding.

 

 

 

On Sat, Dec 22, 2012 at 4:00 PM, Paul E. Jones <paulej@packetizer.com> wrote:

If we made it a requireme= nt that “rel” values have no spaces (which I would argue is a d= amn good thing for many reasons) then we would not have to double-encode.

 <= /p>

Paul

 <= /p>

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of nov matake=
Sent: Saturday, De= cember 22, 2012 11:12 AM
To: Melvin Carvalh= o


Cc: webf= inger@ietf.org
Subject: Re: [webf= inger] feedback for multiple "rel"

 

BTW, why double encoding lead "problems with thi= ngs like canonical urls and search engines"?

Can you provide more details?

 

If 2 rel included, the response would be different th= an when only 1 rel given.

So I feel those 2 are not the same, and can be indexe= d as 2 resources..

 

On 2012/12/23, at 0:44, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

 

 

On 22 December 2012 05:48, nov matake <mat= ake@gmail.com> wrote:

Hi,

I have a comment for they way to specify multiple "rel" values.
As a ruby library developer, my main target is rails developers.
Since rails can't handle multiple same query keys, developers will need to = hack query params parser in rails middleware layer.
I can easily imagine it'll be an annoying part to support webfinger in rail= s.

Is the multiple "rel" case can be a space-delimitered (or some ot= her character) strings like multiple redirect_uri in OAuth2?
Or any reason for putting multiple same keys in query parameters?


each time you delimit a list, you have to be able to escape the delimiter, = which can be a pain and also leads to problems with things like canonical u= rls and search engines

can you use mod_rewrite?
 


Cheers,

Nov Matake
_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfi= nger

 

 


_______________________________________________
webfinger mailing list
webfinge= r@ietf.org
https://www.ietf.org/mailman/listinfo/webfi= nger

 

_____________________________________= __________
webfinger mailing list
webfinge= r@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

--_000_4E1F6AAD24975D4BA5B16804296739436699FA11TK5EX14MBXC283r_--