From nobody Mon Apr 2 15:55:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4303212DA15 for ; Mon, 2 Apr 2018 15:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QsAcIWK4ZWb for ; Mon, 2 Apr 2018 15:55:22 -0700 (PDT) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533D31252BA for ; Mon, 2 Apr 2018 15:55:22 -0700 (PDT) Received: by mail-vk0-f52.google.com with SMTP id m69so7151683vka.8 for ; Mon, 02 Apr 2018 15:55:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ictT4EaRRky7Md0BsGbNuQ9j9GaFHd2LJpaK2m6VMgM=; b=VAViRHAbVd8AvXG8GKDXsLqGKrpUIgt6LVYgaPvT7ltU/ndaiU6dt9IYi7vrVGeftU KspRdjC++45PkQgavTKTeVt5fCxbWwseYKvuJL4fmQLWko0VJJeackoXzNSwNtzjEApu /6dIL3G/tadxHTeyUm7dnKdiQQ44Iuh+S9wIsgZYVlsWdnXuMkNu1MkDP3/AS025QESi kBzwe00RjBNZPjMUqct5u179j4dH0ffGgiR8EwNDNmL9xE7YaRHMZY9bupthZco7R4h0 3Vs+ahwPEK/o1LMh9d1LfDd+o0IZJK+r1cvDd2kMT6rE1RaiJMjci35Fj4I9jEmD3Orc 5sUQ== X-Gm-Message-State: ALQs6tA6ZS3oLt+7UTAsb8oW4KsVQ+o16iOUxrDo7gZT0vgzzE0hWLR6 mYMTWFeLIPlxC/QCcrUlRDLJzwQ6GPdqWzn7JXL/4A== X-Google-Smtp-Source: AIpwx49w11yaum4GnHswoyTaoMR85WiciTogba/XO8v1MrQKycM+aOVkqrYLoGCMBSItnQHaM7FfnGT9UHL8FfRwijE= X-Received: by 10.31.165.3 with SMTP id o3mr4648015vke.76.1522709721073; Mon, 02 Apr 2018 15:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.201.149 with HTTP; Mon, 2 Apr 2018 15:55:20 -0700 (PDT) From: Bill Burke Date: Mon, 2 Apr 2018 18:55:20 -0400 Message-ID: To: OAuth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] public clients and token exchange X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:55:24 -0000 We have a need for public clients to perform token exchanges. Anybody have any recommended policies for this? I'm worried about untrusted services obtaining a bearer token that they can exchange for upgraded permissions. The Auth Server has to put a lot of trust in the public client to do the right thing. What should be the initial access token the public client gets? 1) One approach is that it receives an access token devoid of privileges. This forces the public client to request an exchange before invoking on anything. Then what should be the validation policy with teh Auth Server? Do not allow upgrading of token unless the token being exchanged has zero scopes/audiences? 2) Another approach is that the initial access token has all privilges the public client needs and the public client downgrades the token before performing invocations. The auth server only needs to check that the client is asking for a downgrade. 3) The last approach we are considering is a combination of #1 and to only allow public clients to exchange a refresh token. Being in possession of a refresh token means that the public client has been involved with a code to token flow, or a password credentials grant. For code to token, this means the public client had a valid redirect uri. For password credentials grant, the client was trusted enough to obtain user credentials. -- Bill Burke Red Hat From nobody Wed Apr 4 10:26:55 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A0126C22 for ; Wed, 4 Apr 2018 10:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZCowJUIrDZn for ; Wed, 4 Apr 2018 10:26:35 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F67312D969 for ; Wed, 4 Apr 2018 10:26:35 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id m69so10834607vka.8 for ; Wed, 04 Apr 2018 10:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WY1DsMTZX808qFLK6MPwnn/js+VCowq9VgTnTvGO2MU=; b=UUZamyX00NDgrXqfGBScl3zqSShSfYQUaQZuL0jTJknn7hF8UyOuOukOz8NtEDz/jM f4fr5rLvvaLGCSVxNoxZNmqQkysMA/28gTgJixOP9rWPXtrllu5MEfA4rjC+HFvK9tEH nfVNO9D05PpybITeW5ahdAZLgx0nydkeuLntt/b8wQAei9nGG2bGYQSjhCiWvOoldyfc kiP4hURP9OAVlwrjU3fggwe9CkFFHhIUOpHKKylFvDEFtIKkRm5pHSbmtTjB+LtHki6o 3KIUWsm5XfBKSm2kbRy4m1AhSMoNdntTw6e2H93+jWHxZjGotvzuIVhrQuKw/vNenr/l qfPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WY1DsMTZX808qFLK6MPwnn/js+VCowq9VgTnTvGO2MU=; b=CmM7ue0Dt4KHNGk/cQeb3tg/nDhAukfJh/TNV7o0P11enrG2ZCE4Cy9skzThFqtJ3g 7kzh9tL0M0kCyVFYM3Gf9GReEZYwfSBPw1t79Qwyg8ELf3piuzV/HgwmCs/bw7V3rv0n eUy/q5i6s8kKGfD2ggZD+DNvI0ZzS/dnMQl6tg/oOrs/D8mHX0KyHswBWrRyllxFB3RU hAEqkeeCjf4p5ALOczFMqfum9/aFWNj+tsTPtYi1gJOlE3BDnHhMtWO9SdahpDdJU81t i+81SCB/fD0tIGXp24dx/P5V93jnIj/LQrqrj4aLMp6U0kGGGCoXwtmWTC8PA27KOENV b4Ag== X-Gm-Message-State: ALQs6tAZ3MaB0rZ+9qaWy/2uaTmsOi7XaZCTChHlbm4pMHqGpFc69bH0 4OqQQflxL6PD17gnfRyA2Fi9bR7SUEj/xYRym2vxPpuh X-Google-Smtp-Source: AIpwx4/Yt7vXPz6hGI68K2geohOP7sVBnm1Mag1GQ+s3CeDo6Ni2G02b1a40MJt7zr/nDIbz8ztXhoApgkQbq2QbLys= X-Received: by 10.31.210.3 with SMTP id j3mr11152324vkg.105.1522862794037; Wed, 04 Apr 2018 10:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.44.154 with HTTP; Wed, 4 Apr 2018 10:26:33 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Wed, 4 Apr 2018 13:26:33 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114e53c8e15fca0569091f52" Archived-At: Subject: [OAUTH-WG] IETF101 OAuth Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:26:44 -0000 --001a114e53c8e15fca0569091f52 Content-Type: text/plain; charset="UTF-8" Hi, Here are the meeting minutes from the last IETF101 meeting in London: https://datatracker.ietf.org/meeting/101/materials/minutes-101-oauth-03 Please, let us know if you have any comments. Thanks to *Tony *& *Phil *for taking notes. Regards, Rifaat & Hannes --001a114e53c8e15fca0569091f52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here are the meeting min= utes from the last IETF101 meeting in London:

Please, let us know if you have any comments.
Thanks to Tony & Phil for taking notes.
=

Regards,
=C2=A0Rifaat & Hannes
=
--001a114e53c8e15fca0569091f52-- From nobody Wed Apr 4 17:42:07 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3812785F for ; Wed, 4 Apr 2018 17:42:06 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5Np66gIC4Jh for ; Wed, 4 Apr 2018 17:42:01 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E301201F2 for ; Wed, 4 Apr 2018 17:42:01 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id b20so28521114iof.5 for ; Wed, 04 Apr 2018 17:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pk9JkHrPqHR8PWa90Idqyvyn+JdNV5NVvYkFSXm6rHw=; b=h1jtMW9LNLlVVyPxQ5qA2t63D7eIJy3qBrRATTYdOal7X4F5kSctALWU+qu6VSQGw4 cjs4ngcbfKhsQmGnBipIEdz060IhRPUAuvIYA86+Mghhd1Gkao0whcunm6bWmTbJZwNC mjeike4r4OCJ4bjKomkOC2f6a0GZ3KRfSvznY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pk9JkHrPqHR8PWa90Idqyvyn+JdNV5NVvYkFSXm6rHw=; b=WTl1dAc2WSpix28XONsMJfWC0liwd8FMHHkT8GuSVV3TtwpBT6ck9rsm+DYz35ltO6 IyJHP5bnkelTNtmFJh6+d66BV4QOozhSfcwxVeYjwLcjCr7hOP1Bt/NUrcO/5mxyYldB b98zayVTsqGej4/1X+df8OXf98VVgz04zjtR/huJXFfGYkC/chWw46pDuhacpHR/cisW utl7DRzbQtk9Xut9Ex06OfiE8QW+KG3UPLeH1vhl+xJNJPxlPTljuIPUwMY9JdC36q2b XktWOjfaBbtwXAVmEExRGsWtd7K6DhgjI+PbiuugnL9D0SvROYP4XxWn7Q+LZPzgzn1N A6uw== X-Gm-Message-State: ALQs6tCUl4CUF0QMYEYaC4halVRwHOwSwcUte+jL+eRICBONYQCr5EX+ R9foUXp2UAgJDhE04YvpXHekbi/iX/n1aylKmUkWjlm4aCJ804TGdPCTcx55XFQaPPacUbC1Kfc ad/7nIWXPeMrIvHwb X-Google-Smtp-Source: AIpwx49sbjgj0o8clTvA2f+AhIu5ABsH2wtSD6shcFnaGRGr4zrlx5184Brfq8KfC4w27GutJ6jPjCNi5aQbk6kma3Y= X-Received: by 10.107.3.41 with SMTP id 41mr17717651iod.17.1522888920193; Wed, 04 Apr 2018 17:42:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Wed, 4 Apr 2018 17:41:29 -0700 (PDT) In-Reply-To: References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> From: Brian Campbell Date: Thu, 5 Apr 2018 03:41:29 +0300 Message-ID: To: Justin Richer Cc: Vivek Biswas , "" Content-Type: multipart/alternative; boundary="001a113fbf541f079a05690f35ed" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 00:42:06 -0000 --001a113fbf541f079a05690f35ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Strongly agree with Justin that any kind of TLS header forwarding standards like that are well beyond the scope of this spec. On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer wrote: > I don=E2=80=99t believe this is the spec to define TLS header forwarding = standards > in. > > =E2=80=94 Justin > > > On Mar 30, 2018, at 2:03 PM, Vivek Biswas wrote= : > > There are additional challenges which we have faced. > > A. Most of the Mutual SSL communication as mentioned below > terminates at the LBR and the LBR needs to have client certificates to > trust the client. But lot of times the connection from LBR to Authorizati= on > server may be non-SSL. > > The CN, SHA-256 thumprint and serial number of the Client Cert are sent a= s > header to the AuthzServer/Backend Server. However, if the connection from > LBR to AuthzServer/Backend Server is unencrypted it is prone to MIM > attacks. Hence, it=E2=80=99s a MUST requirement to have one-way SSL from = LBR to > AuthzServer/Backend Server, so that the headers passed are not compromise= d. > > This is a MOST common scenario in a real world. And we don=E2=80=99t want= everyone > come up with their own names for the header. There should be some kind of > standardization around the header names. > > Regards > Vivek Biswas, CISSP > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com ] > *Sent:* Thursday, March 29, 2018 11:57 AM > *To:* Neil Madden > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 > > Yes that is quite a common deployment scenario. I think that is the way > most of the Open Banking implementations have deployed it currently. > > The intent is to support that. One problem is that how the certificate > is transmitted to the application tends to be load balancer/reverse proxy > specific as no real standard exists. > > If you think that needs to be clarified text is welcome. > > John B. > > > > > On Mar 29, 2018, at 2:54 PM, Neil Madden > wrote: > > Thanks, and understood. > > The privacy concerns are mostly around correlating activity of *clients*, > which may or may not reveal activity patterns of users using those client= s. > I don=E2=80=99t know how much of a concern that is in reality, but though= t it > should be mentioned. > > A colleague also made the following comment about the draft: > > =E2=80=9CIt is still quite common to terminate TLS in a load balancer or = proxy, > and to deploy authorization servers in a secure network zone behind an > intermediate in a DMZ. In these cases, TLS would not be established betwe= en > the client and authorization server as per =C2=A72, but information about= the > TLS handshake may be made available by other means (typically adding to a > downstream header) allowing lookup and verification of the client > certificate as otherwise described. Given the prevalence of this approach > it would be good to know whether such a deployment would be compliant or > not.=E2=80=9D > > Kind regards, > Neil > -- > > > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley > wrote: > Thanks for the feedback. We will review your comments and reply. > > One data point is that this will not be the only POP spec. The spec using > token binding vs mtls has better privacy properties. It is UK Open bankin= g > that has pressed us to come up with a standard to help with > interoperability. > > This spec has been simplified in some ways to facilitate the majority of > likely deployments. > > I understand that in future certificates may have better than SHA256 > hashes. > > Regards > John B. > > > > On Mar 29, 2018, at 12:18 PM, Neil Madden > wrote: > > Hi, > > I have reviewed this draft and have a number of comments, below. ForgeRoc= k > have not yet implemented this draft, but there is interest in implementin= g > it at some point. (Disclaimer: We have no firm commitments on this at the > moment, I do not speak for ForgeRock, etc). > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defin= es > a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is a= lready a > confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key= , which itself can > contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax a= nd semantics. The > draft proposes: > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6= =E2=80=9D } } > > but you can already do: > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9C= x5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } > > If the intent is just to save some space and avoid the mandatory fields o= f > the existing JWK types, maybe this would be better addressed by defining = a > new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: > =E2=80=9C=E2=80=A6=E2=80=9D }. > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s > really only the client authentication that we are interested here, and th= e > fact that the server also authenticates with a certificate is not hugely > relevant to this particular spec (although it is to the overall security = of > OAuth). Also, TLS defines non-certificate based authentication mechanisms > (e.g. TLS-SRP extension for password authenticated key exchange, PSK for > pre-shared key authentication) and even non-X.509 certificate types ( > https://www.iana.org/assignments/tls-extensiontype- > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2= =80=99d > prefer that the draft explicitly referred to =E2=80=9CX.509 Client Certif= icate > Authentication=E2=80=9D rather than mutual TLS, and changed identifiers l= ike > =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf= -oauth-mtls-07# > section-2.1.1) to something more explicit like =E2=80=98tls_x509_pki_clie= nt_auth=E2=80=99. > > > This is especially confusing in section 3 on sender constrained access > tokens, as there are two different servers involved: the AS and the > protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authe= ntication between > them, only between each of them and the client. > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC > only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The > wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be u= sed with > TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. > > 4. It might be useful to have a discussion for implementors of whether TL= S > session resumption (and PSK in TLS 1.3) and/or renegotiation impact the u= se > of client certificates, if at all? > > 5. Section 3 defines sender-constrained access tokens in terms of the > confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 > Pop Architecture draft defines sender constraint and key confirmation as > different things (https://tools.ietf.org/html/draft-ietf-oauth-pop- > architecture-08#section-6.2). The draft should decide which of those it > is implementing and if sender constraint is intended, then reusing the > confirmation key claims seems misleading. (I think this mTLS draft is doi= ng > key confirmation so should drop the language about sender constrained > tokens). > > 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html= / > draft-ietf-oauth-pop-architecture-08#section-5 > > ): > > Strong, fresh session keys: > > Session keys MUST be strong and fresh.. Each session deserves an > independent session key, i.e., one that is generated specifically > for the intended use. In context of OAuth this means that keying > material is created in such a way that can only be used by the > combination of a client instance, protected resource, and > authorization scope. > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/ > draft-ietf-oauth-mtls-07#section-3) says: > > The client makes protected resource requests as described in > [RFC6750], however, those requests MUST be made over a mutually > authenticated TLS connection using the same certificate that was used > for mutual TLS at the token endpoint. > > These two statements are contradictory: the OAuth 2.0 PoP architecture > effectively requires a fresh key-pair to be used for every access token > request, whereas this draft proposes reusing the same long-lived client > certificate for every single access token and every resource server. > > In the self-signed case (and even in the CA case, with a bit of work - > e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is > perfectly possible for the client to generate a fresh key-pair for each > access token and include the certificate on the token request (e.g., as p= er > https://tools.ietf.org/html/draft-ietf-oauth-pop-key- > distribution-03#section-5.1 - in which case an appropriate =E2=80=9Calg= =E2=80=9D value > should probably be described). This should probably at least be an option= . > > > 7. The use of a single client certificate with every resource server (RS) > should be called out in a Privacy Considerations section, as it allows > correlation of activity. > > 8. This is maybe a more general point, but RFC 6750 defines the > Authorization: Bearer scheme (https://tools.ietf.org/html/ > rfc6750#section-2) for a client to communicate it=E2=80=99s access token = to the > RS in a standard way. As sender-constrained access tokens are not strictl= y > bearer tokens any more, should this draft also register a new scheme for > that? Should there be a generic PoP scheme? > > 9. The Security Considerations should really make some mention of the lon= g > history of attacks against X.509 certificate chain validation, e.g. failu= re > to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in= parsing DNs, etc. > It should be strongly suggested to use an existing TLS library to perform > these checks rather than implementing your own checks. This relates to > Justin=E2=80=99s comments around DN parsing and normalisation. > > 10. The PKI client authentication method (https://tools.ietf.org/html/ > draft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of > certificate revocation and how to handle checking for that (CRLs, OCSP - > with stapling?). Neither does the Security Considerations. If this is a > detail to be agreed between then AS and the CA (or just left up to the AS > TLS stack) then that should perhaps be made explicit. Again, there are > privacy considerations with some of these mechanisms, as OCSP requests ar= e > typically sent in the clear (plain HTTP) and so allow an observer to see > which clients are connecting to which AS. > > 11. The same comment applies to how the protected resource checks for > revocation of the certificate presented during sender constrained access > token usage. Should the RS make its own revocation checks based on the > information in the certificate presented, or should it trust the > certificate while the access token is still valid? If the latter case, is > the AS responsible for revoking any access tokens whose certificate have > been revoked (if so, should it be doing an OCSP call on every token > introspection request, and should the RS be passing on the > certificate/serial number on that request)? If the Client request uses OC= SP > Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS > verify the signature on that if it does not have a separate trust > relationship with the CA already? > > 12. The use of only SHA-256 fingerprints means that the security strength > of the sender-constrained access tokens is limited by the collision > resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without a ne= w > specification for a new thumbprint algorithm. An implication of this is > that is is fairly pointless for the protected resource TLS stack to ever > negotiate cipher suites/keys with a higher level of security. In more > crystal ball territory, if a practical quantum computer becomes a > possibility within the lifetime of this spec, then the expected collision > resistance of SHA-256 would drop quadratically, allowing an attacker to > find a colliding certificate in ~2^64 effort. If we are going to pick jus= t > one thumbprint hash algorithm, I would prefer we pick SHA-512. > > Cheers, > > Neil > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote: > > All, > > As discussed during the meeting today, we are starting a WGLC on the MTLS > document: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end in two weeks, on April 2, 2018. > > Regards, > Rifaat and Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --001a113fbf541f079a05690f35ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Strongly agree with Justin that any kind of TLS heade= r forwarding standards like that are well beyond the scope of this spec.


On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer <jricher@mit.edu= > wrote:
I don=E2=80=99t believe this= is the spec to define TLS header forwarding standards in.

=C2=A0=E2=80=94 Justin


On Mar 30, = 2018, at 2:03 PM, Vivek Biswas <vivek.biswas@oracle.com> wrote:

There are addi= tional challenges which we have faced.
=C2=A0
A.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Most of the Mutual SSL communication as me= ntioned below terminates at the LBR and the LBR needs to have client certif= icates to trust the client. But lot of times the connection from LBR to Aut= horization server may be non-SSL.
=C2=A0
The CN, SHA-256 thumprint and serial number of the Cli= ent Cert are sent as header to the AuthzServer/Backend Server. However, if = the connection from LBR to AuthzServer/Backend Server is unencrypted it is = prone to MIM attacks. Hence, it=E2=80=99s a MUST requirement to have one-wa= y SSL from LBR to AuthzServer/Backend Server, so that the headers passed ar= e not compromised.
=C2=A0
This is a MOST common scenario in a real world. And we don=E2=80=99t = want everyone come up with their own names for the header. There should be = some kind of standardization around the header names.<= /div>
=C2=A0
Regards
=
Vivek Biswas, CISSP
=C2=A0
From:=C2=A0John B= radley [mailto:ve7jt= b@ve7jtb.com]=C2=A0
Sent:=C2=A0Thursday, March 29, 2018 11:57 AM
To:=C2=A0N= eil Madden
Cc:=C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] WGLC on draft-ie= tf-oauth-mtls-07
=C2=A0
Yes that is quite a= common deployment scenario. =C2=A0 I think that is the way most of the Ope= n Banking implementations have deployed it currently. =C2=A0=C2=A0
=C2=A0
The intent is to support that. =C2=A0 One probl= em is that how the certificate is transmitted to the application tends to b= e load balancer/reverse proxy specific as no real standard exists.
=C2=A0
If you think that needs to be clarified t= ext is welcome.
<= /u>=C2=A0
John B.=
=C2=A0
=C2=A0


On Mar 29, 2018, at 2:= 54 PM, Neil Madden <neil.madden@f= orgerock.com> wrote:
=C2=A0
Thanks, and understood.=C2=A0
=C2=A0
The privacy concerns are mostly around correlating activit= y of *clients*, which may or may not reveal activity patterns of users usin= g those clients. I don=E2=80=99t know how much of a concern that is in real= ity, but thought it should be mentioned.=C2=A0
=C2=A0
A colleague also made the following comment about the draft:
=C2=A0
=E2=80=9CIt is still quite common to terminate TLS i= n a load balancer or proxy, and to deploy authorization servers in a secure= network zone behind an intermediate in a DMZ. In these cases, TLS would no= t be established between the client and authorization server as per =C2=A72= , but information about the TLS handshake may be made available by other me= ans (typically adding to a downstream header) allowing lookup and verificat= ion of the client certificate as otherwise described. Given the prevalence = of this approach it would be good to know whether such a deployment would b= e compliant or not.=E2=80=9D
=C2=A0
Kind regards,
Neil
<= /div>
--
=C2=A0<= /u>
On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks for the feedback. We will review your com= ments and reply.=C2=A0

One data point is that this will not be the only POP = spec. The spec using token binding vs mtls has better privacy properties. I= t is UK Open banking that has pressed us to come up with a standard to help= with interoperability.=C2=A0

This spec has been simplified in some ways to = facilitate the majority of likely deployments.=C2=A0

I understand that in fu= ture certificates may have better than SHA256 hashes.=C2=A0

Regards=C2=A0
John B.= =C2=A0


On Mar 29, 2018, at 12:18 PM, Neil Madde= n <neil.madden@forgerock.com>= ; wrote:=C2=A0<= /span>

Hi,=C2=A0

I have reviewed this draft and have a number of comm= ents, below. ForgeRock have not yet implemented this draft, but there is in= terest in implementing it at some point. (Disclaimer: We have no firm commi= tments on this at the moment, I do not speak for ForgeRock, etc).=C2=A0

1.=C2=A0https://to= ols.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1=C2=A0defines a= new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is alre= ady a confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web= Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exac= tly the same syntax and semantics. The draft proposes:=C2=A0

{ =E2=80=9Ccnf= =E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } }=C2=A0
<= br>but you can already do:=C2=A0

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2= =80=9D: { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80= =9D } } }=C2=A0=

If the intent is just to save some space and avoid the manda= tory fields of the existing JWK types, maybe this would be better addressed= by defining a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ck= ty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D }.=C2=A0

2. I find the naming =E2=80=9Cmutual TLS=E2=80= =9D and =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really onl= y the client authentication that we are interested here, and the fact that = the server also authenticates with a certificate is not hugely relevant to = this particular spec (although it is to the overall security of OAuth). Als= o, TLS defines non-certificate based authentication mechanisms (e.g. TLS-SR= P extension for password authenticated key exchange, PSK for pre-shared key= authentication) and even non-X.509 certificate types (https://www.iana.org/assignments/tls-extensio= ntype-values/tls-extensiontype-values.xhtml#tls-extensiontyp= e-values-3). I=E2=80=99d prefer that the draft explicitly referred to = =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rather than mutua= l TLS, and changed identifiers like =E2=80=98tls_client_auth=E2=80=99 (https://= tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) t= o something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.<= span class=3D"m_-3603955558104745770Apple-converted-space">=C2=A0
This is especially confusing in section 3 on sender constrained access= tokens, as there are two different servers involved: the AS and the protec= ted resource server, but there is no =E2=80=9Cmutual=E2=80=9D authenticatio= n between them, only between each of them and the client.=C2=A0

3. The draft= links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC only specifies = TLS 1.0. Is the intention that TLS 1.2+ is required? The wording in Section= 5.1 doesn=E2=80=99t seem clear if this could also be used with TLS 1.0 or = 1.1, or whether it is only referring to future TLS versions.=C2=A0

4. It mig= ht be useful to have a discussion for implementors of whether TLS session r= esumption (and PSK in TLS 1.3) and/or renegotiation impact the use of clien= t certificates, if at all?=C2=A0

5. Section 3 defines sender-constrained acc= ess tokens in terms of the confirmation key claims (e.g., RFC 7800 for JWT)= . However, the OAuth 2.0 Pop Architecture draft defines sender constraint a= nd key confirmation as different things (https://tools.ietf.org/html/= draft-ietf-oauth-pop-architecture-08#section-6.2). The draft = should decide which of those it is implementing and if sender constraint is= intended, then reusing the confirmation key claims seems misleading. (I th= ink this mTLS draft is doing key confirmation so should drop the language a= bout sender constrained tokens).=C2=A0

6. The OAuth 2.0 PoP Architecture dra= ft says (https://tools.ietf.org/html/draft-ietf-oauth-pop-ar= chitecture-08#section-5):=C2=A0

Strong, fresh session keys:=C2=A0

Sessi= on keys MUST be strong and fresh.. Each session deserves an=C2=A0
independent se= ssion key, i.e., one that is generated specifically=C2=A0
for the intended use. = In context of OAuth this means that keying=C2=A0
material is created in such a w= ay that can only be used by the=C2=A0
combination of a client instance, protecte= d resource, and= =C2=A0
authorization scope.=C2=A0


However, the mTLS draft sect= ion 3 (h= ttps://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3= ) says:=C2=A0

The client makes protected resource requests as described in=C2=A0
= [RFC6750], however, those requests MUST be made over a mutually=C2=A0
authentic= ated TLS connection using the same certificate that was used=C2=A0
for mutual TL= S at the token endpoint.=C2=A0

These two statements are contradictory: the O= Auth 2.0 PoP architecture effectively requires a fresh key-pair to be used = for every access token request, whereas this draft proposes reusing the sam= e long-lived client certificate for every single access token and every res= ource server.= =C2=A0

In the self-signed case (and even in the CA case, with= a bit of work - e.g.,=C2=A0https://www.vaultproject.io/docs/secrets/pki/index.html)= it is perfectly possible for the client to generate a fresh key-pair for e= ach access token and include the certificate on the token request (e.g., as= per=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop-key-= distribution-03#section-5.1=C2=A0- in which case an appropriate =E2=80=9Calg=E2= =80=9D value should probably be described). This should probably at least b= e an option.=C2= =A0

7. The use of a single client certificate with every reso= urce server (RS) should be called out in a Privacy Considerations section, = as it allows correlation of activity.=C2=A0

8. This is maybe a more general = point, but RFC 6750 defines the Authorization: Bearer scheme (https://tools.ietf.org/html/rfc67= 50#section-2) for a client to communicate it=E2=80=99s access token to = the RS in a standard way. As sender-constrained access tokens are not stric= tly bearer tokens any more, should this draft also register a new scheme fo= r that? Should there be a generic PoP scheme?=C2=A0

9. The Security Consider= ations should really make some mention of the long history of attacks again= st X.509 certificate chain validation, e.g. failure to check the =E2=80=9CC= A=E2=80=9D bit in the basic constraints, errors in parsing DNs, etc. It sho= uld be strongly suggested to use an existing TLS library to perform these c= hecks rather than implementing your own checks. This relates to Justin=E2= =80=99s comments around DN parsing and normalisation.=C2=A0

10. The PKI clie= nt authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls-= 07#section-2.1) makes no mention at all of certificate revocation = and how to handle checking for that (CRLs, OCSP - with stapling?). Neither = does the Security Considerations. If this is a detail to be agreed between = then AS and the CA (or just left up to the AS TLS stack) then that should p= erhaps be made explicit. Again, there are privacy considerations with some = of these mechanisms, as OCSP requests are typically sent in the clear (plai= n HTTP) and so allow an observer to see which clients are connecting to whi= ch AS.=C2=A0

11. The same comment applies to how the protected resource chec= ks for revocation of the certificate presented during sender constrained ac= cess token usage. Should the RS make its own revocation checks based on the= information in the certificate presented, or should it trust the certifica= te while the access token is still valid? If the latter case, is the AS res= ponsible for revoking any access tokens whose certificate have been revoked= (if so, should it be doing an OCSP call on every token introspection reque= st, and should the RS be passing on the certificate/serial number on that r= equest)? If the Client request uses OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS verify the signature on that if it does not have a separa= te trust relationship with the CA already?=C2=A0

12. The use of only SHA-256= fingerprints means that the security strength of the sender-constrained ac= cess tokens is limited by the collision resistance of SHA-256 - roughly =E2= =80=9C128-bit security" - without a new specification for a new thumbp= rint algorithm. An implication of this is that is is fairly pointless for t= he protected resource TLS stack to ever negotiate cipher suites/keys with a= higher level of security. In more crystal ball territory, if a practical q= uantum computer becomes a possibility within the lifetime of this spec, the= n the expected collision resistance of SHA-256 would drop quadratically, al= lowing an attacker to find a colliding certificate in ~2^64 effort. If we a= re going to pick just one thumbprint hash algorithm, I would prefer we pick= SHA-512.=C2=A0=

Cheers,=C2=A0

Neil=C2=A0



On 19 Ma= r 2018, at 22:34, Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com> wrote:=C2=A0

All,=C2=A0

As discussed during the = meeting today, we are starting a WGLC on the MTLS document:=C2=A0
https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=C2=A0

Please, review the document and provide = feedback on any issues you see with the document.=C2=A0

The WGLC will end in= two weeks, on April 2, 2018.=C2=A0

Regards,=C2=A0
Rifaat and Hannes=C2=A0

_____= __________________________________________=C2=A0
OAuth mailing list=C2=A0
OAuth@ietf.org=C2=A0
https://www.ietf.org/mailman/listinfo/oauth=

___________________________= ____________________=C2=A0
OAuth mailing list=C2=A0
OA= uth@ietf.org=C2=A0
https://w= ww.ietf.org/mailman/listinfo/oauth
=C2=A0
=C2=A0<= u>
______________= _________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth


____= ___________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113fbf541f079a05690f35ed-- From nobody Thu Apr 5 09:07:09 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0A12DA0C for ; Thu, 5 Apr 2018 09:07:07 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obgIBy7Sx4hz for ; Thu, 5 Apr 2018 09:07:02 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D710127876 for ; Thu, 5 Apr 2018 09:07:02 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r191so7073057wmg.4 for ; Thu, 05 Apr 2018 09:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A9nyPXBnDAtafNwYj+TADSBUl381j7/vB6d5IVXUOSM=; b=WRXFM98YxAP5bG8eGnINhiKfJ8R1DUj9iekwPj8wsvKhpJDZXn2/1LCweuPe6e/lOY pcM0lzHnPOA9m1C1qoIB76iokrYdGHWLW3YBOjoUrlyW1ZWo/b1t6MO+kWZt231aUT97 z4VBkQCPfJsjfeDptX9/n1Cp5HvrOtDG0UfMeDNbMrHCwruhkgz8cTM0IsTPmq2s9PSF 2TQpGWfBD4PYWN143ir9VyUnLNjaDMbj+NYyu8WAeNU1ST3KGlbiGN2s2+DdFJWea9PK qj+EfYUGpACKnbRlTDRyQHtIShvgYGb4A9i1EBt+7Bq8Rghw8u2sNMrHTXw+Q4rBavy4 wWjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A9nyPXBnDAtafNwYj+TADSBUl381j7/vB6d5IVXUOSM=; b=VaoiEfnPZIksol3f9UUUIrD0NyEb8A6S5Dx28emcv5jW9Yi0+D+yK5jSr0GL+vKC2v jgq6GBM7ROr1yRV3L0yfdXiuLJLjaf2xJBePABZzzlhhT1xVwlxxR0V9AWZJOF7LTJku IZX5MmCCWKm1BcIAivPvZsTZche2zkav2EG0eKqerCDy3PMzskBi4TgKWk+lBO1ecgHx GSvBTG2Io+3k9A+1/7NR8UAx/lB9vVQq7OnsijnXCKFy3hlre0EQC6tGDDzRh8xpkdHU ifu4CAiZMiTBM+xSi20UosBw/FyBGydzgmPN0Nu+wtoft/4WXF/RVvH6HDx50iBGc5sS gFwg== X-Gm-Message-State: AElRT7GiCTNM1/kNAkAQBjOx2mU1GYCFPxWFkMNRQxEQ1rYO6SxL5dAr YzUNjFiw9DjSwzZw2kzN6zMllzco3kCqZETlYo6Yjjbn X-Google-Smtp-Source: AIpwx4+f1rRENbTjsiXJiz79MtaOkWmQ8ugMaJhQmx4Hpm0DWi6N9ja6R8Vww3RtkYJRlUX/Lz7Zn49uS77ut0v8IWk= X-Received: by 10.28.21.4 with SMTP id 4mr10733948wmv.34.1522944420211; Thu, 05 Apr 2018 09:07:00 -0700 (PDT) MIME-Version: 1.0 References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> In-Reply-To: From: John Bradley Date: Thu, 05 Apr 2018 16:06:48 +0000 Message-ID: To: Brian Campbell Cc: Justin Richer , IETF oauth WG Content-Type: multipart/alternative; boundary="001a114424282e00c205691c2103" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:07:08 -0000 --001a114424282e00c205691c2103 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Wed, Apr 4, 2018, 5:42 PM Brian Campbell wrote: > Strongly agree with Justin that any kind of TLS header forwarding > standards like that are well beyond the scope of this spec. > > > On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer wrote: > >> I don=E2=80=99t believe this is the spec to define TLS header forwarding >> standards in. >> >> =E2=80=94 Justin >> >> >> On Mar 30, 2018, at 2:03 PM, Vivek Biswas >> wrote: >> >> There are additional challenges which we have faced. >> >> A. Most of the Mutual SSL communication as mentioned below >> terminates at the LBR and the LBR needs to have client certificates to >> trust the client. But lot of times the connection from LBR to Authorizat= ion >> server may be non-SSL. >> >> The CN, SHA-256 thumprint and serial number of the Client Cert are sent >> as header to the AuthzServer/Backend Server. However, if the connection >> from LBR to AuthzServer/Backend Server is unencrypted it is prone to MIM >> attacks. Hence, it=E2=80=99s a MUST requirement to have one-way SSL from= LBR to >> AuthzServer/Backend Server, so that the headers passed are not compromis= ed. >> >> This is a MOST common scenario in a real world. And we don=E2=80=99t wan= t >> everyone come up with their own names for the header. There should be so= me >> kind of standardization around the header names. >> >> Regards >> Vivek Biswas, CISSP >> >> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com ] >> *Sent:* Thursday, March 29, 2018 11:57 AM >> *To:* Neil Madden >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 >> >> Yes that is quite a common deployment scenario. I think that is the wa= y >> most of the Open Banking implementations have deployed it currently. >> >> The intent is to support that. One problem is that how the certificate >> is transmitted to the application tends to be load balancer/reverse prox= y >> specific as no real standard exists. >> >> If you think that needs to be clarified text is welcome. >> >> John B. >> >> >> >> >> On Mar 29, 2018, at 2:54 PM, Neil Madden >> wrote: >> >> Thanks, and understood. >> >> The privacy concerns are mostly around correlating activity of *clients*= , >> which may or may not reveal activity patterns of users using those clien= ts. >> I don=E2=80=99t know how much of a concern that is in reality, but thoug= ht it >> should be mentioned. >> >> A colleague also made the following comment about the draft: >> >> =E2=80=9CIt is still quite common to terminate TLS in a load balancer or= proxy, >> and to deploy authorization servers in a secure network zone behind an >> intermediate in a DMZ. In these cases, TLS would not be established betw= een >> the client and authorization server as per =C2=A72, but information abou= t the >> TLS handshake may be made available by other means (typically adding to = a >> downstream header) allowing lookup and verification of the client >> certificate as otherwise described. Given the prevalence of this approac= h >> it would be good to know whether such a deployment would be compliant or >> not.=E2=80=9D >> >> Kind regards, >> Neil >> -- >> >> >> On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley >> wrote: >> Thanks for the feedback. We will review your comments and reply. >> >> One data point is that this will not be the only POP spec. The spec usin= g >> token binding vs mtls has better privacy properties. It is UK Open banki= ng >> that has pressed us to come up with a standard to help with >> interoperability. >> >> This spec has been simplified in some ways to facilitate the majority of >> likely deployments. >> >> I understand that in future certificates may have better than SHA256 >> hashes. >> >> Regards >> John B. >> >> >> >> On Mar 29, 2018, at 12:18 PM, Neil Madden >> wrote: >> >> Hi, >> >> I have reviewed this draft and have a number of comments, below. >> ForgeRock have not yet implemented this draft, but there is interest in >> implementing it at some point. (Disclaimer: We have no firm commitments = on >> this at the moment, I do not speak for ForgeRock, etc). >> >> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defi= nes >> a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is = already a >> confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Ke= y, which itself can >> contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax = and semantics. The >> draft proposes: >> >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80= =A6=E2=80=9D } } >> >> but you can already do: >> >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80= =9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } >> >> If the intent is just to save some space and avoid the mandatory fields >> of the existing JWK types, maybe this would be better addressed by defin= ing >> a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80= =9D: =E2=80=9Cx5t=E2=80=9D, >> =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }. >> >> 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s >> really only the client authentication that we are interested here, and t= he >> fact that the server also authenticates with a certificate is not hugely >> relevant to this particular spec (although it is to the overall security= of >> OAuth). Also, TLS defines non-certificate based authentication mechanism= s >> (e.g. TLS-SRP extension for password authenticated key exchange, PSK for >> pre-shared key authentication) and even non-X.509 certificate types ( >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiont= ype-values.xhtml#tls-extensiontype-values-3). >> I=E2=80=99d prefer that the draft explicitly referred to =E2=80=9CX.509 = Client Certificate >> Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like >> =E2=80=98tls_client_auth=E2=80=99 ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) to >> something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99. >> >> This is especially confusing in section 3 on sender constrained access >> tokens, as there are two different servers involved: the AS and the >> protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D auth= entication between >> them, only between each of them and the client. >> >> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC >> only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The >> wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be = used with >> TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. >> >> 4. It might be useful to have a discussion for implementors of whether >> TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the >> use of client certificates, if at all? >> >> 5. Section 3 defines sender-constrained access tokens in terms of the >> confirmation key claims (e.g., RFC 7800 for JWT).. However, the OAuth 2.= 0 >> Pop Architecture draft defines sender constraint and key confirmation as >> different things ( >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section= -6.2). >> The draft should decide which of those it is implementing and if sender >> constraint is intended, then reusing the confirmation key claims seems >> misleading. (I think this mTLS draft is doing key confirmation so should >> drop the language about sender constrained tokens). >> >> 6. The OAuth 2.0 PoP Architecture draft says ( >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section= -5 >> >> ): >> >> Strong, fresh session keys: >> >> Session keys MUST be strong and fresh.. Each session deserves an >> independent session key, i.e., one that is generated specifically >> for the intended use. In context of OAuth this means that keying >> material is created in such a way that can only be used by the >> combination of a client instance, protected resource, and >> authorization scope. >> >> >> However, the mTLS draft section 3 ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) says: >> >> The client makes protected resource requests as described in >> [RFC6750], however, those requests MUST be made over a mutually >> authenticated TLS connection using the same certificate that was used >> for mutual TLS at the token endpoint. >> >> These two statements are contradictory: the OAuth 2.0 PoP architecture >> effectively requires a fresh key-pair to be used for every access token >> request, whereas this draft proposes reusing the same long-lived client >> certificate for every single access token and every resource server. >> >> In the self-signed case (and even in the CA case, with a bit of work - >> e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is >> perfectly possible for the client to generate a fresh key-pair for each >> access token and include the certificate on the token request (e.g., as = per >> >> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#sec= tion-5.1 >> - in which case an appropriate =E2=80=9Calg=E2=80=9D value should proba= bly be >> described). This should probably at least be an option. >> >> 7. The use of a single client certificate with every resource server (RS= ) >> should be called out in a Privacy Considerations section, as it allows >> correlation of activity. >> >> 8. This is maybe a more general point, but RFC 6750 defines the >> Authorization: Bearer scheme ( >> https://tools.ietf.org/html/rfc6750#section-2) for a client to >> communicate it=E2=80=99s access token to the RS in a standard way. As >> sender-constrained access tokens are not strictly bearer tokens any more= , >> should this draft also register a new scheme for that? Should there be a >> generic PoP scheme? >> >> 9. The Security Considerations should really make some mention of the >> long history of attacks against X.509 certificate chain validation, e.g. >> failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing >> DNs, etc. It should be strongly suggested to use an existing TLS library= to >> perform these checks rather than implementing your own checks. This rela= tes >> to Justin=E2=80=99s comments around DN parsing and normalisation. >> >> 10. The PKI client authentication method ( >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes >> no mention at all of certificate revocation and how to handle checking f= or >> that (CRLs, OCSP - with stapling?). Neither does the Security >> Considerations. If this is a detail to be agreed between then AS and the= CA >> (or just left up to the AS TLS stack) then that should perhaps be made >> explicit. Again, there are privacy considerations with some of these >> mechanisms, as OCSP requests are typically sent in the clear (plain HTTP= ) >> and so allow an observer to see which clients are connecting to which AS= . >> >> >> 11. The same comment applies to how the protected resource checks for >> revocation of the certificate presented during sender constrained access >> token usage. Should the RS make its own revocation checks based on the >> information in the certificate presented, or should it trust the >> certificate while the access token is still valid? If the latter case, i= s >> the AS responsible for revoking any access tokens whose certificate have >> been revoked (if so, should it be doing an OCSP call on every token >> introspection request, and should the RS be passing on the >> certificate/serial number on that request)? If the Client request uses O= CSP >> Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS >> verify the signature on that if it does not have a separate trust >> relationship with the CA already? >> >> 12. The use of only SHA-256 fingerprints means that the security strengt= h >> of the sender-constrained access tokens is limited by the collision >> resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without a n= ew >> specification for a new thumbprint algorithm. An implication of this is >> that is is fairly pointless for the protected resource TLS stack to ever >> negotiate cipher suites/keys with a higher level of security. In more >> crystal ball territory, if a practical quantum computer becomes a >> possibility within the lifetime of this spec, then the expected collisio= n >> resistance of SHA-256 would drop quadratically, allowing an attacker to >> find a colliding certificate in ~2^64 effort. If we are going to pick ju= st >> one thumbprint hash algorithm, I would prefer we pick SHA-512. >> >> Cheers, >> >> Neil >> >> >> >> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> As discussed during the meeting today, we are starting a WGLC on the MTL= S >> document: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >> >> Please, review the document and provide feedback on any issues you see >> with the document. >> >> The WGLC will end in two weeks, on April 2, 2018. >> >> Regards, >> Rifaat and Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114424282e00c205691c2103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

O= n Wed, Apr 4, 2018, 5:42 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Strongly agree with Justin t= hat any kind of TLS header forwarding standards like that are well beyond t= he scope of this spec.


On Fri, Mar 30, 2018 at 10:02 PM, Just= in Richer <jricher@mit.edu> wrote:
I don=E2=80=99t believe this is the spec to define TLS he= ader forwarding standards in.

=C2=A0=E2=80=94 Justin


On Mar 30, 2018, at 2:03 PM, Vivek Biswas <v= ivek.biswas@oracle.com> wrote:

There are additional challenges which we have faced.
=C2=A0
=
A.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Mos= t of the Mutual SSL communication as mentioned below terminates at the LBR = and the LBR needs to have client certificates to trust the client. But lot = of times the connection from LBR to Authorization server may be non-SSL.=
=C2= =A0
The CN, SHA-2= 56 thumprint and serial number of the Client Cert are sent as header to the= AuthzServer/Backend Server. However, if the connection from LBR to AuthzSe= rver/Backend Server is unencrypted it is prone to MIM attacks. Hence, it=E2= =80=99s a MUST requirement to have one-way SSL from LBR to AuthzServer/Back= end Server, so that the headers passed are not compromised.
=C2=A0
This is a MOST common scenario in a real world. And we= don=E2=80=99t want everyone come up with their own names for the header. T= here should be some kind of standardization around the header names.=
=C2=A0=
Regards
Vivek Biswas, CISSP
=C2=A0<= /u>
From:=C2=A0John Bradley [mailto:ve7jtb@ve7jtb.com]=C2=A0
Sent:=C2=A0Thursday, March 29, 2018= 11:57 AM
To:=C2=A0Neil Madden
Cc:= =C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] WGLC= on draft-ietf-oauth-mtls-07
=C2=A0
Yes tha= t is quite a common deployment scenario. =C2=A0 I think that is the way mos= t of the Open Banking implementations have deployed it currently. =C2=A0=C2= =A0
=C2=A0
The intent is to support that. =C2= =A0 One problem is that how the certificate is transmitted to the applicati= on tends to be load balancer/reverse proxy specific as no real standard exi= sts.
=C2=A0
If you think that needs to b= e clarified text is welcome.
=C2=A0
John= B.
=C2=A0=
=C2=A0


On Mar 29,= 2018, at 2:54 PM, Neil Madden <neil.madden@forgerock.com> wrote:
=C2=A0
Thanks, and understood.=C2=A0
=C2=A0
The pri= vacy concerns are mostly around correlating activity of *clients*, which ma= y or may not reveal activity patterns of users using those clients. I don= =E2=80=99t know how much of a concern that is in reality, but thought it sh= ould be mentioned.=C2=A0
=C2=A0
A colleague also= made the following comment about the draft:
=C2=A0
=E2=80=9CIt is still quite common to terminate TLS in a load balancer or p= roxy, and to deploy authorization servers in a secure network zone behind a= n intermediate in a DMZ. In these cases, TLS would not be established betwe= en the client and authorization server as per =C2=A72, but information abou= t the TLS handshake may be made available by other means (typically adding = to a downstream header) allowing lookup and verification of the client cert= ificate as otherwise described. Given the prevalence of this approach it wo= uld be good to know whether such a deployment would be compliant or not.=E2= =80=9D
=C2=A0<= /span>
Kind regards,
Neil
--<= /span>
=C2=A0
On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:
Thanks for the feedback. We w= ill review your comments and reply.=C2=A0

One data poin= t is that this will not be the only POP spec. The spec using token binding = vs mtls has better privacy properties. It is UK Open banking that has press= ed us to come up with a standard to help with interoperability.=C2= =A0

This spec has been simplified in some ways to facilitate = the majority of likely deployments.=C2=A0

I understand = that in future certificates may have better than SHA256 hashes.=C2= =A0

Regards=C2=A0
John B.=C2=A0<= br>


On Mar 29, 2018, at 12:18 PM, Neil Madd= en <neil.madden@= forgerock.com> wrote:=C2=A0

Hi,=C2=A0

I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in imp= lementing it at some point. (Disclaimer: We have no firm commitments on thi= s at the moment, I do not speak for ForgeRock, etc).=C2=A0
=
1.=C2=A0https://tools.ietf.org/html/draft-iet= f-oauth-mtls-07#section-3.1=C2=A0defines a new confirmatio= n method =E2=80=9Cx5t#S256=E2=80=9D. However, there is already a confirmati= on method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key, which itse= lf can contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syn= tax and semantics. The draft proposes:=C2=A0

{ =E2=80= =9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D = } }=C2=A0

but you can already do:=C2=A0
{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80= =9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }=C2=A0<= br>
If the intent is just to save some space and avoid the mandatory fie= lds of the existing JWK types, maybe this would be better addressed by defi= ning a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80= =9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6= =E2=80=9D }.=C2=A0

2. I find the naming =E2=80=9Cmutual= TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s = really only the client authentication that we are interested here, and the = fact that the server also authenticates with a certificate is not hugely re= levant to this particular spec (although it is to the overall security of O= Auth). Also, TLS defines non-certificate based authentication mechanisms (e= .g. TLS-SRP extension for password authenticated key exchange, PSK for pre-= shared key authentication) and even non-X.509 certificate types (https://www.iana.org/= assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-ext= ensiontype-values-3). I=E2=80=99d prefer that the draft explicitly refe= rred to =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rather th= an mutual TLS, and changed identifiers like =E2=80=98tls_client_auth=E2=80= =99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#se= ction-2.1.1) to something more explicit like =E2=80=98tls_x509_pki_clie= nt_auth=E2=80=99.=C2=A0

This is especially confusing in= section 3 on sender constrained access tokens, as there are two different = servers involved: the AS and the protected resource server, but there is no= =E2=80=9Cmutual=E2=80=9D authentication between them, only between each of= them and the client.=C2=A0

3. The draft links to the T= LS 1.2 RFC, while the original OAuth 2.0 RFC only specifies TLS 1.0. Is the= intention that TLS 1.2+ is required? The wording in Section 5.1 doesn=E2= =80=99t seem clear if this could also be used with TLS 1.0 or 1.1, or wheth= er it is only referring to future TLS versions.=C2=A0

4= . It might be useful to have a discussion for implementors of whether TLS s= ession resumption (and PSK in TLS 1.3) and/or renegotiation impact the use = of client certificates, if at all?=C2=A0

5. Section 3 d= efines sender-constrained access tokens in terms of the confirmation key cl= aims (e.g., RFC 7800 for JWT).. However, the OAuth 2.0 Pop Architecture dra= ft defines sender constraint and key confirmation as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-archi= tecture-08#section-6.2). The draft should decide which of those it is i= mplementing and if sender constraint is intended, then reusing the confirma= tion key claims seems misleading. (I think this mTLS draft is doing key con= firmation so should drop the language about sender constrained tokens).=C2=A0

6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft-ietf-oauth-pop-architec= ture-08#section-5):=C2=A0

Strong, fresh session key= s:=C2=A0

Session keys MUST be strong and fresh.. Each s= ession deserves an=C2=A0
independent session key, i.e., one= that is generated specifically=C2=A0
for the intended use.= In context of OAuth this means that keying=C2=A0
material = is created in such a way that can only be used by the=C2=A0combination of a client instance, protected resource, and=C2=A0
authorization scope.=C2=A0


However, the mTLS = draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mt= ls-07#section-3) says:=C2=A0

The client makes prote= cted resource requests as described in=C2=A0
[RFC6750], how= ever, those requests MUST be made over a mutually=C2=A0
aut= henticated TLS connection using the same certificate that was used=C2= =A0
for mutual TLS at the token endpoint.=C2=A0
<= br>These two statements are contradictory: the OAuth 2.0 PoP architecture e= ffectively requires a fresh key-pair to be used for every access token requ= est, whereas this draft proposes reusing the same long-lived client certifi= cate for every single access token and every resource server.=C2=A0

In the self-signed case (and even in the CA case, with a bit o= f work - e.g.,=C2=A0https://www.vaultproject.io/docs/secre= ts/pki/index.html) it is perfectly possible for the client to generate = a fresh key-pair for each access token and include the certificate on the t= oken request (e.g., as per=C2=A0h= ttps://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section= -5.1=C2=A0- in which case an appropriate =E2=80=9Calg=E2= =80=9D value should probably be described). This should probably at least b= e an option.=C2=A0

7. The use of a single client certif= icate with every resource server (RS) should be called out in a Privacy Con= siderations section, as it allows correlation of activity.=C2=A0

8. This is maybe a more general point, but RFC 6750 defines the A= uthorization: Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2) f= or a client to communicate it=E2=80=99s access token to the RS in a standar= d way. As sender-constrained access tokens are not strictly bearer tokens a= ny more, should this draft also register a new scheme for that? Should ther= e be a generic PoP scheme?=C2=A0

9. The Security Consid= erations should really make some mention of the long history of attacks aga= inst X.509 certificate chain validation, e.g. failure to check the =E2=80= =9CCA=E2=80=9D bit in the basic constraints, errors in parsing DNs, etc. It= should be strongly suggested to use an existing TLS library to perform the= se checks rather than implementing your own checks. This relates to Justin= =E2=80=99s comments around DN parsing and normalisation.=C2=A0=

10. The PKI client authentication method (https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes no mention = at all of certificate revocation and how to handle checking for that (CRLs,= OCSP - with stapling?). Neither does the Security Considerations. If this = is a detail to be agreed between then AS and the CA (or just left up to the= AS TLS stack) then that should perhaps be made explicit. Again, there are = privacy considerations with some of these mechanisms, as OCSP requests are = typically sent in the clear (plain HTTP) and so allow an observer to see wh= ich clients are connecting to which AS.=C2=A0

11. The s= ame comment applies to how the protected resource checks for revocation of = the certificate presented during sender constrained access token usage. Sho= uld the RS make its own revocation checks based on the information in the c= ertificate presented, or should it trust the certificate while the access t= oken is still valid? If the latter case, is the AS responsible for revoking= any access tokens whose certificate have been revoked (if so, should it be= doing an OCSP call on every token introspection request, and should the RS= be passing on the certificate/serial number on that request)? If the Clien= t request uses OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how = can the RS verify the signature on that if it does not have a separate trus= t relationship with the CA already?=C2=A0

12. The use o= f only SHA-256 fingerprints means that the security strength of the sender-= constrained access tokens is limited by the collision resistance of SHA-256= - roughly =E2=80=9C128-bit security" - without a new specification fo= r a new thumbprint algorithm. An implication of this is that is is fairly p= ointless for the protected resource TLS stack to ever negotiate cipher suit= es/keys with a higher level of security. In more crystal ball territory, if= a practical quantum computer becomes a possibility within the lifetime of = this spec, then the expected collision resistance of SHA-256 would drop qua= dratically, allowing an attacker to find a colliding certificate in ~2^64 e= ffort. If we are going to pick just one thumbprint hash algorithm, I would = prefer we pick SHA-512.=C2=A0

Cheers,=C2=A0

Neil=C2=A0



=
On 19 = Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=C2=A0=

All,=C2=A0

As discussed during the meeting toda= y, we are starting a WGLC on the MTLS document:=C2=A0
http= s://tools.ietf.org/html/draft-ietf-oauth-mtls-07=C2=A0
=
Please, review the document and provide feedback on any issues you see = with the document.=C2=A0

The WGLC will end in two weeks= , on April 2, 2018.=C2=A0

Regards,=C2=A0Rifaat and Hannes=C2=A0

_____________________________= __________________=C2=A0
OAuth mailing list=C2=A0
OAuth@ietf.org=C2=A0
https://www.ietf.org/mailman/listinfo/oauth

___________________________________= ____________=C2=A0
OAuth mailing list=C2=A0OAuth@ietf.org=C2= =A0
https://www.ietf.org/mailman/listinfo/oauth<= /div>
=C2=A0
<= /u>=C2=A0
____= ___________________________________________
OAuth mailing list
OAuth@i= etf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth


__________________________________________= _____
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114424282e00c205691c2103-- From nobody Thu Apr 5 22:25:55 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0612E8C5; Thu, 5 Apr 2018 22:25:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152299234729.3767.13086203926677943957@ietfa.amsl.com> Date: Thu, 05 Apr 2018 22:25:47 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 05:25:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-16.txt Pages : 27 Date : 2018-04-05 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 7 08:01:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC1A12D7F0; Sat, 7 Apr 2018 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqNwZtQvT293; Sat, 7 Apr 2018 08:01:43 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A76E1270AE; Sat, 7 Apr 2018 08:01:43 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q38so2460549uad.5; Sat, 07 Apr 2018 08:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4CKgChIqksCz5tThtYEOMidqizSnnaa0UKUBTOFegPE=; b=QvuDi9tBNUB4+kqGhKBghIwkZBdYxLbug71MtK0XWvmxls67Y01U6XjO9kePV30nKw ct1zOxBp8uRpjryfVFo8jneOyICxxNRRDbz7suM9H2ZCuA3THk6pS6QlW9V1BHkMw+xV YzYsPTDbdnhBwXE7oIa+vRkMw9rEXYs4rAIMa57ms9mJpfgpsw2OHrAzbfIucJcBSYda 0O3Ju2J7rbQcEVRzp0TXBso/M2ch9+DtojzjSOaZHXgqhy+qTIYQCEkcoD2uDauJ+LiW j8AmvTvdBF2WNSs+jVFErkdNqfSE36vB0X1A+wqz70dN/w+XCgh/a2te12Kgyy74eTau 1EWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4CKgChIqksCz5tThtYEOMidqizSnnaa0UKUBTOFegPE=; b=QqUIhfeLPHTddtKWpWIlpLwpYvhSi7yDq+XBFuGAy5OZNodTDw1erqmnAxD0ANbAAo Gbpcvy/dqYH91PF0H808cutLGN2a0bvLNJcCBFO55TFbXJN9NzxUPBAQN8Aokw59x7ls 8oQfC5iTPYi5vea571Vmuxtp/EUpuLhvBsLfIOAQ66Him1N9x+boky3Z+DFdwr/KViyG 5vKW3x6QlF/OHoVLESWSUPS9cEDmNfdalIHqo23CRGvhHxtBFu6xhN5y65wVziobP2x4 KonzjqfbmMGopWh/3yFdNC0+RF8KjGCybPees9wV5dO5PYAKobCQb7TjB0H/Wy0+z6bH HO8g== X-Gm-Message-State: ALQs6tBpDMV+xTeyzA5ijpgnt7hGm52cz1AJzNIFp6wH6SRNXqdcz52O 9g/LsPco+hJnG1Dy4yGG/qcE9MMImUbc/h56TWUExg== X-Google-Smtp-Source: AIpwx4/dzLgG2ujxqkBg8Iz5pzbLPbewlRVpNbTvk0Dg3frc5ws3vHeiE6533P/lgvc993Af/lTtMlm47FCmCDdG4Uw= X-Received: by 10.176.12.7 with SMTP id a7mr11394150uak.194.1523113302058; Sat, 07 Apr 2018 08:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.44.154 with HTTP; Sat, 7 Apr 2018 08:01:41 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Sat, 7 Apr 2018 11:01:41 -0400 Message-ID: To: Eric Rescorla Cc: "oauth-chairs@ietf.org" , "saag@ietf.org" , oauth Content-Type: multipart/alternative; boundary="089e08255a4c526d500569437365" Archived-At: Subject: Re: [OAUTH-WG] Conflict review for draft-young-entity-category-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 15:01:45 -0000 --089e08255a4c526d500569437365 Content-Type: text/plain; charset="UTF-8" Adding the OAuth mailing list. Regards, Rifaat On Thursday, April 5, 2018, Eric Rescorla wrote: > Hi folks, > > I have been asked to shepherd the 5742 conflict review for this > document. I believe that the right answer here is: > > The IESG has concluded that there is no conflict between this > document and IETF work. > > It's not clear to me at this point which relevant WGs to ask, so I'm > emailing SAAG + Oauth in the hope that this will get the relevant > people. If you disagree with this, please let me know by Friday > April 13. Also, please feel free to add anyone else you think > might have a relevant opinion. > > -Ekr > > --089e08255a4c526d500569437365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding the OAuth mailing list.

Regards,
=C2=A0= Rifaat


On Thursday, April 5, 2018, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

I have been asked to sheph= erd the 5742 conflict review for this
document. I believe that the right= answer here is:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The IESG has conclud= ed that there is no conflict between this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= document and IETF work.

It's not clear to me at this point whic= h relevant WGs to ask, so I'm
emailing SAAG + Oauth in the hope that= this will get the relevant
people. If you disagree with this, please le= t me know by Friday
April 13. Also, please feel free to add anyone else = you think
might have a relevant opinion.

-Ekr

<= /div>
--089e08255a4c526d500569437365-- From nobody Mon Apr 9 16:11:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01012D86F for ; Mon, 9 Apr 2018 16:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-pKwHQNRgQq for ; Mon, 9 Apr 2018 16:11:00 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1DD12D87A for ; Mon, 9 Apr 2018 16:11:00 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q80so11600210ioi.13 for ; Mon, 09 Apr 2018 16:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cjN4o5EE0qEkYcb+Ype0akGWc1uWmJsiZl/OQOO0Gk4=; b=FYxiDKddni7TKz63fYR9UEHl5W2W0Y/AwJG+Qqghv4iH8L0YtY6d51YVqtN70TT18T LS3qWIgOu4IQ5oz5AXRoHOkaOnBagwGf+38CSfPjtg02SLFqkhHdqaQwOTn8iZVjN7Lm 0K8+4Ha4vRkc0DeTSueV+qjWBvst+DOC2iQyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cjN4o5EE0qEkYcb+Ype0akGWc1uWmJsiZl/OQOO0Gk4=; b=ESbwhyD5C31kkuuik4ai6FvbFNwfcLhMzBx815/sbOjF7rtHuv0WY5wdTPJxGx/15r drjrT83kUWiJ4zdo7YKB9bua95VwIOWtSrt/SNyCheOWe6pu678Dy62xXcy3FbEMoYLu KBFeLNi33RgSuo11u8n2Zqo2llsRFHVTg+iM9kMXreAEyV4QF+sPwJgtk1+DmKK+WfDT NCk6t2pcdycydyPV55TAn/cJLXtZfLaxIzcE+R5p+CLkMaRxX4lmxBwb6V/6uOD11zbw 1cwifmCIt3B6TQA1fH3+IexSnRv3f9zj7JMFMYW5U6+eempcHsYmKbS9QGOzak+3VqL8 zPgw== X-Gm-Message-State: ALQs6tAQuw/tVPJhhwpZkrR8ETaENJyMBNBY8NQUx0C4+HOQEyrHdCDk 6m2exjkORCzOnB9xkcBSBtF2/8KWj2UG3i2it7v0MLXFXmYftoaV1ZRulEOpRcdwuvawSvGzvrv 4FQWpgEF2pOntJw== X-Google-Smtp-Source: AIpwx4/2vOZMmfVtRlXxNfFbknoC+zj2yDrpl2sTjIvH4BONUWOSGDzpnN9hjiz/RHTZsSXPt4IGGFjzqopJ+Bt/RSI= X-Received: by 10.107.20.88 with SMTP id 85mr928176iou.218.1523315459110; Mon, 09 Apr 2018 16:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Mon, 9 Apr 2018 16:10:28 -0700 (PDT) In-Reply-To: References: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> From: Brian Campbell Date: Mon, 9 Apr 2018 17:10:28 -0600 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="001a114fd41cd25ba405697284f2" Archived-At: Subject: Re: [OAUTH-WG] Review of oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 23:11:03 -0000 --001a114fd41cd25ba405697284f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the responses and additional suggestions. Also sorry for the slow reply on my end - I was away on a nice long spring break with the family, which was immediately followed by some other travel. I totally get what you are saying about DN comparison and agree with the sentiment. I've just struggled a bit with wording that would be both appropriate for a spec and also helpful to implementers. Having looked at it just a little more I see that RFC 2253 is obsoleted by RFC 4514. But RFC 4514 says that it "does not define a canonical string representation for DNs" and points to RFC 4517 for comparison of DNs. So this change https://github.com/ietf-oauth-mtls/i-d/commit/73e42346c90c3e 25ec9248fbc0e52bee76afe7bd, which just a non normative bit with an informational reference, is what I came up with for a note about DN comparison that is consistent with those RFCs. Suggestions on improvements or alternatives are welcome as always. Looking again at the current text about authentication method metadata values and your proposed alternative text, what I have does seem a bit superfluous. I'm leaning towards using your suggestion for 2.1.1 & 2.2.1. I'll take another pass over Appendix A and consider incorporating some of your text and/or the sentiment. On Wed, Mar 28, 2018 at 3:57 PM, Justin Richer wrote: > Thanks for the responses. I=E2=80=99ve cut out places where we seem to ag= ree here > and responded to the rest inline below. > > > >> >> =C2=A72.1=C2=B61: It would be helpful to have a pointer on methods of co= mparing >> DNs. In our implementation we serialize them to strings using a canonica= l >> format (RFC2253) and doing a string comparison based on that. There are >> probably other ways, but it would be good to help developers avoid doing >> something naive like comparing two different serializations as strings. >> > > That's really an implementation detail but I can note that some kind of > normalization is likely needed in comparing DNs. > > > Might be worth pointing to to RFC4514 in a non-normative example here. Th= e > thing is, there are equivalent DNs that aren=E2=80=99t exact string copie= s of each > other. We=E2=80=99ll want to avoid developers either doing a naive string > comparison (leading to false negatives) or doing their own home-made > regexes (leading to probable breakage and potentially security holes). > > > > >> =C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an unnec= essary distinction, 6749 >> calls it =E2=80=9Cregistered=E2=80=9D regardless of how it got there >> > > While I suppose that's true about 6749, I think colloquially 'registered' > and 'configured' have come to have more meaning to some/many people about > how the client came to be setup at the AS. So it might be strictly > unnecessary but I'd prefer to keep the "configured or registered" just to > help say that it doesn't matter how the AS came to get the expected DN fo= r > client. > > > That=E2=80=99s a fair assessment, and I=E2=80=99m fine with it as-is in t= hat case. > > > > >> =C2=A72.1.1=C2=B61: Is it necessary to introduce the registry here inste= ad of just >> pointing to it? I=E2=80=99m fine with stating that the values are used i= n both >> discovery and client registration. >> > > I had a hard time describing things concisely here because of the history > of how and when the authentication methods registry came to be, it's name= , > and where it's used. That text in =C2=B61 is what I was able to come up = with > that I thought adequately explained it. It's admittedly not the most > elegant prose ever written but it does convey the info and I'm inclined t= o > leave it. However, I would be happy to consider alternative text here, if > you've got something specific to propose. > > > I guess I just don=E2=80=99t think all that history is really needed righ= t here. > So I=E2=80=99d replace it with: > > For the PKI method of mutual TLS client authentication, this specificatio= n > defines and registers the following authentication method metadata > value into the "OAuth Token Endpoint Authentication Methods" registry > > [IANA.OAuth.Parameters ]. > > If you feel it needs a reference, you can potentially put it in intro > paragraph of the IANA section that sets the values, maybe? (=C2=A76.3) > > In the end I=E2=80=99m fine if the text stays =E2=80=94 it=E2=80=99s not = incorrect, I just feel > it=E2=80=99s superfluous. Same comments apply to the other sections so I= =E2=80=99m not > going to copy them here. > > > > =C2=A7A=C2=B62: This paragraph reads a bit overly defensive. I understand= the need >> to position the two drafts in relationship to each other, but the tone h= ere >> could be adjusted significantly without losing the thrust of the main >> argument. >> > > The line about Token Binding not having a monopoly on the binding of > tokens is admittedly a bit tongue-in-cheek and also a nod to the point yo= u > made the other day about running out of names. > > Honestly though, this text wasn't intended to be defensive and, even when > I read it again, it doesn't come off that way to me. As usual, if you've > got specific text to propose that you think would be better, I'd be happy > to consider it. But I don't feel like the current text is particularly > problematic or in need of change. > > > I took a crack at rewriting the second paragraph (note that I removed the > first sentence entirely), but in the end it=E2=80=99s up to you how you w= ant to > present the comparison between the documents: > > Token Binding uses bare keys that are generated on the client, which a= voids many of > the difficulties of creating, distributing, and managing the certifica= tes used in this specification. > > However, Token Binding requires support across different portions of t= he application > > stack, including TLS and browser implementations. At the time of this = writing, > > there is relatively little support for it in available application > development platforms and tooling. On the other hand, mutual TLS has = been around for some time > and enjoys widespread support in web servers and development > platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built and= deployed now > using existing platforms and tools. In the future, the two specificati= ons are likely to be > > deployed in parallel for solving similar problems in different environ= ments. > > > =E2=80=94 Justin > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --001a114fd41cd25ba405697284f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the responses and additional suggesti= ons. Also sorry for the slow reply on my end - I was away on a nice long sp= ring break with the family, which was immediately followed by some other tr= avel.

I totally get what you are saying about DN compari= son and agree with the sentiment. I've just struggled a bit with wordin= g that would be both appropriate for a spec and also helpful to implementer= s. Having looked at it just a little more I see that RFC 2253 is obsoleted = by RFC 4514. But RFC 4514 says that it "does not define a canonical st= ring representation for DNs" and points to RFC 4517 for comparison of = DNs. So this change https://githu= b.com/ietf-oauth-mtls/i-d/commit/73e42346c90c3e25ec9248fbc0e52bee= 76afe7bd, which=C2=A0just a non normative bit with an informational ref= erence, is what I came up with for a note about DN comparison that is consi= stent with those RFCs. Suggestions on improvements or alternatives are welc= ome as always.

Looking again at the current text about authen= tication method metadata values and your proposed alternative text, what I = have does seem a bit superfluous. I'm leaning towards using your sugges= tion for 2.1.1 & 2.2.1.

I'll take another pass over A= ppendix A and consider incorporating some of your text and/or the sentiment= .



=C2=A0


On Wed, Mar 28, 2018 at 3:57 PM,= Justin Richer <jricher@mit.edu> wrote:
Thanks for the responses. I=E2=80=99ve cut out places where we seem to = agree here and responded to the rest inline below.=C2=A0

=C2=A0

<= /blockquote>
=C2=A72.1=C2=B61: It would be helpful to have a pointer on= methods of comparing DNs. In our implementation we serialize them to strin= gs using a canonical format (RFC2253) and doing a string comparison based o= n that. There are probably other ways, but it would be good to help develop= ers avoid doing something naive like comparing two different serializations= as strings.=C2=A0

That&#= 39;s really an implementation detail but I can note that some kind of norma= lization is likely needed in comparing DNs.

Might be worth pointing to= to RFC4514 in a non-normative example here. The thing is, there are equiva= lent DNs that aren=E2=80=99t exact string copies of each other. We=E2=80=99= ll want to avoid developers either doing a naive string comparison (leading= to false negatives) or doing their own home-made regexes (leading to proba= ble breakage and potentially security holes).


=C2=A0
=C2=A72.1=C2=B61: =E2=80=9Cconfigur= ed or registered=E2=80=9D is an unnecessary distinction, 6749 calls it =E2= =80=9Cregistered=E2=80=9D regardless of how it got there
<= /blockquote>

While I suppose that's true about 6749,= I think colloquially 'registered' and 'configured' have co= me to have more meaning to some/many people about how the client came to be= setup at the AS. So it might be strictly unnecessary but I'd prefer to= keep the "configured or registered" just to help say that it doe= sn't matter how the AS came to get the expected DN for client.

That= =E2=80=99s a fair assessment, and I=E2=80=99m fine with it as-is in that ca= se.

=C2=A0 = =C2=A0 =C2=A0
=C2=A0
=C2=A72.1.1=C2=B61: Is it necessary to intro= duce the registry here instead of just pointing to it? I=E2=80=99m fine wit= h stating that the values are used in both discovery and client registratio= n.=C2=A0

I had a hard tim= e describing things concisely here because of the history of how and when t= he authentication methods registry came to be, it's name, and where it&= #39;s used.=C2=A0 That text in=C2=A0=C2=B61 is what I was able to come up w= ith that I thought adequately explained it. It's admittedly not the mos= t elegant prose ever written but it does convey the info and I'm inclin= ed to leave it. However, I would be happy to consider alternative text here= , if you've got something specific to propose.

I guess I just don= =E2=80=99t think all that history is really needed right here. So I=E2=80= =99d replace it with:

For the PKI method of mutual TLS client authentication, th=
is specification
   defines and registers the following authentication method metadata
   value into the "OAuth Token Endpoint Authentication Methods" r=
egistry
   [IANA.OAuth.Parameters].
If you feel it needs a reference, you can potentially put it = in intro paragraph of the IANA section that sets the values, maybe? (=C2=A7= 6.3)

In the end I=E2=80=99m fine if the text stays= =E2=80=94 it=E2=80=99s not incorrect, I just feel it=E2=80=99s superfluous= . Same comments apply to the other sections so I=E2=80=99m not going to cop= y them here.

= =C2=A0

   Token Bi=
nding uses bare keys that are generated on the client, which avoids many of
   the difficulties of creating, distributing, and managing the certificate=
s used in this specification.
   However, Token Binding requires support across different portions o=
f the application
   stac=
k, including TLS and browser implementations. At the time of this writing,<=
/pre>
   there is relatively li=
ttle support for it in available application
   development platforms and tooling.  On the other hand, mutual TLS has be=
en around for some time
   and enjoys widespread support in web servers and development
   platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built and d=
eployed now
   using existing platforms and tools. In the future, the two specification=
s are likely to be
   dep=
loyed in parallel for solving similar problems in different environments.

=E2=80=94 Justin


=


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114fd41cd25ba405697284f2-- From nobody Tue Apr 10 11:59:13 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168FE129C6E for ; Tue, 10 Apr 2018 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmWp5xzAaxdP for ; Tue, 10 Apr 2018 11:59:09 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CE51273B1 for ; Tue, 10 Apr 2018 11:59:08 -0700 (PDT) X-AuditID: 1209190c-a67ff70000000bb8-8e-5acd097bc4b8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id D9.75.03000.B790DCA5; Tue, 10 Apr 2018 14:59:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w3AIx6Yb022907; Tue, 10 Apr 2018 14:59:07 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3AIx4w9002934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Apr 2018 14:59:05 -0400 From: Justin Richer Message-Id: <1A715ADF-F187-4469-926B-851E8EB097A5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_EEEAF77A-042E-4EC2-9E36-62C87BE12083" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 10 Apr 2018 14:59:03 -0400 In-Reply-To: Cc: "" To: Brian Campbell References: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixCmqrFvNeTbKoOOPkcXq/zcZLU6+fcXm wOSxZMlPJo+7Ry+yBDBFcdmkpOZklqUW6dslcGW0HdnCXjBjHWPF2Tl7GBsYT09m7GLk5JAQ MJFo7+xj7WLk4hASWMwk8XvqakYIZyOjxJVbXUwgVUIC15kkrmwPBrHZBFQlpq9pAYpzcPAK WEl8WeMHEmYWSJLoebOHBcTmBRq640obO4gtLKAvsezlWTYQmwWodeui4+wgrZwCgRI3NyuB mMwC6hLtJ11AKkSAqm8/ncMOccFPRolHBy6wQtypJPF/1xHmCYz8s5Bsm4VkG0RcW2LZwtfM ELamxP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokR HNiSPDsYz7zxOsQowMGoxMN74daZKCHWxLLiytxDjJIcTEqivHf/AYX4kvJTKjMSizPii0pz UosPMUpwMCuJ8PYynY0S4k1JrKxKLcqHSUlzsCiJ8y7avzdKSCA9sSQ1OzW1ILUIJivDwaEk wdvOAdQoWJSanlqRlplTgpBm4uAEGc4DNHwtSA1vcUFibnFmOkT+FKMlx6H3U3qYOc6ByWOX p/UwC7Hk5eelSonzZoE0CIA0ZJTmwc0EJSr3dXYWrxjFgV4U5j0EUsUDTHJwU18BLWQCWnjM 5wzIwpJEhJRUA+NmlVmX0yKZwnn1Zq0yWifV8tpR0bZERGq7j/zzRdzxs//nTtMX8v40fyp/ 8n/liL9n7Tn4DQ3sJ2mnGH52FHJaPilhhXYnR+9dW8lL8wK6LYS2RFhcLPiV8nAvj/G3COcT IQ/i1FtVH5pc7K2RcGp7PO/ejUetNUdWruEMSFL8pZf661hhthJLcUaioRZzUXEiAAa8iagv AwAA Archived-At: Subject: Re: [OAUTH-WG] Review of oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 18:59:12 -0000 --Apple-Mail=_EEEAF77A-042E-4EC2-9E36-62C87BE12083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Welcome back and I hope the break was enjoyable! The proposed diff below is great and just the kind of thing that I was = after. It=E2=80=99s non-normative but it alerts a naive developer (like = me) that doing string.equals() might not do what they intend.=20 I=E2=80=99ll keep an eye out for the next revision and be sure to read = it through. Thank you for being so responsive, the document is good and provides = important functionality that people are implementing today. =E2=80=94 Justin > On Apr 9, 2018, at 7:10 PM, Brian Campbell = wrote: >=20 > Thanks for the responses and additional suggestions. Also sorry for = the slow reply on my end - I was away on a nice long spring break with = the family, which was immediately followed by some other travel.=20 >=20 > I totally get what you are saying about DN comparison and agree with = the sentiment. I've just struggled a bit with wording that would be both = appropriate for a spec and also helpful to implementers. Having looked = at it just a little more I see that RFC 2253 is obsoleted by RFC 4514. = But RFC 4514 says that it "does not define a canonical string = representation for DNs" and points to RFC 4517 for comparison of DNs. So = this change = https://github.com/ietf-oauth-mtls/i-d/commit/73e42346c90c3e25ec9248fbc0e5= 2bee76afe7bd = , which just a non normative bit with an informational = reference, is what I came up with for a note about DN comparison that is = consistent with those RFCs. Suggestions on improvements or alternatives = are welcome as always.=20 >=20 > Looking again at the current text about authentication method metadata = values and your proposed alternative text, what I have does seem a bit = superfluous. I'm leaning towards using your suggestion for 2.1.1 & = 2.2.1.=20 >=20 > I'll take another pass over Appendix A and consider incorporating some = of your text and/or the sentiment.=20 >=20 >=20 >=20 > =20 >=20 >=20 > On Wed, Mar 28, 2018 at 3:57 PM, Justin Richer > wrote: > Thanks for the responses. I=E2=80=99ve cut out places where we seem to = agree here and responded to the rest inline below.=20 >=20 >> =20 >>=20 >> =C2=A72.1=C2=B61: It would be helpful to have a pointer on methods of = comparing DNs. In our implementation we serialize them to strings using = a canonical format (RFC2253) and doing a string comparison based on = that. There are probably other ways, but it would be good to help = developers avoid doing something naive like comparing two different = serializations as strings.=20 >>=20 >> That's really an implementation detail but I can note that some kind = of normalization is likely needed in comparing DNs.=20 >=20 > Might be worth pointing to to RFC4514 in a non-normative example here. = The thing is, there are equivalent DNs that aren=E2=80=99t exact string = copies of each other. We=E2=80=99ll want to avoid developers either = doing a naive string comparison (leading to false negatives) or doing = their own home-made regexes (leading to probable breakage and = potentially security holes). >=20 >>=20 >> =20 >> =C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an = unnecessary distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D = regardless of how it got there >>=20 >> While I suppose that's true about 6749, I think colloquially = 'registered' and 'configured' have come to have more meaning to = some/many people about how the client came to be setup at the AS. So it = might be strictly unnecessary but I'd prefer to keep the "configured or = registered" just to help say that it doesn't matter how the AS came to = get the expected DN for client. >=20 > That=E2=80=99s a fair assessment, and I=E2=80=99m fine with it as-is = in that case. >=20 >> =20 >> =20 >> =C2=A72.1.1=C2=B61: Is it necessary to introduce the registry here = instead of just pointing to it? I=E2=80=99m fine with stating that the = values are used in both discovery and client registration.=20 >>=20 >> I had a hard time describing things concisely here because of the = history of how and when the authentication methods registry came to be, = it's name, and where it's used. That text in =C2=B61 is what I was able = to come up with that I thought adequately explained it. It's admittedly = not the most elegant prose ever written but it does convey the info and = I'm inclined to leave it. However, I would be happy to consider = alternative text here, if you've got something specific to propose. >=20 > I guess I just don=E2=80=99t think all that history is really needed = right here. So I=E2=80=99d replace it with: >=20 > For the PKI method of mutual TLS client authentication, this = specification > defines and registers the following authentication method metadata > value into the "OAuth Token Endpoint Authentication Methods" = registry > [IANA.OAuth.Parameters = ]. > If you feel it needs a reference, you can potentially put it in intro = paragraph of the IANA section that sets the values, maybe? (=C2=A76.3) >=20 > In the end I=E2=80=99m fine if the text stays =E2=80=94 it=E2=80=99s = not incorrect, I just feel it=E2=80=99s superfluous. Same comments apply = to the other sections so I=E2=80=99m not going to copy them here. >=20 >> =20 >>=20 >> =C2=A7A=C2=B62: This paragraph reads a bit overly defensive. I = understand the need to position the two drafts in relationship to each = other, but the tone here could be adjusted significantly without losing = the thrust of the main argument. >>=20 >> The line about Token Binding not having a monopoly on the binding of = tokens is admittedly a bit tongue-in-cheek and also a nod to the point = you made the other day about running out of names.=20 >>=20 >> Honestly though, this text wasn't intended to be defensive and, even = when I read it again, it doesn't come off that way to me. As usual, if = you've got specific text to propose that you think would be better, I'd = be happy to consider it. But I don't feel like the current text is = particularly problematic or in need of change.=20 >=20 > I took a crack at rewriting the second paragraph (note that I removed = the first sentence entirely), but in the end it=E2=80=99s up to you how = you want to present the comparison between the documents: >=20 > Token Binding uses bare keys that are generated on the client, = which avoids many of > the difficulties of creating, distributing, and managing the = certificates used in this specification. > However, Token Binding requires support across different portions = of the application > stack, including TLS and browser implementations. At the time of = this writing, > there is relatively little support for it in available application > development platforms and tooling. On the other hand, mutual TLS = has been around for some time > and enjoys widespread support in web servers and development > platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built = and deployed now > using existing platforms and tools. In the future, the two = specifications are likely to be > deployed in parallel for solving similar problems in different = environments. >=20 > =E2=80=94 Justin >=20 >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_EEEAF77A-042E-4EC2-9E36-62C87BE12083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Welcome back and I hope the break was enjoyable!

The proposed diff below = is great and just the kind of thing that I was after. It=E2=80=99s = non-normative but it alerts a naive developer (like me) that doing = string.equals() might not do what they intend. 

I=E2=80=99ll keep an eye = out for the next revision and be sure to read it through.

Thank you for being so = responsive, the document is good and provides important functionality = that people are implementing today.

 =E2=80=94 Justin

On Apr 9, 2018, at 7:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks for the responses and additional suggestions. Also = sorry for the slow reply on my end - I was away on a nice long spring = break with the family, which was immediately followed by some other = travel.

I totally = get what you are saying about DN comparison and agree with the = sentiment. I've just struggled a bit with wording that would be both = appropriate for a spec and also helpful to implementers. Having looked = at it just a little more I see that RFC 2253 is obsoleted by RFC 4514. = But RFC 4514 says that it "does not define a canonical string = representation for DNs" and points to RFC 4517 for comparison of DNs. So = this change https://github.com/ietf-oauth-mtls/i-d/commit/73e42346c90c3e25ec9248fbc0e52bee76afe7bd, which just a non = normative bit with an informational reference, is what I came up with = for a note about DN comparison that is consistent with those RFCs. = Suggestions on improvements or alternatives are welcome as always.

Looking again at the current text about = authentication method metadata values and your proposed alternative = text, what I have does seem a bit superfluous. I'm leaning towards using = your suggestion for 2.1.1 & 2.2.1.

I'll take another pass over Appendix A and consider = incorporating some of your text and/or the sentiment.



 


On Wed, = Mar 28, 2018 at 3:57 PM, Justin Richer <jricher@mit.edu> wrote:
Thanks for the responses. I=E2=80=99ve cut out places where = we seem to agree here and responded to the rest inline below. 

 

=C2=A72.1=C2=B61: It = would be helpful to have a pointer on methods of comparing DNs. In our = implementation we serialize them to strings using a canonical format = (RFC2253) and doing a string comparison based on that. There are = probably other ways, but it would be good to help developers avoid doing = something naive like comparing two different serializations as = strings. 

That's really an implementation detail = but I can note that some kind of normalization is likely needed in = comparing DNs.

Might be worth = pointing to to RFC4514 in a non-normative example here. The thing is, = there are equivalent DNs that aren=E2=80=99t exact string copies of each = other. We=E2=80=99ll want to avoid developers either doing a naive = string comparison (leading to false negatives) or doing their own = home-made regexes (leading to probable breakage and potentially security = holes).


 
=C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D = is an unnecessary distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D = regardless of how it got there

While I suppose that's = true about 6749, I think colloquially 'registered' and 'configured' have = come to have more meaning to some/many people about how the client came = to be setup at the AS. So it might be strictly unnecessary but I'd = prefer to keep the "configured or registered" just to help say that it = doesn't matter how the AS came to get the expected DN for client.

That=E2=80=99s a = fair assessment, and I=E2=80=99m fine with it as-is in that = case.

     
 
=C2=A72.1.1=C2=B61: Is it necessary to introduce the registry = here instead of just pointing to it? I=E2=80=99m fine with stating that = the values are used in both discovery and client = registration. 

I had a hard time describing things = concisely here because of the history of how and when the authentication = methods registry came to be, it's name, and where it's used.  That = text in =C2=B61 is what I was able to come up with that I thought = adequately explained it. It's admittedly not the most elegant prose ever = written but it does convey the info and I'm inclined to leave it. = However, I would be happy to consider alternative text here, if you've = got something specific to propose.

I guess I just = don=E2=80=99t think all that history is really needed right here. So = I=E2=80=99d replace it with:

For the PKI =
method of mutual TLS client authentication, this specification
   defines and registers the following authentication method metadata
   value into the "OAuth Token Endpoint Authentication Methods" =
registry
   [IANA.OAuth.Parameters].
If you feel it needs a reference, you can = potentially put it in intro paragraph of the IANA section that sets the = values, maybe? (=C2=A76.3)

In the end I=E2=80=99m fine if the text stays =E2=80=94 = it=E2=80=99s not incorrect, I just feel it=E2=80=99s superfluous. Same = comments apply to the other sections so I=E2=80=99m not going to copy = them here.

 

=C2=A7A=C2=B62: This paragraph reads a bit = overly defensive. I understand the need to position the two drafts in = relationship to each other, but the tone here could be adjusted = significantly without losing the thrust of the main = argument.

The line about Token Binding not having = a monopoly on the binding of tokens is admittedly a bit tongue-in-cheek = and also a nod to the point you made the other day about running out of = names.

Honestly = though, this text wasn't intended to be defensive and, even when I = read it again, it doesn't come off that way to me. As usual, if you've = got specific text to propose that you think would be better, I'd be = happy to consider it. But I don't feel like the current text is = particularly problematic or in need of change.

I took a crack = at rewriting the second paragraph (note that I removed the first = sentence entirely), but in the end it=E2=80=99s up to you how you want = to present the comparison between the documents:

   Token Binding uses bare keys =
that are generated on the client, which avoids many of
   the difficulties of creating, distributing, and managing the =
certificates used in this specification.
   However, Token Binding =
requires support across different portions of the application
   stack, including TLS and =
browser implementations. At the time of this writing,
   there is relatively little =
support for it in available application
   development platforms and tooling.  On the other hand, mutual TLS has =
been around for some time
   and enjoys widespread support in web servers and development
   platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built =
and deployed now
   using existing platforms and tools. In the future, the two =
specifications are likely to be
   deployed in parallel for =
solving similar problems in different =
environments.

=E2=80=94 Justin




CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_EEEAF77A-042E-4EC2-9E36-62C87BE12083-- From nobody Wed Apr 11 13:47:43 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB112D7EA for ; Wed, 11 Apr 2018 13:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R-cdxZkAtuP for ; Wed, 11 Apr 2018 13:47:36 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF7312D77E for ; Wed, 11 Apr 2018 13:47:35 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 15-v6so4329035itl.1 for ; Wed, 11 Apr 2018 13:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YAofezifCr/LK83ueMlvQE51R1xkNn7cAQn7dc2B23g=; b=JY1lWy9fgmEKWZuHFN9fqTX6jXeMFKdvV2ygkuO/oRtCvcupPuoIT4x/8TLjjYzptA YDyPnD4JLqEdju9eE25d+hRpNWrbxKCqRJlA8VbHZJnTMn/vLURaPbvyIlPlAfmbaAhy XcWajQRkoxStD50OuZeH4F4AhJrgu1JsDj2qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YAofezifCr/LK83ueMlvQE51R1xkNn7cAQn7dc2B23g=; b=VnESO8VH1xcllLi391P8C1ODFKAcVg7th3bN/sF84IJloGOizPiAT4KOXp3UKOPJ6T jaZQvAc3KDcSgWCPKRE9VyN4JBSDaKPhj/igPYrT7BIi1ZNzRJIA6Ly5+75uOlGMSrP6 HoM0JollvIw61TvZSYyNf5gCEpTCgsbIRM9oum12fqj/BJU8Pdwe8PK5TXuu8CNUUMao IcmadEZ5qBJ8q0NC2Cz9+w/uHgj0K2UVBoDymnSEwJD4Q+p39mPBgtl3ez0cTiNXrHLQ aEuvevZRLCNUSfK8LHZrJifq0stkDJPSgrocYC4BzAkmNuetAQxQvFk8Pg3JA9qQKLnf y2Ig== X-Gm-Message-State: ALQs6tBtZIxZWhDC8Nw3ZTc0ofImUEdYnla+VWQXay7+dQ0UcX95vbeQ 1fmT4v+Pah+70kcQSgtp9plU0o6JJQRxbFxzCNVVn5CBr64/FTy9xDrhpEc1jTO6xpwYYK+Ae/L 3oBz1ySDiREp3wQ== X-Google-Smtp-Source: AIpwx4/P2GP1uw1yIuNgNP/Ddyzv5rh8SH1IPj4RDzcaWjkx/HxBMUFd5oGRRSxyoDVrDb+lUVw4FBxDV/6M9Ny+zHU= X-Received: by 2002:a24:e4c2:: with SMTP id o185-v6mr5539479ith.37.1523479654842; Wed, 11 Apr 2018 13:47:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.126.212 with HTTP; Wed, 11 Apr 2018 13:47:04 -0700 (PDT) In-Reply-To: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> From: Brian Campbell Date: Wed, 11 Apr 2018 14:47:04 -0600 Message-ID: To: Neil Madden Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000a676ec056998bfd9" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 20:47:42 -0000 --000000000000a676ec056998bfd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and feedback, Neil. I apologize for my being slow to respond. As I said to Justin recently , I've been away from things for a while. Also there's a lot here to get through so took me some time. It looks like John touched on some of your comments but not all. I'll try and reply to them as best I can inline below. On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden wrote: > Hi, > > I have reviewed this draft and have a number of comments, below. ForgeRoc= k > have not yet implemented this draft, but there is interest in implementin= g > it at some point. (Disclaimer: We have no firm commitments on this at the > moment, I do not speak for ForgeRock, etc). > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 > defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, th= ere is already a > confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key= , which itself can > contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax a= nd semantics. The > draft proposes: > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D } } > > but you can already do: > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } > > If the intent is just to save some space and avoid the mandatory fields o= f > the existing JWK types, maybe this would be better addressed by defining = a > new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: > =E2=80=9C=E2=80=A6=E2=80=9D }. > The intent of the x5t#S256 confirmation method was to be space efficient and straightforward while utilizing the framework and registry that RFC 7800 gives. Even a new JWK type like that would still use more space. And I'd argue that the new confirmation method is considerably more straightforward than registering a new JWK type (and the implications that would have on JWK implementations in general) in order to use the existing "jwk" confirmation method. > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s > really only the client authentication that we are interested here, and th= e > fact that the server also authenticates with a certificate is not hugely > relevant to this particular spec (although it is to the overall security = of > OAuth). Also, TLS defines non-certificate based authentication mechanisms > (e.g. TLS-SRP extension for password authenticated key exchange, PSK for > pre-shared key authentication) and even non-X.509 certificate types ( > https://www.iana.org/assignments/tls-extensiontype-values/t > ls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d pr= efer > that the draft explicitly referred to =E2=80=9CX.509 Client Certificate > Authentication=E2=80=9D rather than mutual TLS, and changed identifiers l= ike > =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/d > raft-ietf-oauth-mtls-07#section-2.1.1) to something more explicit like > =E2=80=98tls_x509_pki_client_auth=E2=80=99. > > This is especially confusing in section 3 on sender constrained access > tokens, as there are two different servers involved: the AS and the > protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authe= ntication between > them, only between each of them and the client. > Choosing names and terminology is difficult and the "right" wording is often subjective. I believe that the current wording sufficiently conveys what is going on in the draft to most readers. Most readers thus far seem to agree. There is some text now that does say that the mutual auth in the draft is in fact X.509 client cert authn but, in the next revision, I'll look for other opportunities where it could be stated more clearly. > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC > only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The > wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be u= sed with > TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. > The reference to BCP 195 (which unfortunately the original OAuth 2.0 RFC doesn't have because it didn't exist then) is meant to account for changing versions and recommendations around TLS. Currently that BCP says TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't outright prohibit them. > > 4. It might be useful to have a discussion for implementors of whether TL= S > session resumption (and PSK in TLS 1.3) and/or renegotiation impact the u= se > of client certificates, if at all? > That might well be useful but I don't myself know what it would say. I've (maybe naively) figured those are deployment details that will just work out. Perhaps you could propose some text around such a discussion that the WG could consider? > > 5. Section 3 defines sender-constrained access tokens in terms of the > confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 > Pop Architecture draft defines sender constraint and key confirmation as > different things (https://tools.ietf.org/html/d > raft-ietf-oauth-pop-architecture-08#section-6.2). The draft should decide > which of those it is implementing and if sender constraint is intended, > then reusing the confirmation key claims seems misleading. (I think this > mTLS draft is doing key confirmation so should drop the language about > sender constrained tokens). > I will say again that choosing names and terminology is difficult... Although I must admit that I started using "sender constrained" somewhat indiscriminately at first and it's just sort of stuck. At the time I was trying to incorporate bits of draft-sakimura-oauth-jpop in a way that might help bring on and keep the authors of that draft onboard with this mtls draft. In retrospect it looks like I did that part wrong anyway. But that was the thinking at the time and the history, for whatever it's worth. More recently, Nat was requesting that "sender constrained" be included in the title. So there's that too. In defense of my mistake, however, if there's a line between "sender constrained" and "key confirmation" tokens, it's a bit of a fuzzy line. And I'd argue that what this draft is doing pretty close to the line. But ultimately I think you are right that what this mtls draft is doing with access tokens is more accurately described with the key confirmation term. So, yes, the draft should probably drop (or at least minimize) the language about sender constrained. I'll do that in the next draft version, barring big objections from the WG. The tricky thing with making that change is that there a client and server metadata parameters with the name "mutual_tls_sender_constrained_access_tok= ens" that should probably also change. But that would be a breaking change (of sorts anyway), which shouldn't be taken lightly at this stage. I feel that some explicit okays from the WG are needed before doing so (rough consensus stye) . Any WG members want to weigh in here and help get a "sense of the group" concerning changing those metadata names? > > 6. The OAuth 2.0 PoP Architecture draft says ( > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5 > ): > > Strong, fresh session keys: > > Session keys MUST be strong and fresh. Each session > deserves an > independent session key, i.e., one that is generated > specifically > for the intended use. In context of OAuth this means tha= t > keying > material is created in such a way that can only be used b= y > the > combination of a client instance, protected resource, and > authorization scope. > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/d > raft-ietf-oauth-mtls-07#section-3) says: > > The client makes protected resource requests as described in > [RFC6750], however, those requests MUST be made over a mutually > authenticated TLS connection using the same certificate that was > used > for mutual TLS at the token endpoint. > > These two statements are contradictory: the OAuth 2.0 PoP architecture > effectively requires a fresh key-pair to be used for every access token > request, whereas this draft proposes reusing the same long-lived client > certificate for every single access token and every resource server. > > In the self-signed case (and even in the CA case, with a bit of work - > e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is > perfectly possible for the client to generate a fresh key-pair for each > access token and include the certificate on the token request (e.g., as p= er > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distrib > ution-03#section-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D= value should > probably be described). This should probably at least be an option. > This draft doesn't necessarily seek to align with the (long expired) PoP architecture draft. Rather it is aiming to provide a pragmatic solution for PoP style access tokens and OAuth client auth using mTLS client certificates. That said, with the current draft, it's certainly possible for a client to update its cert more frequently, even so far as using a new one for each access token. The details of how that would work will vary some based on the token endpoint authentication method. But it's not precluded. > > 7. The use of a single client certificate with every resource server (RS) > should be called out in a Privacy Considerations section, as it allows > correlation of activity. > Practically speaking the access tokens being presented likely already have correlatable info in them about the client as well as the user. I don't know that there's much of a (new) concern in reality. If you feel this concern is unique and import enough though, perhaps there's some text you'd like to propose for a Privacy Considerations section that the WG could consider? I mean, I guess it doesn't hurt to mention it but I would like to avoid overstating the issue. > > 8. This is maybe a more general point, but RFC 6750 defines the > Authorization: Bearer scheme (https://tools.ietf.org/html/r > fc6750#section-2) for a client to communicate it=E2=80=99s access token t= o the RS > in a standard way. As sender-constrained access tokens are not strictly > bearer tokens any more, should this draft also register a new scheme for > that? Should there be a generic PoP scheme? > The thinking and general consensus (in this draft as well as the OAuth token binding work) has been that continuing to use the RFC 6750 scheme while putting the "not strictly bearer" stuff in (or referenced by) the token itself will be easier on deployment and implementation. And better for adoption as a result. I believe some early implementation work has borne that out too. > > 9. The Security Considerations should really make some mention of the lon= g > history of attacks against X.509 certificate chain validation, e.g. failu= re > to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in= parsing DNs, etc. > It should be strongly suggested to use an existing TLS library to perform > these checks rather than implementing your own checks. This relates to > Justin=E2=80=99s comments around DN parsing and normalisation. > Suggesting to use an existing TLS library is certainly sound advice and I sort of felt is implied in the draft. But saying so more strongly/explicitly might be worthwhile. And pointing to historical reasons to do so would probably be good too. Could you propose a new Security Considerations section or maybe augmentation of =C2=A75.2 with tha= t content? > > 10. The PKI client authentication method (https://tools.ietf.org/html/d > raft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of > certificate revocation and how to handle checking for that (CRLs, OCSP - > with stapling?). Neither does the Security Considerations. If this is a > detail to be agreed between then AS and the CA (or just left up to the AS > TLS stack) then that should perhaps be made explicit. Again, there are > privacy considerations with some of these mechanisms, as OCSP requests ar= e > typically sent in the clear (plain HTTP) and so allow an observer to see > which clients are connecting to which AS. > I didn't think that a TLS client could do OCSP stapling? That aside, revocation checking (how and even if) is something that's at the discretion of the AS. I can add something in =C2=A72.1 to say that more explicitly. > 11. The same comment applies to how the protected resource checks for > revocation of the certificate presented during sender constrained access > token usage. Should the RS make its own revocation checks based on the > information in the certificate presented, or should it trust the > certificate while the access token is still valid? If the latter case, is > the AS responsible for revoking any access tokens whose certificate have > been revoked (if so, should it be doing an OCSP call on every token > introspection request, and should the RS be passing on the > certificate/serial number on that request)? If the Client request uses OC= SP > Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS > verify the signature on that if it does not have a separate trust > relationship with the CA already? > The draft effectively uses cert mtls at the RS as a proof-of-possession method only and not as authentication. So revocation checking isn't really applicable. In specific deployment situations, I suppose an RS could check revocation. But that'd be a deployment decision for the RS that's beyond the scope of this draft. > 12. The use of only SHA-256 fingerprints means that the security strength > of the sender-constrained access tokens is limited by the collision > resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without a ne= w > specification for a new thumbprint algorithm. An implication of this is > that is is fairly pointless for the protected resource TLS stack to ever > negotiate cipher suites/keys with a higher level of security. In more > crystal ball territory, if a practical quantum computer becomes a > possibility within the lifetime of this spec, then the expected collision > resistance of SHA-256 would drop quadratically, allowing an attacker to > find a colliding certificate in ~2^64 effort. If we are going to pick jus= t > one thumbprint hash algorithm, I would prefer we pick SHA-512. > The idea behind haveing just one thumbprint hash algorithm was to keep things simple. And SHA-256 seems good enough for the reasonably foreseeable future (and space aware). Also a new little spec to register a different hash algorithm, should the need arise, didn't seem particularity onerous. That was the thinking anyway. Maybe it is too short sighted though? I do think SHA-256 should stay regardless. But the draft could also define SHA-512 (and maybe others). What do you and WG folks think about that? It would probably then be useful for the metadata in =C2=A73.3 and =C2=A73.= 4 to change from just boolean values to something to convey what hash alg/cnf method the client expects and the list of what the server supports. That's maybe something that should be done anyway. That'd be a breaking change to the metadata. But there's already another potential breaking change identified earlier in this message. So maybe it's worth doing... How do folks feel about making this kind of change? > Cheers, > > Neil > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote: > > > > All, > > > > As discussed during the meeting today, we are starting a WGLC on the > MTLS document: > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > > > Please, review the document and provide feedback on any issues you see > with the document. > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > Regards, > > Rifaat and Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a676ec056998bfd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review and feedback, Neil. I apologize= for my being slow to respond. As I said to Just= in recently, I've been away from things for a while. Also there'= ;s a lot here to get through so took me some time.

It looks l= ike John touched on some of your comments but not all. I'll try and rep= ly to them as best I can inline below.


On Thu, Mar 29, 2018 at 9:18 AM, Ne= il Madden <neil.madden@forgerock.com> wrote:
Hi,

I have reviewed this draft and have a number of comments, below. ForgeRock = have not yet implemented this draft, but there is interest in implementing = it at some point. (Disclaimer: We have no firm commitments on this at the m= oment, I do not speak for ForgeRock, etc).

1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defines a new confirmation me= thod =E2=80=9Cx5t#S256=E2=80=9D. However, there is already a confirmation m= ethod =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key, which itself c= an contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax = and semantics. The draft proposes:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2= =80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } }

but you can already do:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80= =9D: { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D = } } }

If the intent is just to save some space and avoid the mandatory fields of = the existing JWK types, maybe this would be better addressed by defining a = new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80= =9D }.

The intent of the x5t#S256=C2=A0= confirmation method was to be space efficient and straightforward while uti= lizing the framework and registry that RFC 7800 gives.=C2=A0 Even a new JWK= type like that would still use more space. And I'd argue that the new = confirmation method is considerably more straightforward than registering a= new JWK type (and the implications that would have on JWK implementations = in general) in order to use the existing "jwk" confirmation metho= d.=C2=A0

=C2=A0

2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client authentication= that we are interested here, and the fact that the server also authenticat= es with a certificate is not hugely relevant to this particular spec (altho= ugh it is to the overall security of OAuth). Also, TLS defines non-certific= ate based authentication mechanisms (e.g. TLS-SRP extension for password au= thenticated key exchange, PSK for pre-shared key authentication) and even n= on-X.509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls= -extensiontype-values-3). I=E2=80=99d prefer that the draft explicitly = referred to =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rathe= r than mutual TLS, and changed identifiers like =E2=80=98tls_client_auth=E2= =80=99 (https://tools.ietf.org/htm= l/draft-ietf-oauth-mtls-07#section-2.1.1) to something more e= xplicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.

This is especially confusing in section 3 on sender constrained access toke= ns, as there are two different servers involved: the AS and the protected r= esource server, but there is no =E2=80=9Cmutual=E2=80=9D authentication bet= ween them, only between each of them and the client.
<= br>
Choosing names and terminology is difficult and the "rig= ht" wording is often subjective. I believe that the current wording su= fficiently conveys what is going on in the draft to most readers. Most read= ers thus far seem to agree. There is some text now that does say that the m= utual auth in the draft is in fact X.509 client cert authn but, in the next= revision, I'll look for other opportunities where it could be stated m= ore clearly.

=C2=A0

3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC onl= y specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The wordin= g in Section 5.1 doesn=E2=80=99t seem clear if this could also be used with= TLS 1.0 or 1.1, or whether it is only referring to future TLS versions.

The reference to BCP 195 (which unfortuna= tely the=C2=A0original OAuth 2.0 RFC doesn't have because it didn't= exist then) is meant to account for changing versions and recommendations = around TLS. Currently that BCP says TLS 1.2 is a must and suggests against = 1.1 & 1.0 but doesn't outright prohibit them.

= =C2=A0

4. It might be useful to have a discussion for implementors of whether TLS = session resumption (and PSK in TLS 1.3) and/or renegotiation impact the use= of client certificates, if at all?

Tha= t might well be useful but I don't myself know what it would say. I'= ;ve (maybe naively) figured those are deployment details that will just wor= k out. Perhaps you could propose some text around such a discussion that th= e WG could consider?

=C2=A0

5. Section 3 defines sender-constrained access tokens in terms of the confi= rmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 Pop Arc= hitecture draft defines sender constraint and key confirmation as different= things (https://tools.i= etf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2= ). The draft should decide which of those it is implementing and if sender = constraint is intended, then reusing the confirmation key claims seems misl= eading. (I think this mTLS draft is doing key confirmation so should drop t= he language about sender constrained tokens).

I will say again that choosing names and terminology is difficult...=

Although I must admit that I started using "sender constrained= " somewhat indiscriminately at first and it's just sort of stuck. = At the time I was trying to incorporate bits of draft-sakimura-oauth-jpop i= n a way that might help bring on and keep the authors of that draft onboard= with this mtls draft. In retrospect it looks like I did that part wrong an= yway. But that was the thinking at the time and the history, for whatever i= t's worth. More recently, Nat was requesting that "sender constrai= ned" be included in the title. So there's that too.=C2=A0

=
In defense of my mistake, however, if there's a line between= "sender constrained" and "key confirmation" tokens, it= 's a bit of a fuzzy line. And I'd argue that what this draft is doi= ng pretty close to the line.

But ultimately I think you = are right that what this mtls draft is doing with access tokens is more acc= urately described with the key confirmation term.

=
So, yes, the draft should probably drop (or at least minimize) the lan= guage about sender constrained. I'll do that in the next draft version,= barring big objections from the WG.

The tricky thing wit= h making that change is that there a client and server metadata parameters = with the name "mutual_tls_sender_constrained_access_tokens" = that should probably also change. But that would be a breaking change (of s= orts anyway), which shouldn't be taken lightly at this stage. I feel th= at some explicit okays from the WG are needed before doing so (rough consen= sus stye) . Any WG members want to weigh in here and help get a "sense of the group" con= cerning changing those metadata names?

=C2=A0

6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft-ietf-oauth-pop-a= rchitecture-08#section-5):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Strong, fresh session keys:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Session keys MUST b= e strong and fresh.=C2=A0 Each session deserves an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 independent session= key, i.e., one that is generated specifically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the intended us= e.=C2=A0 In context of OAuth this means that keying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 material is created= in such a way that can only be used by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 combination of a cl= ient instance, protected resource, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization scope= .


However, the mTLS draft section 3 (htt= ps://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) = says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client makes protected resource requests as= described in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC6750], however, those requests MUST be made= over a mutually
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated TLS connection using the same cer= tificate that was used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for mutual TLS at the token endpoint.

These two statements are contradictory: the OAuth 2.0 PoP architecture effe= ctively requires a fresh key-pair to be used for every access token request= , whereas this draft proposes reusing the same long-lived client certificat= e for every single access token and every resource server.

In the self-signed case (and even in the CA case, with a bit of work - e.g.= , https://www.vaultproject.io/docs/sec= rets/pki/index.html) it is perfectly possible for the client to generat= e a fresh key-pair for each access token and include the certificate on the= token request (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distrib<= wbr>ution-03#section-5.1 - in which case an appropriate =E2=80=9Calg=E2= =80=9D value should probably be described). This should probably at least b= e an option.

This draft doesn't nec= essarily seek to align with the (long expired) PoP architecture draft.=C2= =A0 Rather it is aiming to provide a pragmatic solution for PoP style acces= s tokens and OAuth client auth using mTLS client certificates.

That said, with the current draft, it's certainly possible for a= client to update its cert more frequently, even so far as using a new one = for each access token. The details of how that would work will vary some ba= sed on the token endpoint authentication method. But it's not precluded= .

=C2=A0

7. The use of a single client certificate with every resource server (RS) s= hould be called out in a Privacy Considerations section, as it allows corre= lation of activity.

Practically speakin= g the access tokens being presented likely already have correlatable info i= n them about the client as well as the user. I don't know that there= 9;s much of a (new) concern in reality. If you feel this=C2=A0concern is un= ique and import enough though, perhaps there's some text you'd like= to propose for a Privacy Considerations section that the WG could consider= ? I mean, I guess it doesn't hurt to mention it but I would like to avo= id overstating the issue.=C2=A0

=C2=A0

8. This is maybe a more general point, but RFC 6750 defines the Authorizati= on: Bearer scheme (https://tools.ietf.org/html/rfc= 6750#section-2) for a client to communicate it=E2=80=99s access token t= o the RS in a standard way. As sender-constrained access tokens are not str= ictly bearer tokens any more, should this draft also register a new scheme = for that? Should there be a generic PoP scheme?

The thinking and general consensus (in this draft as well as the O= Auth token binding work) has been that continuing to use the RFC 6750 schem= e while putting the "not strictly bearer" stuff in (or referenced= by) the token itself will be easier on deployment and implementation. And = better for adoption as a result. I believe some early implementation work h= as borne that out too.

=C2=A0

9. The Security Considerations should really make some mention of the long = history of attacks against X.509 certificate chain validation, e.g. failure= to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in = parsing DNs, etc. It should be strongly suggested to use an existing TLS li= brary to perform these checks rather than implementing your own checks. Thi= s relates to Justin=E2=80=99s comments around DN parsing and normalisation.=

Suggesting to use an existing TLS libr= ary is certainly sound advice and I sort of felt is implied in the draft. B= ut saying so more strongly/explicitly might be worthwhile.=C2=A0 And pointi= ng to historical reasons to do so would probably be good too.=C2=A0 Could y= ou propose a new Security Considerations section or maybe augmentation of = =C2=A75.2 with that content?

=C2=A0

10. The PKI client authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#sectio= n-2.1) makes no mention at all of certificate revocation and how to han= dle checking for that (CRLs, OCSP - with stapling?). Neither does the Secur= ity Considerations. If this is a detail to be agreed between then AS and th= e CA (or just left up to the AS TLS stack) then that should perhaps be made= explicit. Again, there are privacy considerations with some of these mecha= nisms, as OCSP requests are typically sent in the clear (plain HTTP) and so= allow an observer to see which clients are connecting to which AS.

I didn't think that a TLS client could do = OCSP=C2=A0stapling?

That aside, revocation checking (how = and even if) is something that's at the discretion of the AS. I can add= something in =C2=A72.1 to say that more explicitly.



11. The same comment applies to how the protected resource checks for revoc= ation of the certificate presented during sender constrained access token u= sage. Should the RS make its own revocation checks based on the information= in the certificate presented, or should it trust the certificate while the= access token is still valid? If the latter case, is the AS responsible for= revoking any access tokens whose certificate have been revoked (if so, sho= uld it be doing an OCSP call on every token introspection request, and shou= ld the RS be passing on the certificate/serial number on that request)? If = the Client request uses OCSP Stapling (https://en.wikiped= ia.org/wiki/OCSP_stapling) how can the RS verify the signature on = that if it does not have a separate trust relationship with the CA already?=

The draft effectively uses cert mtls a= t the RS as a proof-of-possession method only and not as authentication. So= revocation checking isn't really applicable. In specific deployment si= tuations, I suppose an RS could check revocation. But that'd be a deplo= yment decision for the RS that's beyond the scope of this draft.
=C2=A0


12. The use of only SHA-256 fingerprints means that the security strength o= f the sender-constrained access tokens is limited by the collision resistan= ce of SHA-256 - roughly =E2=80=9C128-bit security" - without a new spe= cification for a new thumbprint algorithm. An implication of this is that i= s is fairly pointless for the protected resource TLS stack to ever negotiat= e cipher suites/keys with a higher level of security. In more crystal ball = territory, if a practical quantum computer becomes a possibility within the= lifetime of this spec, then the expected collision resistance of SHA-256 w= ould drop quadratically, allowing an attacker to find a colliding certifica= te in ~2^64 effort. If we are going to pick just one thumbprint hash algori= thm, I would prefer we pick SHA-512.

Th= e idea behind haveing just one thumbprint hash algorithm was to keep things= simple. And SHA-256 seems good enough for the reasonably foreseeable futur= e (and space aware). Also a new little spec to register a different hash al= gorithm, should the need arise, didn't seem particularity onerous.
=
That was the thinking anyway. Maybe it is too short sighted = though?

I do think SHA-256 should stay regardless.
But the draft could also define SHA-512 (and maybe others). Wh= at do you and WG folks think about that?

It would probabl= y then be useful for the metadata in =C2=A73.3 and =C2=A73.4 to change from= just boolean values to something to convey what hash alg/cnf method the cl= ient expects and the list of what the server supports. That's maybe som= ething that should be done anyway. That'd be a breaking change to the m= etadata. But there's already another potential breaking change identifi= ed earlier in this message. So maybe it's worth doing...

<= div>How do folks feel about making this kind of change?

=


=C2=A0
Cheers,

Neil


> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= br> >
> All,
>
> As discussed during the meeting today, we are starting a WGLC on the M= TLS document:
> https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07
>
> Please, review the document and provide feedback on any issues you see= with the document.
>
> The WGLC will end in two weeks, on April 2, 2018.
>
> Regards,
>=C2=A0 Rifaat and Hannes
>
> ______________= _________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a676ec056998bfd9-- From nobody Wed Apr 11 22:37:59 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1712711A for ; Wed, 11 Apr 2018 22:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbyqo1JRgaN8 for ; Wed, 11 Apr 2018 22:37:57 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23BC127058 for ; Wed, 11 Apr 2018 22:37:56 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id p142-v6so5859700lfd.6 for ; Wed, 11 Apr 2018 22:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=uB/tUZWebn0U1jQj6VonosB1jEkm5zaPHqJuweW/sqA=; b=hqlcgIotJN8C0zXDchwNaHrjdmC/M/aw5NPZxt+yH4q9DMruAxfiKIk1/md2SLau4j dS0eeJzBsAUskW9rYVgsQVPP62o+ohH/PqNSA1a0ggzZFVrENa16QAA8uYyEbvxF2TkG UEM7fRO5AXpxCs9z4N/jaJBrDGLjJ9D3iCyPvMp7Pbd8fw9LSm3CVaTI3S0kajEdGtMP xASdMZHVp/PDNNBRcrvH7lI0U9MVIL+IWJQIh6SP8HIV27jMrjec2ovYFYiGvs6Tlz/a t8keuEds7nLNPdEWOsJCxL2vMrl1UsjvZc32c5P8t72HVDR3IBQaWCNGCcIRdO086LEA Tq1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=uB/tUZWebn0U1jQj6VonosB1jEkm5zaPHqJuweW/sqA=; b=jhTJIsOTRqAvvA6C5uB8OOjOU7bXsQAX/4NoDCFyl3DLokyVvNNMzhuMoulADc/Bez NaU8hN+A72mkLtOtGfMCDgp+j53NFzcm0VriOEvvmtAOEcucihlaZl2EsMzTyBPsxCnt JrdoIk26NoyRadC1aIs7/2BFyiT90wcpo3TDgpjAHPuJVCGxzn3gA7oJ4uC4zQRugtlo D2nSLaZOHhMKLcvaVLni+zXwdePuwXJae197Iq9eMAwax5XLyrER8KhCxR2yO+Xvzye+ ICLwH4q0g1oNjJhG2JV1tC7yrJvs92unvyWXdAwtmNBPUqtE9jnucm1ITshw8EbwICw2 kN2w== X-Gm-Message-State: ALQs6tBqIG3CiBGTtbLYhKNjfjJYDt3MbZihcDI311Npk9/mp++h3eAM Jp8lWHfW2w396B6KQ3ABrkrhTznt+msGvihETazexQ== X-Google-Smtp-Source: AIpwx48ey+QrWz5kRnyj87id3lam1ZQB7hlbmwcAoanh2OmR5t+PYRAZ/Ru6b6VLnkjKO3xMnSmBPLrsK6CZx23cNH8= X-Received: by 10.46.157.136 with SMTP id c8mr4944254ljj.85.1523511474297; Wed, 11 Apr 2018 22:37:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d190:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 22:37:53 -0700 (PDT) Reply-To: solenwin2@gmail.com From: Solen win Date: Thu, 12 Apr 2018 12:37:53 +0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="883d24f220a03c9fce0569a028b1" Archived-At: Subject: [OAUTH-WG] Confirm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 05:37:58 -0000 --883d24f220a03c9fce0569a028b1 Content-Type: text/plain; charset="UTF-8" -- Solenwin --883d24f220a03c9fce0569a028b1 Content-Type: text/html; charset="UTF-8"


--
Solenwin
--883d24f220a03c9fce0569a028b1-- From nobody Thu Apr 12 02:03:25 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02882124F57 for ; Thu, 12 Apr 2018 02:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PGOzfkLQ38R for ; Thu, 12 Apr 2018 02:03:18 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923B5120454 for ; Thu, 12 Apr 2018 02:03:17 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r82so8365749wme.0 for ; Thu, 12 Apr 2018 02:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=SCscFi7JXE4em+hyvUH+hT1HwOcU35ssNt27CRgfV6M=; b=D/TweHR+e7Nod8wc28jdUFok3aslBAx8QXvlD1wEkpL8STTtaAr5ipG6c9EKw+tSZI Yq9OMLnSPD0BCLmuLB9xVeT2zLTCJXYUW2I/BGhTBr7hPf3/tM3A+1BuEUk1jrHuB+ph ZX0wPOd1hs2rQrIuzjKt34Lh3CfAVYDE0gEJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=SCscFi7JXE4em+hyvUH+hT1HwOcU35ssNt27CRgfV6M=; b=fkM1b6z/pfdD4Tp3zSczaUAPlJHJmO2n0YfIRj0BGtlLzLyXRCugN8GKB07HQSXLIX bZOXcIp6UKv0iEp98woDN9uR35r7GjmdV1lMM1u98HIO0EE9CAvyKiH5xs1knp5vdQyA 1CsJMT4v1mu5xwcDtpcfT+kOGLpq+JCmjFP3srZ1X2VuZ8/U8UbouddEtW+RuE2vOTDf Nouhjh97D+Vok2oaQ2Msgw0xwbzjzeDOkJ/73ZD2jk4mBHpuVGe2ZLh8cwaI/KBHidxR ra5/dEoinV+Ezf4XYhUgGAAG/hQvTcmnJmzt4PFqxruMsvToIqFFdDDq7oKgZzTXilkO xj9A== X-Gm-Message-State: ALQs6tBfQWi/B04dnHjqzcbjQ2zz3EHMFlcIsQGMZvyWauVkc/Vc4s+N FNpzccV7+7zhtS+se0Sw761U8A== X-Google-Smtp-Source: AIpwx4+PvbSu/v3cULWM6AFDb0tRxoGOWZZzN6Ob9T4gltxVmr+NsxOXzprWZMRq/yQUgQYtEq/jzw== X-Received: by 10.28.190.23 with SMTP id o23mr17119wmf.53.1523523795597; Thu, 12 Apr 2018 02:03:15 -0700 (PDT) Received: from [100.102.225.75] ([213.205.198.87]) by smtp.gmail.com with ESMTPSA id t196sm4033484wme.35.2018.04.12.02.03.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 02:03:14 -0700 (PDT) Date: Thu, 12 Apr 2018 10:03:11 +0100 From: Neil Madden To: Brian Campbell Cc: oauth , Rifaat Shekh-Yusef Message-ID: <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> In-Reply-To: References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5acf20d0_327b23c6_40d"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 09:03:24 -0000 --5acf20d0_327b23c6_40d Content-Type: multipart/alternative; boundary="5acf20cf_6b8b4567_40d" --5acf20cf_6b8b4567_40d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Brian, Thanks for the detailed responses. Comments in line below (marked with **= *). Neil > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell wrote: > Thanks for the review and feedback, Neil. I apologize for my being slow= to respond. As I said to Justin recently (https://mailarchive.ietf.org/a= rch/msg/oauth/cNmk8fSuxp37L-z8Rvr6=5FEnyCug), I've been away from things = for a while. Also there's a lot here to get through so took me some time.= > > It looks like John touched on some of your comments but not all. I'll t= ry and reply to them as best I can inline below. > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden wrote: > > Hi, > > > > I have reviewed this draft and have a number of comments, below. =46o= rgeRock have not yet implemented this draft, but there is interest in imp= lementing it at some point. (Disclaimer: We have no firm commitments on t= his at the moment, I do not speak for =46orgeRock, etc). > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23section-3.1= defines a new confirmation method =E2=80=9Cx5t=23S256=E2=80=9D. However,= there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can co= ntain a JSON Web Key, which itself can contain a =E2=80=9Cx5t=23S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft proposes:= > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D =7D =7D > > > > but you can already do: > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80=9D: =7B =E2=80=A6 ,= =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D =7D > > > > If the intent is just to save some space and avoid the mandatory fiel= ds of the existing JWK types, maybe this would be better addressed by def= ining a new JWK type which only has a thumbprint=3F e.g., =7B =E2=80=9Ckt= y=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D =7D. > > The intent of the x5t=23S256 confirmation method was to be space effici= ent and straightforward while utilizing the framework and registry that R= =46C 7800 gives. Even a new JWK type like that would still use more space= . And I'd argue that the new confirmation method is considerably more str= aightforward than registering a new JWK type (and the implications that w= ould have on JWK implementations in general) in order to use the existing= =22jwk=22 confirmation method. > > *** OK, that is reasonable. Given that the draft says SHOULD rather tha= n MUST for using this confirmation key method, I think it is currently al= lowed to use either representation. > > > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s really only the client authentic= ation that we are interested here, and the fact that the server also auth= enticates with a certificate is not hugely relevant to this particular sp= ec (although it is to the overall security of OAuth). Also, TLS defines n= on-certificate based authentication mechanisms (e.g. TLS-SRP extension fo= r password authenticated key exchange, PSK for pre-shared key authenticat= ion) and even non-X.509 certificate types (https://www.iana.org/assignmen= ts/tls-extensiontype-values/tls-extensiontype-values.xhtml=23tls-extensio= ntype-values-3). I=E2=80=99d prefer that the draft explicitly referred to= =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rather than mu= tual TLS, and changed identifiers like =E2=80=98tls=5Fclient=5Fauth=E2=80= =99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23section-2.1.1= ) to something more explicit like =E2=80=98tls=5Fx509=5Fpki=5Fclient=5Fau= th=E2=80=99. > > > > This is especially confusing in section 3 on sender constrained acces= s tokens, as there are two different servers involved: the AS and the pro= tected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authenti= cation between them, only between each of them and the client. > > Choosing names and terminology is difficult and the =22right=22 wording= is often subjective. I believe that the current wording sufficiently con= veys what is going on in the draft to most readers. Most readers thus far= seem to agree. There is some text now that does say that the mutual auth= in the draft is in fact X.509 client cert authn but, in the next revisio= n, I'll look for other opportunities where it could be stated more clearl= y. > > *** Thanks. > > > > > 3. The draft links to the TLS 1.2 R=46C, while the original OAuth 2.0= R=46C only specifies TLS 1.0. Is the intention that TLS 1.2+ is required= =3F The wording in Section 5.1 doesn=E2=80=99t seem clear if this could a= lso be used with TLS 1.0 or 1.1, or whether it is only referring to futur= e TLS versions. > > The reference to BCP 195 (which unfortunately the original OAuth 2.0 R=46= C doesn't have because it didn't exist then) is meant to account for chan= ging versions and recommendations around TLS. Currently that BCP says TLS= 1.2 is a must and suggests against 1.1 & 1.0 but doesn't outright prohib= it them. > > *** OK, that seems good to me. > > > > > 4. It might be useful to have a discussion for implementors of whethe= r TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact= the use of client certificates, if at all=3F > > That might well be useful but I don't myself know what it would say. I'= ve (maybe naively) figured those are deployment details that will just wo= rk out. Perhaps you could propose some text around such a discussion that= the WG could consider=3F > > *** > To be honest, when I raised this it was because I didn=E2=80=99t really= know what the implications were. I=E2=80=99ve done some reading around a= nd I think it should all just work - both session resumption and PSK-base= d resumption preserve the original client and server authentication conte= xt so we can assume that any presented client cert is still valid for the= resumed session. So I think we can leave out any discussion of this and = assume it works as expected. > > > > > > 5. Section 3 defines sender-constrained access tokens in terms of the= confirmation key claims (e.g., R=46C 7800 for JWT). However, the OAuth 2= .0 Pop Architecture draft defines sender constraint and key confirmation = as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-arc= hitecture-08=23section-6.2). The draft should decide which of those it is= implementing and if sender constraint is intended, then reusing the conf= irmation key claims seems misleading. (I think this mTLS draft is doing k= ey confirmation so should drop the language about sender constrained toke= ns). > > I will say again that choosing names and terminology is difficult... > > Although I must admit that I started using =22sender constrained=22 som= ewhat indiscriminately at first and it's just sort of stuck. At the time = I was trying to incorporate bits of draft-sakimura-oauth-jpop in a way th= at might help bring on and keep the authors of that draft onboard with th= is mtls draft. In retrospect it looks like I did that part wrong anyway. = But that was the thinking at the time and the history, for whatever it's = worth. More recently, Nat was requesting that =22sender constrained=22 be= included in the title. So there's that too. > > In defense of my mistake, however, if there's a line between =22sender = constrained=22 and =22key confirmation=22 tokens, it's a bit of a fuzzy l= ine. And I'd argue that what this draft is doing pretty close to the line= . > > But ultimately I think you are right that what this mtls draft is doing= with access tokens is more accurately described with the key confirmatio= n term. > > So, yes, the draft should probably drop (or at least minimize) the lang= uage about sender constrained. I'll do that in the next draft version, ba= rring big objections from the WG. > > The tricky thing with making that change is that there a client and ser= ver metadata parameters with the name =22mutual=5Ftls=5Fsender=5Fconstrai= ned=5Faccess=5Ftokens=22 that should probably also change. But that would= be a breaking change (of sorts anyway), which shouldn't be taken lightly= at this stage. I feel that some explicit okays from the WG are needed be= fore doing so (rough consensus stye) . Any WG members want to weigh in he= re and help get a =22sense of the group=22 concerning changing those meta= data names=3F > > *** Thanks. I agree this might cause compatibility issues. It is not a = big issue for us, but might cause some confusion. > > > > > 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/= html/draft-ietf-oauth-pop-architecture-08=23section-5): > > > > Strong, fresh session keys: > > > > Session keys MUST be strong and fresh. Each session deserves an > > independent session key, i.e., one that is generated specifically > > for the intended use. In context of OAuth this means that keying > > material is created in such a way that can only be used by the > > combination of a client instance, protected resource, and > > authorization scope. > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-= ietf-oauth-mtls-07=23section-3) says: > > > > The client makes protected resource requests as described in > > =5BR=46C6750=5D, however, those requests MUST be made over a mutually= > > authenticated TLS connection using the same certificate that was used= > > for mutual TLS at the token endpoint. > > > > These two statements are contradictory: the OAuth 2.0 PoP architectur= e effectively requires a fresh key-pair to be used for every access token= request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server. > > > > In the self-signed case (and even in the CA case, with a bit of work = - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is pe= rfectly possible for the client to generate a fresh key-pair for each acc= ess token and include the certificate on the token request (e.g., as per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03=23se= ction-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D value shou= ld probably be described). This should probably at least be an option. > > This draft doesn't necessarily seek to align with the (long expired) Po= P architecture draft. Rather it is aiming to provide a pragmatic solution= for PoP style access tokens and OAuth client auth using mTLS client cert= ificates. > > That said, with the current draft, it's certainly possible for a client= to update its cert more frequently, even so far as using a new one for e= ach access token. The details of how that would work will vary some based= on the token endpoint authentication method. But it's not precluded. > > *** You are right, the text doesn=E2=80=99t preclude that. I am happy w= ith that solution. I suspect most people will deploy and be happy with re= using a long-lived cert for every access token, so this may not matter in= practice. > > > > 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it allo= ws correlation of activity. > > Practically speaking the access tokens being presented likely already h= ave correlatable info in them about the client as well as the user. I don= 't know that there's much of a (new) concern in reality. If you feel this= concern is unique and import enough though, perhaps there's some text yo= u'd like to propose for a Privacy Considerations section that the WG coul= d consider=3F I mean, I guess it doesn't hurt to mention it but I would l= ike to avoid overstating the issue. > > *** On reflection, I am going to withdraw this comment. As you say ther= e are other ways to correlate clients. The privacy issue would mainly ari= se in the context of dynamic client registration e.g., a pattern I=E2=80=99= ve seen described where every instance of a mobile app does dynamic clien= t registration to avoid including credentials directly in the app bundle.= This would make clients one-to-one with users. But (a) those apps are fa= irly unlikely to be using TLS certs, and (b) that is more of a privacy co= nsideration for dynamic client registration rather than this draft. > > > > > 8. This is maybe a more general point, but R=46C 6750 defines the Aut= horization: Bearer scheme (https://tools.ietf.org/html/rfc6750=23section-= 2) for a client to communicate it=E2=80=99s access token to the RS in a s= tandard way. As sender-constrained access tokens are not strictly bearer = tokens any more, should this draft also register a new scheme for that=3F= Should there be a generic PoP scheme=3F > > The thinking and general consensus (in this draft as well as the OAuth = token binding work) has been that continuing to use the R=46C 6750 scheme= while putting the =22not strictly bearer=22 stuff in (or referenced by) = the token itself will be easier on deployment and implementation. And bet= ter for adoption as a result. I believe some early implementation work ha= s borne that out too. > > *** OK. > > > > > 9. The Security Considerations should really make some mention of the= long history of attacks against X.509 certificate chain validation, e.g.= failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an exi= sting TLS library to perform these checks rather than implementing your o= wn checks. This relates to Justin=E2=80=99s comments around DN parsing an= d normalisation. > > Suggesting to use an existing TLS library is certainly sound advice and= I sort of felt is implied in the draft. But saying so more strongly/expl= icitly might be worthwhile. And pointing to historical reasons to do so w= ould probably be good too. Could you propose a new Security Consideration= s section or maybe augmentation of =C2=A75.2 with that content=3F > > *** I=E2=80=99ll try and come up with some text. > > > > > 10. The PKI client authentication method (https://tools.ietf.org/html= /draft-ietf-oauth-mtls-07=23section-2.1) makes no mention at all of certi= ficate revocation and how to handle checking for that (CRLs, OCSP - with = stapling=3F). Neither does the Security Considerations. If this is a deta= il to be agreed between then AS and the CA (or just left up to the AS TLS= stack) then that should perhaps be made explicit. Again, there are priva= cy considerations with some of these mechanisms, as OCSP requests are typ= ically sent in the clear (plain HTTP) and so allow an observer to see whi= ch clients are connecting to which AS. > > I didn't think that a TLS client could do OCSP stapling=3F > > *** I think you are right about this. I always assumed it was symmetric= (and I think it technically could work), but the spec only talks about s= tapling in the server-side of the handshake. > > That aside, revocation checking (how and even if) is something that's a= t the discretion of the AS. I can add something in =C2=A72.1 to say that = more explicitly. > > *** Thanks. > > > > > > 11. The same comment applies to how the protected resource checks for= revocation of the certificate presented during sender constrained access= token usage. Should the RS make its own revocation checks based on the i= nformation in the certificate presented, or should it trust the certifica= te while the access token is still valid=3F If the latter case, is the AS= responsible for revoking any access tokens whose certificate have been r= evoked (if so, should it be doing an OCSP call on every token introspecti= on request, and should the RS be passing on the certificate/serial number= on that request)=3F If the Client request uses OCSP Stapling (https://en= .wikipedia.org/wiki/OCSP=5Fstapling) how can the RS verify the signature = on that if it does not have a separate trust relationship with the CA alr= eady=3F > > The draft effectively uses cert mtls at the RS as a proof-of-possession= method only and not as authentication. So revocation checking isn't real= ly applicable. In specific deployment situations, I suppose an RS could c= heck revocation. But that'd be a deployment decision for the RS that's be= yond the scope of this draft. > > *** OK, that is an interesting observation. If either the client or AS = suspect the key has been compromised they can revoke the access token(s) = instead. > > > > > > 12. The use of only SHA-256 fingerprints means that the security stre= ngth of the sender-constrained access tokens is limited by the collision = resistance of SHA-256 - roughly =E2=80=9C128-bit security=22 - without a = new specification for a new thumbprint algorithm. An implication of this = is that is is fairly pointless for the protected resource TLS stack to ev= er negotiate cipher suites/keys with a higher level of security. In more = crystal ball territory, if a practical quantum computer becomes a possibi= lity within the lifetime of this spec, then the expected collision resist= ance of SHA-256 would drop quadratically, allowing an attacker to find a = colliding certificate in =7E2=5E64 effort. If we are going to pick just o= ne thumbprint hash algorithm, I would prefer we pick SHA-512. > > The idea behind haveing just one thumbprint hash algorithm was to keep = things simple. And SHA-256 seems good enough for the reasonably foreseeab= le future (and space aware). Also a new little spec to register a differe= nt hash algorithm, should the need arise, didn't seem particularity onero= us. > > That was the thinking anyway. Maybe it is too short sighted though=3F > > I do think SHA-256 should stay regardless. > > But the draft could also define SHA-512 (and maybe others). What do you= and WG folks think about that=3F > > *** Yes please. > > It would probably then be useful for the metadata in =C2=A73.3 and =C2=A7= 3.4 to change from just boolean values to something to convey what hash a= lg/cnf method the client expects and the list of what the server supports= . That's maybe something that should be done anyway. That'd be a breaking= change to the metadata. But there's already another potential breaking c= hange identified earlier in this message. So maybe it's worth doing... > > How do folks feel about making this kind of change=3F > > > > > > Cheers, > > > > Neil > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef wrote: > > > > > > All, > > > > > > As discussed during the meeting today, we are starting a WGLC on th= e MTLS document: > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > > > > > Please, review the document and provide feedback on any issues you = see with the document. > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > Regards, > > > Rifaat and Hannes > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > OAuth mailing list > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth > > > > > CON=46IDENTIALITY NOTICE: This email may contain confidential and privi= leged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited. If you= have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you. --5acf20cf_6b8b4567_40d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
Hi Brian,

Thanks for the detailed responses. Comme= nts in line below (marked with ***).

Neil

On Wednesday, Apr= 11, 2018 at 9:47 pm, Brian Campbell <bcampbell=40pingidentity.com> wrote:
=
Thanks for the review and feedback, Neil.= I apologize for my being slow to respond. As I said to Justin recently, I've been away from things for= a while. Also there's a lot here to get through so took me some time.
It looks like John touched on some of your comments but not a= ll. I'll try and reply to them as best I can inline below.

<= br>
On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden <<= a href=3D=22mailto:neil.madden=40forgerock.com=22 target=3D=22=5Fblank=22= >neil.madden=40forgerock.com> wrote:
Hi,

I have reviewed th= is draft and have a number of comments, below. =46orgeRock have not yet i= mplemented this draft, but there is interest in implementing it at some p= oint. (Disclaimer: We have no firm commitments on this at the moment, I d= o not speak for =46orgeRock, etc).

1. https://tools.ietf.org/html/draft-iet= f-oauth-mtls-07=23section-3.1 defines a new confirmation method = =E2=80=9Cx5t=23S256=E2=80=9D. However, there is already a confirmation me= thod =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key, which itself = can contain a =E2=80=9Cx5t=23S526=E2=80=9D claim with exactly the same sy= ntax and semantics. The draft proposes:

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D =7D =7D

but you can already do:

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80=9D= : =7B =E2=80=A6 , =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D= =7D =7D =7D

If the intent is just to save some space and avoid = the mandatory fields of the existing JWK types, maybe this would be bette= r addressed by defining a new JWK type which only has a thumbprint=3F e.g= ., =7B =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t=23S256=E2= =80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D.

<= div>The intent of the x5t=23S256=C2=A0confirmation method was to be space= efficient and straightforward while utilizing the framework and registry= that R=46C 7800 gives.=C2=A0 Even a new JWK type like that would still u= se more space. And I'd argue that the new confirmation method is consider= ably more straightforward than registering a new JWK type (and the implic= ations that would have on JWK implementations in general) in order to use= the existing =22jwk=22 confirmation method.=C2=A0

***
O= K, that is reasonable. Given that the draft says SHOULD rather than MUST = for using this confirmation key method, I think it is currently allowed t= o use either representation.=C2=A0

=C2=A0

2. I find the namin= g =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a bit of a misn= omer: it=E2=80=99s really only the client authentication that we are inte= rested here, and the fact that the server also authenticates with a certi= ficate is not hugely relevant to this particular spec (although it is to = the overall security of OAuth). Also, TLS defines non-certificate based a= uthentication mechanisms (e.g. TLS-SRP extension for password authenticat= ed key exchange, PSK for pre-shared key authentication) and even non-X.50= 9 certificate types (https://www.iana.= org/assignments/tls-extensiontype-values/tls-extensiontype-valu= es.xhtml=23tls-extensiontype-values-3). I=E2=80=99d prefer that = the draft explicitly referred to =E2=80=9CX.509 Client Certificate Authen= tication=E2=80=9D rather than mutual TLS, and changed identifiers like =E2= =80=98tls=5Fclient=5Fauth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-m= tls-07=23section-2.1.1) to something more explicit like =E2=80=98= tls=5Fx509=5Fpki=5Fclient=5Fauth=E2=80=99.

This is especially co= nfusing in section 3 on sender constrained access tokens, as there are tw= o different servers involved: the AS and the protected resource server, b= ut there is no =E2=80=9Cmutual=E2=80=9D authentication between them, only= between each of them and the client.

Choosing names and terminology is difficult and the =22right=22 wording = is often subjective. I believe that the current wording sufficiently conv= eys what is going on in the draft to most readers. Most readers thus far = seem to agree. There is some text now that does say that the mutual auth = in the draft is in fact X.509 client cert authn but, in the next revision= , I'll look for other opportunities where it could be stated more clearly= .=C2=A0

*** Thanks.=C2=A0

=C2=A0=

= 3. The draft links to the TLS 1.2 R=46C, while the original OAuth 2.0 R=46= C only specifies TLS 1.0. Is the intention that TLS 1.2+ is required=3F T= he wording in Section 5.1 doesn=E2=80=99t seem clear if this could also b= e used with TLS 1.0 or 1.1, or whether it is only referring to future TLS= versions.

The reference to BCP 195 (= which unfortunately the=C2=A0original OAuth 2.0 R=46C doesn't have becaus= e it didn't exist then) is meant to account for changing versions and rec= ommendations around TLS. Currently that BCP says TLS 1.2 is a must and su= ggests against 1.1 & 1.0 but doesn't outright prohibit them.

*** OK, that seems good to me.=C2=A0

= =C2=A0

4. It might be useful to have a discussion for implementors of whe= ther TLS session resumption (and PSK in TLS 1.3) and/or renegotiation imp= act the use of client certificates, if at all=3F
That might well be useful but I don't myself know what it wou= ld say. I've (maybe naively) figured those are deployment details that wi= ll just work out. Perhaps you could propose some text around such a discu= ssion that the WG could consider=3F

=C2=A0***
To be honest, when I raised this it was because I didn=E2=80=99t really= know what the implications were. I=E2=80=99ve done some reading around a= nd I think it should all just work - both session resumption and PSK-base= d resumption preserve the original client and server authentication conte= xt so we can assume that any presented client cert is still valid for the= resumed session. So I think we can leave out any discussion of this and = assume it works as expected.=C2=A0



5. Secti= on 3 defines sender-constrained access tokens in terms of the confirmatio= n key claims (e.g., R=46C 7800 for JWT). However, the OAuth 2.0 Pop Archi= tecture draft defines sender constraint and key confirmation as different= things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08=23section-6.2). The draft should decide which of those it is i= mplementing and if sender constraint is intended, then reusing the confir= mation key claims seems misleading. (I think this mTLS draft is doing key= confirmation so should drop the language about sender constrained tokens= ).

I will say again that choosing nam= es and terminology is difficult...

Although I must admit that I st= arted using =22sender constrained=22 somewhat indiscriminately at first a= nd it's just sort of stuck. At the time I was trying to incorporate bits = of draft-sakimura-oauth-jpop in a way that might help bring on and keep t= he authors of that draft onboard with this mtls draft. In retrospect it l= ooks like I did that part wrong anyway. But that was the thinking at the = time and the history, for whatever it's worth. More recently, Nat was req= uesting that =22sender constrained=22 be included in the title. So there'= s that too.=C2=A0

In defense of my mistake, however, i= f there's a line between =22sender constrained=22 and =22key confirmation= =22 tokens, it's a bit of a fuzzy line. And I'd argue that what this draf= t is doing pretty close to the line.

But ultimately I = think you are right that what this mtls draft is doing with access tokens= is more accurately described with the key confirmation term.
<= div>
So, yes, the draft should probably drop (or at least m= inimize) the language about sender constrained. I'll do that in the next = draft version, barring big objections from the WG.

The = tricky thing with making that change is that there a client and server me= tadata parameters with the name =22mutual=5Ftls=5Fsender=5Fconstrained=5Faccess=5Ftokens=22 that should probably also change. But that would = be a breaking change (of sorts anyway), which shouldn't be taken lightly = at this stage. I feel that some explicit okays from the WG are needed bef= ore doing so (rough consensus stye) . Any WG members want to weigh in her= e and help get a =22sense of the group=22 concerning changing those metadata names=3F

*** Thanks. I agree this might cause compatibility issues. It = is not a big issue for us, but might cause some confusion.=C2=A0

=C2=A0

6. The OAuth 2.0 PoP Architecture draft says (https://tools= .ietf.org/html/draft-ietf-oauth-pop-architecture-08=23section-5= ):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Strong, fresh session k= eys:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ses= sion keys MUST be strong and fresh.=C2=A0 Each session deserves an
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 independent session = key, i.e., one that is generated specifically
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the intended use.=C2=A0 In context of= OAuth this means that keying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 material is created in such a way that can only be used by= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 combinat= ion of a client instance, protected resource, and
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization scope.


Ho= wever, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23= section-3) says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client= makes protected resource requests as described in
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =5BR=46C6750=5D, however, those requests MUST be made over a mutu= ally
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated TLS connection using t= he same certificate that was used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for mut= ual TLS at the token endpoint.

These two statements are contradi= ctory: the OAuth 2.0 PoP architecture effectively requires a fresh key-pa= ir to be used for every access token request, whereas this draft proposes= reusing the same long-lived client certificate for every single access t= oken and every resource server.

In the self-signed case (and eve= n in the CA case, with a bit of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index= .html) it is perfectly possible for the client to generate a fresh ke= y-pair for each access token and include the certificate on the token req= uest (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-= key-distribution-03=23section-5.1 - in which case an appropriate= =E2=80=9Calg=E2=80=9D value should probably be described). This should p= robably at least be an option.

This d= raft doesn't necessarily seek to align with the (long expired) PoP archit= ecture draft.=C2=A0 Rather it is aiming to provide a pragmatic solution f= or PoP style access tokens and OAuth client auth using mTLS client certif= icates.

That said, with the current draft, it's certai= nly possible for a client to update its cert more frequently, even so far= as using a new one for each access token. The details of how that would = work will vary some based on the token endpoint authentication method. Bu= t it's not precluded.

*** You ar= e right, the text doesn=E2=80=99t preclude that. I am happy with that sol= ution. I suspect most people will deploy and be happy with reusing a long= -lived cert for every access token, so this may not matter in practice.=C2= =A0
=C2=A0

7. The use of a single client certificate with every resour= ce server (RS) should be called out in a Privacy Considerations section, = as it allows correlation of activity.

Practically speaking the access tokens being presented likely already ha= ve correlatable info in them about the client as well as the user. I don'= t know that there's much of a (new) concern in reality. If you feel this=C2= =A0concern is unique and import enough though, perhaps there's some text = you'd like to propose for a Privacy Considerations section that the WG co= uld consider=3F I mean, I guess it doesn't hurt to mention it but I would= like to avoid overstating the issue.=C2=A0

*** On reflection, I am going to withdraw this comment. As you say there= are other ways to correlate clients. The privacy issue would mainly aris= e in the context of dynamic client registration e.g., a pattern I=E2=80=99= ve seen described where every instance of a mobile app does dynamic clien= t registration to avoid including credentials directly in the app bundle.= This would make clients one-to-one with users. But (a) those apps are fa= irly unlikely to be using TLS certs, and (b) that is more of a privacy co= nsideration for dynamic client registration rather than this draft.=C2=A0=

=C2=A0

8. This is maybe a more general point, but R=46C 6750= defines the Authorization: Bearer scheme (https://tools.ietf.org/html/rfc6750=23section-2) for a c= lient to communicate it=E2=80=99s access token to the RS in a standard wa= y. As sender-constrained access tokens are not strictly bearer tokens any= more, should this draft also register a new scheme for that=3F Should th= ere be a generic PoP scheme=3F

The th= inking and general consensus (in this draft as well as the OAuth token bi= nding work) has been that continuing to use the R=46C 6750 scheme while p= utting the =22not strictly bearer=22 stuff in (or referenced by) the toke= n itself will be easier on deployment and implementation. And better for = adoption as a result. I believe some early implementation work has borne = that out too.

=C2=A0*** OK.=C2=A0

=

9. Th= e Security Considerations should really make some mention of the long his= tory of attacks against X.509 certificate chain validation, e.g. failure = to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in= parsing DNs, etc. It should be strongly suggested to use an existing TLS= library to perform these checks rather than implementing your own checks= . This relates to Justin=E2=80=99s comments around DN parsing and normali= sation.

Suggesting to use an existing= TLS library is certainly sound advice and I sort of felt is implied in t= he draft. But saying so more strongly/explicitly might be worthwhile.=C2=A0= And pointing to historical reasons to do so would probably be good too.=C2= =A0 Could you propose a new Security Considerations section or maybe augm= entation of =C2=A75.2 with that content=3F=C2=A0

*** I=E2=80=99ll try and come up with some text.=C2=A0

=C2=A0

10. The PKI client authentication method (https://tools.ietf.org/html/draft-i= etf-oauth-mtls-07=23section-2.1) makes no mention at all of cert= ificate revocation and how to handle checking for that (CRLs, OCSP - with= stapling=3F). Neither does the Security Considerations. If this is a det= ail to be agreed between then AS and the CA (or just left up to the AS TL= S stack) then that should perhaps be made explicit. Again, there are priv= acy considerations with some of these mechanisms, as OCSP requests are ty= pically sent in the clear (plain HTTP) and so allow an observer to see wh= ich clients are connecting to which AS.

I didn't think that a TLS client could do OCSP=C2=A0stapling=3F<= div>
*** I think you are right about this. I always assumed= it was symmetric (and I think it technically could work), but the spec o= nly talks about stapling in the server-side of the handshake.=C2=A0
That aside, revocation checking (how and even if) is somethi= ng that's at the discretion of the AS. I can add something in =C2=A72.1 t= o say that more explicitly.=C2=A0

*** Thanks.=C2= =A0



11. The same comment applies to how the protected resourc= e checks for revocation of the certificate presented during sender constr= ained access token usage. Should the RS make its own revocation checks ba= sed on the information in the certificate presented, or should it trust t= he certificate while the access token is still valid=3F If the latter cas= e, is the AS responsible for revoking any access tokens whose certificate= have been revoked (if so, should it be doing an OCSP call on every token= introspection request, and should the RS be passing on the certificate/s= erial number on that request)=3F If the Client request uses OCSP Stapling= (https://en.wikipedia.org/wiki/= OCSP=5Fstapling) how can the RS verify the signature on that if it do= es not have a separate trust relationship with the CA already=3F

The draft effectively uses cert mtls at the R= S as a proof-of-possession method only and not as authentication. So revo= cation checking isn't really applicable. In specific deployment situation= s, I suppose an RS could check revocation. But that'd be a deployment dec= ision for the RS that's beyond the scope of this draft.
*** OK, that is an interesting observation. If either the cl= ient or AS suspect the key has been compromised they can revoke the acces= s token(s) instead.=C2=A0
=C2=A0


12. The use of only SH= A-256 fingerprints means that the security strength of the sender-constra= ined access tokens is limited by the collision resistance of SHA-256 - ro= ughly =E2=80=9C128-bit security=22 - without a new specification for a ne= w thumbprint algorithm. An implication of this is that is is fairly point= less for the protected resource TLS stack to ever negotiate cipher suites= /keys with a higher level of security. In more crystal ball territory, if= a practical quantum computer becomes a possibility within the lifetime o= f this spec, then the expected collision resistance of SHA-256 would drop= quadratically, allowing an attacker to find a colliding certificate in =7E= 2=5E64 effort. If we are going to pick just one thumbprint hash algorithm= , I would prefer we pick SHA-512.

The= idea behind haveing just one thumbprint hash algorithm was to keep thing= s simple. And SHA-256 seems good enough for the reasonably foreseeable fu= ture (and space aware). Also a new little spec to register a different ha= sh algorithm, should the need arise, didn't seem particularity onerous. <= br>
That was the thinking anyway. Maybe it is too short sig= hted though=3F

I do think SHA-256 should stay regardles= s.

But the draft could also define SHA-512 (and maybe = others). What do you and WG folks think about that=3F

*** Yes please.=C2=A0

It would probably then be u= seful for the metadata in =C2=A73.3 and =C2=A73.4 to change from just boo= lean values to something to convey what hash alg/cnf method the client ex= pects and the list of what the server supports. That's maybe something th= at should be done anyway. That'd be a breaking change to the metadata. Bu= t there's already another potential breaking change identified earlier in= this message. So maybe it's worth doing...

How do folk= s feel about making this kind of change=3F



=C2=A0
Cheers,

Neil


> On 19 Mar= 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf=40gmail.com> wrot= e:
>
> All,
>
> As discussed during the meeti= ng today, we are starting a WGLC on the MTLS document:
> https://tools.ietf.org/html/draft-i= etf-oauth-mtls-07
>
> Please, review the document and p= rovide feedback on any issues you see with the document.
>
>= ; The WGLC will end in two weeks, on April 2, 2018.
>
> Reg= ards,
>=C2=A0 Rifaat and Hannes
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
> OAuth mailing list
> OAuth=40ietf.org
> https://www.ietf.org/mailman/listinf= o/oauth


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth


=
CON=46IDENTIALITY N= OTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or= disclosure by others is strictly prohibited.=C2=A0 If you have received = this communication in error, please notify the sender immediately by e-ma= il and delete the message and any file attachments from your computer. Th= ank you.
--5acf20cf_6b8b4567_40d-- --5acf20d0_327b23c6_40d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJazyDPAAoJEJD4Q99O3axdFt0P/0dU+fBHE++gM+aJ76GK4qXc38B2PwNIkrLh a5aUgceFeBu/PHQ3WXpu8Nv64e4fkTy25VXNcFuYhxJo4zdARxxd50OgFdMWbp1oXuuiRD5ta1fx wCaFY7R35PGW5YcjxEWTztcffgGQ78mvyNYp7DmgKIfiILvcF2Gc3IsayfMJ9aRg1KaYI9FfAkru 5vq95g8FRNxUW5ztjcT2BVaDbVxmHMZg8D6kWXcurS0bXwddyRCMOb1l6nuLPDx0wd4fV4Ss5pCM oAG3srpBLkGRgSfykE6rTLvSWdI3ESu3qVwB5GMQt7YAQFoWCbOsZ1wrQuUxWAxeN+j2TZdY0rQE 8ChUxUIcs1EP02TyVzvfxpbaXG4CBec3fQevkgk4DBxOdDkvsanJDegqNfXli6MNWzyINn9J1vva rPRkKYLQg5551fSbcjlNelkOehDsIsIDijRZG7ciQh71jEN+2Ha9Mhi8bkHpxdP0T+CS/tN/viZ2 jdO5xqiwHvxflFsNVfahRjnD5uZG0wkH09f556gIcDrSry3wZBOs3vEgFYhE1MPP2ezAGv/SxNDE wwoVxltDAJPQtJFLjQe/eOT/G/8lSMdNL9lGfjutrsXyHVGULAvEh1mQs/hribRymZr5SYQWOqIr boqZhcvkmjUmV5R+imNSEKdiLqfKhtAkhK5NqEgw =lvbW -----END PGP SIGNATURE----- --5acf20d0_327b23c6_40d-- From nobody Thu Apr 12 03:11:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18F126D85 for ; Thu, 12 Apr 2018 03:11:53 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrQ4P31ruc9o for ; Thu, 12 Apr 2018 03:11:49 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71558126CD6 for ; Thu, 12 Apr 2018 03:11:48 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id u11so4522455wri.12 for ; Thu, 12 Apr 2018 03:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=/d8AZ3KmCIpIAPXO/s+Em0Vn3Uldh7s30j6cylkaQ+0=; b=B4Yn3p5Vu3HbXqx7yrL1e+xZFwEgz0yxxcoucU979iTk6SzqSSPjNoIrb1wsvfdHwP D51Ug8jB5VWhE3p3BwHvXfbYKOvWvWAlAeDb6ZNYbcKnNXpP8vEOTtrAeE4avBzU5jQO MxwB3Oo/h9uujt39f6a8lYsG7EfLAd1M3aMac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=/d8AZ3KmCIpIAPXO/s+Em0Vn3Uldh7s30j6cylkaQ+0=; b=iH/z91NBBduA2SeHPDI9i8fUbUlIyL767ruXr/8XQNRKt1F7Uw7/omckpcvrwIOV8h yocNzYtz3QVWyt0xXc09LNR2BaT+lDNr6Noz1RGTYhylYD8XGd1Imf4NGJEdO1/boEvo Kjr+03oE/HU0BgHfu9SLe8YjEfF7QuXYhDSGIZJJ5esY7zmACTvjssVq4Il8eTnWBpdE 5ZjGo3gcBZ4ZUjMM2Qv6OfkwXlfAL9bRnc2WQNvIvTverK1tdu2BYUrzPXFaHlirL7Fz /x0os2wiI6GRVzvw1tfCC2FgEhkK3XOh9vw1V4it/LKSPNxK66/WdOt97jTZpOoMWA8e 4FhQ== X-Gm-Message-State: ALQs6tAIARL4ej16MIzznEkAHn22HCBLtxVF4DufsIbxkfaQxT5Zkz2/ xWce5QC2eg0iKW+nFp+JdEtYQOE5YlU= X-Google-Smtp-Source: AIpwx4+iP1W9jiwAzPEiJmdM8CcQd25i1VWnzvaohxdqw4fb4+BxAB9zVpb1tMSQgoHRTN8l3e25Rw== X-Received: by 10.223.192.3 with SMTP id z3mr267623wre.177.1523527906653; Thu, 12 Apr 2018 03:11:46 -0700 (PDT) Received: from [192.168.1.81] (198.179.93.209.dyn.plus.net. [209.93.179.198]) by smtp.gmail.com with ESMTPSA id 31sm2929874wrm.68.2018.04.12.03.11.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 03:11:45 -0700 (PDT) Date: Thu, 12 Apr 2018 11:11:42 +0100 From: Neil Madden To: Brian Campbell , John Bradley Cc: IETF oauth WG Message-ID: <41ae74de-4258-49ae-aa16-1fb24f19e3d8@Canary> In-Reply-To: References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5acf30df_66334873_40d"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 10:11:54 -0000 --5acf30df_66334873_40d Content-Type: multipart/alternative; boundary="5acf30df_643c9869_40d" --5acf30df_643c9869_40d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree that this is beyond the scope of the spec. To be clear, our desir= e is that the mtls spec includes some wording along the following lines: =E2=80=9CThe AS MAY choose to terminate TLS connections at a load balance= r, reverse proxy, or other network intermediary. How the client certifica= te metadata is securely communicated between the intermediary and the AS = in this case is out of scope of this specification.=E2=80=9D That makes it clear that it is a supported pattern without commiting to h= ow it should be achieved. Regards, Neil -- > On Thursday, Apr 05, 2018 at 5:07 pm, John Bradley wrote: > +1 > On Wed, Apr 4, 2018, 5:42 PM Brian Campbell wrote: > > Strongly agree with Justin that any kind of TLS header forwarding sta= ndards like that are well beyond the scope of this spec. > > > > > > On =46ri, Mar 30, 2018 at 10:02 PM, Justin Richer wrote: > > > I don=E2=80=99t believe this is the spec to define TLS header forwa= rding standards in. > > > > > > =E2=80=94 Justin > > > > > > > > > > On Mar 30, 2018, at 2:03 PM, Vivek Biswas wrote: > > > > There are additional challenges which we have faced. > > > > > > > > A. Most of the Mutual SSL communication as mentioned below termin= ates at the LBR and the LBR needs to have client certificates to trust th= e client. But lot of times the connection from LBR to Authorization serve= r may be non-SSL. > > > > > > > > The CN, SHA-256 thumprint and serial number of the Client Cert ar= e sent as header to the AuthzServer/Backend Server. However, if the conne= ction from LBR to AuthzServer/Backend Server is unencrypted it is prone t= o MIM attacks. Hence, it=E2=80=99s a MUST requirement to have one-way SSL= from LBR to AuthzServer/Backend Server, so that the headers passed are n= ot compromised. > > > > > > > > This is a MOST common scenario in a real world. And we don=E2=80=99= t want everyone come up with their own names for the header. There should= be some kind of standardization around the header names. > > > > > > > > Regards > > > > Vivek Biswas, CISSP > > > > > > > > =46rom: John Bradley =5Bmailto:ve7jtb=40ve7jtb.com (mailto:ve7jtb= =40ve7jtb..com)=5D > > > > Sent: Thursday, March 29, 2018 11:57 AM > > > > To: Neil Madden > > > > Cc: oauth > > > > Subject: Re: =5BOAUTH-WG=5D WGLC on draft-ietf-oauth-mtls-07 > > > > > > > > Yes that is quite a common deployment scenario. I think that is t= he way most of the Open Banking implementations have deployed it currentl= y. > > > > > > > > > > > > The intent is to support that. One problem is that how the certif= icate is transmitted to the application tends to be load balancer/reverse= proxy specific as no real standard exists. > > > > > > > > > > > > > > > > If you think that needs to be clarified text is welcome. > > > > > > > > > > > > > > > > John B. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 29, 2018, at 2:54 PM, Neil Madden wrote: > > > > > > > > > > Thanks, and understood. > > > > > > > > > > > > > > > > > > > > The privacy concerns are mostly around correlating activity of = *clients*, which may or may not reveal activity patterns of users using t= hose clients. I don=E2=80=99t know how much of a concern that is in reali= ty, but thought it should be mentioned. > > > > > > > > > > > > > > > > > > > > A colleague also made the following comment about the draft: > > > > > > > > > > > > > > > > > > > > =E2=80=9CIt is still quite common to terminate TLS in a load ba= lancer or proxy, and to deploy authorization servers in a secure network = zone behind an intermediate in a DMZ. In these cases, TLS would not be es= tablished between the client and authorization server as per =C2=A72, but= information about the TLS handshake may be made available by other means= (typically adding to a downstream header) allowing lookup and verificati= on of the client certificate as otherwise described. Given the prevalence= of this approach it would be good to know whether such a deployment woul= d be compliant or not.=E2=80=9D > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > Neil > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley wrote: > > > > > > > > > > > > Thanks for the feedback. We will review your comments and rep= ly. > > > > > > > > > > > > One data point is that this will not be the only POP spec. Th= e spec using token binding vs mtls has better privacy properties. It is U= K Open banking that has pressed us to come up with a standard to help wit= h interoperability. > > > > > > > > > > > > This spec has been simplified in some ways to facilitate the = majority of likely deployments. > > > > > > > > > > > > I understand that in future certificates may have better than= SHA256 hashes. > > > > > > > > > > > > Regards > > > > > > John B. > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 29, 2018, at 12:18 PM, Neil Madden wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I have reviewed this draft and have a number of comments, b= elow. =46orgeRock have not yet implemented this draft, but there is inter= est in implementing it at some point. (Disclaimer: We have no firm commit= ments on this at the moment, I do not speak for =46orgeRock, etc). > > > > > > > > > > > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23s= ection-3.1 defines a new confirmation method =E2=80=9Cx5t=23S256=E2=80=9D= . However, there is already a confirmation method =E2=80=9Cjwk=E2=80=9D t= hat can contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t=23= S526=E2=80=9D claim with exactly the same syntax and semantics. The draft= proposes: > > > > > > > > > > > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cx5t=23S256=E2=80=9D= : =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D > > > > > > > > > > > > > > but you can already do: > > > > > > > > > > > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80=9D: =7B =E2= =80=A6 , =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D= =7D > > > > > > > > > > > > > > If the intent is just to save some space and avoid the mand= atory fields of the existing JWK types, maybe this would be better addres= sed by defining a new JWK type which only has a thumbprint=3F e.g., =7B =E2= =80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t=23S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D =7D. > > > > > > > > > > > > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80= =9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really only the client= authentication that we are interested here, and the fact that the server= also authenticates with a certificate is not hugely relevant to this par= ticular spec (although it is to the overall security of OAuth). Also, TLS= defines non-certificate based authentication mechanisms (e..g. TLS-SRP e= xtension for password authenticated key exchange, PSK for pre-shared key = authentication) and even non-X.509 certificate types (https://www.iana.or= g/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml=23t= ls-extensiontype-values-3). I=E2=80=99d prefer that the draft explicitly = referred to =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rat= her than mutual TLS, and changed identifiers like =E2=80=98tls=5Fclient=5F= auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23sec= tion-2.1.1) to something more explicit like =E2=80=98tls=5Fx509=5Fpki=5Fc= lient=5Fauth=E2=80=99. > > > > > > > > > > > > > > This is especially confusing in section 3 on sender constra= ined access tokens, as there are two different servers involved: the AS a= nd the protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D= authentication between them, only between each of them and the client. > > > > > > > > > > > > > > 3. The draft links to the TLS 1.2 R=46C, while the original= OAuth 2.0 R=46C only specifies TLS 1.0. Is the intention that TLS 1.2+ i= s required=3F The wording in Section 5.1 doesn=E2=80=99t seem clear if th= is could also be used with TLS 1.0 or 1.1, or whether it is only referrin= g to future TLS versions. > > > > > > > > > > > > > > 4.. It might be useful to have a discussion for implementor= s of whether TLS session resumption (and PSK in TLS 1.3) and/or renegotia= tion impact the use of client certificates, if at all=3F > > > > > > > > > > > > > > 5. Section 3 defines sender-constrained access tokens in te= rms of the confirmation key claims (e.g., R=46C 7800 for JWT).. However, = the OAuth 2.0 Pop Architecture draft defines sender constraint and key co= nfirmation as different things (https://tools.ietf.org/html/draft-ietf-oa= uth-pop-architecture-08=23section-6.2). The draft should decide which of = those it is implementing and if sender constraint is intended, then reusi= ng the confirmation key claims seems misleading. (I think this mTLS draft= is doing key confirmation so should drop the language about sender const= rained tokens). > > > > > > > > > > > > > > 6. The OAuth 2.0 PoP Architecture draft says (https://tools= .ietf.org/html/draft-ietf-oauth-pop-architecture-08=23section-5 (https://= tools..ietf.org/html/draft-ietf-oauth-pop-architecture-08=23section-5)): > > > > > > > > > > > > > > Strong, fresh session keys: > > > > > > > > > > > > > > Session keys MUST be strong and fresh.. Each session deserv= es an > > > > > > > independent session key, i.e., one that is generated specif= ically > > > > > > > for the intended use. In context of OAuth this means that k= eying > > > > > > > material is created in such a way that can only be used by = the > > > > > > > combination of a client instance, protected resource, and > > > > > > > authorization scope. > > > > > > > > > > > > > > > > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/h= tml/draft-ietf-oauth-mtls-07=23section-3) says: > > > > > > > > > > > > > > The client makes protected resource requests as described i= n > > > > > > > =5BR=46C6750=5D, however, those requests MUST be made over = a mutually > > > > > > > authenticated TLS connection using the same certificate tha= t was used > > > > > > > for mutual TLS at the token endpoint. > > > > > > > > > > > > > > These two statements are contradictory: the OAuth 2.0 PoP a= rchitecture effectively requires a fresh key-pair to be used for every ac= cess token request, whereas this draft proposes reusing the same long-liv= ed client certificate for every single access token and every resource se= rver. > > > > > > > > > > > > > > In the self-signed case (and even in the CA case, with a bi= t of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html= ) it is perfectly possible for the client to generate a fresh key-pair fo= r each access token and include the certificate on the token request (e.g= ., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-03=23section-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D = value should probably be described). This should probably at least be an = option. > > > > > > > > > > > > > > 7. The use of a single client certificate with every resour= ce server (RS) should be called out in a Privacy Considerations section, = as it allows correlation of activity. > > > > > > > > > > > > > > 8. This is maybe a more general point, but R=46C 6750 defin= es the Authorization: Bearer scheme (https://tools.ietf.org/html/rfc6750=23= section-2) for a client to communicate it=E2=80=99s access token to the R= S in a standard way. As sender-constrained access tokens are not strictly= bearer tokens any more, should this draft also register a new scheme for= that=3F Should there be a generic PoP scheme=3F > > > > > > > > > > > > > > 9. The Security Considerations should really make some ment= ion of the long history of attacks against X.509 certificate chain valida= tion, e.g. failure to check the =E2=80=9CCA=E2=80=9D bit in the basic con= straints, errors in parsing DNs, etc. It should be strongly suggested to = use an existing TLS library to perform these checks rather than implement= ing your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation. > > > > > > > > > > > > > > 10. The PKI client authentication method (https://tools.iet= f.org/html/draft-ietf-oauth-mtls-07=23section-2.1) makes no mention at al= l of certificate revocation and how to handle checking for that (CRLs, OC= SP - with stapling=3F). Neither does the Security Considerations. If this= is a detail to be agreed between then AS and the CA (or just left up to = the AS TLS stack) then that should perhaps be made explicit. Again, there= are privacy considerations with some of these mechanisms, as OCSP reques= ts are typically sent in the clear (plain HTTP) and so allow an observer = to see which clients are connecting to which AS. > > > > > > > > > > > > > > 11. The same comment applies to how the protected resource = checks for revocation of the certificate presented during sender constrai= ned access token usage. Should the RS make its own revocation checks base= d on the information in the certificate presented, or should it trust the= certificate while the access token is still valid=3F If the latter case,= is the AS responsible for revoking any access tokens whose certificate h= ave been revoked (if so, should it be doing an OCSP call on every token i= ntrospection request, and should the RS be passing on the certificate/ser= ial number on that request)=3F If the Client request uses OCSP Stapling (= https://en.wikipedia.org/wiki/OCSP=5Fstapling) how can the RS verify the = signature on that if it does not have a separate trust relationship with = the CA already=3F > > > > > > > > > > > > > > 12. The use of only SHA-256 fingerprints means that the sec= urity strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security=22 - = without a new specification for a new thumbprint algorithm. An implicatio= n of this is that is is fairly pointless for the protected resource TLS s= tack to ever negotiate cipher suites/keys with a higher level of security= . In more crystal ball territory, if a practical quantum computer becomes= a possibility within the lifetime of this spec, then the expected collis= ion resistance of SHA-256 would drop quadratically, allowing an attacker = to find a colliding certificate in =7E2=5E64 effort. If we are going to p= ick just one thumbprint hash algorithm, I would prefer we pick SHA-512. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Neil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef wrote: > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > As discussed during the meeting today, we are starting a = WGLC on the MTLS document: > > > > > > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > > > > > > > > > > > > > > > Please, review the document and provide feedback on any i= ssues you see with the document. > > > > > > > > > > > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Rifaat and Hannes > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F > > > > > > > > OAuth mailing list > > > > > > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > > > > > > > OAuth mailing list > > > > > > > OAuth=40ietf.org (mailto:OAuth=40ietf..org) > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > OAuth mailing list > > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > OAuth mailing list > > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > CON=46IDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any revie= w, use, distribution or disclosure by others is strictly prohibited... If= you have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments fro= m your computer. Thank you.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth --5acf30df_643c9869_40d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
I agree that this is beyond the scope of the spec. To be clear, our de= sire is that the mtls spec includes some wording along the following line= s:

=E2=80=9CThe AS MAY choose to terminate TLS c= onnections at a load balancer, reverse proxy, or other network intermedia= ry. How the client certificate metadata is securely communicated between = the intermediary and the AS in this case is out of scope of this specific= ation.=E2=80=9D

That makes it clear that it is a= supported pattern without commiting to how it should be achieved.=C2=A0<= /div>

Regards,

Neil

--

On Thursday, Apr 05, 2018 at 5:07 pm, Joh= n Bradley <ve7jtb=40ve7jtb.= com> wrote:
+1

On Wed, Apr 4, 2018, 5:4= 2 PM Brian Campbell <bcampbell=40pingidentity.com> wrote:
Strongly agree with Ju= stin that any kind of TLS header forwarding standards like that are well = beyond the scope of this spec.


On =46ri, Mar 30= , 2018 at 10:02 PM, Justin Richer <jricher=40mit.edu> wrote:
I don=E2=80=99t believe this is the spec to define TLS header f= orwarding standards in.=

=C2= =A0=E2=80=94 Justin


On Mar 30, 2018= , at 2:03 PM, Vivek Biswas <vivek.biswas=40orac= le.com> wrote:

There are additional challenges which we = have faced.
=C2=A0
A.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Most of the Mutual SSL communication as mentioned below terminates = at the LBR and the LBR needs to have client certificates to trust the cli= ent. But lot of times the connection from LBR to Authorization server may= be non-SSL.
=C2=A0
The CN, SHA-256 thumprint and serial number of = the Client Cert are sent as header to the AuthzServer/Backend Server. How= ever, if the connection from LBR to AuthzServer/Backend Server is unencry= pted it is prone to MIM attacks. Hence, it=E2=80=99s a MUST requirement t= o have one-way SSL from LBR to AuthzServer/Backend Server, so that the he= aders passed are not compromised.
=C2=A0
This is a MOST common scenario in a real world. And we don= =E2=80=99t want everyone come up with their own names for the header. The= re should be some kind of standardization around the header names.=
= =C2=A0
Regards
Vivek Biswas, CISSP
=C2=A0
=46rom:=C2=A0John Bradley =5Bmailto:ve7jtb=40ve7jtb.com=5D=C2=A0Sent:=C2=A0Thursday, March 29, 2018 11:57 = AM
To:=C2=A0Neil Madden
Cc:=C2=A0oauth
Subject:=C2=A0<= /span>Re: =5BOAUTH-WG=5D WGLC on draft-ietf-oauth-mtls-07
=C2=A0
Yes that is quite a common deployme= nt scenario. =C2=A0 I think that is the way most of the Open Banking impl= ementations have deployed it currently. =C2=A0=C2=A0
<= div>
=C2=A0
<= div style=3D=22margin:0in 0in 0.0001pt;font-size:12pt;font-family:"T= imes New Roman",serif=22>The intent is to support that. =C2=A0 One p= roblem is that how the certificate is transmitted to the application tend= s to be load balancer/reverse proxy specific as no real standard exists.<= u>
=C2=A0=
If you think that = needs to be clarified text is welcome.
=C2=A0
John B.
=C2=A0
=C2=A0


On Mar 29, 2018, at 2:= 54 PM, Neil Madden <neil.madden=40forgerock.com> wrote:=
=C2=A0
Thanks, and understood.=C2=A0
=C2=A0<= u>
The privacy concern= s are mostly around correlating activity of *clients*, which may or may n= ot reveal activity patterns of users using those clients. I don=E2=80=99t= know how much of a concern that is in reality, but thought it should be = mentioned.=C2=A0
=C2=A0
A colleague also made the following comment about the draft:<= u>
=C2=A0
=E2=80=9CIt is stil= l quite common to terminate TLS in a load balancer or proxy, and to deplo= y authorization servers in a secure network zone behind an intermediate i= n a DMZ. In these cases, TLS would not be established between the client = and authorization server as per =C2=A72, but information about the TLS ha= ndshake may be made available by other means (typically adding to a downs= tream header) allowing lookup and verification of the client certificate = as otherwise described. Given the prevalence of this approach it would be= good to know whether such a deployment would be compliant or not.=E2=80=9D=
=C2= =A0
Kind regards,
Neil
--
=C2=A0
=
On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley &l= t;v= e7jtb=40ve7jtb.com> wrote:
Thanks for the feedback. We will review your comm= ents and reply.=C2=A0

One data point is tha= t this will not be the only POP spec. The spec using token binding vs mtl= s has better privacy properties. It is UK Open banking that has pressed u= s to come up with a standard to help with interoperability.=C2=A0

This spec has been simplified in some ways to facil= itate the majority of likely deployments.=C2=A0
I understand that in future certificates may have better than SHA256= hashes.=C2=A0

Regards=C2=A0=
John B.=C2=A0



=
On Mar 29, 2018, at 12:18 PM, Neil Madden <= neil.madden=40forgerock.com> wrote:=C2=A0

Hi,=C2=A0

I have reviewed this d= raft and have a number of comments, below. =46orgeRock have not yet imple= mented this draft, but there is interest in implementing it at some point= . (Disclaimer: We have no firm commitments on this at the moment, I do no= t speak for =46orgeRock, etc).=C2=A0

1.=C2=A0https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-07=23section-3.1=C2= =A0defines a new confirmation method =E2=80=9Cx5t=23S256=E2=80=9D.= However, there is already a confirmation method =E2=80=9Cjwk=E2=80=9D th= at can contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t=23= S526=E2=80=9D claim with exactly the same syntax and semantics. The draft= proposes:=C2=A0

=7B =E2=80=9Ccnf=E2=80=9D:= =7B =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D=C2=A0

but you can already do:=C2= =A0

=7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80=9D: =7B= =E2=80=A6 , =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D= =7D =7D=C2=A0

If the intent is just to sav= e some space and avoid the mandatory fields of the existing JWK types, ma= ybe this would be better addressed by defining a new JWK type which only = has a thumbprint=3F e.g., =7B =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D= , =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D.=C2=A0

2. I find the naming =E2=80=9Cmutual TLS=E2=80= =9D and =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really o= nly the client authentication that we are interested here, and the fact t= hat the server also authenticates with a certificate is not hugely releva= nt to this particular spec (although it is to the overall security of OAu= th). Also, TLS defines non-certificate based authentication mechanisms (e= ..g. TLS-SRP extension for password authenticated key exchange, PSK for p= re-shared key authentication) and even non-X.509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml=23tls-extensiontype-values-3). I=E2=80=99d = prefer that the draft explicitly referred to =E2=80=9CX.509 Client Certif= icate Authentication=E2=80=9D rather than mutual TLS, and changed identif= iers like =E2=80=98tls=5Fclient=5Fauth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23sect= ion-2.1.1) to something more explicit like =E2=80=98tls=5Fx509=5Fpki=5F= client=5Fauth=E2=80=99.=C2=A0

This is espec= ially confusing in section 3 on sender constrained access tokens, as ther= e are two different servers involved: the AS and the protected resource s= erver, but there is no =E2=80=9Cmutual=E2=80=9D authentication between th= em, only between each of them and the client.=C2=A0

3. The draft links to the TLS 1.2 R=46C, while the original OAut= h 2.0 R=46C only specifies TLS 1.0. Is the intention that TLS 1.2+ is req= uired=3F The wording in Section 5.1 doesn=E2=80=99t seem clear if this co= uld also be used with TLS 1.0 or 1.1, or whether it is only referring to = future TLS versions.=C2=A0

4.. It might be = useful to have a discussion for implementors of whether TLS session resum= ption (and PSK in TLS 1.3) and/or renegotiation impact the use of client = certificates, if at all=3F=C2=A0

5. Section= 3 defines sender-constrained access tokens in terms of the confirmation = key claims (e.g., R=46C 7800 for JWT).. However, the OAuth 2.0 Pop Archit= ecture draft defines sender constraint and key confirmation as different = things (https://tools.ie= tf.org/html/draft-ietf-oauth-pop-architecture-08=23section-6.2). The = draft should decide which of those it is implementing and if sender const= raint is intended, then reusing the confirmation key claims seems mislead= ing. (I think this mTLS draft is doing key confirmation so should drop th= e language about sender constrained tokens).=C2=A0=

6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft-ietf-oauth-= pop-architecture-08=23section-5):=C2=A0
Strong, fresh session keys:=C2=A0

Session = keys MUST be strong and fresh.. Each session deserves an=C2= =A0
independent session key, i.e., one that is generated specif= ically=C2=A0
for the intended use. In context o= f OAuth this means that keying=C2=A0
material is= created in such a way that can only be used by the=C2=A0=
combination of a client instance, protected resource, and=C2=A0
authorization scope.=C2=A0


However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23secti= on-3) says:=C2=A0

The client makes prot= ected resource requests as described in=C2=A0
=5B= R=46C6750=5D, however, those requests MUST be made over a mutually=C2=A0
authenticated TLS connection using the same cer= tificate that was used=C2=A0
for mutual TLS at = the token endpoint.=C2=A0

These two stateme= nts are contradictory: the OAuth 2.0 PoP architecture effectively require= s a fresh key-pair to be used for every access token request, whereas thi= s draft proposes reusing the same long-lived client certificate for every= single access token and every resource server.=C2=A0

In the self-signed case (and even in the CA case, with a bit o= f work - e.g.,=C2=A0http= s://www.vaultproject.io/docs/secrets/pki/index.html) it is perfectly = possible for the client to generate a fresh key-pair for each access toke= n and include the certificate on the token request (e.g., as per=C2=A0= https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03=23se= ction-5.1=C2=A0- in which case an appropriate = =E2=80=9Calg=E2=80=9D value should probably be described). This should pr= obably at least be an option.=C2=A0

7. The = use of a single client certificate with every resource server (RS) should= be called out in a Privacy Considerations section, as it allows correlat= ion of activity.=C2=A0

8. This is maybe a m= ore general point, but R=46C 6750 defines the Authorization: Bearer schem= e (https://tools.ietf.org/html/rfc6750=23section-2) for= a client to communicate it=E2=80=99s access token to the RS in a standar= d way. As sender-constrained access tokens are not strictly bearer tokens= any more, should this draft also register a new scheme for that=3F Shoul= d there be a generic PoP scheme=3F=C2=A0

9.= The Security Considerations should really make some mention of the long = history of attacks against X.509 certificate chain validation, e.g. failu= re to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors= in parsing DNs, etc. It should be strongly suggested to use an existing = TLS library to perform these checks rather than implementing your own che= cks. This relates to Justin=E2=80=99s comments around DN parsing and norm= alisation.=C2=A0

10. The PKI client authent= ication method (https://tools.ietf.o= rg/html/draft-ietf-oauth-mtls-07=23section-2.1) makes no mention at a= ll of certificate revocation and how to handle checking for that (CRLs, O= CSP - with stapling=3F). Neither does the Security Considerations. If thi= s is a detail to be agreed between then AS and the CA (or just left up to= the AS TLS stack) then that should perhaps be made explicit. Again, ther= e are privacy considerations with some of these mechanisms, as OCSP reque= sts are typically sent in the clear (plain HTTP) and so allow an observer= to see which clients are connecting to which AS.=C2=A0

11. The same comment applies to how the protected resource c= hecks for revocation of the certificate presented during sender constrain= ed access token usage. Should the RS make its own revocation checks based= on the information in the certificate presented, or should it trust the = certificate while the access token is still valid=3F If the latter case, = is the AS responsible for revoking any access tokens whose certificate ha= ve been revoked (if so, should it be doing an OCSP call on every token in= trospection request, and should the RS be passing on the certificate/seri= al number on that request)=3F If the Client request uses OCSP Stapling (<= a href=3D=22https://en.wikipedia.org/wiki/OCSP=5Fstapling=22 style=3D=22c= olor:purple;text-decoration:underline=22 target=3D=22=5Fblank=22 rel=3D=22= noreferrer=22>https://en.wikipedia.org/wiki/OCSP=5Fstapling) how can = the RS verify the signature on that if it does not have a separate trust = relationship with the CA already=3F=C2=A0

1= 2. The use of only SHA-256 fingerprints means that the security strength = of the sender-constrained access tokens is limited by the collision resis= tance of SHA-256 - roughly =E2=80=9C128-bit security=22 - without a new s= pecification for a new thumbprint algorithm. An implication of this is th= at is is fairly pointless for the protected resource TLS stack to ever ne= gotiate cipher suites/keys with a higher level of security. In more cryst= al ball territory, if a practical quantum computer becomes a possibility = within the lifetime of this spec, then the expected collision resistance = of SHA-256 would drop quadratically, allowing an attacker to find a colli= ding certificate in =7E2=5E64 effort. If we are going to pick just one th= umbprint hash algorithm, I would prefer we pick SHA-512.=C2= =A0

Cheers,=C2=A0

Neil=C2=A0



On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf=40gmail= .com> wrote:=C2=A0

All,=C2=A0

As discussed during the meeting today, we are start= ing a WGLC on the MTLS document:=C2=A0
https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=C2=A0

Please, review the document and provide = feedback on any issues you see with the document.=C2=A0

The WGLC will end in two weeks, on April 2, 2018.=C2=A0

Regards,=C2=A0
Rifaat= and Hannes=C2=A0

=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=C2=A0
O= Auth mailing list=C2=A0
OAuth=40ietf.org=C2=A0
https://www.ietf.org/mailman/listin= fo/oauth

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =C2=A0
OAuth mailing list=C2=A0=
OAuth=40ietf.org=C2=A0
= https://www.ietf.org/mailman/listinfo/oauth
=C2=A0
=
=C2=A0
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth



CON=46= IDENTIALITY NOTICE: This email may contain confidential and privileged ma= terial for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited...=C2=A0 If you= have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from yo= ur computer. Thank you.=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth
=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth= mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
--5acf30df_643c9869_40d-- --5acf30df_66334873_40d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJazzDfAAoJEJD4Q99O3axd+asQAK7tJfzUD1AefXTSvY5u3EnBhNZ7nz3qQnSo OmEcaZzvZPQyWvAzjQ00G+iyKYHzZgQOZJnTOclVWaxdouBIlYinSKUhUk2bIfRFrrocdzahG3b4 asrJZfuIlG0lkikDqkjiNazC+s7HgP6hRx5jf3izIUOlt9JKXU/jNqLkAXaiDesMPrMLUwSfJ1ZU xEym4Qh55vFTjv1LClsAR1D+L5eXIlkCJTUOOfSqjmGg6uTGHuoKaf2vT0Rgt+RVhjeFRcPML458 P/0LgN6FBpXRFDFQjuHRj/KcDPjuaB+kRrxEYLgw4k7KU/I5wyOA+haOquKrk8XBRDxGQcP+t++L S5Jv577OYe+iEwOLJhoHlGLIxeRHqTCis1SFPtyi7ysDhiAgMtQHGuN0au8MxU2DS0yu7neirWO7 CRXpxg7FguDHcl7doRUWcpeLWDEV8Pqa+fj3H/tJuCvyNqJL1TIyt1JRPrnbhBXEvA0w0SN33/yX wgG8BzFp1aIM3KMhPwdAgWoCf5UZ9Qwh6LFncufIxRlPLWRqGiK942JP/wJgFhPe1U6IHvE8TmRR ue6X5xqpyIdYIzu9kx5p7ZPR2OvRHaxCB83BG+FX9HMg12I7qPX9clGFb0FAVh0mS0FsLtD17H2Y Xb+6ygvok0+6jHS7+U3j7LGbk4viyjSjJTrMW4r+ =xXIk -----END PGP SIGNATURE----- --5acf30df_66334873_40d-- From nobody Thu Apr 12 06:26:23 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BCE127275 for ; Thu, 12 Apr 2018 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohImgFggpbEJ for ; Thu, 12 Apr 2018 06:26:20 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C41127136 for ; Thu, 12 Apr 2018 06:26:20 -0700 (PDT) X-AuditID: 12074425-0f9ff70000000a54-d5-5acf5e78396f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 17.84.02644.97E5FCA5; Thu, 12 Apr 2018 09:26:18 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w3CDQBMw013411; Thu, 12 Apr 2018 09:26:13 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3CDQ7E2023640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Apr 2018 09:26:10 -0400 Date: Thu, 12 Apr 2018 08:26:08 -0500 From: Benjamin Kaduk To: Neil Madden Cc: Brian Campbell , oauth Message-ID: <20180412132607.GF97291@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nrlsVdz7K4NBbFYvV/28yWsyZ94vN 4uTbV2wOzB432hYweixZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGSsOLWQv+Cxccfv2J7YG xlbBLkZODgkBE4nX144wdjFycQgJLGaSuLnmEguEs5FRom/5NmYI5yqTxPVzt5hAWlgEVCWO dDayg9hsAioSDd2XmUFsEQFtiRWLFzCC2MwC7hJ/X74As4UFLCROPfoB1MvBwQu0bmFDIcTM f4wSc9v6WUFqeAUEJU7OfMICUsMsUCYxfbcChCktsfwfB0gFp4CVxO3uyywgtqiAssTevkPs ExgFZiFpnoXQPAuheRbYOVoSN/69ZMIQ1pZYtvA1M4RtK7Fu3XuWBYzsqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYKjwkV1B+Ocv16HGAU4GJV4eDeYnosSYk0sK67MPcQo ycGkJMq7MeZ8lBBfUn5KZUZicUZ8UWlOavEhRhWgXY82rL7AKMWSl5+XqiTCO8cOqI43JbGy KrUoH6ZMmoNFSZx38f69UUIC6YklqdmpqQWpRTBZGQ4OJQle9ligRsGi1PTUirTMnBKENBMH 5yFGCQ4eoOHLQY7gLS5IzC3OTIfIn2JUlBLnZQRpFgBJZJTmwfWCkplE9v6aV4ziQG8J8xqC VPEAEyFc9yugwUxAg4/5nAEZXJKIkJJqYHS6fib8b3EmT7SEG3ffqWfhj94kup+72jjnygyT jIrW87lSoqbHWNQOvt0guH0f45Zw3Q9bJP3XMfHrL9u02dnisrBqZLhjjOwaln2SRXlnHEQy L6Rfq9JX7BHa+4jdT2LzgddH4hbe0d4/Z+Kzz5umtE8OvZDLtOfP7oM/rgZdf17Mt12olU2J pTgj0VCLuag4EQDj7eL1QQMAAA== Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 13:26:22 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just replying on one thing... On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote: > Hi Brian, >=20 > Thanks for the detailed responses. Comments in line below (marked with **= *). >=20 > Neil >=20 > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell wrote: > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden wrote: > > > 10. The PKI client authentication method (https://tools.ietf.org/html= /draft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of certifica= te revocation and how to handle checking for that (CRLs, OCSP - with stapli= ng?). Neither does the Security Considerations. If this is a detail to be a= greed between then AS and the CA (or just left up to the AS TLS stack) then= that should perhaps be made explicit. Again, there are privacy considerati= ons with some of these mechanisms, as OCSP requests are typically sent in t= he clear (plain HTTP) and so allow an observer to see which clients are con= necting to which AS. > > > > I didn't think that a TLS client could do OCSP stapling? > > > > *** I think you are right about this. I always assumed it was symmetric= (and I think it technically could work), but the spec only talks about sta= pling in the server-side of the handshake. This changed between TLS 1.2 and TLS 1.3 -- in 1.3, the server can include "status_request" in its CertificateRequest, and the extensions block in the client's Certificate message can include the OCSP staple. -Ben --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlrPXmkACgkQKNmm82Tr dRLjHAwePvzJPdGlNV+1aOF2twY5VGZ5bkZu2q9Cs3FBXYFPsxg3juPyhC0VpqSl Beaas6p8mY0or8l97/0qYCYjLShaRXljRM3b6yhqoiMPUyJt54BTfeQu162kopk3 0TTwFWiq+nbTjZtlYEvcBlZZnFO71svnIoeW7cvSI8ss8ZnCh51Ubw57gIbHHh0T hJF7PJbEAMY+ZRl17+AjHK/fiB8EJSPnens1FqICGiW7dYqc1QkZiauh6ePms00I 6mQ8Ab6ucq6z6h3Y8TyIQ1k7xEIuLXTmjcdRFwMyLnbPO88vpTF5YcPbxCG1ZlGI ju/F/5sLsYvCghc5rPDf+mC6xL5kw+jrSf5lPl9sj9ojS3HGOS9ZkYtQ0z6XEZO9 CZsc5pnBc/G4bVBAunicWIK+0T8KOb6vYcJHW7OhTudc6Dpuxwlym1An4uEszw/k v+0eIzF9e32oi2XGfPYLy3p5Y0o0+2PE5zIVR8aZhJ7laQS0e393zi3trO7GYSWR 07a6wmquYmP/rQ== =cVLs -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From nobody Thu Apr 12 12:33:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867E2128959 for ; Thu, 12 Apr 2018 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LT2dxHiyAYs for ; Thu, 12 Apr 2018 12:33:22 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B351250B8 for ; Thu, 12 Apr 2018 12:33:22 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id t123so440486iof.7 for ; Thu, 12 Apr 2018 12:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/g0GDOvFVwNm4rXSa2TbkpaOyL2KcJ1H1hnp7eZ6+cQ=; b=UFFoRDvRmQCfxKVQV2Hj5Bsle2UFfEaUdAZXL9OceOEzZfPZzRezZU2hM5tjBwMFgc 7boy2JSdpEjBHXb1xrewcOwX7InL26RJ6H+lRGK/Z67i4ESMWvDd56mR5Hg8X8dGLZe0 1IMGJjfR/TptWM4PXGxyTfckeZ7GEYzUUz/SI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/g0GDOvFVwNm4rXSa2TbkpaOyL2KcJ1H1hnp7eZ6+cQ=; b=tmsGnuqK6aAdwcAfQtiFXKbEES87gm9jEFoGyHLQahyuVX55ONU4EsGKF3GA5AUFqs O/ZxI2zZcNd/2FJWzIrwwpmZDQY/WRZc9RbqXhPCRyZgC/Arsvm49iakNQnoZwo7Tv5g tvYOnOfl0biFE32MHEIqlt/ZwGVxeYJ2cKLR7l+ZLVvLWnMPhWpRLJGPbvbjHdFF6qzq xdGJCbIVTTCOvNOLkqVVAaLcCV9yYzrq3V2JB8dtQzNI3xca5dra1zAxcYgEWZs/bh8e GU1dKh9WnUHN9STl+FJwTh68UOUspYMJajsXV16J4/ugb+AmXMTpXunkTAd0+eqlfkNk Uwlg== X-Gm-Message-State: ALQs6tC7Pf7qjetTouBXD6d+v4NX0othFCjnt1MEHsz+OYI4YRFNOlub 0BYHB17KMHpnvd2lZFNbD3ZqYnzHrthyMIlFXh70lnUNisQFhbTfI7YpPpf6SrtHf2xxKmGH8bQ cAocoEDBo/4zFnA== X-Google-Smtp-Source: AIpwx4+/ynSsMPYzW3oNGdQlIWzETy8glmFEwJvvMcgV3EbRF8MRdkKFrNiRh1jpCFUe+R/KlBhZ52uAtPSsK+gFfiA= X-Received: by 10.107.131.16 with SMTP id f16mr952392iod.17.1523561601846; Thu, 12 Apr 2018 12:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.126.149 with HTTP; Thu, 12 Apr 2018 12:32:51 -0700 (PDT) In-Reply-To: <20180412132607.GF97291@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <20180412132607.GF97291@kduck.kaduk.org> From: Brian Campbell Date: Thu, 12 Apr 2018 13:32:51 -0600 Message-ID: To: Benjamin Kaduk Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="001a113e6938126a890569abd4ca" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:33:25 -0000 --001a113e6938126a890569abd4ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the schooling, Ben. On Thu, Apr 12, 2018 at 7:26 AM, Benjamin Kaduk wrote: > Just replying on one thing... > > On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote: > > Hi Brian, > > > > Thanks for the detailed responses. Comments in line below (marked with > ***). > > > > Neil > > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > bcampbell@pingidentity.com (mailto:bcampbell@pingidentity.com)> wrote: > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden < > neil.madden@forgerock.com (mailto:neil.madden@forgerock.com)> wrote: > > > > 10. The PKI client authentication method ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes > no mention at all of certificate revocation and how to handle checking fo= r > that (CRLs, OCSP - with stapling?). Neither does the Security > Considerations. If this is a detail to be agreed between then AS and the = CA > (or just left up to the AS TLS stack) then that should perhaps be made > explicit. Again, there are privacy considerations with some of these > mechanisms, as OCSP requests are typically sent in the clear (plain HTTP) > and so allow an observer to see which clients are connecting to which AS. > > > > > > I didn't think that a TLS client could do OCSP stapling? > > > > > > *** I think you are right about this. I always assumed it was > symmetric (and I think it technically could work), but the spec only talk= s > about stapling in the server-side of the handshake. > > This changed between TLS 1.2 and TLS 1.3 -- in 1.3, the server can > include "status_request" in its CertificateRequest, and the > extensions block in the client's Certificate message can include the > OCSP staple. > > -Ben > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --001a113e6938126a890569abd4ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the schooling, Ben.

On Thu, Apr 12, 2018 at 7:26 AM, B= enjamin Kaduk <kaduk@mit.edu> wrote:
Just replying on one thing...

On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote:
> Hi Brian,
>
> Thanks for the detailed responses. Comments in line below (marked with= ***).
>
> Neil
>
> > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell <= bcampbell@pingidentity.com (mailto:bcampbell@ping= identity.com)> wrote:
> > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden <= ;neil.madden@forgerock.com= (mailto:neil.madden@forgerock= .com)> wrote:
> > > 10. The PKI client authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls= -07#section-2.1) makes no mention at all of certificate revocation= and how to handle checking for that (CRLs, OCSP - with stapling?). Neither= does the Security Considerations. If this is a detail to be agreed between= then AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with some= of these mechanisms, as OCSP requests are typically sent in the clear (pla= in HTTP) and so allow an observer to see which clients are connecting to wh= ich AS.
> >
> > I didn't think that a TLS client could do OCSP stapling?
> >
> > *** I think you are right about this. I always assumed it was sym= metric (and I think it technically could work), but the spec only talks abo= ut stapling in the server-side of the handshake.

This changed between TLS 1.2 and TLS 1.3 -- in 1.3, the server can include "status_request" in its CertificateRequest, and the
extensions block in the client's Certificate message can include the OCSP staple.

-Ben


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113e6938126a890569abd4ca-- From nobody Thu Apr 12 12:36:58 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960651250B8 for ; Thu, 12 Apr 2018 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efMcdkn2ELHL for ; Thu, 12 Apr 2018 12:36:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC07B129515 for ; Thu, 12 Apr 2018 12:36:51 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id h10so4495746iob.2 for ; Thu, 12 Apr 2018 12:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wn9v5qWlM91gAYcqHEcqgPcCE0XcQJou9wTgwLyACbc=; b=nG/JzGgFNvMppXMsEujMW92aj8zvLM+4Z1kSurOEP0blmOOCQ1SLunhm6nEhtkcro4 XbDJfgERN8tBTf2bTL8WUvYO+PPNYd2M8BU/UU+feQIcjIYIeHnk8n5dNkuyvSr7ifR3 j5J7rQLFNOptCMVkz8QJCcevGEcrYFWyi/66s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wn9v5qWlM91gAYcqHEcqgPcCE0XcQJou9wTgwLyACbc=; b=gZ/M1tb++kMh7yGh63aETPE2d3Qc4j5nDZ7fDEW3j0DAHawq/4ujEOQZ3CBZmYj0d9 RGDVunAp8aikeDNLd3mRgvkfbozrGas5D11PgLCQOWHryPDGEEBbRHiGSuKlJN1F3lmR IR2mMQXfj+UH9fJHHULPHNGQxE+mhJKLSdMrOJ0cn6Ho7CRYMoxpzvbv1fTExqobyzrm 0M+atwJV7S/E3nTd2sye3D49Gp0g1oy1gig4ocBqQFi5rL1oSHncr/WY30xp1HzKmFH0 XCRXjC+IZvzwev1MV25ltybY6so3j4eOJuJJNokysjTEicol90Glwn5vDx5UIDNZWkqD lpJw== X-Gm-Message-State: ALQs6tBCgOfL/MdYjrmEvf6lVtBmwQfvxwpHZQ3rhMoaqKP+YswMr8VA fl8Mb/IVD1Cft6IjbkToElDeBRdGyIifw8PboFfwcm6YTAPw8qLtSdd5+yoqbQ46bUy3hU5JxML x/BfZwft6yxFGoTMD X-Google-Smtp-Source: AIpwx4+I5uPbEb84injPojxQm95GfS6lwxEKJ8Lv8QT8tfKUvoxB18IvKOij2mcSwEXjwr9egqQwp0YliU0OmOJ/kIs= X-Received: by 10.107.28.15 with SMTP id c15mr10706062ioc.247.1523561810956; Thu, 12 Apr 2018 12:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.126.149 with HTTP; Thu, 12 Apr 2018 12:36:20 -0700 (PDT) In-Reply-To: <41ae74de-4258-49ae-aa16-1fb24f19e3d8@Canary> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> <41ae74de-4258-49ae-aa16-1fb24f19e3d8@Canary> From: Brian Campbell Date: Thu, 12 Apr 2018 13:36:20 -0600 Message-ID: To: Neil Madden Cc: John Bradley , IETF oauth WG Content-Type: multipart/alternative; boundary="001a114098128931e50569abe03f" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:36:57 -0000 --001a114098128931e50569abe03f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, that makes sense. I think something along those lines could fit into the Implementation Considerations somewhere pretty well. I'll add that to my list of updates for the next revision. On Thu, Apr 12, 2018 at 4:11 AM, Neil Madden wrote: > I agree that this is beyond the scope of the spec. To be clear, our desir= e > is that the mtls spec includes some wording along the following lines: > > =E2=80=9CThe AS MAY choose to terminate TLS connections at a load balance= r, > reverse proxy, or other network intermediary. How the client certificate > metadata is securely communicated between the intermediary and the AS in > this case is out of scope of this specification.=E2=80=9D > > That makes it clear that it is a supported pattern without commiting to > how it should be achieved. > > Regards, > > Neil > > -- > > On Thursday, Apr 05, 2018 at 5:07 pm, John Bradley > wrote: > +1 > > On Wed, Apr 4, 2018, 5:42 PM Brian Campbell > wrote: > >> Strongly agree with Justin that any kind of TLS header forwarding >> standards like that are well beyond the scope of this spec. >> >> >> On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer wrote: >> >>> I don=E2=80=99t believe this is the spec to define TLS header forwardin= g >>> standards in. >>> >>> =E2=80=94 Justin >>> >>> >>> On Mar 30, 2018, at 2:03 PM, Vivek Biswas >>> wrote: >>> >>> There are additional challenges which we have faced. >>> >>> A. Most of the Mutual SSL communication as mentioned below >>> terminates at the LBR and the LBR needs to have client certificates to >>> trust the client. But lot of times the connection from LBR to Authoriza= tion >>> server may be non-SSL. >>> >>> The CN, SHA-256 thumprint and serial number of the Client Cert are sent >>> as header to the AuthzServer/Backend Server. However, if the connection >>> from LBR to AuthzServer/Backend Server is unencrypted it is prone to MI= M >>> attacks. Hence, it=E2=80=99s a MUST requirement to have one-way SSL fro= m LBR to >>> AuthzServer/Backend Server, so that the headers passed are not compromi= sed. >>> >>> This is a MOST common scenario in a real world. And we don=E2=80=99t wa= nt >>> everyone come up with their own names for the header. There should be s= ome >>> kind of standardization around the header names. >>> >>> Regards >>> Vivek Biswas, CISSP >>> >>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com ] >>> *Sent:* Thursday, March 29, 2018 11:57 AM >>> *To:* Neil Madden >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 >>> >>> Yes that is quite a common deployment scenario. I think that is the >>> way most of the Open Banking implementations have deployed it currently= . >>> >>> The intent is to support that. One problem is that how the certificat= e >>> is transmitted to the application tends to be load balancer/reverse pro= xy >>> specific as no real standard exists. >>> >>> If you think that needs to be clarified text is welcome. >>> >>> John B. >>> >>> >>> >>> >>> On Mar 29, 2018, at 2:54 PM, Neil Madden >>> wrote: >>> >>> Thanks, and understood. >>> >>> The privacy concerns are mostly around correlating activity of >>> *clients*, which may or may not reveal activity patterns of users using >>> those clients. I don=E2=80=99t know how much of a concern that is in re= ality, but >>> thought it should be mentioned. >>> >>> A colleague also made the following comment about the draft: >>> >>> =E2=80=9CIt is still quite common to terminate TLS in a load balancer o= r proxy, >>> and to deploy authorization servers in a secure network zone behind an >>> intermediate in a DMZ. In these cases, TLS would not be established bet= ween >>> the client and authorization server as per =C2=A72, but information abo= ut the >>> TLS handshake may be made available by other means (typically adding to= a >>> downstream header) allowing lookup and verification of the client >>> certificate as otherwise described. Given the prevalence of this approa= ch >>> it would be good to know whether such a deployment would be compliant o= r >>> not.=E2=80=9D >>> >>> Kind regards, >>> Neil >>> -- >>> >>> >>> On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley >>> wrote: >>> Thanks for the feedback. We will review your comments and reply. >>> >>> One data point is that this will not be the only POP spec. The spec >>> using token binding vs mtls has better privacy properties. It is UK Ope= n >>> banking that has pressed us to come up with a standard to help with >>> interoperability. >>> >>> This spec has been simplified in some ways to facilitate the majority o= f >>> likely deployments. >>> >>> I understand that in future certificates may have better than SHA256 >>> hashes. >>> >>> Regards >>> John B. >>> >>> >>> >>> On Mar 29, 2018, at 12:18 PM, Neil Madden >>> wrote: >>> >>> Hi, >>> >>> I have reviewed this draft and have a number of comments, below. >>> ForgeRock have not yet implemented this draft, but there is interest in >>> implementing it at some point. (Disclaimer: We have no firm commitments= on >>> this at the moment, I do not speak for ForgeRock, etc). >>> >>> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 def= ines >>> a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is= already a >>> confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web K= ey, which itself can >>> contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax= and semantics. The >>> draft proposes: >>> >>> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80= =A6=E2=80=9D } } >>> >>> but you can already do: >>> >>> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80= =9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } >>> >>> If the intent is just to save some space and avoid the mandatory fields >>> of the existing JWK types, maybe this would be better addressed by defi= ning >>> a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80= =9D: =E2=80=9Cx5t=E2=80=9D, >>> =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }. >>> >>> 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s >>> really only the client authentication that we are interested here, and = the >>> fact that the server also authenticates with a certificate is not hugel= y >>> relevant to this particular spec (although it is to the overall securit= y of >>> OAuth). Also, TLS defines non-certificate based authentication mechanis= ms >>> (e..g. TLS-SRP extension for password authenticated key exchange, PSK f= or >>> pre-shared key authentication) and even non-X.509 certificate types ( >>> https://www.iana.org/assignments/tls-extensiontype- >>> values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2= =80=99d >>> prefer that the draft explicitly referred to =E2=80=9CX.509 Client Cert= ificate >>> Authentication=E2=80=9D rather than mutual TLS, and changed identifiers= like >>> =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07# >>> section-2.1.1) to something more explicit like >>> =E2=80=98tls_x509_pki_client_auth=E2=80=99. >>> >>> This is especially confusing in section 3 on sender constrained access >>> tokens, as there are two different servers involved: the AS and the >>> protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D aut= hentication between >>> them, only between each of them and the client. >>> >>> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC >>> only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The >>> wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be= used with >>> TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. >>> >>> 4.. It might be useful to have a discussion for implementors of whether >>> TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact= the >>> use of client certificates, if at all? >>> >>> >>> 5. Section 3 defines sender-constrained access tokens in terms of the >>> confirmation key claims (e.g., RFC 7800 for JWT).. However, the OAuth 2= .0 >>> Pop Architecture draft defines sender constraint and key confirmation a= s >>> different things (https://tools.ietf.org/html/draft-ietf-oauth-pop- >>> architecture-08#section-6.2). The draft should decide which of those it >>> is implementing and if sender constraint is intended, then reusing the >>> confirmation key claims seems misleading. (I think this mTLS draft is d= oing >>> key confirmation so should drop the language about sender constrained >>> tokens). >>> >>> 6. The OAuth 2.0 PoP Architecture draft says ( >>> https://tools.ietf.org/html/draft-ietf-oauth-pop- >>> architecture-08#section-5 >>> >>> ): >>> >>> Strong, fresh session keys: >>> >>> Session keys MUST be strong and fresh.. Each session deserves an >>> independent session key, i.e., one that is generated specifically >>> for the intended use. In context of OAuth this means that keying >>> material is created in such a way that can only be used by the >>> combination of a client instance, protected resource, and >>> authorization scope. >>> >>> >>> However, the mTLS draft section 3 (https://tools.ietf.org/html/ >>> draft-ietf-oauth-mtls-07#section-3) says: >>> >>> The client makes protected resource requests as described in >>> [RFC6750], however, those requests MUST be made over a mutually >>> authenticated TLS connection using the same certificate that was used >>> for mutual TLS at the token endpoint. >>> >>> These two statements are contradictory: the OAuth 2.0 PoP architecture >>> effectively requires a fresh key-pair to be used for every access token >>> request, whereas this draft proposes reusing the same long-lived client >>> certificate for every single access token and every resource server. >>> >>> In the self-signed case (and even in the CA case, with a bit of work - >>> e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is >>> perfectly possible for the client to generate a fresh key-pair for each >>> access token and include the certificate on the token request (e.g., as= per >>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key- >>> distribution-03#section-5.1 - in which case an appropriate =E2=80=9Calg= =E2=80=9D value >>> should probably be described). This should probably at least be an opti= on. >>> >>> >>> 7. The use of a single client certificate with every resource server >>> (RS) should be called out in a Privacy Considerations section, as it al= lows >>> correlation of activity. >>> >>> 8. This is maybe a more general point, but RFC 6750 defines the >>> Authorization: Bearer scheme (https://tools.ietf.org/html/ >>> rfc6750#section-2) for a client to communicate it=E2=80=99s access toke= n to the >>> RS in a standard way. As sender-constrained access tokens are not stric= tly >>> bearer tokens any more, should this draft also register a new scheme fo= r >>> that? Should there be a generic PoP scheme? >>> >>> 9. The Security Considerations should really make some mention of the >>> long history of attacks against X.509 certificate chain validation, e.g= . >>> failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints,= errors in parsing >>> DNs, etc. It should be strongly suggested to use an existing TLS librar= y to >>> perform these checks rather than implementing your own checks. This rel= ates >>> to Justin=E2=80=99s comments around DN parsing and normalisation. >>> >>> 10. The PKI client authentication method (https://tools.ietf.org/html/ >>> draft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of >>> certificate revocation and how to handle checking for that (CRLs, OCSP = - >>> with stapling?). Neither does the Security Considerations. If this is a >>> detail to be agreed between then AS and the CA (or just left up to the = AS >>> TLS stack) then that should perhaps be made explicit. Again, there are >>> privacy considerations with some of these mechanisms, as OCSP requests = are >>> typically sent in the clear (plain HTTP) and so allow an observer to se= e >>> which clients are connecting to which AS. >>> >>> 11. The same comment applies to how the protected resource checks for >>> revocation of the certificate presented during sender constrained acces= s >>> token usage. Should the RS make its own revocation checks based on the >>> information in the certificate presented, or should it trust the >>> certificate while the access token is still valid? If the latter case, = is >>> the AS responsible for revoking any access tokens whose certificate hav= e >>> been revoked (if so, should it be doing an OCSP call on every token >>> introspection request, and should the RS be passing on the >>> certificate/serial number on that request)? If the Client request uses = OCSP >>> Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS >>> verify the signature on that if it does not have a separate trust >>> relationship with the CA already? >>> >>> 12. The use of only SHA-256 fingerprints means that the security >>> strength of the sender-constrained access tokens is limited by the >>> collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a >>> new specification for a new thumbprint algorithm. An implication of thi= s is >>> that is is fairly pointless for the protected resource TLS stack to eve= r >>> negotiate cipher suites/keys with a higher level of security. In more >>> crystal ball territory, if a practical quantum computer becomes a >>> possibility within the lifetime of this spec, then the expected collisi= on >>> resistance of SHA-256 would drop quadratically, allowing an attacker to >>> find a colliding certificate in ~2^64 effort. If we are going to pick j= ust >>> one thumbprint hash algorithm, I would prefer we pick SHA-512. >>> >>> Cheers, >>> >>> Neil >>> >>> >>> >>> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef >>> wrote: >>> >>> All, >>> >>> As discussed during the meeting today, we are starting a WGLC on the >>> MTLS document: >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >>> >>> Please, review the document and provide feedback on any issues you see >>> with the document. >>> >>> The WGLC will end in two weeks, on April 2, 2018. >>> >>> Regards, >>> Rifaat and Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.*__________________________ >> _____________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --001a114098128931e50569abe03f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, that makes sense. I think something along those line= s could fit into the Implementation Considerations somewhere pretty well. I= 'll add that to my list of updates for the next revision.

On Thu, Apr 12, 2018= at 4:11 AM, Neil Madden <neil.madden@forgerock.com>= wrote:
I agree that this is beyond the scope of the spec. To be clear= , our desire is that the mtls spec includes some wording along the followin= g lines:

=E2=80=9CThe AS MAY choose to terminate T= LS connections at a load balancer, reverse proxy, or other network intermed= iary. How the client certificate metadata is securely communicated between = the intermediary and the AS in this case is out of scope of this specificat= ion.=E2=80=9D

That makes it clear that it is a sup= ported pattern without commiting to how it should be achieved.=C2=A0
<= div>
Regards,

Neil

--

=
On Thursday, Apr 05, 2018 at 5:07 pm, John Bradley <ve7jtb@ve7jtb.com> w= rote:
+1

On Wed, Apr 4, 201= 8, 5:42 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Strongly agree with Justin that any kind of TLS header forwarding s= tandards like that are well beyond the scope of this spec.
<= br>

On Fri, Mar 30, 2018 at 10:02 PM, Justin R= icher <jricher@mit.edu> wrote:
I don=E2=80=99t believe this= is the spec to define TLS header forwarding standards in.
=C2=A0=E2=80=94 Ju= stin


= On Mar 30, 2018, at 2:03 PM, Vivek Biswas <vivek.biswas@oracle.com<= /a>> wrote:

From:=C2=A0John Bradley [mailto:= ve7jtb@ve7jtb.com]=C2=A0
Sent:<= /b>=C2=A0Thursday, March 29, 2018 11:57 A= M
To:=C2=A0Neil Madden
Cc= :=C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] WGLC on draft-ietf-oauth-m= tls-07
=C2=A0
Yes that is quite a common de= ployment scenario. =C2=A0 I think that is the way most of the Open Banking = implementations have deployed it currently. =C2=A0=C2=A0
=C2=A0
The intent is to support that. =C2=A0 One problem is that= how the certificate is transmitted to the application tends to be load bal= ancer/reverse proxy specific as no real standard exists.
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times= New Roman",serif">If you think that needs to be clarified text is wel= come.
=C2=A0<= u>
John B.
=
=C2=A0
<= /div>
=C2=A0


neil.madden@forgerock.com> wrote:=
=C2=A0
Thanks, and un= derstood.=C2=A0
= =C2=A0
The privacy concerns a= re mostly around correlating activity of *clients*, which may or may not re= veal activity patterns of users using those clients. I don=E2=80=99t know h= ow much of a concern that is in reality, but thought it should be mentioned= .=C2=A0
=C2=A0=
A colleague also made the following comment about the= draft:
=C2=A0=
=E2=80=9CIt is still quite common to= terminate TLS in a load balancer or proxy, and to deploy authorization ser= vers in a secure network zone behind an intermediate in a DMZ. In these cas= es, TLS would not be established between the client and authorization serve= r as per =C2=A72, but information about the TLS handshake may be made avail= able by other means (typically adding to a downstream header) allowing look= up and verification of the client certificate as otherwise described. Given= the prevalence of this approach it would be good to know whether such a de= ployment would be compliant or not.=E2=80=9D
=C2=A0
Kind regards,=
Neil
--
=C2=A0
=
On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley = <ve7jtb@ve7jtb.com&g= t; wrote:
Thanks for the feedback. We will review your comments= and reply.=C2=A0

One data point i= s that this will not be the only POP spec. The spec using token binding vs = mtls has better privacy properties. It is UK Open banking that has pressed = us to come up with a standard to help with interoperability.=C2=A0

This spec has been simplified in some ways= to facilitate the majority of likely deployments.=C2=A0

Reg= ards=C2=A0
John B.=C2=A0



=
<= div class=3D"h5">On Mar 29, 2018, at 12:18 PM, Neil Madden <neil.madden@forgerock.com&g= t; wrote:=C2=A0

Hi,=C2=A0

I have reviewed this draft and have a numb= er of comments, below. ForgeRock have not yet implemented this draft, but t= here is interest in implementing it at some point. (Disclaimer: We have no = firm commitments on this at the moment, I do not speak for ForgeRock, etc).= =C2=A0

1.https://tools.ietf.org/html/draft-ietf-oau= th-mtls-07#section-3.1=C2=A0defi= nes a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is= already a confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSO= N Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80=9D claim with= exactly the same syntax and semantics. The draft proposes:=C2=A0

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S25= 6=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } }=C2= =A0

but you can already do:=C2=A0<= /span>

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6= , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }=C2=A0

If the intent is just to save some spa= ce and avoid the mandatory fields of the existing JWK types, maybe this wou= ld be better addressed by defining a new JWK type which only has a thumbpri= nt? e.g., { =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256= =E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }.=C2=A0<= /span>

2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D= and =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really only t= he client authentication that we are interested here, and the fact that the= server also authenticates with a certificate is not hugely relevant to thi= s particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e..g. TLS-SRP = extension for password authenticated key exchange, PSK for pre-shared key a= uthentication) and even non-X.509 certificate types (https://www.iana.org/assignm= ents/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-= extensiontype-values-3). I=E2=80=99d prefer that the draft explici= tly referred to =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D r= ather than mutual TLS, and changed identifiers like =E2=80=98tls_client_aut= h=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-07#section-2.1.1) to something more explicit like =E2=80=98= tls_x509_pki_client_auth=E2=80=99.=C2=A0<= span class=3D"">

This is especially confusing in section 3 on sender= constrained access tokens, as there are two different servers involved: th= e AS and the protected resource server, but there is no =E2=80=9Cmutual=E2= =80=9D authentication between them, only between each of them and the clien= t.=C2=A0

3. The draft links to the= TLS 1.2 RFC, while the original OAuth 2.0 RFC only specifies TLS 1.0. Is t= he intention that TLS 1.2+ is required? The wording in Section 5.1 doesn=E2= =80=99t seem clear if this could also be used with TLS 1.0 or 1.1, or wheth= er it is only referring to future TLS versions.= =C2=A0

4.. It might be useful to have a discussion for= implementors of whether TLS session resumption (and PSK in TLS 1.3) and/or= renegotiation impact the use of client certificates, if at all?=C2=A0


5. Section 3 de= fines sender-constrained access tokens in terms of the confirmation key cla= ims (e.g., RFC 7800 for JWT).. However, the OAuth 2.0 Pop Architecture draf= t defines sender constraint and key confirmation as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-<= wbr>architecture-08#section-6.2). The draft should decide which of thos= e it is implementing and if sender constraint is intended, then reusing the= confirmation key claims seems misleading. (I think this mTLS draft is doin= g key confirmation so should drop the language about sender constrained tok= ens).=C2=A0

6. The OAuth 2.0 PoP A= rchitecture draft says (https://tools.ietf.org/html= /draft-ietf-oauth-pop-architecture-08#section-5):=C2=A0

Strong, fresh session keys:=C2=A0

Session keys MUST be strong and fresh.= . Each session deserves an=C2=A0
indep= endent session key, i.e., one that is generated specifically=C2=A0
for the intended use. In context of OAuth this= means that keying=C2=A0
material is c= reated in such a way that can only be used by the=C2=A0
combination of a client instance, protected resource, and= =C2=A0
authorization scope.=C2=A0


However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#= section-3) says:=C2=A0

The cli= ent makes protected resource requests as described in=C2=A0
[RFC6750], however, those requests MUST be made over = a mutually=C2=A0
authenticated TLS con= nection using the same certificate that was used= =C2=A0
for mutual TLS at the token endpoint.=C2=A0

These two statements are contradictory: the OAut= h 2.0 PoP architecture effectively requires a fresh key-pair to be used for= every access token request, whereas this draft proposes reusing the same l= ong-lived client certificate for every single access token and every resour= ce server.=C2=A0

In the self-signe= d case (and even in the CA case, with a bit of work - e.g.,=C2=A0https://www.vaultproject.io/docs/secrets/<= wbr>pki/index.html) it is perfectly possible for the client to generate= a fresh key-pair for each access token and include the certificate on the = token request (e.g., as per=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-pop= -key-distribution-03#section-5.1=C2=A0<= /span>- in which case an appropriate =E2=80=9Calg=E2=80=9D value should pro= bably be described). This should probably at least be an option.=C2=A0

7. The use of a single client certific= ate with every resource server (RS) should be called out in a Privacy Consi= derations section, as it allows correlation of activity.=C2=A0

8. This is maybe a more general point, but RFC= 6750 defines the Authorization: Bearer scheme (https://tools.ietf.org/html/= rfc6750#section-2) for a client to communicate it=E2=80=99s access toke= n to the RS in a standard way. As sender-constrained access tokens are not = strictly bearer tokens any more, should this draft also register a new sche= me for that? Should there be a generic PoP scheme?=C2=A0

10. = The PKI client authentication method (https://tools.ietf.org/h= tml/draft-ietf-oauth-mtls-07#section-2.1) makes no mention at= all of certificate revocation and how to handle checking for that (CRLs, O= CSP - with stapling?). Neither does the Security Considerations. If this is= a detail to be agreed between then AS and the CA (or just left up to the A= S TLS stack) then that should perhaps be made explicit. Again, there are pr= ivacy considerations with some of these mechanisms, as OCSP requests are ty= pically sent in the clear (plain HTTP) and so allow an observer to see whic= h clients are connecting to which AS.=C2=A0

11. The same comment applies to how the protected resource checks= for revocation of the certificate presented during sender constrained acce= ss token usage. Should the RS make its own revocation checks based on the i= nformation in the certificate presented, or should it trust the certificate= while the access token is still valid? If the latter case, is the AS respo= nsible for revoking any access tokens whose certificate have been revoked (= if so, should it be doing an OCSP call on every token introspection request= , and should the RS be passing on the certificate/serial number on that req= uest)? If the Client request uses OCSP Stapling (https://en.wikipedia.org/wiki= /OCSP_stapling) how can the RS verify the signature on that if it does = not have a separate trust relationship with the CA already?=C2=A0

12. The use of only SHA-256 fingerprints me= ans that the security strength of the sender-constrained access tokens is l= imited by the collision resistance of SHA-256 - roughly =E2=80=9C128-bit se= curity" - without a new specification for a new thumbprint algorithm. = An implication of this is that is is fairly pointless for the protected res= ource TLS stack to ever negotiate cipher suites/keys with a higher level of= security. In more crystal ball territory, if a practical quantum computer = becomes a possibility within the lifetime of this spec, then the expected c= ollision resistance of SHA-256 would drop quadratically, allowing an attack= er to find a colliding certificate in ~2^64 effort. If we are going to pick= just one thumbprint hash algorithm, I would prefer we pick SHA-512.=C2=A0

Cheers,= =C2=A0

Neil=C2=A0


On 19 Mar 201= 8, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=C2=A0

All,=C2=A0

A= s discussed during the meeting today, we are starting a WGLC on the MTLS do= cument:=C2=A0
https://tools.ietf.org/= html/draft-ietf-oauth-mtls-07=C2=A0

Please, review the document and provide feedback on any issues y= ou see with the document.=C2=A0

Th= e WGLC will end in two weeks, on April 2, 2018.= =C2=A0

Regards,=C2=A0
Ri= faat and Hannes=C2=A0

____________= ___________________________________=C2=A0
OAuth mailing list=C2=A0
OAuth@ietf.org=C2=A0
https://www.ietf.org/mailman/listinfo/oauth=

__________________= _____________________________=C2=A0<= br>OAuth mailing list=C2=A0
OAuth@ietf.org=C2=A0
https://www.ietf.org/mailman/listinfo/oauth<= u>
=C2=A0<= /u>
=C2=A0
______________________________= _________________
OAuth mail= ing list
OAuth@ietf.orghttps://www.ietf.org/mai= lman/listinfo/oauth

_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oa= uth



CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited...=C2=A0 = If you have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments from = your computer. Thank you.___________________________= ____________________
OAuth mailing list
OAuth@ietf.org=
https://www.ietf.org/mailman/lis= tinfo/oauth
 ____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114098128931e50569abe03f-- From nobody Thu Apr 12 12:43:22 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2561A12DA06 for ; Thu, 12 Apr 2018 12:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LyWi34JBcI1 for ; Thu, 12 Apr 2018 12:43:15 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA8F12D9FE for ; Thu, 12 Apr 2018 12:43:14 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id 141so7623114iou.12 for ; Thu, 12 Apr 2018 12:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tN1PaItPc1j+n05zcd0dW68/EIwPf87bQnse+JYo2Ck=; b=Iif1eA13VhDJeziplkXY3FHp1VxTPzikfQnhcwKtrLeqn74dsZNe+MLhnH0KSYedqm 4qZm0tfEFQ/qSVAx9sLp1+RwHvi4N1ZKlwIjit2920lThNUzEHGIm+7X4rNvyNnGiZT+ gA5luwhiPdblhvZn4gU+3UM8YLOhD+TeiHA6E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tN1PaItPc1j+n05zcd0dW68/EIwPf87bQnse+JYo2Ck=; b=Qu5pET/CJv2pmYcd+50eI/SZ+Fx1kZPIg+VVo/sl50wLyqi9ijzs0FO6wi7SpoDtWv UVoaNx/hRn4qnLX2Z5cRyEIW3567L1cwQDs5Ni0ApuKPvnOsMIrXHg0+plmhTCd8h1ua 7Uj9EBi8EPlaBxbXXMXqDtJI8ev5SuQ3B+eb9FF7orMFUYDyqDas1VUXsvTkpVcji07V MmfdKZBwTbArm0ZsF9/PmRiMg6QMoK5FuWQVCdD36MKYPy9w+i7/C4FTPiRd7kiF+qh+ cxB7svkkGwCx8ela8fcqCiv3e/W5exET2IKe6z2RyBJTYKKRCt5PRnTOJjCvABo2JZFr g5uw== X-Gm-Message-State: ALQs6tDLsHt5cYbUEFSwDicuBuKoHYwwcE9I8vMQO/HAnaLZbbFw/nbE 65Ho0b9pyoDnz4eusQtPsTx7VLuiP2l9doCS7cdVVk3cgITJX46v+t3dBiHE3Lba5OPVpliAv7c wgPItdXA17+j1cA== X-Google-Smtp-Source: AIpwx4/H3uP8xwwRcA6VDM8AvgpDvJwvSDVzqboJvXJrrU0gKP3vFbiQRhhl+9B7fwqPW8jnLHYKY3Yw+SoWDNajG6Y= X-Received: by 10.107.131.16 with SMTP id f16mr980893iod.17.1523562193870; Thu, 12 Apr 2018 12:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.126.149 with HTTP; Thu, 12 Apr 2018 12:42:43 -0700 (PDT) In-Reply-To: <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> From: Brian Campbell Date: Thu, 12 Apr 2018 13:42:43 -0600 Message-ID: To: Neil Madden Cc: oauth , Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary="001a113e69385bfa9c0569abf715" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:43:20 -0000 --001a113e69385bfa9c0569abf715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Neil. Other than the potential metadata changes, which I'd like more WG input on and may raise in a new thread, I think I've got enough to make updates addressing your comments. But please do send text for that Security Considerations bit, if you come up with something. On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden wrote: > Hi Brian, > > Thanks for the detailed responses. Comments in line below (marked with > ***). > > Neil > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > bcampbell@pingidentity.com> wrote: > Thanks for the review and feedback, Neil. I apologize for my being slow t= o > respond. As I said to Justin recently > = , > I've been away from things for a while. Also there's a lot here to get > through so took me some time. > > It looks like John touched on some of your comments but not all. I'll try > and reply to them as best I can inline below. > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden > wrote: > >> Hi, >> >> I have reviewed this draft and have a number of comments, below. >> ForgeRock have not yet implemented this draft, but there is interest in >> implementing it at some point. (Disclaimer: We have no firm commitments = on >> this at the moment, I do not speak for ForgeRock, etc). >> >> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 >> defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, t= here is already a >> confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Ke= y, which itself can >> contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax = and semantics. The >> draft proposes: >> >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D } } >> >> but you can already do: >> >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } >> >> If the intent is just to save some space and avoid the mandatory fields >> of the existing JWK types, maybe this would be better addressed by defin= ing >> a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80= =9D: =E2=80=9Cx5t=E2=80=9D, >> =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }. >> > > The intent of the x5t#S256 confirmation method was to be space efficient > and straightforward while utilizing the framework and registry that RFC > 7800 gives. Even a new JWK type like that would still use more space. An= d > I'd argue that the new confirmation method is considerably more > straightforward than registering a new JWK type (and the implications tha= t > would have on JWK implementations in general) in order to use the existin= g > "jwk" confirmation method. > > *** > OK, that is reasonable. Given that the draft says SHOULD rather than MUST > for using this confirmation key method, I think it is currently allowed t= o > use either representation. > > > >> >> 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s >> really only the client authentication that we are interested here, and t= he >> fact that the server also authenticates with a certificate is not hugely >> relevant to this particular spec (although it is to the overall security= of >> OAuth). Also, TLS defines non-certificate based authentication mechanism= s >> (e.g. TLS-SRP extension for password authenticated key exchange, PSK for >> pre-shared key authentication) and even non-X.509 certificate types ( >> https://www.iana.org/assignments/tls-extensiontype-values/t >> ls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d p= refer >> that the draft explicitly referred to =E2=80=9CX.509 Client Certificate >> Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like >> =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/d >> raft-ietf-oauth-mtls-07#section-2.1.1) to something more explicit like >> =E2=80=98tls_x509_pki_client_auth=E2=80=99. >> >> This is especially confusing in section 3 on sender constrained access >> tokens, as there are two different servers involved: the AS and the >> protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D auth= entication between >> them, only between each of them and the client. >> > > Choosing names and terminology is difficult and the "right" wording is > often subjective. I believe that the current wording sufficiently conveys > what is going on in the draft to most readers. Most readers thus far seem > to agree. There is some text now that does say that the mutual auth in th= e > draft is in fact X.509 client cert authn but, in the next revision, I'll > look for other opportunities where it could be stated more clearly. > > *** Thanks. > > > >> >> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC >> only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The >> wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be = used with >> TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. >> > > The reference to BCP 195 (which unfortunately the original OAuth 2.0 RFC > doesn't have because it didn't exist then) is meant to account for changi= ng > versions and recommendations around TLS. Currently that BCP says TLS 1.2 = is > a must and suggests against 1.1 & 1.0 but doesn't outright prohibit them. > > *** OK, that seems good to me. > > > >> >> 4. It might be useful to have a discussion for implementors of whether >> TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the >> use of client certificates, if at all? >> > > That might well be useful but I don't myself know what it would say. I've > (maybe naively) figured those are deployment details that will just work > out. Perhaps you could propose some text around such a discussion that th= e > WG could consider? > > *** > To be honest, when I raised this it was because I didn=E2=80=99t really k= now what > the implications were. I=E2=80=99ve done some reading around and I think = it should > all just work - both session resumption and PSK-based resumption preserve > the original client and server authentication context so we can assume th= at > any presented client cert is still valid for the resumed session. So I > think we can leave out any discussion of this and assume it works as > expected. > > > >> 5. Section 3 defines sender-constrained access tokens in terms of the >> confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 >> Pop Architecture draft defines sender constraint and key confirmation as >> different things (https://tools.ietf.org/html/d >> raft-ietf-oauth-pop-architecture-08#section-6.2). The draft should >> decide which of those it is implementing and if sender constraint is >> intended, then reusing the confirmation key claims seems misleading. (I >> think this mTLS draft is doing key confirmation so should drop the langu= age >> about sender constrained tokens). >> > > I will say again that choosing names and terminology is difficult... > > Although I must admit that I started using "sender constrained" somewhat > indiscriminately at first and it's just sort of stuck. At the time I was > trying to incorporate bits of draft-sakimura-oauth-jpop in a way that mig= ht > help bring on and keep the authors of that draft onboard with this mtls > draft. In retrospect it looks like I did that part wrong anyway. But that > was the thinking at the time and the history, for whatever it's worth. Mo= re > recently, Nat was requesting that "sender constrained" be included in the > title. So there's that too. > > In defense of my mistake, however, if there's a line between "sender > constrained" and "key confirmation" tokens, it's a bit of a fuzzy line. A= nd > I'd argue that what this draft is doing pretty close to the line. > > But ultimately I think you are right that what this mtls draft is doing > with access tokens is more accurately described with the key confirmation > term. > > So, yes, the draft should probably drop (or at least minimize) the > language about sender constrained. I'll do that in the next draft version= , > barring big objections from the WG. > > The tricky thing with making that change is that there a client and serve= r > metadata parameters with the name "mutual_tls_sender_constrained_access_t= okens" > that should probably also change. But that would be a breaking change (of > sorts anyway), which shouldn't be taken lightly at this stage. I feel tha= t > some explicit okays from the WG are needed before doing so (rough consens= us > stye) . Any WG members want to weigh in here and help get a "sense of the > group" concerning changing those metadata names? > > *** Thanks. I agree this might cause compatibility issues. It is not a bi= g > issue for us, but might cause some confusion. > > > >> >> 6. The OAuth 2.0 PoP Architecture draft says ( >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architectu >> re-08#section-5): >> >> Strong, fresh session keys: >> >> Session keys MUST be strong and fresh. Each session >> deserves an >> independent session key, i.e., one that is generated >> specifically >> for the intended use. In context of OAuth this means >> that keying >> material is created in such a way that can only be used >> by the >> combination of a client instance, protected resource, an= d >> authorization scope. >> >> >> However, the mTLS draft section 3 (https://tools.ietf.org/html/d >> raft-ietf-oauth-mtls-07#section-3) says: >> >> The client makes protected resource requests as described in >> [RFC6750], however, those requests MUST be made over a mutually >> authenticated TLS connection using the same certificate that was >> used >> for mutual TLS at the token endpoint. >> >> These two statements are contradictory: the OAuth 2.0 PoP architecture >> effectively requires a fresh key-pair to be used for every access token >> request, whereas this draft proposes reusing the same long-lived client >> certificate for every single access token and every resource server. >> >> In the self-signed case (and even in the CA case, with a bit of work - >> e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is >> perfectly possible for the client to generate a fresh key-pair for each >> access token and include the certificate on the token request (e.g., as = per >> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distrib >> ution-03#section-5.1 - in which case an appropriate =E2=80=9Calg=E2=80= =9D value should >> probably be described). This should probably at least be an option. >> > > This draft doesn't necessarily seek to align with the (long expired) PoP > architecture draft. Rather it is aiming to provide a pragmatic solution > for PoP style access tokens and OAuth client auth using mTLS client > certificates. > > That said, with the current draft, it's certainly possible for a client t= o > update its cert more frequently, even so far as using a new one for each > access token. The details of how that would work will vary some based on > the token endpoint authentication method. But it's not precluded. > > *** You are right, the text doesn=E2=80=99t preclude that. I am happy wit= h that > solution. I suspect most people will deploy and be happy with reusing a > long-lived cert for every access token, so this may not matter in practic= e. > > >> >> 7. The use of a single client certificate with every resource server (RS= ) >> should be called out in a Privacy Considerations section, as it allows >> correlation of activity. >> > > Practically speaking the access tokens being presented likely already hav= e > correlatable info in them about the client as well as the user. I don't > know that there's much of a (new) concern in reality. If you feel > this concern is unique and import enough though, perhaps there's some tex= t > you'd like to propose for a Privacy Considerations section that the WG > could consider? I mean, I guess it doesn't hurt to mention it but I would > like to avoid overstating the issue. > > *** On reflection, I am going to withdraw this comment. As you say there > are other ways to correlate clients. The privacy issue would mainly arise > in the context of dynamic client registration e.g., a pattern I=E2=80=99v= e seen > described where every instance of a mobile app does dynamic client > registration to avoid including credentials directly in the app bundle. > This would make clients one-to-one with users. But (a) those apps are > fairly unlikely to be using TLS certs, and (b) that is more of a privacy > consideration for dynamic client registration rather than this draft. > > > >> >> 8. This is maybe a more general point, but RFC 6750 defines the >> Authorization: Bearer scheme (https://tools.ietf.org/html/r >> fc6750#section-2) for a client to communicate it=E2=80=99s access token = to the >> RS in a standard way. As sender-constrained access tokens are not strict= ly >> bearer tokens any more, should this draft also register a new scheme for >> that? Should there be a generic PoP scheme? >> > > The thinking and general consensus (in this draft as well as the OAuth > token binding work) has been that continuing to use the RFC 6750 scheme > while putting the "not strictly bearer" stuff in (or referenced by) the > token itself will be easier on deployment and implementation. And better > for adoption as a result. I believe some early implementation work has > borne that out too. > > *** OK. > > >> 9. The Security Considerations should really make some mention of the >> long history of attacks against X.509 certificate chain validation, e.g. >> failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing >> DNs, etc. It should be strongly suggested to use an existing TLS library= to >> perform these checks rather than implementing your own checks. This rela= tes >> to Justin=E2=80=99s comments around DN parsing and normalisation. >> > > Suggesting to use an existing TLS library is certainly sound advice and I > sort of felt is implied in the draft. But saying so more > strongly/explicitly might be worthwhile. And pointing to historical > reasons to do so would probably be good too. Could you propose a new > Security Considerations section or maybe augmentation of =C2=A75.2 with t= hat > content? > > *** I=E2=80=99ll try and come up with some text. > > > >> >> 10. The PKI client authentication method (https://tools.ietf.org/html/d >> raft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of >> certificate revocation and how to handle checking for that (CRLs, OCSP - >> with stapling?). Neither does the Security Considerations. If this is a >> detail to be agreed between then AS and the CA (or just left up to the A= S >> TLS stack) then that should perhaps be made explicit. Again, there are >> privacy considerations with some of these mechanisms, as OCSP requests a= re >> typically sent in the clear (plain HTTP) and so allow an observer to see >> which clients are connecting to which AS. >> > > I didn't think that a TLS client could do OCSP stapling? > > *** I think you are right about this. I always assumed it was symmetric > (and I think it technically could work), but the spec only talks about > stapling in the server-side of the handshake. > > That aside, revocation checking (how and even if) is something that's at > the discretion of the AS. I can add something in =C2=A72.1 to say that mo= re > explicitly. > > *** Thanks. > > > >> 11. The same comment applies to how the protected resource checks for >> revocation of the certificate presented during sender constrained access >> token usage. Should the RS make its own revocation checks based on the >> information in the certificate presented, or should it trust the >> certificate while the access token is still valid? If the latter case, i= s >> the AS responsible for revoking any access tokens whose certificate have >> been revoked (if so, should it be doing an OCSP call on every token >> introspection request, and should the RS be passing on the >> certificate/serial number on that request)? If the Client request uses O= CSP >> Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS >> verify the signature on that if it does not have a separate trust >> relationship with the CA already? >> > > The draft effectively uses cert mtls at the RS as a proof-of-possession > method only and not as authentication. So revocation checking isn't reall= y > applicable. In specific deployment situations, I suppose an RS could chec= k > revocation. But that'd be a deployment decision for the RS that's beyond > the scope of this draft. > > *** OK, that is an interesting observation. If either the client or AS > suspect the key has been compromised they can revoke the access token(s) > instead. > > > >> 12. The use of only SHA-256 fingerprints means that the security strengt= h >> of the sender-constrained access tokens is limited by the collision >> resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without a n= ew >> specification for a new thumbprint algorithm. An implication of this is >> that is is fairly pointless for the protected resource TLS stack to ever >> negotiate cipher suites/keys with a higher level of security. In more >> crystal ball territory, if a practical quantum computer becomes a >> possibility within the lifetime of this spec, then the expected collisio= n >> resistance of SHA-256 would drop quadratically, allowing an attacker to >> find a colliding certificate in ~2^64 effort. If we are going to pick ju= st >> one thumbprint hash algorithm, I would prefer we pick SHA-512. >> > > The idea behind haveing just one thumbprint hash algorithm was to keep > things simple. And SHA-256 seems good enough for the reasonably foreseeab= le > future (and space aware). Also a new little spec to register a different > hash algorithm, should the need arise, didn't seem particularity onerous. > > That was the thinking anyway. Maybe it is too short sighted though? > > I do think SHA-256 should stay regardless. > > But the draft could also define SHA-512 (and maybe others). What do you > and WG folks think about that? > > *** Yes please. > > It would probably then be useful for the metadata in =C2=A73.3 and =C2=A7= 3.4 to > change from just boolean values to something to convey what hash alg/cnf > method the client expects and the list of what the server supports. That'= s > maybe something that should be done anyway. That'd be a breaking change t= o > the metadata. But there's already another potential breaking change > identified earlier in this message. So maybe it's worth doing... > > How do folks feel about making this kind of change? > > > > > > >> Cheers, >> >> Neil >> >> >> > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef >> wrote: >> > >> > All, >> > >> > As discussed during the meeting today, we are starting a WGLC on the >> MTLS document: >> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >> > >> > Please, review the document and provide feedback on any issues you see >> with the document. >> > >> > The WGLC will end in two weeks, on April 2, 2018. >> > >> > Regards, >> > Rifaat and Hannes >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --001a113e69385bfa9c0569abf715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Neil.

Other than the potent= ial metadata changes, which I'd like more WG input on and may raise in = a new thread, I think I've got enough to make updates addressing your c= omments.=C2=A0 But please do send text for that Security Considerations bit= , if you come up with something.=C2=A0

On Thu, Apr 12, 2018 at 3:03 AM, Neil= Madden <neil.madden@forgerock.com> wrote:
Hi B= rian,

Thanks for the detailed responses. Comments in li= ne below (marked with ***).

Neil

<= div>
On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Cam= pbell <b= campbell@pingidentity.com> wrote:
Thanks for the review and feedback, Neil. I apol= ogize for my being slow to respond. As I said to= Justin recently, I've been away from things for a while. Also ther= e's a lot here to get through so took me some time.

It lo= oks like John touched on some of your comments but not all. I'll try an= d reply to them as best I can inline below.


On Thu= , Mar 29, 2018 at 9:18 AM, Neil Madden <neil.madden@forgerock.com<= /a>> wrote:
= Hi,

I have reviewed this draft and have a number of comments, belo= w. ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments on = this at the moment, I do not speak for ForgeRock, etc).

1. https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07#section-3.1 defines a new confirmation method =E2= =80=9Cx5t#S256=E2=80=9D. However, there is already a confirmation method = =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key, which itself can con= tain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax and se= mantics. The draft proposes:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 { =E2=80= =9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D = } }

but you can already do:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {= =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5t= #S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }

If the intent is= just to save some space and avoid the mandatory fields of the existing JWK= types, maybe this would be better addressed by defining a new JWK type whi= ch only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80= =9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }.

The intent of the x5t#S256=C2=A0confirmation metho= d was to be space efficient and straightforward while utilizing the framewo= rk and registry that RFC 7800 gives.=C2=A0 Even a new JWK type like that wo= uld still use more space. And I'd argue that the new confirmation metho= d is considerably more straightforward than registering a new JWK type (and= the implications that would have on JWK implementations in general) in ord= er to use the existing "jwk" confirmation method.=C2=A0

***=
OK, that is reasonable. Given that the draft says SHOULD rather than = MUST for using this confirmation key method, I think it is currently allowe= d to use either representation.=C2=A0

=C2=A0

2. I find the n= aming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a bit of a mi= snomer: it=E2=80=99s really only the client authentication that we are inte= rested here, and the fact that the server also authenticates with a certifi= cate is not hugely relevant to this particular spec (although it is to the = overall security of OAuth). Also, TLS defines non-certificate based authent= ication mechanisms (e.g. TLS-SRP extension for password authenticated key e= xchange, PSK for pre-shared key authentication) and even non-X.509 certific= ate types (https://www.iana.org/assignments/tls-extensi= ontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-va= lues-3). I=E2=80=99d prefer that the draft explicitly referred to =E2= =80=9CX.509 Client Certificate Authentication=E2=80=9D rather than mutual T= LS, and changed identifiers like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07#section-2.1.1) to something more explicit like = =E2=80=98tls_x509_pki_client_auth=E2=80=99.

This is especially con= fusing in section 3 on sender constrained access tokens, as there are two d= ifferent servers involved: the AS and the protected resource server, but th= ere is no =E2=80=9Cmutual=E2=80=9D authentication between them, only betwee= n each of them and the client.

Choosing= names and terminology is difficult and the "right" wording is of= ten subjective. I believe that the current wording sufficiently conveys wha= t is going on in the draft to most readers. Most readers thus far seem to a= gree. There is some text now that does say that the mutual auth in the draf= t is in fact X.509 client cert authn but, in the next revision, I'll lo= ok for other opportunities where it could be stated more clearly.=C2=A0

*** Thanks.=C2=A0

=C2=A0

= 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC onl= y specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The wordin= g in Section 5.1 doesn=E2=80=99t seem clear if this could also be used with= TLS 1.0 or 1.1, or whether it is only referring to future TLS versions.

The reference to BCP 195 (which unfortuna= tely the=C2=A0original OAuth 2.0 RFC doesn't have because it didn't= exist then) is meant to account for changing versions and recommendations = around TLS. Currently that BCP says TLS 1.2 is a must and suggests against = 1.1 & 1.0 but doesn't outright prohibit them.

*** OK, that seems good to me.=C2=A0
=

=C2=A0
4. It might be useful to have a discussion for implementors of whether TL= S session resumption (and PSK in TLS 1.3) and/or renegotiation impact the u= se of client certificates, if at all?

T= hat might well be useful but I don't myself know what it would say. I&#= 39;ve (maybe naively) figured those are deployment details that will just w= ork out. Perhaps you could propose some text around such a discussion that = the WG could consider?

=C2=A0***
To be = honest, when I raised this it was because I didn=E2=80=99t really know what= the implications were. I=E2=80=99ve done some reading around and I think i= t should all just work - both session resumption and PSK-based resumption p= reserve the original client and server authentication context so we can ass= ume that any presented client cert is still valid for the resumed session. = So I think we can leave out any discussion of this and assume it works as e= xpected.=C2=A0



5. Section 3 defines sender= -constrained access tokens in terms of the confirmation key claims (e.g., R= FC 7800 for JWT). However, the OAuth 2.0 Pop Architecture draft defines sen= der constraint and key confirmation as different things (https://tools.ietf.org/html/draft-ie= tf-oauth-pop-architecture-08#section-6.2). The draft should decide= which of those it is implementing and if sender constraint is intended, th= en reusing the confirmation key claims seems misleading. (I think this mTLS= draft is doing key confirmation so should drop the language about sender c= onstrained tokens).

I will say again th= at choosing names and terminology is difficult...

Although I must ad= mit that I started using "sender constrained" somewhat indiscrimi= nately at first and it's just sort of stuck. At the time I was trying t= o incorporate bits of draft-sakimura-oauth-jpop in a way that might help br= ing on and keep the authors of that draft onboard with this mtls draft. In = retrospect it looks like I did that part wrong anyway. But that was the thi= nking at the time and the history, for whatever it's worth. More recent= ly, Nat was requesting that "sender constrained" be included in t= he title. So there's that too.=C2=A0

In defense of m= y mistake, however, if there's a line between "sender constrained&= quot; and "key confirmation" tokens, it's a bit of a fuzzy li= ne. And I'd argue that what this draft is doing pretty close to the lin= e.

But ultimately I think you are right that what this m= tls draft is doing with access tokens is more accurately described with the= key confirmation term.

So, yes, the draft sh= ould probably drop (or at least minimize) the language about sender constra= ined. I'll do that in the next draft version, barring big objections fr= om the WG.

The tricky thing with making that change is th= at there a client and server metadata parameters with the name "mutual= _tls_sender_constrained_access_tokens" that should probably also = change. But that would be a breaking change (of sorts anyway), which should= n't be taken lightly at this stage. I feel that some explicit okays fro= m the WG are needed before doing so (rough consensus stye) . Any WG members= want to weigh in here and help get a "sense of the group" concerni= ng changing those metadata names?

*** Thanks. I agree this might cause compatibility issues. It is not = a big issue for us, but might cause some confusion.=C2=A0

=C2=A0

6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft-ie= tf-oauth-pop-architecture-08#section-5):

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Strong, fresh session keys:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Session keys MUST be strong and fres= h.=C2=A0 Each session deserves an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 independent session key, i.e., one that is generated s= pecifically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for= the intended use.=C2=A0 In context of OAuth this means that keying
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 material is created in= such a way that can only be used by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 combination of a client instance, protected res= ource, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth= orization scope.


However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-o= auth-mtls-07#section-3) says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0= The client makes protected resource requests as described in
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 [RFC6750], however, those requests MUST be made over a= mutually
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated TLS connection usin= g the same certificate that was used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for mu= tual TLS at the token endpoint.

These two statements are contradic= tory: the OAuth 2.0 PoP architecture effectively requires a fresh key-pair = to be used for every access token request, whereas this draft proposes reus= ing the same long-lived client certificate for every single access token an= d every resource server.

In the self-signed case (and even in the = CA case, with a bit of work - e.g., https://w= ww.vaultproject.io/docs/secrets/pki/index.html) it is perfectly po= ssible for the client to generate a fresh key-pair for each access token an= d include the certificate on the token request (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section-5.1 - in which cas= e an appropriate =E2=80=9Calg=E2=80=9D value should probably be described).= This should probably at least be an option.

This draft doesn't necessarily seek to align with the (long expir= ed) PoP architecture draft.=C2=A0 Rather it is aiming to provide a pragmati= c solution for PoP style access tokens and OAuth client auth using mTLS cli= ent certificates.

That said, with the current draft, it&= #39;s certainly possible for a client to update its cert more frequently, e= ven so far as using a new one for each access token. The details of how tha= t would work will vary some based on the token endpoint authentication meth= od. But it's not precluded.

=
*** You are right, the text doesn=E2=80=99t preclude that. I am happy = with that solution. I suspect most people will deploy and be happy with reu= sing a long-lived cert for every access token, so this may not matter in pr= actice.=C2=A0
=C2=A0

7. The use of a single client certificate with e= very resource server (RS) should be called out in a Privacy Considerations = section, as it allows correlation of activity.

Practically speaking the access tokens being presented likely alrea= dy have correlatable info in them about the client as well as the user. I d= on't know that there's much of a (new) concern in reality. If you f= eel this=C2=A0concern is unique and import enough though, perhaps there'= ;s some text you'd like to propose for a Privacy Considerations section= that the WG could consider? I mean, I guess it doesn't hurt to mention= it but I would like to avoid overstating the issue.=C2=A0
<= br>
*** On reflection, I am going to withdraw this comment= . As you say there are other ways to correlate clients. The privacy issue w= ould mainly arise in the context of dynamic client registration e.g., a pat= tern I=E2=80=99ve seen described where every instance of a mobile app does = dynamic client registration to avoid including credentials directly in the = app bundle. This would make clients one-to-one with users. But (a) those ap= ps are fairly unlikely to be using TLS certs, and (b) that is more of a pri= vacy consideration for dynamic client registration rather than this draft.= =C2=A0

=C2=A0

8. This is maybe a more general point, but R= FC 6750 defines the Authorization: Bearer scheme (https= ://tools.ietf.org/html/rfc6750#section-2) for a client to communic= ate it=E2=80=99s access token to the RS in a standard way. As sender-constr= ained access tokens are not strictly bearer tokens any more, should this dr= aft also register a new scheme for that? Should there be a generic PoP sche= me?

The thinking and general consensus = (in this draft as well as the OAuth token binding work) has been that conti= nuing to use the RFC 6750 scheme while putting the "not strictly beare= r" stuff in (or referenced by) the token itself will be easier on depl= oyment and implementation. And better for adoption as a result. I believe s= ome early implementation work has borne that out too.

=C2=A0*** OK.=C2=A0


9. The Security Considerations s= hould really make some mention of the long history of attacks against X.509= certificate chain validation, e.g. failure to check the =E2=80=9CCA=E2=80= =9D bit in the basic constraints, errors in parsing DNs, etc. It should be = strongly suggested to use an existing TLS library to perform these checks r= ather than implementing your own checks. This relates to Justin=E2=80=99s c= omments around DN parsing and normalisation.

Suggesting to use an existing TLS library is certainly sound advice a= nd I sort of felt is implied in the draft. But saying so more strongly/expl= icitly might be worthwhile.=C2=A0 And pointing to historical reasons to do = so would probably be good too.=C2=A0 Could you propose a new Security Consi= derations section or maybe augmentation of =C2=A75.2 with that content?=C2= =A0

*** I=E2=80=99ll try and come up with s= ome text.=C2=A0

=C2=A0

10. The PKI client authenticati= on method (https://tools.ietf.org/ht= ml/draft-ietf-oauth-mtls-07#section-2.1) makes no mention at = all of certificate revocation and how to handle checking for that (CRLs, OC= SP - with stapling?). Neither does the Security Considerations. If this is = a detail to be agreed between then AS and the CA (or just left up to the AS= TLS stack) then that should perhaps be made explicit. Again, there are pri= vacy considerations with some of these mechanisms, as OCSP requests are typ= ically sent in the clear (plain HTTP) and so allow an observer to see which= clients are connecting to which AS.

I = didn't think that a TLS client could do OCSP=C2=A0stapling?
<= br>
*** I think you are right about this. I always assumed= it was symmetric (and I think it technically could work), but the spec onl= y talks about stapling in the server-side of the handshake.=C2=A0

That aside, revocation checking (how and even if)= is something that's at the discretion of the AS. I can add something i= n =C2=A72.1 to say that more explicitly.=C2=A0

<= div>*** Thanks.=C2=A0



11. The same comment applies to how = the protected resource checks for revocation of the certificate presented d= uring sender constrained access token usage. Should the RS make its own rev= ocation checks based on the information in the certificate presented, or sh= ould it trust the certificate while the access token is still valid? If the= latter case, is the AS responsible for revoking any access tokens whose ce= rtificate have been revoked (if so, should it be doing an OCSP call on ever= y token introspection request, and should the RS be passing on the certific= ate/serial number on that request)? If the Client request uses OCSP Staplin= g (https://en.wikipedia.org/wiki/OCSP_stapling) = how can the RS verify the signature on that if it does not have a separate = trust relationship with the CA already?

The draft effectively uses cert mtls at the RS as a proof-of-possession me= thod only and not as authentication. So revocation checking isn't reall= y applicable. In specific deployment situations, I suppose an RS could chec= k revocation. But that'd be a deployment decision for the RS that's= beyond the scope of this draft.

*** O= K, that is an interesting observation. If either the client or AS suspect t= he key has been compromised they can revoke the access token(s) instead.=C2= =A0
=C2=A0


12. The use of only SHA-256 fingerprints me= ans that the security strength of the sender-constrained access tokens is l= imited by the collision resistance of SHA-256 - roughly =E2=80=9C128-bit se= curity" - without a new specification for a new thumbprint algorithm. = An implication of this is that is is fairly pointless for the protected res= ource TLS stack to ever negotiate cipher suites/keys with a higher level of= security. In more crystal ball territory, if a practical quantum computer = becomes a possibility within the lifetime of this spec, then the expected c= ollision resistance of SHA-256 would drop quadratically, allowing an attack= er to find a colliding certificate in ~2^64 effort. If we are going to pick= just one thumbprint hash algorithm, I would prefer we pick SHA-512.

The idea behind haveing just one thumbprint h= ash algorithm was to keep things simple. And SHA-256 seems good enough for = the reasonably foreseeable future (and space aware). Also a new little spec= to register a different hash algorithm, should the need arise, didn't = seem particularity onerous.

That was the thinking anyway= . Maybe it is too short sighted though?

I do think SHA-25= 6 should stay regardless.

But the draft could also defin= e SHA-512 (and maybe others). What do you and WG folks think about that?

*** Yes please.=C2=A0

It would probably then be useful for the metadata in =C2=A73.3 = and =C2=A73.4 to change from just boolean values to something to convey wha= t hash alg/cnf method the client expects and the list of what the server su= pports. That's maybe something that should be done anyway. That'd b= e a breaking change to the metadata. But there's already another potent= ial breaking change identified earlier in this message. So maybe it's w= orth doing...

How do folks feel about making this kind of= change?




=C2=A0
Cheers,

Neil


= > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= br> >
> All,
>
> As discussed during the meeting to= day, we are starting a WGLC on the MTLS document:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >
> Please, review the document and provide feedback on any is= sues you see with the document.
>
> The WGLC will end in two = weeks, on April 2, 2018.
>
> Regards,
>=C2=A0 Rifaat a= nd Hannes
>
> ________________________= _______________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



CONFIDENTIALITY NOTICE: This email may conta= in confidential and privileged material for the sole use of the intended re= cipient(s). Any review, use, distribution or disclosure by others is strict= ly prohibited.=C2=A0 If you have received this communication in error, plea= se notify the sender immediately by e-mail and delete the message and any f= ile attachments from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a113e69385bfa9c0569abf715-- From nobody Thu Apr 12 12:52:22 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EEA12D87F for ; Thu, 12 Apr 2018 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AkDdWe3ViGn for ; Thu, 12 Apr 2018 12:52:19 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11CAA129515 for ; Thu, 12 Apr 2018 12:52:18 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id p126-v6so2616584ybg.8 for ; Thu, 12 Apr 2018 12:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aRQF4dYHF/7n89NXJ7+6iMmKLlTku77kZU2wErXjBjk=; b=yVuXdZJeMJfDJPhhmIDorOp9ShLEncVq4X2E2hjNiR9kSeja3W8RgZ2PWzHmB6uiBA +f3l2AZCLR5MsSn7ZBkxx+vNke8c4g3JKlA0jEnMOpIlaQdr4MMHfz8XXyV4/cclq+j+ vE8DH0rtkA7+f5S7w4MpQhHG4lRFjsLis8S1igq1Ms3ny2IE8zBdgLECg3XZLnJcNDHb ev5GQwvv/PoP0bcKLGrugvyfbKSfHJnvVam9s/iA5YLgU03bRp1D7GpV+Y2nVxooPs9p 02Mq9NLKtuSCmgQkSY5iPV+eHByo4hUt8kD43gyuMR5pxohXFsIx7SycvPp5JqyOHQ3w CcPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aRQF4dYHF/7n89NXJ7+6iMmKLlTku77kZU2wErXjBjk=; b=Sja1/832XA+JaiNVqh2iio1SO4ODsohJx04maqNZk6sKL+ZFUnnVZrrey8XVK9XQzS tO0yKoQnfbRSQK3Sxi7iKIVZ+vVztYe2Cvm/jokvkQ5FALpqyQSIhKELZb/MW/kIYtRR jL0EWWq4O8pJ3kyqwD2wSbS6+Z2oujTB579Hwt2STQojNZNkewEXtYftDcbhvDE+6RR8 xk/jzPGSUSx7Es8XqHB5egnucF2d93qBYGpeJmhUHBH1ldf579WrR90x4jOQRHRVxhdq TtmoFafFHaTygF32TiyUnrnoPzLUONOJY8E9tzpjd6MxnzzSpmnMiB4uUVzJiiwkzIx3 Dzdw== X-Gm-Message-State: ALQs6tA/NXAxlAvzFH5uD9U2eUp/m0wZoLB5JQMLbH6vOE4u2vKLA2mZ XHBLENUxvBUCuVLHiaaY/Mq0hA== X-Google-Smtp-Source: AIpwx49eYeWb3vBvke1VAuTs/2ryeRiJDB4ZYF8WEqmUsqHfl2RD6T9UZDbEOkjxDCC5O/zzzjj1uw== X-Received: by 2002:a25:e645:: with SMTP id d66-v6mr1589283ybh.370.1523562737807; Thu, 12 Apr 2018 12:52:17 -0700 (PDT) Received: from [192.168.8.102] ([181.201.130.225]) by smtp.gmail.com with ESMTPSA id i15sm694366qta.4.2018.04.12.12.52.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 12:52:16 -0700 (PDT) From: John Bradley Message-Id: <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A659EE5D-AF1C-409B-BD63-10A2D747E52B" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 12 Apr 2018 16:52:12 -0300 In-Reply-To: <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> Cc: Brian Campbell , oauth To: Neil Madden References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 19:52:21 -0000 --Apple-Mail=_A659EE5D-AF1C-409B-BD63-10A2D747E52B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline Snip >=20 >=20 > 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. >=20 > The idea behind haveing just one thumbprint hash algorithm was to keep = things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous.=20 >=20 > That was the thinking anyway. Maybe it is too short sighted though? >=20 > I do think SHA-256 should stay regardless.=20 >=20 > But the draft could also define SHA-512 (and maybe others). What do = you and WG folks think about that? >=20 > *** Yes please.=20 >=20 > It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server = supports. That's maybe something that should be done anyway. That'd be a = breaking change to the metadata. But there's already another potential = breaking change identified earlier in this message. So maybe it's worth = doing... >=20 > How do folks feel about making this kind of change?=20 >=20 >=20 The confirmation method is opaque to the client. I don=E2=80=99t think = adding hash algs to discovery will really help. The AS selection needs to be based on what the RS can support. If anyplace it should be in RS discovery.=20 As a practical matter you art going to find a client certificate with = more than a SHA256 hash anytime in the near future.=20 So for a short lived access token 128bits of collision resistance is = quite good. We are going to have issues with certificates long before = this becomes a problem. SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RSA = keys, but again that is over the long term. =20 We are using short lived access tokens. People should rotate the = certificate more often than once a year if this is a real issue. I am not against new hash for the fingerprint, but I also don=E2=80=99t = know that SHA512 would be the best choice if we are concerned about = quantum crypto resistance. That is a issue beyond mtls and should be = addressed by CFRG etc. Regards John B. --Apple-Mail=_A659EE5D-AF1C-409B-BD63-10A2D747E52B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Inline

Snip


=
12. The use of only SHA-256 fingerprints means that the = security strength of the sender-constrained access tokens is limited by = the collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" = - without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512.

The idea behind haveing = just one thumbprint hash algorithm was to keep things simple. And = SHA-256 seems good enough for the reasonably foreseeable future (and = space aware). Also a new little spec to register a different hash = algorithm, should the need arise, didn't seem particularity onerous.

That was the thinking = anyway. Maybe it is too short sighted though?

I do think SHA-256 should stay = regardless.

But the = draft could also define SHA-512 (and maybe others). What do you and WG = folks think about that?

*** Yes please. 

It would probably then be useful for the metadata in =C2=A73.3 = and =C2=A73.4 to change from just boolean values to something to convey = what hash alg/cnf method the client expects and the list of what the = server supports. That's maybe something that should be done anyway. = That'd be a breaking change to the metadata. But there's already another = potential breaking change identified earlier in this message. So maybe = it's worth doing...

How= do folks feel about making this kind of change?


The confirmation method is opaque to the = client.  I don=E2=80=99t think adding hash algs to discovery will = really help.
The AS selection needs to be based on what = the RS can support.

If anyplace it should be in RS discovery. 

As a practical matter = you art going to find a client certificate with more than a SHA256 hash = anytime in the near future. 
So for a short = lived access token 128bits of collision resistance is quite good.   = We are going to have issues with certificates long before this becomes a = problem.

SHA256 = is appropriate for AES128 256bit elliptic curves and 3072bit RSA keys, = but again that is over the long term.  
We are = using short lived access tokens.  People should rotate the = certificate more often than once a year if this is a real = issue.

I am = not against new hash for the fingerprint, but I also don=E2=80=99t know = that SHA512 would be the best choice if we are concerned about quantum = crypto resistance.   That is a issue beyond mtls and should be = addressed by CFRG etc.

Regards
John B.


= --Apple-Mail=_A659EE5D-AF1C-409B-BD63-10A2D747E52B-- From nobody Thu Apr 12 13:21:15 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CE412DA0D for ; Thu, 12 Apr 2018 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSk4h7YVyCVk for ; Thu, 12 Apr 2018 13:21:07 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B9812D87F for ; Thu, 12 Apr 2018 13:21:07 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 142-v6so482510itl.5 for ; Thu, 12 Apr 2018 13:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOWtBwxrzP1bGkoMFFNrES7c7Qn+Yg+c16CefUaumQA=; b=Cx+kFoJlI0iogpWcHm4tjpeoI+RlqF0Mm9zFPyCBXsjQMGwOsTw5+FIXjsRuLG4vxi hXtyVjZC7j2CiMUp86x67Uy+CQ/q2W6OdFQgbmjoO7758qRUV8W4IUbs8uTPo38LXM19 RS++CDNvy6ihnbXQbrmxN75F+k2umq0ryOFL8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nOWtBwxrzP1bGkoMFFNrES7c7Qn+Yg+c16CefUaumQA=; b=Byxe3jcXJepJiF2aC9SwVHUtxjb+NlyK/4uTNQqVvYm12N21e0uGaikuWiDi+SM515 uLBDv9T6QlNb0Ve0Ak0FYhBVvyByPKU59Xt8XfZ/Jv00TgZDr9gWvJpf0LM6jvb6P8fw CMSnDxOtVz8cRBDCFSdJc0csyE/zZOgiWFc57TlIBslFnI5cHAvJNCpdArl68UbBv5xo Ygo0VqfIBBv0SkoQUCj9Hblu9vl/2129dNGITEi8zI8IHnzjOk5xChm5O5rdOZ+vw4kP kk4lyTht9pjRhM6e5tG3IPZlnLaT+T1dDxwBYmDsrJ+CRi4M3B6A+5h0iaGeDH9hc5za 8meA== X-Gm-Message-State: ALQs6tDwiYZfB6DvA0JhU1FHrk6EfO1rGW9eypMVQhN2Tiq4G2yY7occ 7NuNWfUAbOFKDqvDDhRCJqVX61ej6FmQj+/JwEo7UYZKjq+MIaENkHB0ipfGiW0oBuE49lEInAq BEZFdFET9tF8xlw== X-Google-Smtp-Source: AIpwx49uAP8I4HJBo1HdRKgHKtztMCRAMDhj31tQ4nPz238rFOsJjfVInHcddJBylR8bbXcAqCc8oaKbMB8BNTEMTk8= X-Received: by 2002:a24:5491:: with SMTP id t139-v6mr2430345ita.89.1523564466188; Thu, 12 Apr 2018 13:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.126.149 with HTTP; Thu, 12 Apr 2018 13:20:35 -0700 (PDT) In-Reply-To: <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> From: Brian Campbell Date: Thu, 12 Apr 2018 14:20:35 -0600 Message-ID: To: John Bradley Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000ccf2260569ac7e91" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 20:21:14 -0000 --000000000000ccf2260569ac7e91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's true about it being opaque to the client. I was thinking of client metadata (config or registration) as a way for the AS to decide if to bind the AT to a cert. And moving from a boolean to a conf method as an extension of that. It would be more meaningful in RS discovery, if there was such a thing. I don=E2=80=99t know that SHA512 would be the best choice either but it is something that is stronger and could be included now. If there's consensus to do more than SHA256 in this doc. On Thu, Apr 12, 2018 at 1:52 PM, John Bradley wrote: > Inline > > Snip > > > >> 12. The use of only SHA-256 fingerprints means that the security strengt= h >> of the sender-constrained access tokens is limited by the collision >> resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without a n= ew >> specification for a new thumbprint algorithm. An implication of this is >> that is is fairly pointless for the protected resource TLS stack to ever >> negotiate cipher suites/keys with a higher level of security. In more >> crystal ball territory, if a practical quantum computer becomes a >> possibility within the lifetime of this spec, then the expected collisio= n >> resistance of SHA-256 would drop quadratically, allowing an attacker to >> find a colliding certificate in ~2^64 effort. If we are going to pick ju= st >> one thumbprint hash algorithm, I would prefer we pick SHA-512. >> > > The idea behind haveing just one thumbprint hash algorithm was to keep > things simple. And SHA-256 seems good enough for the reasonably foreseeab= le > future (and space aware). Also a new little spec to register a different > hash algorithm, should the need arise, didn't seem particularity onerous. > > That was the thinking anyway. Maybe it is too short sighted though? > > I do think SHA-256 should stay regardless. > > But the draft could also define SHA-512 (and maybe others). What do you > and WG folks think about that? > > *** Yes please. > > It would probably then be useful for the metadata in =C2=A73.3 and =C2=A7= 3.4 to > change from just boolean values to something to convey what hash alg/cnf > method the client expects and the list of what the server supports. That'= s > maybe something that should be done anyway. That'd be a breaking change t= o > the metadata. But there's already another potential breaking change > identified earlier in this message. So maybe it's worth doing... > > How do folks feel about making this kind of change? > > > The confirmation method is opaque to the client. I don=E2=80=99t think a= dding > hash algs to discovery will really help. > The AS selection needs to be based on what the RS can support. > > If anyplace it should be in RS discovery. > > As a practical matter you art going to find a client certificate with mor= e > than a SHA256 hash anytime in the near future. > So for a short lived access token 128bits of collision resistance is quit= e > good. We are going to have issues with certificates long before this > becomes a problem. > > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RSA > keys, but again that is over the long term. > We are using short lived access tokens. People should rotate the > certificate more often than once a year if this is a real issue. > > I am not against new hash for the fingerprint, but I also don=E2=80=99t k= now that > SHA512 would be the best choice if we are concerned about quantum crypto > resistance. That is a issue beyond mtls and should be addressed by CFRG > etc. > > Regards > John B. > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ccf2260569ac7e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's true about it being opaque to the client. = I was thinking of client metadata (config or registration) as a way for the= AS to decide if to bind the AT to a cert. And moving from a boolean to a c= onf method as an extension of that. It would be more meaningful in RS disco= very, if there was such a thing.

I don=E2=80=99t know tha= t SHA512 would be the best choice either but it is something that is strong= er and could be included now. If there's consensus to do more than SHA2= 56 in this doc.=C2=A0


On Thu, Apr 12, 2018 at 1:52 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
Inli= ne

Snip

=

12. The u= se of only SHA-256 fingerprints means that the security strength of the sen= der-constrained access tokens is limited by the collision resistance of SHA= -256 - roughly =E2=80=9C128-bit security" - without a new specificatio= n for a new thumbprint algorithm. An implication of this is that is is fair= ly pointless for the protected resource TLS stack to ever negotiate cipher = suites/keys with a higher level of security. In more crystal ball territory= , if a practical quantum computer becomes a possibility within the lifetime= of this spec, then the expected collision resistance of SHA-256 would drop= quadratically, allowing an attacker to find a colliding certificate in ~2^= 64 effort. If we are going to pick just one thumbprint hash algorithm, I wo= uld prefer we pick SHA-512.

The idea be= hind haveing just one thumbprint hash algorithm was to keep things simple. = And SHA-256 seems good enough for the reasonably foreseeable future (and sp= ace aware). Also a new little spec to register a different hash algorithm, = should the need arise, didn't seem particularity onerous.

That was the thinking anyway. Maybe it is too short sighted though?
I do think SHA-256 should stay regardless.

<= div>But the draft could also define SHA-512 (and maybe others). What do you= and WG folks think about that?

*** Yes please.=C2= =A0

It would probably then be useful for the metadata in = =C2=A73.3 and =C2=A73.4 to change from just boolean values to something to = convey what hash alg/cnf method the client expects and the list of what the= server supports. That's maybe something that should be done anyway. Th= at'd be a breaking change to the metadata. But there's already anot= her potential breaking change identified earlier in this message. So maybe = it's worth doing...

How do folks feel about making th= is kind of change?


The confi= rmation method is opaque to the client.=C2=A0 I don=E2=80=99t think adding = hash algs to discovery will really help.
The AS selection needs to be b= ased on what the RS can support.

If anyplace it sh= ould be in RS discovery.=C2=A0

As a practical matt= er you art going to find a client certificate with more than a SHA256 hash = anytime in the near future.=C2=A0
So for a short lived access tok= en 128bits of collision resistance is quite good. =C2=A0 We are going to ha= ve issues with certificates long before this becomes a problem.
<= br>
SHA256 is appropriate for AES128 256bit elliptic curves and 3= 072bit RSA keys, but again that is over the long term. =C2=A0
We = are using short lived access tokens.=C2=A0 People should rotate the certifi= cate more often than once a year if this is a real issue.

I am not against new hash for the fingerprint, but I also don=E2=80= =99t know that SHA512 would be the best choice if we are concerned about qu= antum crypto resistance. =C2=A0 That is a issue beyond mtls and should be a= ddressed by CFRG etc.

Regards
John B.




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ccf2260569ac7e91-- From nobody Thu Apr 12 14:07:30 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340C512DA11 for ; Thu, 12 Apr 2018 14:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KckTophQxiM for ; Thu, 12 Apr 2018 14:07:25 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858A812D779 for ; Thu, 12 Apr 2018 14:07:25 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id k1-v6so2912544yba.5 for ; Thu, 12 Apr 2018 14:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q3TPqOr9mclseXHF0L0KCP440MwQ4YSBU6PY3CxfaV8=; b=EbD4JSbynIDRtsLWeVfTwCzL/rSP7Jdpk9+t+ff3hu1VuS+FNBHe4J4a5cKgYErvET I5GGCIsPa4TJ31GhEZ1NfzPIuRDOAj9zb7aU2QQu5DgCTbypkprVC0R4AGiY3cTZuqWC rKoUi1+ivV/+nr/rbjmpkV4YXnVB4OMV+XwSfnupyPKYulSY/K627pVzFHW/re8UNlTn SRl8NVFqis8DBuQz5NGmXpWNqHGinny1spB7pK+k1gexULRB31xkogfnPxf+gybS5vkh m4SsR+8NN45V5/lVdMAvcFe5xOIyp8bN8LiqUEfLD877aVdCZTgARgrie1pstTFEh3tO 3DUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q3TPqOr9mclseXHF0L0KCP440MwQ4YSBU6PY3CxfaV8=; b=lu6vcJ4bZ7qOEKGJZPT/KXdKP8NY3A7BoNJXNVoEXKvlNVB9baudt58rAAwbiijmfv q/Rnc+XSa0TdKoN4v7e5wec7KUA2Pw3RKUGZyNr5F4S6f6BVXY+r7eBzZLBiksLqnIc2 A04DzLAQH+loSEc/hEhWcDif/Hbprg/ecuveYo54lGp2CWKXQtk63Eff1o3HF8fj+UuT IQymWiYu53/wlLz+6Z5DfB8mrNkAqNke2kp0GEAersn9qemBx32P0qqRBt+RlY3zy2Qm hlG7hTO25sHOI6h6jXJGYHd18nMlGiGTDH9vbGm2U3u/vh67pBcPPWOX1HVmNbbA9eXX FUmg== X-Gm-Message-State: ALQs6tDdMcUF95bSYsw9QdVMol3JhDHS/9G2BF/UDYfOm5GGQ3LmPapm RH8ykfhlTP1WGC0IXj3Z7HvVYQ== X-Google-Smtp-Source: AIpwx4+1J7O1rNsVMiBzfaqR+2XcTjmMMRFbjTe9lzMZ7ObtiaxOSz5h2szSVk/y31+IhHP3mdp5KA== X-Received: by 2002:a25:acc2:: with SMTP id x2-v6mr1957970ybd.179.1523567244126; Thu, 12 Apr 2018 14:07:24 -0700 (PDT) Received: from [192.168.8.102] ([181.201.130.225]) by smtp.gmail.com with ESMTPSA id b25sm3831322qte.88.2018.04.12.14.07.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 14:07:22 -0700 (PDT) From: John Bradley Message-Id: <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3160D64A-624C-42F7-B4EE-0780098777C2" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 12 Apr 2018 18:07:18 -0300 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 21:07:28 -0000 --Apple-Mail=_3160D64A-624C-42F7-B4EE-0780098777C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The WG discusses RS meta-data as part of one of Dick=E2=80=99s = proposals. I am unclear on who is going to work on it in what draft. If the client is doing mtls to both the Token endpoint and RS the = information in the confirmation method is not relevant to the client as = long as the AS and RS are in agreement like with most tokens. The hash on the certificate and length of the signing key are equally or = more vulnerable to any sort of attack. At least with AT the tokens are not long lived. Doing anything better than SHA256 only makes sense if the cert is signed = by something stronger like SHA512 with a 2048bit RSA key. That seems = sort of unlikely in the near term. =20 I prefer to wait to see what general fix is proposed before we jump the = gun with a bandade for a small part of the overall problem. People are typically using SHA1 fingerprints. We added SHA256 for JWT = and got push back on that as overkill.=20 I don=E2=80=99t think this is the correct place to be deciding this. =20= We could say that if new thumbprints are defined the AS and RS can = decide to use them as necessary. That is sort of the situation we have now. The correct solution may be a thousand rounds of PBKDF2 or something = like that to make finding collisions more difficult rather than longer = hashes. John B. > On Apr 12, 2018, at 5:20 PM, Brian Campbell = wrote: >=20 > That's true about it being opaque to the client. I was thinking of = client metadata (config or registration) as a way for the AS to decide = if to bind the AT to a cert. And moving from a boolean to a conf method = as an extension of that. It would be more meaningful in RS discovery, if = there was such a thing. >=20 > I don=E2=80=99t know that SHA512 would be the best choice either but = it is something that is stronger and could be included now. If there's = consensus to do more than SHA256 in this doc. =20 >=20 >=20 >=20 > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley > wrote: > Inline >=20 > Snip >=20 >>=20 >>=20 >> 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. >>=20 >> The idea behind haveing just one thumbprint hash algorithm was to = keep things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous.=20 >>=20 >> That was the thinking anyway. Maybe it is too short sighted though? >>=20 >> I do think SHA-256 should stay regardless.=20 >>=20 >> But the draft could also define SHA-512 (and maybe others). What do = you and WG folks think about that? >>=20 >> *** Yes please.=20 >>=20 >> It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server = supports. That's maybe something that should be done anyway. That'd be a = breaking change to the metadata. But there's already another potential = breaking change identified earlier in this message. So maybe it's worth = doing... >>=20 >> How do folks feel about making this kind of change?=20 >>=20 >>=20 > The confirmation method is opaque to the client. I don=E2=80=99t = think adding hash algs to discovery will really help. > The AS selection needs to be based on what the RS can support. >=20 > If anyplace it should be in RS discovery.=20 >=20 > As a practical matter you art going to find a client certificate with = more than a SHA256 hash anytime in the near future.=20 > So for a short lived access token 128bits of collision resistance is = quite good. We are going to have issues with certificates long before = this becomes a problem. >=20 > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit = RSA keys, but again that is over the long term. =20 > We are using short lived access tokens. People should rotate the = certificate more often than once a year if this is a real issue. >=20 > I am not against new hash for the fingerprint, but I also don=E2=80=99t = know that SHA512 would be the best choice if we are concerned about = quantum crypto resistance. That is a issue beyond mtls and should be = addressed by CFRG etc. >=20 > Regards > John B. >=20 >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_3160D64A-624C-42F7-B4EE-0780098777C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals. =   I am unclear on who is going to work on it in what draft.

If the client is doing = mtls to both the Token endpoint and RS the information in the = confirmation method is not relevant to the client as long as the AS and = RS are in agreement like with most tokens.

The hash on the certificate and length = of the signing key are equally or more vulnerable to any sort of = attack.
At least with AT the tokens are not long = lived.

Doing = anything better than SHA256 only makes sense if the cert is signed by = something stronger like SHA512 with a 2048bit RSA key.   That seems = sort of unlikely in the near term.  

I prefer to wait to see what general = fix is proposed before we jump the gun with a bandade for a small part = of the overall problem.

People are typically using SHA1 fingerprints.  We added = SHA256 for JWT and got push back on that as overkill. 
I don=E2=80=99t think this is the correct place to be = deciding this.   

We could say that if new thumbprints are defined the AS and = RS can decide to use them as necessary.
That is = sort of the situation we have now.

The correct solution may be a thousand = rounds of PBKDF2 or something like that to make finding collisions more = difficult rather than longer hashes.

John B.

On Apr = 12, 2018, at 5:20 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

That's true about it being opaque to the = client. I was thinking of client metadata (config or registration) as a = way for the AS to decide if to bind the AT to a cert. And moving from a = boolean to a conf method as an extension of that. It would be more = meaningful in RS discovery, if there was such a thing.

I don=E2=80=99t know that SHA512 would = be the best choice either but it is something that is stronger and could = be included now. If there's consensus to do more than SHA256 in this = doc. 



On Thu, = Apr 12, 2018 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Inline

Snip



12. The use of = only SHA-256 fingerprints means that the security strength of the = sender-constrained access tokens is limited by the collision resistance = of SHA-256 - roughly =E2=80=9C128-bit security" - without a new = specification for a new thumbprint algorithm. An implication of this is = that is is fairly pointless for the protected resource TLS stack to ever = negotiate cipher suites/keys with a higher level of security. In more = crystal ball territory, if a practical quantum computer becomes a = possibility within the lifetime of this spec, then the expected = collision resistance of SHA-256 would drop quadratically, allowing an = attacker to find a colliding certificate in ~2^64 effort. If we are = going to pick just one thumbprint hash algorithm, I would prefer we pick = SHA-512.

The idea behind haveing just one = thumbprint hash algorithm was to keep things simple. And SHA-256 seems = good enough for the reasonably foreseeable future (and space aware). = Also a new little spec to register a different hash algorithm, should = the need arise, didn't seem particularity onerous.

That was the thinking anyway. Maybe it = is too short sighted though?

I do think SHA-256 should stay regardless.

But the draft could also define SHA-512 = (and maybe others). What do you and WG folks think about that?

*** Yes please. 

It would probably then = be useful for the metadata in =C2=A73.3 and =C2=A73.4 to change from = just boolean values to something to convey what hash alg/cnf method the = client expects and the list of what the server supports. That's maybe = something that should be done anyway. That'd be a breaking change to the = metadata. But there's already another potential breaking change = identified earlier in this message. So maybe it's worth doing...

How do folks feel about = making this kind of change?


The confirmation method is opaque to = the client.  I don=E2=80=99t think adding hash algs to discovery = will really help.
The AS selection needs to be based on = what the RS can support.

If anyplace it should be in RS discovery. 

As a practical matter = you art going to find a client certificate with more than a SHA256 hash = anytime in the near future. 
So for a short = lived access token 128bits of collision resistance is quite good.   = We are going to have issues with certificates long before this becomes a = problem.

SHA256 = is appropriate for AES128 256bit elliptic curves and 3072bit RSA keys, = but again that is over the long term.  
We are = using short lived access tokens.  People should rotate the = certificate more often than once a year if this is a real = issue.

I am = not against new hash for the fingerprint, but I also don=E2=80=99t know = that SHA512 would be the best choice if we are concerned about quantum = crypto resistance.   That is a issue beyond mtls and should be = addressed by CFRG etc.

Regards
John B.




CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
= --Apple-Mail=_3160D64A-624C-42F7-B4EE-0780098777C2-- From nobody Fri Apr 13 03:49:10 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8290124319 for ; Fri, 13 Apr 2018 03:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msKUsLURkdck for ; Fri, 13 Apr 2018 03:49:05 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2261200C5 for ; Fri, 13 Apr 2018 03:49:05 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b21so3399540wme.4 for ; Fri, 13 Apr 2018 03:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gBhgFJ9tXprmSQVEKMsjOMQ/pBDU7NPtyhLLRHgSAU8=; b=LfMBTYkrGqf35/YDxtmiz1IN2qQBwIW5lAkaKa4LoN9rRlnczREQOxR79b4Y5aahlI jSwhcF5bzRk0SP6h6WGheFIMTNk8FlN8OYs1YY9DOv9naXIZ1vu6Y5zxBAYClG96MIhl jt+9cwsLAJ0U1ENxPifmXtyrcrABKnOJVaLO0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gBhgFJ9tXprmSQVEKMsjOMQ/pBDU7NPtyhLLRHgSAU8=; b=lEGD1ILxBg/LM+5JM/VWhwCi8bSFIV3vn8l0AOakAEntCuzvmkBnwSMNr7v8/OPZdW qeHEGDvYXj0bC2d926SZXKxyum0I9QSkVnQqzETw4HTaB2XKZr6CvtvYwAex6TWQCAR0 OsAVfyqB4tTdrAvFbAFRQH3W1RGhn3yc+iSaadSY4nQ6nuTP7jYswVwtbYLucfnjxMgv FU45JZoR3YJdgYcyDdHUx2zvaFS4btL8kzuxMpX2a0Sib3WgChvsg/+6+B7bxhUObTaj 5i+QmGir/HA1z44z6GbKYU0lJwyGnwbGHYf/VlzjVzODSt2L1p+Xeadz3mTZigflfjK7 cAVg== X-Gm-Message-State: ALQs6tBQh/iZVNj4KRmBnl1TZsNbuFb65+wNhJJg0HEri76yUubvoZYE O+3lILbSOp2DGxnNkhpU+24HJA== X-Google-Smtp-Source: AIpwx4/Hd0OVFX/E4NE74Q/qnx4PantJrsVmcRMHzza8PBSlDOz9+W/EXv5ECdPeiSrHrW3vl7KPAA== X-Received: by 10.28.88.195 with SMTP id m186mr3228918wmb.113.1523616543943; Fri, 13 Apr 2018 03:49:03 -0700 (PDT) Received: from guest2s-mbp.home (198.179.93.209.dyn.plus.net. [209.93.179.198]) by smtp.gmail.com with ESMTPSA id p4sm1528925wma.5.2018.04.13.03.49.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 03:49:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Neil Madden In-Reply-To: <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> Date: Fri, 13 Apr 2018 11:49:00 +0100 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> To: Brian Campbell , John Bradley X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 10:49:09 -0000 I=E2=80=99m not particularly wedded to SHA-512, just that it should be = possible to use something else. At the moment, the draft seems pretty = wedded to SHA-256. SHA-512 may be overkill, but it is fast (faster than = SHA-256 on many 64-bit machines) and provides a very wide security = margin against any future crypto advances (quantum or otherwise). I=E2=80=99= d also be happy with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems = pretty widely available.=20 I don=E2=80=99t think short-lived access tokens is a help if the = likelihood is that certs will be reused for many access tokens.=20 Public Web PKI certs tend to only use SHA-256 as it has broad support, = and I gather there were some compatibility issues with SHA-512 certs in = TLS. There are a handful of SHA-384 certs - e.g., the Comodo CA certs = for https://home.cern/ are signed with SHA-384 (although with RSA-2048, = which NSA estimates at only ~112-bit security). SHA-512 is used on some = internal networks where there is more control over components being = used, which is also where people are mostly likely to care about = security beyond 128-bit level (eg government internal networks).=20 By the way, I just mentioned quantum attacks as an example of something = that might weaken the hash in future. Obviously, quantum attacks = completely destroy RSA, ECDSA etc, so SHA-512 would not solve this on = its own, but it provides a considerable margin to hedge against future = quantum *or classical* advances while allowing the paranoid to pick a = stronger security level now. We have customers that ask for 256-bit AES = already. (I also misremembered the quantum attack - =E2=80=9CSerious = Cryptography=E2=80=9D by Aumasson tells me the best known quantum attack = against collision resistance is O(2^n/3) - so ~2^85 for SHA-256 but also = needs O(2^85) space so is impractical. I don=E2=80=99t know if that is = the last word though). =20 As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty = broken now with practical collisions having been demonstrated. The kind = of attacks on CA certs demonstrated for MD5 [1] are probably not too far = off for SHA-1 now. As far as I am aware, we=E2=80=99re nowhere near = those kinds of attacks on SHA-256, but I=E2=80=99d prefer that there was = a backup plan in place already rather than waiting to see (and waiting = for everyone to have hard-coded SHA-256 everywhere). Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 = :-) [1] http://www.win.tue.nl/hashclash/rogue-ca/ Neil On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley = wrote: The WG discusses RS meta-data as part of one of Dick=E2=80=99s = proposals. I am unclear on who is going to work on it in what draft. If the client is doing mtls to both the Token endpoint and RS the = information in the confirmation method is not relevant to the client as = long as the AS and RS are in agreement like with most tokens. The hash on the certificate and length of the signing key are equally or = more vulnerable to any sort of attack. At least with AT the tokens are not long lived. Doing anything better than SHA256 only makes sense if the cert is signed = by something stronger like SHA512 with a 2048bit RSA key. That seems = sort of unlikely in the near term. =20 I prefer to wait to see what general fix is proposed before we jump the = gun with a bandade for a small part of the overall problem. People are typically using SHA1 fingerprints. We added SHA256 for JWT = and got push back on that as overkill.=20 I don=E2=80=99t think this is the correct place to be deciding this. =20= We could say that if new thumbprints are defined the AS and RS can = decide to use them as necessary. That is sort of the situation we have now. The correct solution may be a thousand rounds of PBKDF2 or something = like that to make finding collisions more difficult rather than longer = hashes. John B. > On Apr 12, 2018, at 5:20 PM, Brian Campbell = wrote: >=20 > That's true about it being opaque to the client. I was thinking of = client metadata (config or registration) as a way for the AS to decide = if to bind the AT to a cert. And moving from a boolean to a conf method = as an extension of that. It would be more meaningful in RS discovery, if = there was such a thing. >=20 > I don=E2=80=99t know that SHA512 would be the best choice either but = it is something that is stronger and could be included now. If there's = consensus to do more than SHA256 in this doc. =20 >=20 >=20 >=20 > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley = wrote: > Inline >=20 > Snip >=20 >>=20 >>=20 >> 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. >>=20 >> The idea behind haveing just one thumbprint hash algorithm was to = keep things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous.=20 >>=20 >> That was the thinking anyway. Maybe it is too short sighted though? >>=20 >> I do think SHA-256 should stay regardless.=20 >>=20 >> But the draft could also define SHA-512 (and maybe others). What do = you and WG folks think about that? >>=20 >> *** Yes please.=20 >>=20 >> It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server = supports. That's maybe something that should be done anyway. That'd be a = breaking change to the metadata. But there's already another potential = breaking change identified earlier in this message. So maybe it's worth = doing... >>=20 >> How do folks feel about making this kind of change?=20 >>=20 >>=20 > The confirmation method is opaque to the client. I don=E2=80=99t = think adding hash algs to discovery will really help. > The AS selection needs to be based on what the RS can support. >=20 > If anyplace it should be in RS discovery.=20 >=20 > As a practical matter you art going to find a client certificate with = more than a SHA256 hash anytime in the near future.=20 > So for a short lived access token 128bits of collision resistance is = quite good. We are going to have issues with certificates long before = this becomes a problem. >=20 > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit = RSA keys, but again that is over the long term. =20 > We are using short lived access tokens. People should rotate the = certificate more often than once a year if this is a real issue. >=20 > I am not against new hash for the fingerprint, but I also don=E2=80=99t = know that SHA512 would be the best choice if we are concerned about = quantum crypto resistance. That is a issue beyond mtls and should be = addressed by CFRG etc. >=20 > Regards > John B. >=20 >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. From nobody Fri Apr 13 17:39:18 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8825126CBF for ; Fri, 13 Apr 2018 17:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8m-_PaDW2M3 for ; Fri, 13 Apr 2018 17:39:15 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1D11204DA for ; Fri, 13 Apr 2018 17:39:14 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c3-v6so9908560oib.5 for ; Fri, 13 Apr 2018 17:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=liq2MdZ5BGWMrzJbe+BAEackg8/hX/KE1gikkShTWao=; b=HHGptmK2/s5UaOD0h7REy3sJxhyy3yxCfAXOWfrXugbMsqCBbvy2Bn4dJ5cHpjvPPt ALHH3i0tGOjAx6bej8AfEgNFbGx/b2M9f173HiLNUL0llsyfd6LJCSD6nRDvpbqewTXE cEATbggOGtUcKROr8VBUekiW9cDrOt8nWe7A1mR5YIx0hYOq7fctT0cXd/Sj3xhwJwQ2 9MZCFWfjTXztX0GBUeVUcG5i69Mr1J2db2DwpLoUhqFZD4sE/S7N4axzBog6uphGg5Jx LMMHl405P+VRDnCMGSnNBmfMJxFrRHSfGr3RfrL8+taF7rjd7YPoKbfVWvfxPRq1YB4w DMCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=liq2MdZ5BGWMrzJbe+BAEackg8/hX/KE1gikkShTWao=; b=AHCOiiWF0gonbWqSyQjpX8DWZp0XfBCkm9mWdZ63Mxq9TcVrrgav0/o1dOfqt83Tzo eDNIMMLhUKvCaULp5gcfsVWE/k2EkJb0j8pxGGCi+AgVWIMM4LjJOdsxidKkt42aJB0s 9IU+9Ok2SnpHK11vwwIpdCdIyZQYCYbBt9Zbp29XaIQm3zWEkLZIs6JeX+AewtrY8/Z7 WQ70YskrirCyCwgR+WpSvvbFi6sgTaG8goYbnPqZ2BzdAKLEPOK36X6VCTwohhWNq+iN sB0eqDi+JJSfYiKA7RbYIFT19mvXJVS0SEOR098v9EJj6ZEGbzIT/v2vFhHiwWCEemdc NH1A== X-Gm-Message-State: ALQs6tAfE7PRg9kcU1Rzc+ftabyUv29QtlXvBf2/TBbeGsNtx11EgUnH jVkhmGX33j4FToGXv8/ndIFDwIeB6p5ectO1B4qybJU2Y/o= X-Google-Smtp-Source: AIpwx4+i0PYuE/255oz0xbUZilDd/rCrGTSurGRbB0fcU3DfumrrLtKtYxGzqUJaovAvA1+SO+pq5rsO2JgUCAyFrT0= X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr9272588oif.43.1523666354035; Fri, 13 Apr 2018 17:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 17:38:33 -0700 (PDT) From: Eric Rescorla Date: Fri, 13 Apr 2018 17:38:33 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9f4ab0569c4378e" Archived-At: Subject: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 00:39:17 -0000 --000000000000c9f4ab0569c4378e Content-Type: text/plain; charset="UTF-8" Hi folks, I've gone over draft-ietf-oauth-token-exchange-12 and things seem generally OK. I do still have one remaining concern, which is about the actor claim. Specifically, what is the RP supposed to do when they encounter it? This seems kind of underspecified. In particular: 1. What facts am I supposed to know here? Merely that everyone in the chain signed off on the next person in the chain acting as them? 2. Am I just supposed to pretend that the person presenting the token is the identity at the top of the chain? Say I have the delegation A -> B -> C, and there is some resource which B can access but A and C cannot, should I give access? I think the first question definitely needs an answer. The second question I guess we could make not answer, but it's pretty hard to know how to make a system with this left open. -Ekr --000000000000c9f4ab0569c4378e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I've gone over draft-ietf-oauth-token= -exchange-12 and things seem
generally OK. I do still have one remaining= concern, which is about
the actor claim. Specifically, what is the RP s= upposed to do when they
encounter it? This seems kind of underspecified.=

In particular:

1. What facts am I supposed to know here? Mer= ely that everyone in
=C2=A0=C2=A0 the chain signed off on the next perso= n in the chain acting as them?

2. Am I just supposed to pretend that= the person presenting the token
=C2=A0=C2=A0 is the identity at the top= of the chain? Say I have the
=C2=A0=C2=A0 delegation A -> B -> C,= and there is some resource which
=C2=A0=C2=A0 B can access but A and C = cannot, should I give access?

I think the first question definitely = needs an answer. The second
question I guess we could make not answer, b= ut it's pretty hard
to know how to make a system with this left open= .

-Ekr

--000000000000c9f4ab0569c4378e-- From nobody Fri Apr 13 18:00:32 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50C127201 for ; Fri, 13 Apr 2018 18:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYyyD4dYPUyJ for ; Fri, 13 Apr 2018 18:00:29 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0962A12422F for ; Fri, 13 Apr 2018 18:00:29 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id 26-v6so365542ois.9 for ; Fri, 13 Apr 2018 18:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=3jGzU/QoILD49OrL6ANPIwSSSVreAst12fjEmF11RRY=; b=OjlNoQ3Zs0KOsdn9dgvwF02zREW5LMyFKJYQgEpPs0vE+EwUUvMrAVhWBbYjDac5+l x0wiRkn+SeTPUHHhf2N+h1C4Qa9lpVs8wjUHLj8TADamDTZfF8hxyjOli9LUODP7DcVt WzMQTWYMdDWZsw305cw7v+3cECRQXzMH01hcc6s+Vt93zhaBkX16x93IFk/Jh1hSnG+t kVeh3KWyXPewnWVy+UE+e7YMQVZFzzf5PjoLjihkUo+yagPHIR7UhAksxttNH2va+cUM x+/+QYdsO2gCiciHzEkoX4HrZuHDotb5OJZ9jhkgeDWycqGekC67HmSIz6iTVLf/Gf7l OIrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3jGzU/QoILD49OrL6ANPIwSSSVreAst12fjEmF11RRY=; b=pnJKr3l/XPlJuK2EGclhQD1JGxE1jCq8tkJ6W+EiTiZMBrJANFKWrotm3bBEYsnVny 8BtXmCmJmQginOFEHqDTKg+IeemrlvvTiCRtJtokzrGQrZEH2oos3VomuA+vt/1KpLgK /HVwa7BV7HolzDySYqjUc4Pa+dl4ZpUtTtz58/51uNNhmHYyb3SxzVdLTsiv1IkuhInH WLpn7qwEjCRdDW9vvY1vXICMfaEKRqQO0cglpUtFJnBykULkXN43+B2fkAgih5EKseCD NGmCeoFbmA1OAPiA+Ec61VaeIRC6cB/Q1/arFmT2nqVxuJ0el9qye9q0TV+W202654o3 N1Wg== X-Gm-Message-State: ALQs6tCoU/3EqCeG4124wjd4zAafagBtEopelbP9g0DgHeZHLyP+YcE4 /Q6hBumpMpPutGAnexl2HhkkLAFwXhCKEj7FIcuW9ADh X-Google-Smtp-Source: AIpwx4+0Fst+JPocnLVBxz9KXnSfLiKzf3sAArdqcK3R29o8Sj4lf4nimeDUAMkFevaPwIE3hXfO2AGDqzZJEE70O7E= X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr9295439oif.43.1523667628061; Fri, 13 Apr 2018 18:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 17:59:47 -0700 (PDT) From: Eric Rescorla Date: Fri, 13 Apr 2018 17:59:47 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba00c00569c483cd" Archived-At: Subject: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 01:00:30 -0000 --000000000000ba00c00569c483cd Content-Type: text/plain; charset="UTF-8" Hi folks, I just looked at the -08 diffs and I see a new section on brute forcing the token but not describing the confused deputy attack. Did I miss something, or were you still planning to add more text? Thanks -Ekr --000000000000ba00c00569c483cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I just looked at t= he -08 diffs and I see a new section on brute forcing the token
b= ut not describing the confused deputy attack. Did I miss something, or were= you
still planning to add more text?

Th= anks
-Ekr


--000000000000ba00c00569c483cd-- From nobody Fri Apr 13 18:07:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E912422F for ; Fri, 13 Apr 2018 18:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8nxV8GuNKte for ; Fri, 13 Apr 2018 18:07:00 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E506D1204DA for ; Fri, 13 Apr 2018 18:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=njb/bUk4aGfLepVnJtISgS3O4UqgygQJ0zQCRZVhXxg=; b=jVCwb/Sp+VFneMlHJFnYGEseede7RRQihkFSF5yTXhbgchQn36x6ID2nRV/5S4P4G/xholLzpnKwFOdWlEl0LoT5RWCXYvn+l95pSBCPA5NxpdxnxeKpM0V0SW7PndCu+G0XhqJPwUiVzeVDBlZpzZDMil+uAWWCOcFFk4IMpQg= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0403.namprd00.prod.outlook.com (2603:10b6:207:1f::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.719.0; Sat, 14 Apr 2018 01:06:54 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::e0f6:c52a:b96e:a10a]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::e0f6:c52a:b96e:a10a%4]) with mapi id 15.20.0714.000; Sat, 14 Apr 2018 01:06:54 +0000 From: Mike Jones To: Eric Rescorla , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 Thread-Index: AQHT04wCwx4Q8pxqD0CRb2HM3g16k6P/coIw Date: Sat, 14 Apr 2018 01:06:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::4df] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0403; 7:WENzZpoP7DQkn2WdHlQe4DPJyzk34agmW55W8dJU5ieCq98NxVT4pR6ctnkXTcw+rZYAMypAvSpttxKGCgpVrxm8FLLJFz4PaTou/u19dzoMfxWNKiDRUdGGt4WT9WM2rDFsjv3s99KtIDiJXDOKfSIcYvxRPkVXbnseep0hKIeTzuMMF4gOhUH1VahnFK/5Z7M1sl5pdljQLL1F49/Z6dK88L/WBQXBWpEV6p1JQGz1umtS25FEveZhQuMZpklu; 20:or7My7Z4pNSy+mQc/QwwbDEq93orWJdpA4EptEJouXbfKH2NXe8jVocoP+1nfgZwbgQyCrGv89BQ/zUm7puKOfoQWh5NBNv2spbinwqpCCC5V7cAdymt/ZkJjXYgmbwN6GgcCbI0hx5vK3AL98duugSjcl3EJLDcXk2b0AOSDos= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0403; x-ms-traffictypediagnostic: BL0PR00MB0403: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231232)(944501347)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BL0PR00MB0403; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0403; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(39380400002)(396003)(376002)(199004)(189003)(476003)(5660300001)(9686003)(54896002)(55016002)(6306002)(6246003)(446003)(11346002)(186003)(99286004)(229853002)(97736004)(5250100002)(2900100001)(52396003)(7696005)(68736007)(486006)(76176011)(2501003)(53936002)(46003)(6116002)(86362001)(53546011)(790700001)(6506007)(478600001)(22452003)(8990500004)(10290500003)(102836004)(86612001)(25786009)(106356001)(14454004)(3280700002)(3660700001)(33656002)(110136005)(72206003)(6436002)(10090500001)(2906002)(105586002)(8676002)(7736002)(8936002)(74316002)(81166006)(81156014)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0403; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: n9VrObUAo1St/kCizMdqfA6PTML7NpYarze1FjddAwrjC3JxLHEw9FazV6fmcQwtxoF5AyyZr2DXwG4UwkZiZ76q6jht8ra98ymA2EIt/SVNvZUmnUiseXA04ZpEUmidSeRr2MSR+MCrc3U55iVsiS6Gcap9edUQqpLWU2vxdXedxkUnXVEyRAigIv//vcMs spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292EB90294DE62DEF6BDF43F5B20BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1d43164a-8123-4359-ccba-08d5a1a40362 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d43164a-8123-4359-ccba-08d5a1a40362 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2018 01:06:54.4056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0403 Archived-At: Subject: Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 01:07:02 -0000 --_000_BL0PR00MB0292EB90294DE62DEF6BDF43F5B20BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugc3RpbGwgbmVlZCB0byBhZGQgdGhlIHRleHQgYWRkcmVzc2luZyB0aGUgcG9pbnRzIGRlc2Ny aWJlZCBpbiBKb2huIEJyYWRsZXnigJlzIHJlcGx5IHRvIHlvdSBzZW50IHdoaWxlIGluIExvbmRv bi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4IDY6MDAg UE0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBGb2xsb3cgdXAgb24g ZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wOA0KDQpIaSBmb2xrcywNCg0KSSBqdXN0IGxv b2tlZCBhdCB0aGUgLTA4IGRpZmZzIGFuZCBJIHNlZSBhIG5ldyBzZWN0aW9uIG9uIGJydXRlIGZv cmNpbmcgdGhlIHRva2VuDQpidXQgbm90IGRlc2NyaWJpbmcgdGhlIGNvbmZ1c2VkIGRlcHV0eSBh dHRhY2suIERpZCBJIG1pc3Mgc29tZXRoaW5nLCBvciB3ZXJlIHlvdQ0Kc3RpbGwgcGxhbm5pbmcg dG8gYWRkIG1vcmUgdGV4dD8NCg0KVGhhbmtzDQotRWtyDQoNCg0K --_000_BL0PR00MB0292EB90294DE62DEF6BDF43F5B20BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XZSBzdGlsbCBuZWVkIHRvIGFkZCB0aGUg dGV4dCBhZGRyZXNzaW5nIHRoZSBwb2ludHMgZGVzY3JpYmVkIGluIEpvaG4gQnJhZGxleeKAmXMg cmVwbHkgdG8geW91IHNlbnQgd2hpbGUgaW4gTG9uZG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYu b3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4IDY6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gRm9sbG93IHVwIG9uIGRy YWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBqdXN0IGxvb2tlZCBhdCB0aGUgLTA4IGRpZmZzIGFuZCBJIHNl ZSBhIG5ldyBzZWN0aW9uIG9uIGJydXRlIGZvcmNpbmcgdGhlIHRva2VuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgbm90IGRlc2NyaWJpbmcg dGhlIGNvbmZ1c2VkIGRlcHV0eSBhdHRhY2suIERpZCBJIG1pc3Mgc29tZXRoaW5nLCBvciB3ZXJl IHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ c3RpbGwgcGxhbm5pbmcgdG8gYWRkIG1vcmUgdGV4dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR00MB0292EB90294DE62DEF6BDF43F5B20BL0PR00MB0292namp_-- From nobody Fri Apr 13 19:38:09 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAAA120713 for ; Fri, 13 Apr 2018 19:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouScrO5HHES0 for ; Fri, 13 Apr 2018 19:38:05 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E89712D7E8 for ; Fri, 13 Apr 2018 19:38:05 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id y46-v6so11915235otd.4 for ; Fri, 13 Apr 2018 19:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PIAfwiKbY7Qz5/ggf5F6C5Sy1RZq6PP5mzKpCLO/ii0=; b=EoL0EJ5WeaxAhaCUfanPKqq5idDRAaWyo63lk2yImGDUth3MqQvYi+VtlzUyaGLM2d 6aR5U4eHo9cSspuHG5RmrQP60UyvRBM/8CYGyVzAjaWJcsw9ETZXajH+16Kss2KE/mSe itd7T5XL5I0rbgKWPuKV/HByTQetFIODnBhIoSGAiMgZE0W9menNzkhHr3J0nd3BzeP+ NjPWV8VeisUvLe5xTEqUl08hl7u1dEe4CDBxqrwWCo9v0/SpSbpU/emVu8Ut/hhoHGjk XIOyHc6xbJp1HAMwQWwJ0Nx/mym6fnTXuR+aWUJ9bP61eCtNC2lhuXQYDg9ENnViTzda AfxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PIAfwiKbY7Qz5/ggf5F6C5Sy1RZq6PP5mzKpCLO/ii0=; b=S6Lu5oyC+MlN4DYCKJghDRhZTrKMrglC2ssmsEj1LcYWa5dFj5T2cE5GbbB9Gpgu/b jxH4yx6NVZL61PhMRL8PaVl3AzzwrIyQZvK9vigFH2Gl2QMXmqulDywjERO9WSzF+YOQ qeElG3tbDum88kW9NumiH/esaNdyQV1fsYE6GuoPuvBmyN3zOxbud1MnQRrXu6khUeFf xj8YC5d9q1DaPgkgWDASlw4xtrUDffGZ3b+l1iVZDinKvnHwbsfzvM2dZe+M8pc3yCnU HkD1nVg3caQjZh0VBqR7GlkV7P2JlpVflSkkhikXpGw5qbzZpCiemNcyx5ChGqzDt7Ta Z1Bw== X-Gm-Message-State: ALQs6tCzvdrhLW4SquUIrMQtnwz71jxRTBSvnUDFlHREyBUIaAsACWmm 23ebGvsToZ26v6YvQHfdm0d5Y2tpmFcYknt/mCYZqA== X-Google-Smtp-Source: AIpwx4+zRTWTL60j1pNtBdN+n7HwNLHV+WgsQx5jfwVBZMUn1ysBXaFK6JjstMyQngq1giDM/ULiqYO1VJrRTSnyrFo= X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr1689943oth.217.1523673484463; Fri, 13 Apr 2018 19:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 13 Apr 2018 19:37:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 13 Apr 2018 19:37:24 -0700 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cba5340569c5e0da" Archived-At: Subject: Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 02:38:07 -0000 --000000000000cba5340569c5e0da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the quick followup. I will take a look at the next version -Ekr On Fri, Apr 13, 2018 at 6:06 PM, Mike Jones wrote: > We still need to add the text addressing the points described in John > Bradley=E2=80=99s reply to you sent while in London. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Eric Rescorla > *Sent:* Friday, April 13, 2018 6:00 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 > > > > Hi folks, > > > > I just looked at the -08 diffs and I see a new section on brute forcing > the token > > but not describing the confused deputy attack. Did I miss something, or > were you > > still planning to add more text? > > > > Thanks > > -Ekr > > > > > --000000000000cba5340569c5e0da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick followup. I will take a look at = the next version

-Ekr


On Fri, Apr 13, 201= 8 at 6:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We still need to add t= he text addressing the points described in John Bradley=E2=80=99s reply to = you sent while in London.

=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= =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=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=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Eric Rescorla
Sent: Friday, April 13, 2018 6:00 PM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-0= 8

=C2=A0

Hi folks,

=C2=A0

I just looked at the -08 diffs and I see a new secti= on on brute forcing the token

but not describing the confused deputy attack. Did I= miss something, or were you

still planning to add more text?

=C2=A0

Thanks

-Ekr

=C2=A0

=C2=A0


--000000000000cba5340569c5e0da-- From nobody Sun Apr 15 09:43:11 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E416124BE8 for ; Sun, 15 Apr 2018 09:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p55SLnzF7tSf for ; Sun, 15 Apr 2018 09:43:08 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D3F12426E for ; Sun, 15 Apr 2018 09:43:07 -0700 (PDT) Received: from [79.253.45.21] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f7kk4-0000oL-Sh for oauth@ietf.org; Sun, 15 Apr 2018 18:43:04 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_A3E6F0DD-257B-4347-8E1E-076EE8E5FB81"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Sun, 15 Apr 2018 18:43:03 +0200 To: oauth X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 16:43:10 -0000 --Apple-Mail=_A3E6F0DD-257B-4347-8E1E-076EE8E5FB81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a = claim =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC = 7662 use a claim =E2=80=9Escope=E2=80=9C for the same purpose. As far as = I understand the text, the intension is to represent a list of RFC6749 = scopes. Is this correct? What=E2=80=99s the rationale behind? Different claim names for representing scope values confuse people. I = realized that when one of our developers pointed out that difference = recently.=20 best regards, Torsten.= --Apple-Mail=_A3E6F0DD-257B-4347-8E1E-076EE8E5FB81 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNDE1MTY0MzA0WjAjBgkqhkiG9w0BCQQxFgQUB/RcugoMOeyl vMhIa1X+pL1PpBEwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAH7d8JQ17AAFjh2dvai6IlsuqeVYOwxSJWK7G4tMeq5A+W/3ufZU TmR4bpTtOa5a9EWK54G2m8I+VT9BbqH1DIvGf0uT+mbSLlmqHM70PKc8orrr86cndxSlUz3grZ2g ObBAE9cemwIydNcAad7JFBBAnVSIp8yfUEfMz2vyxG3tA+Oe55b8cs2bfFe07M8lFTytnNk6SGXY zOhz7mMb9t0nmrzyvPm4MATLwlkEPr7A1uokbdfbixfhzr2LC1DchgX5ZcXzIXrKiYVAX+dj5QJ/ 8kS7Od7LrTa+S8r8hZgFPFEUEKJhmdJdHr5obDLIv+lUtG9kcSPHrf6C1MGTLA4AAAAAAAA= --Apple-Mail=_A3E6F0DD-257B-4347-8E1E-076EE8E5FB81-- From nobody Sun Apr 15 09:44:56 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32C9124BE8 for ; Sun, 15 Apr 2018 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO_h8o9J2juN for ; Sun, 15 Apr 2018 09:44:52 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEC212426E for ; Sun, 15 Apr 2018 09:44:51 -0700 (PDT) Received: from [79.253.45.21] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f7klk-0005EE-Hu; Sun, 15 Apr 2018 18:44:48 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B397B9C5-CD6F-4A66-B693-6693477CDBB3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 15 Apr 2018 18:44:45 +0200 In-Reply-To: <261C62EA-2327-4EF5-8585-542AA7672893@oracle.com> Cc: OAuth WG To: Phil Hunt References: <261C62EA-2327-4EF5-8585-542AA7672893@oracle.com> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 16:44:55 -0000 --Apple-Mail=_B397B9C5-CD6F-4A66-B693-6693477CDBB3 Content-Type: multipart/alternative; boundary="Apple-Mail=_CA71914E-0901-4C62-B445-5B14EFAF422A" --Apple-Mail=_CA71914E-0901-4C62-B445-5B14EFAF422A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Phil,=20 thanks for reviewing it. We incorporated the respective changes in the = upcoming -06.=20 best regards, Torsten.=20 > Am 22.03.2018 um 10:52 schrieb Phil Hunt : >=20 > Torsten, >=20 > Great document! >=20 > Some minor nits and comments: >=20 > Abstract - double period after first sentence. >=20 >> It updates and extends the OAuth 2.0 Security Threat Model to >> incorporate practical experiences gathered since OAuth 2.0 was >> published and cover new threats relevant due to the broader >> application of OAuth 2.0. >=20 > When I first read, it sounds like this is a replacement for the threat = model or at least could be read that way. I think you mean readers still = need to read 6819. How about... >=20 > "This specification uses the OAuth 2.0 Security Threat Model and = supplements it to incorporate practical experiences gathered"... >=20 > Section 1. >=20 > The paragraph starting =E2=80=9COAuth initially assumed a static=E2=80=A6= =E2=80=9D appears to continue the previous bullet point. Should the = paragraph be indented? >=20 > Last paragraph 3.1.1 >> This kind of injections is covered in >> Section Code Injection. >=20 > Should this say Section 3.5? >=20 > Section 3.1.5 > This paragraph seems unfinished... >>=20 >> Question: Does redirect uri validation solve any problem for >> native apps? Effective against impersonation when used in >> conjunction with claimed HTTPS redirect URIs only. >> For Windows token broker exact redirect URI matching is = important >> as the redirect URI encodes the app identity. For custom = scheme >> redirects there is a question however it is probably a useful = part >> of defense in depth. >=20 > Section 3.4 >> AS returns client_id and its iss in the response. Client compares >> this data to AS it believed it sent the user agent to. > =E2=80=9Cclient_id=E2=80=9D and =E2=80=9Ciss=E2=80=9D attributes do = not appear to have any marking () = in multiple locations in the document. >=20 > Section 3.5 >> How does an attack look like? > How about: > "An attack looks like:=E2=80=9D >=20 > Writing style of the following comment seems like an editors note = rather than a comment for the reader. Rephrase? >=20 >> But this approach conflicts with the idea to enforce exact = redirect >> URI matching at the authorization endpoint. Moreover, it has been >> observed that providers very often ignore the redirect_uri check >> requirement at this stage, maybe, because it doesn't seem to be >> security-critical from reading the spec. >=20 > Is this appropriate for a BCP (seems like a WG discussion item)? >> The authors therefore propose to the working group to drop this >> feature in favor of more effective and (hopefully) simpler = approaches >> to code injection prevention as described in the following = section. >=20 > Section 3.5.1 >=20 > This seems a bit tentatively worded=E2=80=A6 >> PKCE seem to be the most obvious solution for OAuth clients as it >> available and effectively used today for similar purposes for = OAuth >> native apps whereas "nonce" is appropriate for OpenId Connect >> clients. >=20 > Formatting problem (missing line between paragraphs)? >> Note on pre-warmed secrets: An attacker can circumvent the >> countermeasures described above if he is able to create or capture >> the respective secret or code_challenge on a device under his >> control, which is then used in the victim's authorization request. >> Exact redirect URI matching of authorization requests can prevent = the >> attacker from using the pre-warmed secret in the faked = authorization >> transaction on the victim's device. >> Unfortunately it does not work for all kinds of OAuth clients. It = is >> effective for web and JS apps and for native apps with claimed = URLs. >> Attacks on native apps using custom schemes or redirect URIs on >> localhost cannot be prevented this way, except if the AS enforces >> one-time use for PKCE verifier or Nonce values. >=20 >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@oracle.com = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CA71914E-0901-4C62-B445-5B14EFAF422A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Phil, 

thanks = for reviewing it. We incorporated the respective changes in the upcoming = -06. 

best = regards,
Torsten. 

Am = 22.03.2018 um 10:52 schrieb Phil Hunt <phil.hunt@oracle.com>:

Torsten,

Great = document!

Some = minor nits and comments:

Abstract - double period after first sentence.

It updates and extends the OAuth =
2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and cover new threats relevant due to the broader
   application of OAuth 2.0.

When I first read, it sounds like = this is a replacement for the threat model or at least could be read = that way. I think you mean readers still need to read 6819. How = about...

"This = specification uses the OAuth 2.0 Security Threat Model and supplements = it to incorporate practical experiences gathered"...

Section 1.

The paragraph starting = =E2=80=9COAuth initially assumed a static=E2=80=A6=E2=80=9D appears to = continue the previous bullet point.  Should the paragraph be = indented?

Last = paragraph 3.1.1
This kind of injections is covered in
   Section Code Injection.

Should this say Section = 3.5?

Section = 3.1.5
This paragraph seems unfinished...

 Question: Does redirect =
uri validation solve any problem for
      native apps?  Effective against impersonation when used in
      conjunction with claimed HTTPS redirect URIs only.
      For Windows token broker exact redirect URI matching is important
      as the redirect URI encodes the app identity.  For custom scheme
      redirects there is a question however it is probably a useful part
      of defense in depth.

Section 3.4
AS returns client_id and its =
iss in the response.  Client compares
      this data to AS it believed it sent the user agent =
to.
=E2=80=9Cclient_id=E2=80=9D and = =E2=80=9Ciss=E2=80=9D attributes do not appear to have any marking = (<spanx style=3D=E2=80=9Cverb=E2=80=9D>) in multiple locations in = the document.

Section 3.5
How does an attack look like?
How= about:
"An attack looks like:=E2=80=9D

Writing style of the = following comment seems like an editors note rather than a comment for = the reader.  Rephrase?

   But this approach conflicts =
with the idea to enforce exact redirect
   URI matching at the authorization endpoint.  Moreover, it has been
   observed that providers very often ignore the redirect_uri check
   requirement at this stage, maybe, because it doesn't seem to be
   security-critical from reading the spec.

Is this = appropriate for a BCP (seems like a WG discussion item)?
   The authors therefore =
propose to the working group to drop this
   feature in favor of more effective and (hopefully) simpler approaches
   to code injection prevention as described in the following =
section.

Section 3.5.1

This seems a bit tentatively worded=E2=80=A6
   PKCE seem to be the most =
obvious solution for OAuth clients as it
   available and effectively used today for similar purposes for OAuth
   native apps whereas "nonce" is appropriate for OpenId Connect
   clients.

Formatting problem (missing line = between paragraphs)?
   Note on pre-warmed secrets: An attacker can circumvent the
   countermeasures described above if he is able to create or capture
   the respective secret or code_challenge on a device under his
   control, which is then used in the victim's authorization request.
   Exact redirect URI matching of authorization requests can prevent the
   attacker from using the pre-warmed secret in the faked authorization
   transaction on the victim's device.
   Unfortunately it does not work for all kinds of OAuth clients.  It is
   effective for web and JS apps and for native apps with claimed URLs.
   Attacks on native apps using custom schemes or redirect URIs on
   localhost cannot be prevented this way, except if the AS enforces
   one-time use for PKCE verifier or Nonce values.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

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

= --Apple-Mail=_CA71914E-0901-4C62-B445-5B14EFAF422A-- --Apple-Mail=_B397B9C5-CD6F-4A66-B693-6693477CDBB3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNDE1MTY0NDQ2WjAjBgkqhkiG9w0BCQQxFgQUlJjuYc5S/U86 Sd2b96WSrDW2ZtYwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBADGNjli8kf4iNOcyGrwUt0TBH3pqCsDDtun7O5eGBPGHuu+MsX8O B+iE7TqfBJeQLM06j79EMT7sp1LxuXyorHE3rILD5nTxJl1pfYZN9vDFso3KWWzf89/YtzpF+n00 8zID/PJ7cLxsH+WfK579Gslk9MCYLQBca4rfg1HNg7BKL+6UJdPU0hyhipDectdwAdGt1P3LOs5M gqNk5DftK2DEl4+OJ1hDQHlHXzHPLiXbTTV19peSeC0Eor2wxeJdXtZul4K4CdgzfUq5fr+MuXKi g2uyS7CNW2e7H/0hBgQSjZOjT5tu8x7icd336Lulz36L++X+xR+uGxd8yNAcpWsAAAAAAAA= --Apple-Mail=_B397B9C5-CD6F-4A66-B693-6693477CDBB3-- From nobody Mon Apr 16 07:47:37 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7A12DA26 for ; Mon, 16 Apr 2018 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-IWcMoqoXpQ for ; Mon, 16 Apr 2018 07:47:34 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0891B12DA02 for ; Mon, 16 Apr 2018 07:47:34 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id q26so10263600uab.0 for ; Mon, 16 Apr 2018 07:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yxtweQseNoIElnkG7XH6YF0NrlKFEMBJUEBfxQPLL4o=; b=hpfbFoNt5TpGz2GnlknbFqaJ+E3/GacX7IVqDZBQtbolXkyWgCWp5xmH/Tlziuwfx4 wQ/NVNOoIzOvil+uxTSz0H5rjxBs6ekqcAd1uTBfB+TaIyBshEt3SnsqJqyVCBnNZiag Rk6NCsY4B6aHcw+7QJUi7s9oCYPJ2zvbBx4c/hshQD+WDFk/n7RerU4QCcVtKUR1ilH3 W+bynrjtwUmwt0VfAaoepDVAUT/rBOhAwP8tmAe/ImW9O/ZgxeRypHUJ7GscU+WRs4GJ cX6WOQDAaMIQzTjD3qnrYPGS2M7R2tog06OIz1PIfkks5wBhwy1kpkcfD9sPPVlVF1tE MfDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yxtweQseNoIElnkG7XH6YF0NrlKFEMBJUEBfxQPLL4o=; b=pt87vADcrFGxZAaV45wzDuod2xZeck/I0T6h0djNjBDqytAN5c5vL0FXzgnOKdwQZJ OVSj6JMwpBnDVVN72BWjIaRRNcSTwbE05767r+KLOnocnbDDUKL4c4vhf3qBUR9u7zlr Hten6ajncsw5yjA2NUncxv5ChF/6BTn5OZbDr32sj2+5oxauY1HPdvc2r15G1nFS+jTi TQBcT2Em0cA6pI10XdZhyIY777e9aDhHb352eTY1cP9FIeTiVe8SkjofNSQz6UsNZdh2 CqiMTzmGLi3I14+v0SgnSNXEoOxf8jkl0+J8VePqlZDgjigIb0hzvANdTnSKwgb+I5jo pH1g== X-Gm-Message-State: ALQs6tB2i8zAu3nIGnKzF9yfin2951u5KBjYhtOSuxXdDgTIDQuOXwnX HYjwtrhXwlBbRvn6XG3GnGZJ2LuS+oQ2NEKDGLpSnw== X-Google-Smtp-Source: AIpwx49QXlFt8zwNEWbUicdaz+bXmWpP65keA+wKyTthjYsheo7oXgsB3I1LOR7O4f5pjZ1/CUqJdyoh0+YxVre3KIE= X-Received: by 10.176.7.153 with SMTP id c25mr11593205uaf.194.1523890052899; Mon, 16 Apr 2018 07:47:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.44.154 with HTTP; Mon, 16 Apr 2018 07:47:32 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 16 Apr 2018 10:47:32 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="f403045f8a3c47aa960569f84d76" Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:47:36 -0000 --f403045f8a3c47aa960569f84d76 Content-Type: text/plain; charset="UTF-8" All, We would like to get a confirmation on the mailing list for the adoption of the *OAuth 2.0 Incremental Authorization* as a WG document https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ Please, let us know if you support or object to the adoption of this document. Regards, Rifaat & Hannes --f403045f8a3c47aa960569f84d76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --f4f5e807c0584e82fa056a04ae11-- From nobody Tue Apr 17 02:48:19 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F067126DD9 for ; Tue, 17 Apr 2018 02:48:17 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46cP2M67MgqD for ; Tue, 17 Apr 2018 02:48:09 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CE1126BF0 for ; Tue, 17 Apr 2018 02:48:08 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id d19so33680075wre.1 for ; Tue, 17 Apr 2018 02:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PVVyFWwk5FDNsBhyKjanVVECANdRD1DAbXrU0iQlVVA=; b=Dw/6xwrwajp7iUqXC+yn36HCtjYRDgPqveDw1cb6d+8Yc6mMqBU0HNsL1Pj71suIp1 KkryTRwYVOf2dkbWBjWdz+tHKlCIu6Uc9JY5n6ycGeJwf8HdyRnfFbRMlsaeiWk20XhF 5awvBFM9N0GSFL+UHidryWBnl283ZgThpJRQI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PVVyFWwk5FDNsBhyKjanVVECANdRD1DAbXrU0iQlVVA=; b=bUMVYtKzhoT8H/WuslNWgesH9MPsJPdK+nJLTfQABhj4+w8hL8v1bRxW8VkXTY6wHM VJyW4e4qGBBtfuTclyXJxZ0i7KS9NpowoGwkfDsqQkAV3g0bTrbXszCxO16uzjmzBon9 w0Zf0EPcJParyzTbZbogFvxGPUOEp81wj35HHAQJByveiWxtaESYK/RbQgLgl77JyxrV WqgsbUmEmDqNPvFFFQYpVAU+Qupwa+RqgXjhHp/nUJ2YmbaCwJcdrXBOHfFaIu+e8gzD U64YlsCSqrt+1Z6ayqNha8qijapobY9fatNjCDcMBKtMX79+W7R8khVluPJmYievfJRS 7Sxw== X-Gm-Message-State: ALQs6tAxsmKgtFzxvm+A1OKVdDrR/lJmnhvzpnHsUh4PDpitTn5gQZoo yj0x31y8UE3iwkgTKmmOCLgnBA== X-Google-Smtp-Source: AIpwx4/GgIDlsua9tyurQwWfgKVJ6yHwZqQNJvhASe1trCqvBQxk/OPeH+ohZepaqbYRQ/g0g7E87g== X-Received: by 10.223.156.145 with SMTP id d17mr1099809wre.175.1523958486794; Tue, 17 Apr 2018 02:48:06 -0700 (PDT) Received: from guest2s-mbp.home (198.179.93.209.dyn.plus.net. [209.93.179.198]) by smtp.gmail.com with ESMTPSA id w6sm1315014wra.84.2018.04.17.02.48.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 02:48:06 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_76E9275D-3E86-4FF5-8BDA-A0CB9AB5AD1B" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Apr 2018 10:48:04 +0100 In-Reply-To: Cc: oauth , Rifaat Shekh-Yusef To: Brian Campbell References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 09:48:17 -0000 --Apple-Mail=_76E9275D-3E86-4FF5-8BDA-A0CB9AB5AD1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK, here=E2=80=99s a stab at a new security considerations section on = X.509 parsing and validation: --- 5.3 X.509 Certificate Parsing and Validation Complexity Parsing and validation of X.509 certificates and certificate chains is = complex and implementation mistakes have previously exposed security = vulnerabilities. Complexities of validation include (but are not limited = to) [1][2][3]: - checking of Basic Constraints, basic and extended Key Usage = constraints, validity periods, and critical extensions; - handling of null-terminator bytes and non-canonical string = representations in subject names; - handling of wildcard patterns in subject names; - recursive verification of certificate chains and checking certificate = revocation. For these reasons, implementors SHOULD use an established and = well-tested TLS library for validation of X.509 certificate chains and = SHOULD NOT attempt to write their own X.509 certificate validation = procedures. [1] = https://www.cryptologie.net/article/374/common-x509-certificate-validation= creation-pitfalls/ = [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf = [3] https://tools.ietf.org/html/rfc5280 = =20 --- NB - this blog post [1] is the best concise summary of attacks I could = find. Most of these attacks have been published as Black Hat talks and I = can=E2=80=99t seem to find definitive references or good survey papers = (beyond [2], which is a little older). Let me know what you think, Neil > On 12 Apr 2018, at 20:42, Brian Campbell = wrote: >=20 > Thanks Neil.=20 >=20 > Other than the potential metadata changes, which I'd like more WG = input on and may raise in a new thread, I think I've got enough to make = updates addressing your comments. But please do send text for that = Security Considerations bit, if you come up with something. =20 >=20 > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden = > wrote: > Hi Brian, >=20 > Thanks for the detailed responses. Comments in line below (marked with = ***). >=20 > Neil >=20 > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell = > wrote: > Thanks for the review and feedback, Neil. I apologize for my being = slow to respond. As I said to Justin recently = ,= I've been away from things for a while. Also there's a lot here to get = through so took me some time.=20 >=20 > It looks like John touched on some of your comments but not all. I'll = try and reply to them as best I can inline below.=20 >=20 >=20 > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden = > wrote: > Hi, >=20 > I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc). >=20 > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes: >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D } } >=20 > but you can already do: >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 = , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } >=20 > If the intent is just to save some space and avoid the mandatory = fields of the existing JWK types, maybe this would be better addressed = by defining a new JWK type which only has a thumbprint? e.g., { = =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D }. >=20 > The intent of the x5t#S256 confirmation method was to be space = efficient and straightforward while utilizing the framework and registry = that RFC 7800 gives. Even a new JWK type like that would still use more = space. And I'd argue that the new confirmation method is considerably = more straightforward than registering a new JWK type (and the = implications that would have on JWK implementations in general) in order = to use the existing "jwk" confirmation method. =20 >=20 > *** > OK, that is reasonable. Given that the draft says SHOULD rather than = MUST for using this confirmation key method, I think it is currently = allowed to use either representation.=20 >=20 > =20 >=20 > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client = authentication that we are interested here, and the fact that the server = also authenticates with a certificate is not hugely relevant to this = particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types = (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-3 = ). I=E2=80=99d prefer that = the draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1 = ) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99. >=20 > This is especially confusing in section 3 on sender constrained access = tokens, as there are two different servers involved: the AS and the = protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D = authentication between them, only between each of them and the client. >=20 > Choosing names and terminology is difficult and the "right" wording is = often subjective. I believe that the current wording sufficiently = conveys what is going on in the draft to most readers. Most readers thus = far seem to agree. There is some text now that does say that the mutual = auth in the draft is in fact X.509 client cert authn but, in the next = revision, I'll look for other opportunities where it could be stated = more clearly.=20 >=20 > *** Thanks.=20 >=20 > =20 >=20 > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 = RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? = The wording in Section 5.1 doesn=E2=80=99t seem clear if this could also = be used with TLS 1.0 or 1.1, or whether it is only referring to future = TLS versions. >=20 > The reference to BCP 195 (which unfortunately the original OAuth 2.0 = RFC doesn't have because it didn't exist then) is meant to account for = changing versions and recommendations around TLS. Currently that BCP = says TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't = outright prohibit them.=20 >=20 > *** OK, that seems good to me.=20 >=20 > =20 >=20 > 4. It might be useful to have a discussion for implementors of whether = TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the use of client certificates, if at all? >=20 > That might well be useful but I don't myself know what it would say. = I've (maybe naively) figured those are deployment details that will just = work out. Perhaps you could propose some text around such a discussion = that the WG could consider?=20 >=20 > *** > To be honest, when I raised this it was because I didn=E2=80=99t = really know what the implications were. I=E2=80=99ve done some reading = around and I think it should all just work - both session resumption and = PSK-based resumption preserve the original client and server = authentication context so we can assume that any presented client cert = is still valid for the resumed session. So I think we can leave out any = discussion of this and assume it works as expected.=20 >=20 >=20 >=20 > 5. Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2 = ). The draft should decide which of those it is implementing and if = sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so = should drop the language about sender constrained tokens). >=20 > I will say again that choosing names and terminology is difficult... >=20 > Although I must admit that I started using "sender constrained" = somewhat indiscriminately at first and it's just sort of stuck. At the = time I was trying to incorporate bits of draft-sakimura-oauth-jpop in a = way that might help bring on and keep the authors of that draft onboard = with this mtls draft. In retrospect it looks like I did that part wrong = anyway. But that was the thinking at the time and the history, for = whatever it's worth. More recently, Nat was requesting that "sender = constrained" be included in the title. So there's that too. =20 >=20 > In defense of my mistake, however, if there's a line between "sender = constrained" and "key confirmation" tokens, it's a bit of a fuzzy line. = And I'd argue that what this draft is doing pretty close to the line.=20 >=20 > But ultimately I think you are right that what this mtls draft is = doing with access tokens is more accurately described with the key = confirmation term.=20 >=20 > So, yes, the draft should probably drop (or at least minimize) the = language about sender constrained. I'll do that in the next draft = version, barring big objections from the WG. >=20 > The tricky thing with making that change is that there a client and = server metadata parameters with the name = "mutual_tls_sender_constrained_access_tokens" that should probably also = change. But that would be a breaking change (of sorts anyway), which = shouldn't be taken lightly at this stage. I feel that some explicit = okays from the WG are needed before doing so (rough consensus stye) . = Any WG members want to weigh in here and help get a "sense of the group" = concerning changing those metadata names?=20 >=20 > *** Thanks. I agree this might cause compatibility issues. It is not a = big issue for us, but might cause some confusion.=20 >=20 > =20 >=20 > 6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5 = ): >=20 > Strong, fresh session keys: >=20 > Session keys MUST be strong and fresh. Each session = deserves an > independent session key, i.e., one that is generated = specifically > for the intended use. In context of OAuth this means = that keying > material is created in such a way that can only be = used by the > combination of a client instance, protected resource, = and > authorization scope. >=20 >=20 > However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3 = ) says: >=20 > The client makes protected resource requests as described in > [RFC6750], however, those requests MUST be made over a = mutually > authenticated TLS connection using the same certificate that = was used > for mutual TLS at the token endpoint. >=20 > These two statements are contradictory: the OAuth 2.0 PoP architecture = effectively requires a fresh key-pair to be used for every access token = request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server. >=20 > In the self-signed case (and even in the CA case, with a bit of work - = e.g., https://www.vaultproject.io/docs/secrets/pki/index.html = ) it is = perfectly possible for the client to generate a fresh key-pair for each = access token and include the certificate on the token request (e.g., as = per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#secti= on-5.1 = - in which case an appropriate =E2=80=9Calg=E2=80=9D value = should probably be described). This should probably at least be an = option. >=20 > This draft doesn't necessarily seek to align with the (long expired) = PoP architecture draft. Rather it is aiming to provide a pragmatic = solution for PoP style access tokens and OAuth client auth using mTLS = client certificates.=20 >=20 > That said, with the current draft, it's certainly possible for a = client to update its cert more frequently, even so far as using a new = one for each access token. The details of how that would work will vary = some based on the token endpoint authentication method. But it's not = precluded.=20 >=20 > *** You are right, the text doesn=E2=80=99t preclude that. I am happy = with that solution. I suspect most people will deploy and be happy with = reusing a long-lived cert for every access token, so this may not matter = in practice.=20 > =20 >=20 > 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it = allows correlation of activity. >=20 > Practically speaking the access tokens being presented likely already = have correlatable info in them about the client as well as the user. I = don't know that there's much of a (new) concern in reality. If you feel = this concern is unique and import enough though, perhaps there's some = text you'd like to propose for a Privacy Considerations section that the = WG could consider? I mean, I guess it doesn't hurt to mention it but I = would like to avoid overstating the issue. =20 >=20 > *** On reflection, I am going to withdraw this comment. As you say = there are other ways to correlate clients. The privacy issue would = mainly arise in the context of dynamic client registration e.g., a = pattern I=E2=80=99ve seen described where every instance of a mobile app = does dynamic client registration to avoid including credentials directly = in the app bundle. This would make clients one-to-one with users. But = (a) those apps are fairly unlikely to be using TLS certs, and (b) that = is more of a privacy consideration for dynamic client registration = rather than this draft.=20 >=20 > =20 >=20 > 8. This is maybe a more general point, but RFC 6750 defines the = Authorization: Bearer scheme = (https://tools.ietf.org/html/rfc6750#section-2 = ) for a client to = communicate it=E2=80=99s access token to the RS in a standard way. As = sender-constrained access tokens are not strictly bearer tokens any = more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme? >=20 > The thinking and general consensus (in this draft as well as the OAuth = token binding work) has been that continuing to use the RFC 6750 scheme = while putting the "not strictly bearer" stuff in (or referenced by) the = token itself will be easier on deployment and implementation. And better = for adoption as a result. I believe some early implementation work has = borne that out too.=20 >=20 > *** OK.=20 >=20 >=20 > 9. The Security Considerations should really make some mention of the = long history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation. >=20 > Suggesting to use an existing TLS library is certainly sound advice = and I sort of felt is implied in the draft. But saying so more = strongly/explicitly might be worthwhile. And pointing to historical = reasons to do so would probably be good too. Could you propose a new = Security Considerations section or maybe augmentation of =C2=A75.2 with = that content?=20 >=20 > *** I=E2=80=99ll try and come up with some text.=20 >=20 > =20 >=20 > 10. The PKI client authentication method = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 = ) = makes no mention at all of certificate revocation and how to handle = checking for that (CRLs, OCSP - with stapling?). Neither does the = Security Considerations. If this is a detail to be agreed between then = AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with = some of these mechanisms, as OCSP requests are typically sent in the = clear (plain HTTP) and so allow an observer to see which clients are = connecting to which AS. >=20 > I didn't think that a TLS client could do OCSP stapling? >=20 > *** I think you are right about this. I always assumed it was = symmetric (and I think it technically could work), but the spec only = talks about stapling in the server-side of the handshake.=20 >=20 > That aside, revocation checking (how and even if) is something that's = at the discretion of the AS. I can add something in =C2=A72.1 to say = that more explicitly.=20 >=20 > *** Thanks.=20 >=20 >=20 >=20 > 11. The same comment applies to how the protected resource checks for = revocation of the certificate presented during sender constrained access = token usage. Should the RS make its own revocation checks based on the = information in the certificate presented, or should it trust the = certificate while the access token is still valid? If the latter case, = is the AS responsible for revoking any access tokens whose certificate = have been revoked (if so, should it be doing an OCSP call on every token = introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling = ) how can the RS verify the = signature on that if it does not have a separate trust relationship with = the CA already? >=20 > The draft effectively uses cert mtls at the RS as a = proof-of-possession method only and not as authentication. So revocation = checking isn't really applicable. In specific deployment situations, I = suppose an RS could check revocation. But that'd be a deployment = decision for the RS that's beyond the scope of this draft.=20 >=20 > *** OK, that is an interesting observation. If either the client or AS = suspect the key has been compromised they can revoke the access token(s) = instead.=20 > =20 >=20 >=20 > 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. >=20 > The idea behind haveing just one thumbprint hash algorithm was to keep = things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous.=20 >=20 > That was the thinking anyway. Maybe it is too short sighted though? >=20 > I do think SHA-256 should stay regardless.=20 >=20 > But the draft could also define SHA-512 (and maybe others). What do = you and WG folks think about that? >=20 > *** Yes please.=20 >=20 > It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server = supports. That's maybe something that should be done anyway. That'd be a = breaking change to the metadata. But there's already another potential = breaking change identified earlier in this message. So maybe it's worth = doing... >=20 > How do folks feel about making this kind of change?=20 >=20 >=20 >=20 >=20 > =20 > Cheers, >=20 > Neil >=20 >=20 > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote: > > > > All, > > > > As discussed during the meeting today, we are starting a WGLC on the = MTLS document: > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 = > > > > Please, review the document and provide feedback on any issues you = see with the document. > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > Regards, > > Rifaat and Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_76E9275D-3E86-4FF5-8BDA-A0CB9AB5AD1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK, = here=E2=80=99s a stab at a new security considerations section on X.509 = parsing and validation:

---
5.3 X.509 Certificate Parsing and = Validation Complexity

Parsing and validation of X.509 certificates and certificate = chains is complex and implementation mistakes have previously exposed = security vulnerabilities. Complexities of validation include (but are = not limited to) [1][2][3]:
- checking of Basic = Constraints, basic and extended Key Usage constraints, validity periods, = and critical extensions;
- handling of = null-terminator bytes and non-canonical string representations in = subject names;
- handling of wildcard patterns in = subject names;
- recursive verification of = certificate chains and checking certificate revocation.
For these reasons, implementors SHOULD use an established and = well-tested TLS library for validation of X.509 certificate chains and = SHOULD NOT attempt to write their own X.509 certificate validation = procedures.

[1] https://www.cryptologie.net/article/374/common-x509-certificate= -validationcreation-pitfalls/
[2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
[3] https://tools.ietf.org/html/rfc5280 

---

NB - this blog post [1] = is the best concise summary of attacks I could find. Most of these = attacks have been published as Black Hat talks and I can=E2=80=99t seem = to find definitive references or good survey papers (beyond [2], which = is a little older).

Let me know what you think,

Neil


On = 12 Apr 2018, at 20:42, Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks Neil.
Other than the potential metadata changes, which I'd = like more WG input on and may raise in a new thread, I think I've got = enough to make updates addressing your comments.  But please do = send text for that Security Considerations bit, if you come up with = something. 
On Thu, Apr 12, 2018 at 3:03 AM, = Neil Madden <neil.madden@forgerock.com> wrote:
Hi = Brian,

Thanks for the detailed = responses. Comments in line below (marked with ***).

Neil

On Wednesday, Apr 11, 2018 = at 9:47 pm, Brian Campbell <bcampbell@pingidentity.com> wrote:
=
Thanks for the review and feedback, Neil. I apologize for my = being slow to respond. As I said to Justin recently, I've = been away from things for a while. Also there's a lot here to get = through so took me some time.

It = looks like John touched on some of your comments but not all. I'll try = and reply to them as best I can inline below.


On = Thu, Mar 29, 2018 at 9:18 AM, Neil Madden <neil.madden@forgerock.com> = wrote:
Hi,

I = have reviewed this draft and have a number of comments, below. ForgeRock = have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc).
=
1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes:

        { = =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2= =80=9D } }

but you can already do:

        { =E2=80=9Ccnf=E2=80= =9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D } } }

If the = intent is just to save some space and avoid the mandatory fields of the = existing JWK types, maybe this would be better addressed by defining a = new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80= =9D }.

The intent of the = x5t#S256 confirmation method was to be space efficient and = straightforward while utilizing the framework and registry that RFC 7800 = gives.  Even a new JWK type like that would still use more space. = And I'd argue that the new confirmation method is considerably more = straightforward than registering a new JWK type (and the implications = that would have on JWK implementations in general) in order to use the = existing "jwk" confirmation method. 

***
OK, that is reasonable. Given that the = draft says SHOULD rather than MUST for using this confirmation key = method, I think it is currently allowed to use either = representation. 

 

2. I find the naming = =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a bit of a = misnomer: it=E2=80=99s really only the client authentication that we are = interested here, and the fact that the server also authenticates with a = certificate is not hugely relevant to this particular spec (although it = is to the overall security of OAuth). Also, TLS defines non-certificate = based authentication mechanisms (e.g. TLS-SRP extension for password = authenticated key exchange, PSK for pre-shared key authentication) and = even non-X.509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d prefer that the = draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.
This is especially confusing in section 3 = on sender constrained access tokens, as there are two different servers = involved: the AS and the protected resource server, but there is no = =E2=80=9Cmutual=E2=80=9D authentication between them, only between each = of them and the client.

Choosing names and terminology is = difficult and the "right" wording is often subjective. I believe that = the current wording sufficiently conveys what is going on in the draft = to most readers. Most readers thus far seem to agree. There is some text = now that does say that the mutual auth in the draft is in fact X.509 = client cert authn but, in the next revision, I'll look for other = opportunities where it could be stated more clearly. 

*** = Thanks. 

 

3. The draft links = to the TLS 1.2 RFC, while the original OAuth 2.0 RFC only specifies TLS = 1.0. Is the intention that TLS 1.2+ is required? The wording in Section = 5.1 doesn=E2=80=99t seem clear if this could also be used with TLS 1.0 = or 1.1, or whether it is only referring to future TLS versions.

The reference to BCP 195 (which unfortunately = the original OAuth 2.0 RFC doesn't have because it didn't exist = then) is meant to account for changing versions and recommendations = around TLS. Currently that BCP says TLS 1.2 is a must and suggests = against 1.1 & 1.0 but doesn't outright prohibit them.

*** OK, that seems good to me. 

 

4. It might be = useful to have a discussion for implementors of whether TLS session = resumption (and PSK in TLS 1.3) and/or renegotiation impact the use of = client certificates, if at all?

That might well be = useful but I don't myself know what it would say. I've (maybe naively) = figured those are deployment details that will just work out. Perhaps = you could propose some text around such a discussion that the WG could = consider?

 ***
To be honest, when I raised = this it was because I didn=E2=80=99t really know what the implications = were. I=E2=80=99ve done some reading around and I think it should all = just work - both session resumption and PSK-based resumption preserve = the original client and server authentication context so we can assume = that any presented client cert is still valid for the resumed session. = So I think we can leave out any discussion of this and assume it works = as expected. 



5. Section 3 = defines sender-constrained access tokens in terms of the confirmation = key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 Pop = Architecture draft defines sender constraint and key confirmation as = different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2). The draft should decide which of = those it is implementing and if sender constraint is intended, then = reusing the confirmation key claims seems misleading. (I think this mTLS = draft is doing key confirmation so should drop the language about sender = constrained tokens).

I will say again that choosing names = and terminology is difficult...

Although I = must admit that I started using "sender constrained" somewhat = indiscriminately at first and it's just sort of stuck. At the time I was = trying to incorporate bits of draft-sakimura-oauth-jpop in a way that = might help bring on and keep the authors of that draft onboard with this = mtls draft. In retrospect it looks like I did that part wrong anyway. = But that was the thinking at the time and the history, for whatever it's = worth. More recently, Nat was requesting that "sender constrained" be = included in the title. So there's that too. 

In defense of my mistake, however, if = there's a line between "sender constrained" and "key confirmation" = tokens, it's a bit of a fuzzy line. And I'd argue that what this draft = is doing pretty close to the line.

But ultimately I think you are right = that what this mtls draft is doing with access tokens is more accurately = described with the key confirmation term.

So, yes, the draft = should probably drop (or at least minimize) the language about sender = constrained. I'll do that in the next draft version, barring big = objections from the WG.

The tricky thing with making that change is that there a = client and server metadata parameters with the name = "mutual_tls_sender_constrained_access_tokens" that = should probably also change. But that would be a breaking change (of = sorts anyway), which shouldn't be taken lightly at this stage. I feel = that some explicit okays from the WG are needed before doing so (rough = consensus stye) . Any WG members want to weigh in here and help get a = "sense = of the group" concerning changing those metadata names?

*** = Thanks. I agree this might cause compatibility issues. It is not a big = issue for us, but might cause some confusion. 

 

6. The OAuth = 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-5):

  =        Strong, fresh session keys:
=
                = Session keys MUST be strong and fresh.  Each session deserves an
                = independent session key, i.e., one that is generated specifically
                for = the intended use.  In context of OAuth this means that keying
                = material is created in such a way that can only be used by the
                = combination of a client instance, protected resource, and
=                 authorization = scope.


However, the mTLS = draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) = says:

        The = client makes protected resource requests as described in
=         [RFC6750], however, those requests MUST be = made over a mutually
        = authenticated TLS connection using the same certificate that was used
        for mutual TLS at the token = endpoint.

These two statements are = contradictory: the OAuth 2.0 PoP architecture effectively requires a = fresh key-pair to be used for every access token request, whereas this = draft proposes reusing the same long-lived client certificate for every = single access token and every resource server.

In the self-signed case (and even in the CA case, with a bit = of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is perfectly possible for = the client to generate a fresh key-pair for each access token and = include the certificate on the token request (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section-5.1 - in which case an appropriate = =E2=80=9Calg=E2=80=9D value should probably be described). This should = probably at least be an option.

This draft doesn't = necessarily seek to align with the (long expired) PoP architecture = draft.  Rather it is aiming to provide a pragmatic solution for PoP = style access tokens and OAuth client auth using mTLS client = certificates.

That = said, with the current draft, it's certainly possible for a client to = update its cert more frequently, even so far as using a new one for each = access token. The details of how that would work will vary some based on = the token endpoint authentication method. But it's not precluded.

*** You are right, the text = doesn=E2=80=99t preclude that. I am happy with that solution. I suspect = most people will deploy and be happy with reusing a long-lived cert for = every access token, so this may not matter in practice. 
 

7. The use of a = single client certificate with every resource server (RS) should be = called out in a Privacy Considerations section, as it allows correlation = of activity.

Practically speaking the access tokens = being presented likely already have correlatable info in them about the = client as well as the user. I don't know that there's much of a (new) = concern in reality. If you feel this concern is unique and import = enough though, perhaps there's some text you'd like to propose for a = Privacy Considerations section that the WG could consider? I mean, I = guess it doesn't hurt to mention it but I would like to avoid = overstating the issue. 

*** On reflection, I am going to = withdraw this comment. As you say there are other ways to correlate = clients. The privacy issue would mainly arise in the context of dynamic = client registration e.g., a pattern I=E2=80=99ve seen described where = every instance of a mobile app does dynamic client registration to avoid = including credentials directly in the app bundle. This would make = clients one-to-one with users. But (a) those apps are fairly unlikely to = be using TLS certs, and (b) that is more of a privacy consideration for = dynamic client registration rather than this draft. 

 

8. This is = maybe a more general point, but RFC 6750 defines the Authorization: = Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2) for a client to communicate it=E2=80=99s = access token to the RS in a standard way. As sender-constrained access = tokens are not strictly bearer tokens any more, should this draft also = register a new scheme for that? Should there be a generic PoP scheme?

The thinking and general consensus (in this draft as well as = the OAuth token binding work) has been that continuing to use the RFC = 6750 scheme while putting the "not strictly bearer" stuff in (or = referenced by) the token itself will be easier on deployment and = implementation. And better for adoption as a result. I believe some = early implementation work has borne that out too.

 *** = OK. 

=
9. The Security Considerations should really make some = mention of the long history of attacks against X.509 certificate chain = validation, e.g. failure to check the =E2=80=9CCA=E2=80=9D bit in the = basic constraints, errors in parsing DNs, etc. It should be strongly = suggested to use an existing TLS library to perform these checks rather = than implementing your own checks. This relates to Justin=E2=80=99s = comments around DN parsing and normalisation.

Suggesting to use an existing TLS library is certainly sound = advice and I sort of felt is implied in the draft. But saying so more = strongly/explicitly might be worthwhile.  And pointing to = historical reasons to do so would probably be good too.  Could you = propose a new Security Considerations section or maybe augmentation of = =C2=A75.2 with that content? 

*** I=E2=80=99ll try and come up = with some text. 

 

10. The PKI client = authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) = makes no mention at all of certificate revocation and how to handle = checking for that (CRLs, OCSP - with stapling?). Neither does the = Security Considerations. If this is a detail to be agreed between then = AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with = some of these mechanisms, as OCSP requests are typically sent in the = clear (plain HTTP) and so allow an observer to see which clients are = connecting to which AS.

I didn't think that a TLS client could = do OCSP stapling?

*** I think you are right about = this. I always assumed it was symmetric (and I think it technically = could work), but the spec only talks about stapling in the server-side = of the handshake. 

That aside, revocation checking (how and even = if) is something that's at the discretion of the AS. I can add something = in =C2=A72.1 to say that more explicitly. 

*** Thanks. 



11. The same comment applies to how the protected resource = checks for revocation of the certificate presented during sender = constrained access token usage. Should the RS make its own revocation = checks based on the information in the certificate presented, or should = it trust the certificate while the access token is still valid? If the = latter case, is the AS responsible for revoking any access tokens whose = certificate have been revoked (if so, should it be doing an OCSP call on = every token introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS verify the signature on = that if it does not have a separate trust relationship with the CA = already?

The draft effectively uses cert mtls at = the RS as a proof-of-possession method only and not as authentication. = So revocation checking isn't really applicable. In specific deployment = situations, I suppose an RS could check revocation. But that'd be a = deployment decision for the RS that's beyond the scope of this draft. =

*** OK, that is an interesting observation. If either the = client or AS suspect the key has been compromised they can revoke the = access token(s) instead. 
 


12. The use of = only SHA-256 fingerprints means that the security strength of the = sender-constrained access tokens is limited by the collision resistance = of SHA-256 - roughly =E2=80=9C128-bit security" - without a new = specification for a new thumbprint algorithm. An implication of this is = that is is fairly pointless for the protected resource TLS stack to ever = negotiate cipher suites/keys with a higher level of security. In more = crystal ball territory, if a practical quantum computer becomes a = possibility within the lifetime of this spec, then the expected = collision resistance of SHA-256 would drop quadratically, allowing an = attacker to find a colliding certificate in ~2^64 effort. If we are = going to pick just one thumbprint hash algorithm, I would prefer we pick = SHA-512.

The idea behind haveing just one = thumbprint hash algorithm was to keep things simple. And SHA-256 seems = good enough for the reasonably foreseeable future (and space aware). = Also a new little spec to register a different hash algorithm, should = the need arise, didn't seem particularity onerous.

That was the thinking anyway. Maybe it = is too short sighted though?

I do think SHA-256 should stay regardless.

But the draft could also define SHA-512 = (and maybe others). What do you and WG folks think about that?

*** Yes = please. 

It would probably then be useful for the metadata in =C2=A73.3 = and =C2=A73.4 to change from just boolean values to something to convey = what hash alg/cnf method the client expects and the list of what the = server supports. That's maybe something that should be done anyway. = That'd be a breaking change to the metadata. But there's already another = potential breaking change identified earlier in this message. So maybe = it's worth doing...

How= do folks feel about making this kind of change?




 
Cheers,

= Neil


= > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
>
> All,
>
> As = discussed during the meeting today, we are starting a WGLC on the MTLS = document:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07
>
= > Please, review the document and provide feedback on any issues you = see with the document.
>
> The WGLC = will end in two weeks, on April 2, 2018.
>
> Regards,
>  Rifaat and Hannes
>
> = _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=

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



CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
=


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
= --Apple-Mail=_76E9275D-3E86-4FF5-8BDA-A0CB9AB5AD1B-- From nobody Tue Apr 17 03:24:53 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C57127698 for ; Tue, 17 Apr 2018 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1wUj5Z0882a for ; Tue, 17 Apr 2018 03:24:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DA612D779 for ; Tue, 17 Apr 2018 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3HAOdY8021046; Tue, 17 Apr 2018 12:24:39 +0200 (CEST) Received: from client-0025.vpn.uni-bremen.de (client-0025.vpn.uni-bremen.de [134.102.107.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40QLw73gTlzDWWl; Tue, 17 Apr 2018 12:24:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 17 Apr 2018 12:24:38 +0200 Cc: oauth X-Mao-Original-Outgoing-Id: 545653476.779152-52f533609212caac21e829c30ec9c5cb Content-Transfer-Encoding: quoted-printable Message-Id: <2A008301-0BB6-4DAB-98AF-0728FEE5F205@tzi.org> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 10:24:51 -0000 I haven=E2=80=99t read the document yet, but idnits did some reading for = me: ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC7519]), which it shouldn't. Please replace those with straight textual mentions of = the documents in question. ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) I=E2=80=99ll get to the content later=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 17 04:58:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAA12EAD6 for ; Tue, 17 Apr 2018 04:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTkGCmQQRKGD for ; Tue, 17 Apr 2018 04:58:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA16A12EACF for ; Tue, 17 Apr 2018 04:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3HBwakj005317; Tue, 17 Apr 2018 13:58:37 +0200 (CEST) Received: from client-0025.vpn.uni-bremen.de (client-0025.vpn.uni-bremen.de [134.102.107.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40QP0X3jFQzDWYJ; Tue, 17 Apr 2018 13:58:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <2A008301-0BB6-4DAB-98AF-0728FEE5F205@tzi.org> Date: Tue, 17 Apr 2018 13:58:35 +0200 Cc: oauth X-Mao-Original-Outgoing-Id: 545659113.825737-ebeddc0cd8094a86739a1740e2ed6507 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A008301-0BB6-4DAB-98AF-0728FEE5F205@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 11:58:45 -0000 On Apr 17, 2018, at 12:24, Carsten Bormann wrote: >=20 > ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) That also gives rise to: Minor technical comment: 2.3 claims that JSON can be in different = encodings. This is no longer really the case with RFC 8259 (see Section = 8.1). Please fix the wording to remove the untrue claim (no pun = intended). Major technical comment: Section 3.9 recommends the use of media types=20= of the form application/example+jwt. I don=E2=80=99t find a registration for the RFC 6839 structured syntax suffix "+jwt". If this recommendation is desired, this document will need to register it (preferred) or refer to a document that does. Nit: Section 1.2 could use the newer template (as per RFC 8174) here. Nit: Section 3.6: s/use/use or admit the use of/ Nit: Section 3.8: s/not/not present or not/ I think these are all solved in an obvious way, and once done I strongly = support this document to go forward. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 17 07:13:50 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A80312EB48 for ; Tue, 17 Apr 2018 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLBwQ9HMVU8B for ; Tue, 17 Apr 2018 07:13:42 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7873712D94E for ; Tue, 17 Apr 2018 07:13:42 -0700 (PDT) X-AuditID: 12074422-ae1ff70000003029-b8-5ad601129543 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 34.BB.12329.31106DA5; Tue, 17 Apr 2018 10:13:40 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w3HEDXBW022290; Tue, 17 Apr 2018 10:13:35 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3HEDTpr019912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Apr 2018 10:13:32 -0400 Date: Tue, 17 Apr 2018 09:13:29 -0500 From: Benjamin Kaduk To: Neil Madden Cc: Brian Campbell , oauth Message-ID: <20180417141329.GS54168@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6noivCeC3K4P0TKYvV/28yWsyZ94vN 4uTbV2wOzB432hYweixZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGTuP8hV0H2GseHpSsIHx 1HzGLkYODgkBE4nejsQuRi4OIYHFTBIdaw4xQjgbGSX27bjK3sXICeRcZZJ4vjcJxGYRUJVo mvubCcRmE1CRaOi+zAxiiwhoS6xYvIARxGYWcJf4+/IFmC0sYCFx6tEPsHpeoGWbN71lgljw h0lix7X17BAJQYmTM5+wQDSrS/yZd4kZ5DpmAWmJ5f84IMLaEssWvgbbxSngKDH5zVIwW1RA WWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11QvN7NE LzWldBMjONBdlHYwTvzndYhRgINRiYdXYseVKCHWxLLiytxDjJIcTEqivIfeXo0S4kvKT6nM SCzOiC8qzUktPsQowcGsJMK78zFQOW9KYmVValE+TEqag0VJnHfx/r1RQgLpiSWp2ampBalF MFkZDg4lCd6P/4GGChalpqdWpGXmlCCkmTg4QYbzAA1nZ7gGNLy4IDG3ODMdIn+K0ZJj2rKe HmaOY5enAclv23/3MAux5OXnpUqJ8/4DGSoA0pBRmgc3E5S4JLL317xiFAd6UZj3MEgVDzDp wU19BbSQCWjhNWOQb4pLEhFSUg2MpU+53v868HGWXulXu4fWzcuaDyoWPr0rvkNDoiNmddx/ n97XNRMX/fuVenztutYV9k7ac46tObB0kt7vuhdJhYbzp2ZrKSfZPlyvftireJrqy1dHolWP nrz2LvCF1a0WgRX8ZRvv/Zl/4/+j/c+irybr3O3LWiFqs9Qh4TTP+77OXzG5f6sfPFJiKc5I NNRiLipOBADG6Q9lNwMAAA== Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 14:13:47 -0000 Picking nits, but maybe "established and well-tested X.509 library (such as one used by an established TLS library)", noting that TLS 1.3 has added a new protocol feature that allows for TLS and X.509 library capabilities to be separately indicated (as would be needed if they were organizationally separate). -Ben On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote: > OK, here=E2=80=99s a stab at a new security considerations section on X.5= 09 parsing and validation: >=20 > --- > 5.3 X.509 Certificate Parsing and Validation Complexity >=20 > Parsing and validation of X.509 certificates and certificate chains is co= mplex and implementation mistakes have previously exposed security vulnerab= ilities. Complexities of validation include (but are not limited to) [1][2]= [3]: > - checking of Basic Constraints, basic and extended Key Usage constraints= , validity periods, and critical extensions; > - handling of null-terminator bytes and non-canonical string representati= ons in subject names; > - handling of wildcard patterns in subject names; > - recursive verification of certificate chains and checking certificate r= evocation. > For these reasons, implementors SHOULD use an established and well-tested= TLS library for validation of X.509 certificate chains and SHOULD NOT atte= mpt to write their own X.509 certificate validation procedures. >=20 > [1] https://www.cryptologie.net/article/374/common-x509-certificate-valid= ationcreation-pitfalls/ > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf > [3] https://tools.ietf.org/html/rfc5280 =20 >=20 > --- >=20 > NB - this blog post [1] is the best concise summary of attacks I could fi= nd. Most of these attacks have been published as Black Hat talks and I can= =E2=80=99t seem to find definitive references or good survey papers (beyond= [2], which is a little older). >=20 > Let me know what you think, >=20 > Neil >=20 >=20 > > On 12 Apr 2018, at 20:42, Brian Campbell w= rote: > >=20 > > Thanks Neil.=20 > >=20 > > Other than the potential metadata changes, which I'd like more WG input= on and may raise in a new thread, I think I've got enough to make updates = addressing your comments. But please do send text for that Security Consid= erations bit, if you come up with something. =20 > >=20 > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden > wrote: > > Hi Brian, > >=20 > > Thanks for the detailed responses. Comments in line below (marked with = ***). > >=20 > > Neil > >=20 > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell > wrote: > > Thanks for the review and feedback, Neil. I apologize for my being slow= to respond. As I said to Justin recently , I've been away from things for a = while. Also there's a lot here to get through so took me some time.=20 > >=20 > > It looks like John touched on some of your comments but not all. I'll t= ry and reply to them as best I can inline below.=20 > >=20 > >=20 > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden > wrote: > > Hi, > >=20 > > I have reviewed this draft and have a number of comments, below. ForgeR= ock have not yet implemented this draft, but there is interest in implement= ing it at some point. (Disclaimer: We have no firm commitments on this at t= he moment, I do not speak for ForgeRock, etc). > >=20 > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defines a n= ew confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is alread= y a confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web K= ey, which itself can contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactl= y the same syntax and semantics. The draft proposes: > >=20 > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80= =9C=E2=80=A6=E2=80=9D } } > >=20 > > but you can already do: > >=20 > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 ,= =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } > >=20 > > If the intent is just to save some space and avoid the mandatory fields= of the existing JWK types, maybe this would be better addressed by definin= g a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D= : =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2= =80=9D }. > >=20 > > The intent of the x5t#S256 confirmation method was to be space efficien= t and straightforward while utilizing the framework and registry that RFC 7= 800 gives. Even a new JWK type like that would still use more space. And I= 'd argue that the new confirmation method is considerably more straightforw= ard than registering a new JWK type (and the implications that would have o= n JWK implementations in general) in order to use the existing "jwk" confir= mation method. =20 > >=20 > > *** > > OK, that is reasonable. Given that the draft says SHOULD rather than MU= ST for using this confirmation key method, I think it is currently allowed = to use either representation.=20 > >=20 > > =20 > >=20 > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s really only the client authenticat= ion that we are interested here, and the fact that the server also authenti= cates with a certificate is not hugely relevant to this particular spec (al= though it is to the overall security of OAuth). Also, TLS defines non-certi= ficate based authentication mechanisms (e.g. TLS-SRP extension for password= authenticated key exchange, PSK for pre-shared key authentication) and eve= n non-X.509 certificate types (https://www.iana.org/assignments/tls-extensi= ontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 ). I=E2=80=99d prefer that the draft= explicitly referred to =E2=80=9CX.509 Client Certificate Authentication=E2= =80=9D rather than mutual TLS, and changed identifiers like =E2=80=98tls_cl= ient_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#se= ction-2.1.1 ) to something more explicit like =E2=80=98tls_x509_pki_client_auth= =E2=80=99. > >=20 > > This is especially confusing in section 3 on sender constrained access = tokens, as there are two different servers involved: the AS and the protect= ed resource server, but there is no =E2=80=9Cmutual=E2=80=9D authentication= between them, only between each of them and the client. > >=20 > > Choosing names and terminology is difficult and the "right" wording is = often subjective. I believe that the current wording sufficiently conveys w= hat is going on in the draft to most readers. Most readers thus far seem to= agree. There is some text now that does say that the mutual auth in the dr= aft is in fact X.509 client cert authn but, in the next revision, I'll look= for other opportunities where it could be stated more clearly.=20 > >=20 > > *** Thanks.=20 > >=20 > > =20 > >=20 > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC= only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The wo= rding in Section 5.1 doesn=E2=80=99t seem clear if this could also be used = with TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. > >=20 > > The reference to BCP 195 (which unfortunately the original OAuth 2.0 RF= C doesn't have because it didn't exist then) is meant to account for changi= ng versions and recommendations around TLS. Currently that BCP says TLS 1.2= is a must and suggests against 1.1 & 1.0 but doesn't outright prohibit the= m.=20 > >=20 > > *** OK, that seems good to me.=20 > >=20 > > =20 > >=20 > > 4. It might be useful to have a discussion for implementors of whether = TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact the= use of client certificates, if at all? > >=20 > > That might well be useful but I don't myself know what it would say. I'= ve (maybe naively) figured those are deployment details that will just work= out. Perhaps you could propose some text around such a discussion that the= WG could consider?=20 > >=20 > > *** > > To be honest, when I raised this it was because I didn=E2=80=99t really= know what the implications were. I=E2=80=99ve done some reading around and= I think it should all just work - both session resumption and PSK-based re= sumption preserve the original client and server authentication context so = we can assume that any presented client cert is still valid for the resumed= session. So I think we can leave out any discussion of this and assume it = works as expected.=20 > >=20 > >=20 > >=20 > > 5. Section 3 defines sender-constrained access tokens in terms of the c= onfirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 Pop= Architecture draft defines sender constraint and key confirmation as diffe= rent things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-= 08#section-6.2 ). The draft should decide which of those it is implement= ing and if sender constraint is intended, then reusing the confirmation key= claims seems misleading. (I think this mTLS draft is doing key confirmatio= n so should drop the language about sender constrained tokens). > >=20 > > I will say again that choosing names and terminology is difficult... > >=20 > > Although I must admit that I started using "sender constrained" somewha= t indiscriminately at first and it's just sort of stuck. At the time I was = trying to incorporate bits of draft-sakimura-oauth-jpop in a way that might= help bring on and keep the authors of that draft onboard with this mtls dr= aft. In retrospect it looks like I did that part wrong anyway. But that was= the thinking at the time and the history, for whatever it's worth. More re= cently, Nat was requesting that "sender constrained" be included in the tit= le. So there's that too. =20 > >=20 > > In defense of my mistake, however, if there's a line between "sender co= nstrained" and "key confirmation" tokens, it's a bit of a fuzzy line. And I= 'd argue that what this draft is doing pretty close to the line.=20 > >=20 > > But ultimately I think you are right that what this mtls draft is doing= with access tokens is more accurately described with the key confirmation = term.=20 > >=20 > > So, yes, the draft should probably drop (or at least minimize) the lang= uage about sender constrained. I'll do that in the next draft version, barr= ing big objections from the WG. > >=20 > > The tricky thing with making that change is that there a client and ser= ver metadata parameters with the name "mutual_tls_sender_constrained_access= _tokens" that should probably also change. But that would be a breaking cha= nge (of sorts anyway), which shouldn't be taken lightly at this stage. I fe= el that some explicit okays from the WG are needed before doing so (rough c= onsensus stye) . Any WG members want to weigh in here and help get a "sense= of the group" concerning changing those metadata names?=20 > >=20 > > *** Thanks. I agree this might cause compatibility issues. It is not a = big issue for us, but might cause some confusion.=20 > >=20 > > =20 > >=20 > > 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/ht= ml/draft-ietf-oauth-pop-architecture-08#section-5 ): > >=20 > > Strong, fresh session keys: > >=20 > > Session keys MUST be strong and fresh. Each session de= serves an > > independent session key, i.e., one that is generated sp= ecifically > > for the intended use. In context of OAuth this means t= hat keying > > material is created in such a way that can only be used= by the > > combination of a client instance, protected resource, a= nd > > authorization scope. > >=20 > >=20 > > However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07#section-3 ) says: > >=20 > > The client makes protected resource requests as described in > > [RFC6750], however, those requests MUST be made over a mutually > > authenticated TLS connection using the same certificate that wa= s used > > for mutual TLS at the token endpoint. > >=20 > > These two statements are contradictory: the OAuth 2.0 PoP architecture = effectively requires a fresh key-pair to be used for every access token req= uest, whereas this draft proposes reusing the same long-lived client certif= icate for every single access token and every resource server. > >=20 > > In the self-signed case (and even in the CA case, with a bit of work - = e.g., https://www.vaultproject.io/docs/secrets/pki/index.html ) it is perfectly possible for = the client to generate a fresh key-pair for each access token and include t= he certificate on the token request (e.g., as per https://tools.ietf.org/ht= ml/draft-ietf-oauth-pop-key-distribution-03#section-5.1 - in whic= h case an appropriate =E2=80=9Calg=E2=80=9D value should probably be descri= bed). This should probably at least be an option. > >=20 > > This draft doesn't necessarily seek to align with the (long expired) Po= P architecture draft. Rather it is aiming to provide a pragmatic solution = for PoP style access tokens and OAuth client auth using mTLS client certifi= cates.=20 > >=20 > > That said, with the current draft, it's certainly possible for a client= to update its cert more frequently, even so far as using a new one for eac= h access token. The details of how that would work will vary some based on = the token endpoint authentication method. But it's not precluded.=20 > >=20 > > *** You are right, the text doesn=E2=80=99t preclude that. I am happy w= ith that solution. I suspect most people will deploy and be happy with reus= ing a long-lived cert for every access token, so this may not matter in pra= ctice.=20 > > =20 > >=20 > > 7. The use of a single client certificate with every resource server (R= S) should be called out in a Privacy Considerations section, as it allows c= orrelation of activity. > >=20 > > Practically speaking the access tokens being presented likely already h= ave correlatable info in them about the client as well as the user. I don't= know that there's much of a (new) concern in reality. If you feel this con= cern is unique and import enough though, perhaps there's some text you'd li= ke to propose for a Privacy Considerations section that the WG could consid= er? I mean, I guess it doesn't hurt to mention it but I would like to avoid= overstating the issue. =20 > >=20 > > *** On reflection, I am going to withdraw this comment. As you say ther= e are other ways to correlate clients. The privacy issue would mainly arise= in the context of dynamic client registration e.g., a pattern I=E2=80=99ve= seen described where every instance of a mobile app does dynamic client re= gistration to avoid including credentials directly in the app bundle. This = would make clients one-to-one with users. But (a) those apps are fairly unl= ikely to be using TLS certs, and (b) that is more of a privacy consideratio= n for dynamic client registration rather than this draft.=20 > >=20 > > =20 > >=20 > > 8. This is maybe a more general point, but RFC 6750 defines the Authori= zation: Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2 ) for a client to communicate it= =E2=80=99s access token to the RS in a standard way. As sender-constrained = access tokens are not strictly bearer tokens any more, should this draft al= so register a new scheme for that? Should there be a generic PoP scheme? > >=20 > > The thinking and general consensus (in this draft as well as the OAuth = token binding work) has been that continuing to use the RFC 6750 scheme whi= le putting the "not strictly bearer" stuff in (or referenced by) the token = itself will be easier on deployment and implementation. And better for adop= tion as a result. I believe some early implementation work has borne that o= ut too.=20 > >=20 > > *** OK.=20 > >=20 > >=20 > > 9. The Security Considerations should really make some mention of the l= ong history of attacks against X.509 certificate chain validation, e.g. fai= lure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors= in parsing DNs, etc. It should be strongly suggested to use an existing TL= S library to perform these checks rather than implementing your own checks.= This relates to Justin=E2=80=99s comments around DN parsing and normalisat= ion. > >=20 > > Suggesting to use an existing TLS library is certainly sound advice and= I sort of felt is implied in the draft. But saying so more strongly/explic= itly might be worthwhile. And pointing to historical reasons to do so woul= d probably be good too. Could you propose a new Security Considerations se= ction or maybe augmentation of =C2=A75.2 with that content?=20 > >=20 > > *** I=E2=80=99ll try and come up with some text.=20 > >=20 > > =20 > >=20 > > 10. The PKI client authentication method (https://tools.ietf.org/html/d= raft-ietf-oauth-mtls-07#section-2.1 ) makes no mention at all of certificate revocat= ion and how to handle checking for that (CRLs, OCSP - with stapling?). Neit= her does the Security Considerations. If this is a detail to be agreed betw= een then AS and the CA (or just left up to the AS TLS stack) then that shou= ld perhaps be made explicit. Again, there are privacy considerations with s= ome of these mechanisms, as OCSP requests are typically sent in the clear (= plain HTTP) and so allow an observer to see which clients are connecting to= which AS. > >=20 > > I didn't think that a TLS client could do OCSP stapling? > >=20 > > *** I think you are right about this. I always assumed it was symmetric= (and I think it technically could work), but the spec only talks about sta= pling in the server-side of the handshake.=20 > >=20 > > That aside, revocation checking (how and even if) is something that's a= t the discretion of the AS. I can add something in =C2=A72.1 to say that mo= re explicitly.=20 > >=20 > > *** Thanks.=20 > >=20 > >=20 > >=20 > > 11. The same comment applies to how the protected resource checks for r= evocation of the certificate presented during sender constrained access tok= en usage. Should the RS make its own revocation checks based on the informa= tion in the certificate presented, or should it trust the certificate while= the access token is still valid? If the latter case, is the AS responsible= for revoking any access tokens whose certificate have been revoked (if so,= should it be doing an OCSP call on every token introspection request, and = should the RS be passing on the certificate/serial number on that request)?= If the Client request uses OCSP Stapling (https://en.wikipedia.org/wiki/OC= SP_stapling ) how can the RS v= erify the signature on that if it does not have a separate trust relationsh= ip with the CA already? > >=20 > > The draft effectively uses cert mtls at the RS as a proof-of-possession= method only and not as authentication. So revocation checking isn't really= applicable. In specific deployment situations, I suppose an RS could check= revocation. But that'd be a deployment decision for the RS that's beyond t= he scope of this draft.=20 > >=20 > > *** OK, that is an interesting observation. If either the client or AS = suspect the key has been compromised they can revoke the access token(s) in= stead.=20 > > =20 > >=20 > >=20 > > 12. The use of only SHA-256 fingerprints means that the security streng= th of the sender-constrained access tokens is limited by the collision resi= stance of SHA-256 - roughly =E2=80=9C128-bit security" - without a new spec= ification for a new thumbprint algorithm. An implication of this is that is= is fairly pointless for the protected resource TLS stack to ever negotiate= cipher suites/keys with a higher level of security. In more crystal ball t= erritory, if a practical quantum computer becomes a possibility within the = lifetime of this spec, then the expected collision resistance of SHA-256 wo= uld drop quadratically, allowing an attacker to find a colliding certificat= e in ~2^64 effort. If we are going to pick just one thumbprint hash algorit= hm, I would prefer we pick SHA-512. > >=20 > > The idea behind haveing just one thumbprint hash algorithm was to keep = things simple. And SHA-256 seems good enough for the reasonably foreseeable= future (and space aware). Also a new little spec to register a different h= ash algorithm, should the need arise, didn't seem particularity onerous.=20 > >=20 > > That was the thinking anyway. Maybe it is too short sighted though? > >=20 > > I do think SHA-256 should stay regardless.=20 > >=20 > > But the draft could also define SHA-512 (and maybe others). What do you= and WG folks think about that? > >=20 > > *** Yes please.=20 > >=20 > > It would probably then be useful for the metadata in =C2=A73.3 and =C2= =A73.4 to change from just boolean values to something to convey what hash = alg/cnf method the client expects and the list of what the server supports.= That's maybe something that should be done anyway. That'd be a breaking ch= ange to the metadata. But there's already another potential breaking change= identified earlier in this message. So maybe it's worth doing... > >=20 > > How do folks feel about making this kind of change?=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > Cheers, > >=20 > > Neil > >=20 > >=20 > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote: > > > > > > All, > > > > > > As discussed during the meeting today, we are starting a WGLC on the = MTLS document: > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > > > > > Please, review the document and provide feedback on any issues you se= e with the document. > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > Regards, > > > Rifaat and Hannes > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > >=20 > >=20 > > CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. > >=20 > >=20 > > CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Apr 17 07:43:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A201812D880 for ; Tue, 17 Apr 2018 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXuG7qLvNSgY for ; Tue, 17 Apr 2018 07:43:10 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FB01243F3 for ; Tue, 17 Apr 2018 07:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1523976190; x=1555512190; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+63nLYR2LYAiMPwLu07M7aoA1B1anZ47Z/ycwUPtM7M=; b=r6mKI93cxtrszORxlCloBcpd+MvhZBOVpXtrOoVWTax++15PmkNcPoyL gVlbvsZwMkRouQOOKrQ+zsjptJbGeXHVpkvuS3d/sDBx6wzZithx0ofRf +xdikYpohJoKa2/Nu5aTv1bj9HuhWYbWYmZ0ahKuERp0ukNVrWI8p6E41 w=; X-IronPort-AV: E=Sophos;i="5.48,463,1517875200"; d="scan'208";a="340216452" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Apr 2018 14:43:09 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w3HEh8xd071935 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2018 14:43:08 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 17 Apr 2018 14:43:07 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 17 Apr 2018 14:43:07 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 17 Apr 2018 14:43:07 +0000 From: "Richard Backman, Annabelle" To: Hannes Tschofenig , oauth Thread-Topic: [OAUTH-WG] Call for Adoption: Reciprocal OAuth Thread-Index: AQHT1lpmUkS52HyWSzy33HhEMmhw2w== Date: Tue, 17 Apr 2018 14:43:07 +0000 Message-ID: <6BBA90E7-6496-42C8-A1AB-9D896ECFF120@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.112] Content-Type: text/plain; charset="utf-8" Content-ID: <50607F1E87A3B344B2159BAFA35D0A2C@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 14:43:13 -0000 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiAqUmVjaXByb2NhbCBPQXV0aCogYXMgYSBXRyBkb2N1 bWVudC4NCg0KLS0gDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50 aXR5IFNlcnZpY2VzDQogDQrvu79PbiA0LzE2LzE4LCA4OjIwIEFNLCAiT0F1dGggb24gYmVoYWxm IG9mIEhhbm5lcyBUc2Nob2ZlbmlnIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgSGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQogICAg DQogICAgd2UgaGFkIGdvdHRlbiBwb3NpdGl2ZSBmZWVkYmFjayBmcm9tIHRoZSBncm91cCBvbiBS ZWNpcHJvY2FsIE9BdXRoIGF0IHRoZSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBlYXJsaWVyIHRo aXMgeWVhciBhbmQgYWxzbyBhdCB0aGUgTG9uZG9uIElFVEYgbWVldGluZy4NCiAgICANCiAgICBX ZSB3b3VsZCB0aGVyZWZvcmUgbGlrZSB0byBnZXQgYSBmaW5hbCBjb25maXJtYXRpb24gb24gdGhl IG1haWxpbmcgbGlzdCBmb3IgdGhlIGFkb3B0aW9uIG9mIHRoZSAqUmVjaXByb2NhbCBPQXV0aCog YXMgYSBXRyBkb2N1bWVudA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJkdC1vYXV0aC1tdXR1YWwtMDINCiAgICANCiAgICBQbGVhc2UsIGxldCB1cyBrbm93IGlmIHlv dSBzdXBwb3J0IG9yIG9iamVjdCB0byB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBieSBB cHJpbCAyNXRoLg0KICAgIA0KICAgIENpYW8NCiAgICBIYW5uZXMgJiBSaWZhYXQNCiAgICBJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxp c3QNCiAgICBPQXV0aEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCiAgICANCg0K From nobody Tue Apr 17 08:40:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C22D12D941 for ; Tue, 17 Apr 2018 08:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpskbB4Pf9pX for ; Tue, 17 Apr 2018 08:40:42 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252E0126E64 for ; Tue, 17 Apr 2018 08:40:42 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id j11so710877pgf.2 for ; Tue, 17 Apr 2018 08:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DS+ivwB6jAmm2i86Lnm75r+jDkyXy5CKJQ8feCA9v3Q=; b=QhmdIiJOhi/lqhMfTEYl52XgiGHRVGIVrtgkuqCfW1QwXW5W1bwtwzCzCH2FRWzFn8 65ohPKVIa0K16MkQNNXU988jnFxAq2fbsisK4Kc7eldoGPA0pdUoplAARFt01mbsvxLu I9+Pp1tXV/edggwSeio5UvHR6PR+ulIld6qOBsniITKMmGcuivbtJx0q+2n94Que5+Cn jyxBDlUxUPhhWDcwoa0oxzWKxQwX4KwfTGuVNtCQca2WitBM4cwK2NG+l56+8Z3lp3be uqEX0m+F9z/nK4unHwSzI6Hmjm7W//20aE4mtad8suh+sqrtLQ40GMbg9ijB9MwFlDv0 fYlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DS+ivwB6jAmm2i86Lnm75r+jDkyXy5CKJQ8feCA9v3Q=; b=Hm6x0t60CgEzgt4dmaYVgErVhiyu2EUF+JoteONBrynF4xDMtMBhxT5/be1L4Gzrk+ ncNRf2R3eP/i/y1NqfRhZcH74SOibmQsEUoMpFi4eD/wCMr4hStgzczimcUKaxZi2v3t adG7X7MhJFcnJltA+lT18FLnon1ubpFHktXQfZkcv56MuHbknE0z+c1HAeY+EB0PmYn3 K7I+KPp1JoTwNThFdWbPNKc2gbph/W/xg9lQ2HMb4GdtoEzZADaBLGDCwAw3QW8PU0YS F78RFKrHqWNciZNImBNM5H3Gnm0fRg07NrOQlwBc/urhoVUoRqqp1gdM/PxEcKfHN+wx nuOA== X-Gm-Message-State: ALQs6tA2bo+/eQV/G1JuXOD7RTJPZkMClXt+4nxp84Y9SZDzKKOftfRe vhKgXOoBrfwWOvn20nIjX+k8p7E6hawB7EX+2LA= X-Google-Smtp-Source: AIpwx48sghgTnhhS5JdrDz36rDdPCo34SMomtCacn+/UYU2PFylK23ZBe/Jg+gA7HiNZnyZ37Bg+jrxDymC2mQMknjU= X-Received: by 10.101.86.8 with SMTP id l8mr2132645pgs.182.1523979641348; Tue, 17 Apr 2018 08:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.226.131 with HTTP; Tue, 17 Apr 2018 08:40:20 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Tue, 17 Apr 2018 08:40:20 -0700 Message-ID: To: n-sakimura Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="089e08234a502ae834056a0d2910" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:40:45 -0000 --089e08234a502ae834056a0d2910 Content-Type: text/plain; charset="UTF-8" I'd like to coordinate a side meeting with Nat, Brian, myself and other interested parties in Montreal to discuss Distributed OAuth. If we have two meetings, I'd like a timeslot in the second to summarize the side meeting and discuss next steps (if any). Separately, I'd like a time slot for an update on Reciprocal OAuth. On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura wrote: > No, not really. I was thinking of more informal thing. The session is > supposed to be Wednesday afternoon, so I was thinking that it might be a > good idea to do a bit of recap among contributors to draw up a battle plan > towards IETF 102. > > > > Nat > > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Wednesday, March 07, 2018 9:22 PM > *To:* n-sakimura > *Cc:* Brian Campbell ; oauth > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > Nat, > > > > Are you asking for an interim meeting? > > We could schedule the Distributed OAuth discussion for the Wednesday > meeting; that will give you guys sometime to discuss these face-to-face in > London. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distributed > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for > which will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC > has concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use any > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new milestone > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e08234a502ae834056a0d2910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to coordinate a side meeting with Nat, Brian,= myself and other interested parties in Montreal to discuss Distributed OAu= th.

If we have two meetings, I'd like a timeslot in = the second to summarize the side meeting and discuss next steps (if any).

Separately, I'd like a time slot for an update = on Reciprocal OAuth.

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura= @nri.co.jp> wrote:

No, not really. I was th= inking of more informal thing. The session is supposed to be Wednesday afte= rnoon, so I was thinking that it might be a good idea to do a bit of recap among contributors to draw up a battle plan towa= rds IETF 102.

=C2=A0

Nat=

=C2=A0

From: = Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org>

=

Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

Nat,

=C2=A0

Are you asking for an interim m= eeting?

We could schedule the Distribut= ed OAuth discussion for the Wednesday meeting; that will give you guys some= time to discuss these face-to-face in London.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 7, 2018 at 2:00 AM,= n-sakimura <n= -sakimura@nri.co.jp> wrote:

Then let us do it. We ne= ed to put all the proposals on the table and strategize the design.

Perhaps we need a side m= eeting as well.

=C2=A0

nat

=C2=A0

From: = OAuth [mailto:oauth-= bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I hadn't previously been pl= anning on it but am happy to do so.

=C2=A0

On Tue, Mar 6, 2018 at 8:22 AM,= Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Nat,

=C2=A0

Brian, Hannes,

=C2=A0

Are you planning on presenting = your documents?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 5, 2018 at 8:09 PM,= Nat Sakimura <s= akimura@gmail.com> wrote:

I would be interested in hearin= g that.=C2=A0

=C2=A0

Also, as part of "Distribu= ted OAuth", can we do a bit of re-cap on some of the previous drafts o= n the similar topic as we discussed in the interim? i.e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oauth-meta)?=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

On Tue, Mar 6, 2018 at 3:30 AM = William Denniss <wdenniss@google.com> wrote:

Hannes & Rifaat,<= /u>


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (draft-wdennis= s-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).=

=C2=A0

I can also give an update on th= e status of Device Flow (draft-ietf-oauth-device-flow). I expect that = to be short now that WGLC has concluded and the document has advanced.

=C2=A0

Little late to this thread and = I see we already have 2 sessions in the draft agenda, but I'd like to a= dd my support to keeping both sessions, there's always a lot to discuss and in the past we've been able to use any spare time t= o discuss the security topics of the day.

=C2=A0

Regards,

William

=C2=A0

=C2=A0

= =C2=A0

On Tue, Jan 30, 2018 at 4:40 AM= Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think abo= ut the agenda for the next IETF meeting. Rifaat and I were wondering whethe= r we need one or two sessions. We would like to make the decision based on the topics we will discuss. Below you can find a fir= st version of the agenda with a few remarks. Let us know if you have commen= ts or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

OAuth Agenda

------------

=C2=A0

- Welcome and Status Update=C2=A0 (Chairs)

=C2=A0

=C2=A0 * OAuth Security Workshop Report

=C2=A0

=C2=A0=C2=A0* Documents in IESG processing

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-0= 8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-excha= nge-11

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates = only if needed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

-=C2=A0 JSON Web Token Best Current Practices

=C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

=C2=A0=C2=A0=C2=A0=

=C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this doc= ument.

=C2=A0=C2=A0 Most likely we will not get them during the f2f= meeting

=C2=A0=C2=A0=C2=A0but rather by reaching out to individuals = ahead of time.

=C2=A0=C2=A0=C2=A0=

-=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certi= ficate Bound Access Tokens=

=C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

=C2=A0

=C2=A0=C2=A0 Remark: Could be completed by the time of the I= ETF meeting.

=C2=A0=C2=A0=C2=A0=

- OAuth Security Topics

=C2=A0 # draft-ietf-oauth-security-topics-04

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: We could do a consensus call on parts of= the document soon.

=C2=A0=C2=A0

- OAuth 2.0 Token Binding=

=C2=A0 # draft-ietf-oauth-token-binding-05

=C2=A0

=C2=A0=C2=A0Remark: Document is moving along but we are lack= ing implementations.

=C2=A0=C2=A0

- OAuth 2.0 Device Posture Signals

=C2=A0 # draft-wdenniss-oauth-device-posture-01

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: Interest in the work but we are lacking = content (maybe even

=C2=A0=C2=A0expertise in the group)

=C2=A0

- Reciprocal OAuth=

=C2=A0 # draft-hardt-oauth-mutual-02

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on this topi= c and there is

=C2=A0=C2=A0interest in this work and apparently no competin= g solutions. The plan

=C2=A0 is to run a call for adoption once we are allowed to = add a new milestone

=C2=A0=C2=A0to our charter.

=C2=A0=C2=A0

- Distributed OAuth

=C2=A0 # draft-hardt-oauth-distributed-00

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on this topi= c and there is

=C2=A0=C2=A0interest in this work. Further work on the scope= is needed.

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you.

______________________________<= wbr>_________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

______________________________<= wbr>_________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura

Chairman of the Board, Open= ID Foundation

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.=C2=A0 If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.

=C2=A0


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


--089e08234a502ae834056a0d2910-- From nobody Tue Apr 17 13:19:10 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B94012E86A for ; Tue, 17 Apr 2018 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viYVDicbGMEJ for ; Tue, 17 Apr 2018 13:19:03 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AAB12E889 for ; Tue, 17 Apr 2018 13:18:58 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r184so12682697vke.11 for ; Tue, 17 Apr 2018 13:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wv2zIetsJ32EQkklCY+Ot+To5bxwLu5qhhXGE9ySd+c=; b=hAD6WyAx+2m5b0pwPyRJYE5u26cio/+m/ILfMHE1/ttL7dsGWrN09Uv+G8zq1rRIwF siilSPJybO3MUmL9V1wWhTrAHrzIkewbfjFNArYdxfydPBVHXnDj+Yj8PgE2LSs5/DQe HB+3Ip7AQLwQyYY1ySugR6xouftyVZ0S/15/QxMd8fAwXajynVEVVJMt03pOxlHCt6ib a3D30juvxBdn/VN3+FJEMdjlKYiCck0e/UrFZycK8qtRQL/bLcrTnuRRnRaY/leLAKkL ttOnRdMdp+6B02Ko+8dW+Ez9R28OsOWjYHIqhPv2AnUGT82srE0XMuGP85W0pa58wvNG pR7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wv2zIetsJ32EQkklCY+Ot+To5bxwLu5qhhXGE9ySd+c=; b=q/ttYwDTwjxleNMznCpSpedILWDntxfSCHmhWj1CDnc3L+UWs9/CZ7/KuZP6f4HwHk pD2w3JxqKTq4WOQlstArund+BUo2iPIN9CR6hGhTGG7n+PApLdehP6ppKinmhwNIWPlS rLzdvEua4hVCm+Sv6/y6/rcT4o6YIGINIciz0xOp3xy70J2I0n42ZfwbkhhJdzvD+1Fx cfaku8gpY9bmarcun3YsDFG6XS5pq2Ujqn8mURpMf+nMM88f9SqUOm8Lr6l1oUifoWLE aV5Rs/rBGEmcd+L5xs7sqbUFBywdinJi7YJpyni+dOPT502xkjqvsLWeuDnsDBKB1787 dL+Q== X-Gm-Message-State: ALQs6tBphyFC0jv2tvFPHEFWEpNl8KoH2VjATe/z1cUHVKIn6SJTRdrV VS8eJ7PRWudEfJKRYqrztpyeCe3fc+BR4FzQKuu8gp6kkVg= X-Google-Smtp-Source: AIpwx4+3rIyhekLiweHCQ2bZA85ZXw5MJf1TJTYiL+/UmTeFYqBJz/8C8F7bPZmvnUxmRKnfcsoKBkNFJ9qjTIrnT/M= X-Received: by 10.31.0.194 with SMTP id 185mr2578141vka.25.1523996337472; Tue, 17 Apr 2018 13:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.37 with HTTP; Tue, 17 Apr 2018 13:18:37 -0700 (PDT) In-Reply-To: <6BBA90E7-6496-42C8-A1AB-9D896ECFF120@amazon.com> References: <6BBA90E7-6496-42C8-A1AB-9D896ECFF120@amazon.com> From: William Denniss Date: Tue, 17 Apr 2018 13:18:37 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="001a113d9c3e563aa0056a110cc7" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 20:19:09 -0000 --001a113d9c3e563aa0056a110cc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1, I support the adoption of this document. I've encountered this problem in the wild for account linking scenarios, and I think it would be useful to have a standardized way to do it. On Tue, Apr 17, 2018 at 7:43 AM, Richard Backman, Annabelle < richanna@amazon.com> wrote: > I support the adoption of *Reciprocal OAuth* as a WG document. > > -- > Annabelle Richard Backman > Amazon =E2=80=93 Identity Services > > =EF=BB=BFOn 4/16/18, 8:20 AM, "OAuth on behalf of Hannes Tschofenig" < > oauth-bounces@ietf.org on behalf of Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > we had gotten positive feedback from the group on Reciprocal OAuth at > the virtual interim meeting earlier this year and also at the London IETF > meeting. > > We would therefore like to get a final confirmation on the mailing > list for the adoption of the *Reciprocal OAuth* as a WG document > https://tools.ietf.org/html/draft-hardt-oauth-mutual-02 > > Please, let us know if you support or object to the adoption of this > document by April 25th. > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113d9c3e563aa0056a110cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1, I support the adoption of th= is document.

I've encountered this problem in the = wild for account linking scenarios, and I think it would be useful to have = a standardized way to do it.


=
On Tue, Apr 17, 2018 at 7:43 AM, Richard Backman= , Annabelle <richanna@amazon.com> wrote:
I support the adoption of *Reciprocal OAuth* as a WG docum= ent.

--
Annabelle Richard Backman
Amazon =E2=80=93 Identity Services
=C2=A0
=EF=BB=BFOn 4/16/18, 8:20 AM, "OAuth on behalf of Hannes Tschofenig&qu= ot; <oauth-bounces@ietf.org on behalf of Hannes.Tschofen= ig@arm.com> wrote:

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 we had gotten positive feedback from the group on Reciprocal = OAuth at the virtual interim meeting earlier this year and also at the Lond= on IETF meeting.

=C2=A0 =C2=A0 We would therefore like to get a final confirmation on the ma= iling list for the adoption of the *Reciprocal OAuth* as a WG document
=C2=A0 =C2=A0 https://tools.ietf.org/html/draft-hardt-oauth-mutual-02

=C2=A0 =C2=A0 Please, let us know if you support or object to the adoption = of this document by April 25th.

=C2=A0 =C2=A0 Ciao
=C2=A0 =C2=A0 Hannes & Rifaat
=C2=A0 =C2=A0 IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the i= nformation in any medium. Thank you.

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
=C2=A0 =C2=A0 OAuth@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/oauth


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

--001a113d9c3e563aa0056a110cc7-- From nobody Tue Apr 17 14:09:11 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852361289B0 for ; Tue, 17 Apr 2018 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32L8nEFfsuuE for ; Tue, 17 Apr 2018 14:09:07 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF0412D9FF for ; Tue, 17 Apr 2018 14:09:05 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z73so39209207wrb.0 for ; Tue, 17 Apr 2018 14:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xygc6qiV+TNYEITG0+n+aYqlW/4rf6iEkEfRzmwEm2g=; b=EWxDEI/zqnR95iSIK47btH+Vvgr3mKER2HkNOi7gSJtZ3ydG8AAGQkQuKcOOep+Ua7 1nkYjyCHcSxw/jb7cSmtsVz3kZJVk51PAhtBZl1YfvYm2HE7bZBZtkkRBLWaQkdFYJXJ 1znAPmZlCuui0bB3F9/R9naZwSa1WrDX0PKjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xygc6qiV+TNYEITG0+n+aYqlW/4rf6iEkEfRzmwEm2g=; b=EU3c3iFxCCl1qyPMxKUQzFrcvo63DQ17A/JV0+cdkGXB35YrX/hqLePINEoIE/JuiP uCC2lEQkUFqv/6KCY6x0rAwpgkL+af58rv/gi5kmVPi1AXYvVsXLwRTSBdje3kMhQxuk EMc7UtBkbwgaGFLOtyw+UAlrneDuwMmzNLJ8DLhEPFrcq5vhoDAUPh37pmGe3aG4mzDE n/kyC4XEDyPgX9hTJ6vFI2ldxxaOT5B2vuUy/YONE3B54C+dZeSBUMGXjFeTDAhftjfN KdE7jRae1Q01T7RKJCd9VIVxPi9ALY1vUL3DLtsYsZM0A7S2iQD5N74/ldPPXb9gSKT6 uUZQ== X-Gm-Message-State: ALQs6tDPUb6cmCOtqAp4tkF6NUqwO1udgYyu0bEI14iYxgup7CRZ6imR tE3QLQsuYPwWFvzPgpJWO+FjlHzThwk= X-Google-Smtp-Source: AIpwx4/e3Ll1H9AMjPa65o/nMgvzTQD9uJeg5/8PGsox1t3rl6FfeME1pGwsvq+ZAgOrgzkhYeh84A== X-Received: by 10.28.198.77 with SMTP id w74mr2096747wmf.36.1523999343720; Tue, 17 Apr 2018 14:09:03 -0700 (PDT) Received: from guest2s-mbp.home (198.179.93.209.dyn.plus.net. [209.93.179.198]) by smtp.gmail.com with ESMTPSA id l131sm20102361wmb.36.2018.04.17.14.09.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 14:09:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Neil Madden In-Reply-To: Date: Tue, 17 Apr 2018 22:09:01 +0100 Cc: "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <79532099-B05C-4C22-83CE-E9CE2025B191@forgerock.com> References: To: Mike Jones X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 21:09:10 -0000 Hi Mike, I sent this originally back in June last year, I can see some of these = points have been addressed in -01, but not others, so I will include = further comments in-line below. (Apologies if I missed replies - I=E2=80=99= ve realised a few messages from this WG have ended up in my spam = folder). As a general point, the BCP is for JWT, but some of the advice (and my = points below) apply more generally to other JOSE objects (as pointed out = in the introduction). Should this be reflected in the title? > On 4 Jun 2017, at 15:11, Neil Madden = wrote: >=20 > I originally set this message just to the BCP authors. As requested by = Mike Jones, I am sending it here too: >=20 > Hi, >=20 > I've just seen this draft best-practice guide for JWTs pop up. I have = a number of suggestions for improvements. Mostly, I think the advice is = good but should be spelt out a bit more clearly. Here are some = suggestions: >=20 > 1. Explicitly spell out the ECDH-ES public key validation routines = from NIST. I have a blog post summarising them: = https://neilmadden.wordpress.com/2017/05/17/so-how-do-you-validate-nist-ec= dh-public-keys/ To be clear here, I think section 3.4 (Validate Cryptographic Inputs) = should have text along the lines of the following added: =E2=80=9CECDH-ES ephemeral public key (epk) inputs should be validated = according to the recipient=E2=80=99s chosen elliptic curve. For NIST = prime-order curves P-256, P-384 and P-521, validation MUST be performed = according to Section 5.6.2.3.4 =E2=80=9CECC Partial Public-Key = Validation Routine=E2=80=9D of NIST Special Publication 800-56A revision = 3 [1]. Where the X25519 or X448 curves of RFC 8037 [2] are used, then = the implementation MAY reject any ephemeral public key that produces an = all-zero ECDH shared secret as per RFC 7748 Section 6 [3]." [1] = https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd= f=20 [2] https://tools.ietf.org/html/rfc8037=20 [3] https://tools.ietf.org/html/rfc7748#section-6 I should note that the final sentence about validating X25519/X448 = public keys is not without some controversy. See = https://moderncrypto.org/mail-archive/curves/2017/000896.html for a = rabbit-hole discussion together with associated links. I do not feel confident to say what the right answer is for those curves = - whether to validate at all, and if so whether to blacklist bad public = keys or check for an all-zero shared secret. Perhaps we should get CFRG = input on this point? Or should we take RFC 7748 as being the considered = CFRG opinion on this topic (and so copy the =E2=80=9CMAY=E2=80=9D = wording)? > 2. Recommend that (despite the -ES) ECDH is safest when *both* keys = are ephemeral (eg you use some initial step to retrieve a fresh = authenticated ephemeral key from the other party).=20 I think this comment is not necessary in hindsight. While = fully-ephemeral ECDH has some advantages (as does static-static in some = cases, e.g. NaCl crypto_box), it=E2=80=99s a more complicated = discussion. For this BCP it is best to concentrate on ECDH-ES as = specified and ensure that implementations perform proper validation of = ephemeral public keys. > 3. Spell out how to authenticate ECDH ephemeral keys. For instance, = include an inner signed JWT that repeats the epk and possibly the = apu/apv claims too.=20 This is probably a more general point that none of the public-key = encryption modes in JOSE are authenticated. If sender authentication is = required then nested signed-and-encrypted objects should be used. > 4. Recommend that the apu and apv claims as a bare minimum include a = hash of both public keys and SHOULD include any other known identifiers.=20= Section 5.8.2 of NIST SP.800-56A rev 3 (referenced in point 1 above) = gives some advice on the kinds of things that should be included here. = Appendix B of the same document provides some rationale for why this = should be done, as does RFC 7748 Section 7 (Security Considerations). = RFC 7518 (JWA) Section 4.6.2 already normatively references NIST = SP.800-56A, but only for =E2=80=9Capplications wishing to conform to = [NIST.800-56A]=E2=80=9D. In my opinion, this should be strengthened in = this BCP to a SHOULD/RECOMMENDED. > 5. Recommend that the receiving party recalculates the apu and apv = claims from known inputs to check they match. (Or leave these out of the = JWT and require the other party to recalculate them). > 6. Provide explicit key lifetime requirements. E.g., for AES GCM this = should not exceed 2^32 messages for randomly-generated IVs, and not = exceed 2^64 *blocks* in total (so unless you restrict JWT lengths to = less than 2^32 blocks and use a message counter as IV then this also = limits to 2^32 messages). For CBC it should not exceed 2^48 messages.=20 I withdraw this comment, RFC 7518 Section 8.2 already addresses this = point. > 7. Require that the "alg" and "enc" claims are ONLY used to reject = unexpected algorithms, NEVER to select an algorithm (even amongst a = "supported" set). Cryptographic agility should be achieved by using = "kid" claims that reference one of a set of known keys and the key = should specify the algorithm (either explicitly or by the key = parameters/size).=20 I think this is now adequately addressed by section 3.1. > 8. Deprecate or strongly recommend against all of the RSA encryption = modes except OAEP-256.=20 > 9. Strongly discourage any use of compression with encrypted JWEs - it = is too easy to leak sensitive information.=20 > 10. Recommend that if a JWE is used to encrypt a password or other = value for which knowing the length may be a weakness, that such fields = are explicitly padded by the application or at least use CBC mode to = reduce the amount of length information leaked to a multiple of the AES = block size.=20 These last two points are related: encryption hides everything apart = from the length of a plaintext. Compression varies the length based on = the content. The combination of the two weakens the security of the = encryption, but the length may already be sensitive. Applications should = consider what information might be leaked in these cases and make = informed decisions about whether to pad or compress content before = encryption. > 11. Require constant-time comparisons of HMAC tags.=20 This point is already covered by RFC 7518 Section 3.2. > 12. Recommend using deterministic ECDSA signatures as described in RFC = 6979 to minimise the risk of leaking the private key.=20 > 13. Recommend that if the ECDH calculation produces an all-zero shared = secret that this is rejected.=20 This is covered in my suggestion in point 1. > 14. Never produce a signed JWT containing a "sub" claim unless you are = explicitly vouching for the identity of that subject. It is far too easy = to accidentally produce valid OIDC id tokens from unrelated code! I think this is now covered by the section on explicit typing.=20 Explicit typing is a welcome addition. A complementary approach would be = to recommend using different cryptographic keys for different types of = JWTs. One way to achieve this for symmetric algorithms or ECDH would be = to use a key-derivation function to derive unique keys based on some = domain separation string. I find the discussion in section 3.2 about the =E2=80=9Cnone=E2=80=9D = algorithm unnecessary for the BCP. I would say using =E2=80=9Cnone=E2=80=9D= should not be a recommended best practice. A colleague recently shared this pen-tester JWT cheat-sheet with me: = https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_security_cheat= sheet.pdf which hints at a few other points worth mentioning (I can = draft text for these if you wish): - If the =E2=80=9Ckid=E2=80=9D header is used to perform a lookup in a = database then there is a risk of SQL/LDAP injection if the value is not = validated first or appropriate interfaces used (e.g. prepared = statements). - The =E2=80=9Cjwk=E2=80=9D header should not be directly trusted, but = only ever used to match a known key. Likewise, I=E2=80=99d say the = =E2=80=9Cjku=E2=80=9D header should really be matched against a known = whitelist before being trusted, as it might additionally lead to SSRF = attacks if the server can be tricked into loading arbitrary URLs. Kind regards, Neil= From nobody Tue Apr 17 17:28:34 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A621271DF for ; Tue, 17 Apr 2018 17:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ANCqmq39CyY for ; Tue, 17 Apr 2018 17:28:31 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A67126579 for ; Tue, 17 Apr 2018 17:28:31 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id f14-v6so49362wre.4 for ; Tue, 17 Apr 2018 17:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M2/8Z14IGezWTM1htfgKkbsMBOdIQcPVnWqltT1Tsy0=; b=EfctmQHGrH95ZPTA9YiN4dadvVF/D6kTxKo8Ww2qIbv57lOn433mUS8cXL6Gh9kM8/ CPQpxVDF3hsnFMFc6JrXWjs3lvT+C1hpVl5HC1NdlPh1L4DcRTNdsnNhVuYCs9U7a7Xs RWGBdyodXgDqoPS3acp+V6EcrUl8QC9K7HTsJFmpx92lmUHiKlHQdE+mV8P8/7+VP8Le E6tv2Az4yx+wxASXpml2MwzDgXh1BK96AaSDMMPIftFaktpZnqX30GZzRvHjSATl3RMD BqI7IC47Nsd7d1xGNciNcaSeZbZdaTbXSSV+y4Xi3Qi4GXDmFD28sJppdy67o0w5NqKl OPJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M2/8Z14IGezWTM1htfgKkbsMBOdIQcPVnWqltT1Tsy0=; b=ZtawYFMCnOUZpIMTknLxneedGB2eiQPtmBX2z2N+4WtogHJuXBgyP/d79sx+/GOkXV DKEo3dy9d1o/RnNSseBfhpUY+V63Adz6d+9xafUmPTTTl7H17UwlHo28SEL63wVHqRzl CG5lYyupsfGH4Drpb2kXZ5dwVjKsXop2z93XEUOZYywjP+keRGzI0Gb+RBW8ns9ltI3P cp5cTj+lqUXxQDMju2oNDG05J+7edtST32EinUXEOJQPAll4hvQucT4g4Ncxc5Mtl+oZ jnGaH+l03XbdpVKWavUbDlqgFnKB+hvyb0zZjUNi1hATNfGE7cq0DHzozqFBbA7yOaqL pOCg== X-Gm-Message-State: ALQs6tCQLh8xdS8hVLoeGQc3J9hpLCyLLadPGMpqtL/8+/arNk581Jg1 Tex0z2VcJIPi1orIOf5/VwvihUJSKwY3IgukNmW0oA== X-Google-Smtp-Source: AIpwx48j106XiPCLIcuUS4pnU0/8KVvHoZ8W4f/DHfI9HR6R4mmZUG9NLq02jAjJpyjqdkQdIe1CsRi31/mXatohlL4= X-Received: by 10.28.202.26 with SMTP id a26mr187628wmg.120.1524011309259; Tue, 17 Apr 2018 17:28:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Bradley Date: Wed, 18 Apr 2018 00:28:18 +0000 Message-ID: To: Rifaat Shekh-Yusef Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="089e082fa1c0b8f231056a148841" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 00:28:33 -0000 --089e082fa1c0b8f231056a148841 Content-Type: text/plain; charset="UTF-8" +1 for adoption. On Mon, Apr 16, 2018, 7:47 AM Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption of > the *OAuth 2.0 Incremental Authorization* as a WG document > https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ > > Please, let us know if you support or object to the adoption of this > document. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e082fa1c0b8f231056a148841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption.

On Mon, Apr 16, 2018, 7:47 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= /div>
All,

We= would like to get a confirmation on the mailing list for the=C2=A0adoption<= span style=3D"font-size:12.8px">=C2=A0of the=C2=A0OAuth 2.0 Incremental Authorization=C2=A0as a = WG document

Please, let us know if you suppo= rt or object to the=C2=A0adoption=C2=A0of this do= cument.

Regards,
=C2=A0Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--089e082fa1c0b8f231056a148841-- From nobody Tue Apr 17 17:35:18 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD969127333 for ; Tue, 17 Apr 2018 17:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kfS0560XudT for ; Tue, 17 Apr 2018 17:35:14 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315A1127241 for ; Tue, 17 Apr 2018 17:35:14 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r184so14867vke.11 for ; Tue, 17 Apr 2018 17:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/+9A7VYhs371hAVqLlLbfk65xeY7lo+TjdpOtyXBxR4=; b=Q2nNsXUvGE4jJikVjPH9fy9QT0MBj97obnGzf+k2yapxqqggxD8jB9rkXaUuY2Tz4o 1QRTxmdV7XpcHn7zaNc1v0RO4UoTAp+0Mz4E2IkLhGpKrtNAq+lmo42umpb263IXDRih Ga9BPkbKnVQW+dOPrrVLj2BeSmx+tRIwFlhZ6BRGQTetmEFMtCK2I04UKMT/TiaWmsae 6KAgsmrsEZYf+MubyEuAB3eClNzgFza7JN6erY4lcmDQvTqP4TMovpkeTlWLtiB7Cwhe LiuC9el269piBUsGbBOHF02PJ3r9B+1Ny22hgLxHKdruoSGQr+Du732Z3ubmsF32Rzb4 Io/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/+9A7VYhs371hAVqLlLbfk65xeY7lo+TjdpOtyXBxR4=; b=f29XhaUiiGKSOAt2YLHSm2ymuVGTLKtA867B+qw3lC7ANYA5CuAwERvdPxjxLlVZJI TXIkMaxu9nSaQFV72TMk6zN1t8QiMK0rd3rXrevXqeeyUFQvq1IKRhco/uHzFzkeW0EZ XmBduhgzZ6hpCUOrhg8spekpbLnNbbHLc9EdkwgcdpEAhCByStke0e7WlJFWixhMZYi1 R4Xp3n7/4ZtTQU3TYs9TmpJfaNV2hNUM089i+VFwbCdb2oE+74HrJJZTo7XgtXZzHgNX 9jp6TVhJgK8EFcRpbm0dal9fKmS+mjXutraE7jakLPfuqiOLLv2aE4jKmgAu/MAtNWA5 oDCg== X-Gm-Message-State: ALQs6tBAIFLGK5iwbxhsEFshQjTrmmLBfVLbEE5jPrdxwWzfGbCU2H23 kVB7vt/2Ae85/86vpPg59tBiT9xlnc+IMgTc0Qg22w== X-Google-Smtp-Source: AIpwx48eNxj8eFTOf2uJMF3vJwpkgXOnu+e2RdhY0iamevchTUcZ4taYULtM46btsmpiUsao1BDHON/abRDXiuNS9dA= X-Received: by 10.31.84.194 with SMTP id i185mr3112699vkb.56.1524011712801; Tue, 17 Apr 2018 17:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.37 with HTTP; Tue, 17 Apr 2018 17:34:52 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Tue, 17 Apr 2018 17:34:52 -0700 Message-ID: To: John Bradley Cc: Rifaat Shekh-Yusef , IETF oauth WG Content-Type: multipart/alternative; boundary="001a114e5222c6e95d056a14a08c" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 00:35:17 -0000 --001a114e5222c6e95d056a14a08c Content-Type: text/plain; charset="UTF-8" As the author, I support the adoption of this document by the working group. I'd like to note that there was a hum for adoption during IETF 101 as well, recorded in the minutes as so: "Hum for adoption: A positive hum for adoption was received (no hums against)." For context, my IETF presentations on the topic are here: Incremental Auth @ IETF99 Incremental Auth @ IETF101 The draft documents two incremental authorization techniques, as implemented today on Google's OAuth server. On Tue, Apr 17, 2018 at 5:28 PM, John Bradley wrote: > +1 for adoption. > > On Mon, Apr 16, 2018, 7:47 AM Rifaat Shekh-Yusef > wrote: > >> All, >> >> We would like to get a confirmation on the mailing list for the adoption of >> the *OAuth 2.0 Incremental Authorization* as a WG document >> https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ >> >> Please, let us know if you support or object to the adoption of this >> document. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114e5222c6e95d056a14a08c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As the author, I support the ado= ption of this document by the working group.

I'd l= ike to note that there was a hum for adoption during IETF 101 as well, reco= rded in the=C2=A0minutes=C2=A0as so: "Hum for adoption:= =C2=A0 A positive hum for adoption was received (no hums against)."
For context, my IETF presentations on the topic are here:<= br>

The draft documents two incremental authorization = techniques, as implemented today on Google's OAuth server.


On Tue, Apr 17= , 2018 at 5:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
+1 for adoption.
On Mon= , Apr 16, 2018, 7:47 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

We= would like to get a confirmation on the mailing list for the=C2=A0adoption=C2=A0of the=C2= =A0OAuth 2.0 Incremental Authori= zation=C2=A0as a WG document
<= a href=3D"https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental= -auth/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/<= wbr>doc/draft-wdenniss-oauth-incremental-auth/

<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial">P= lease, let us know if you support or object to the=C2=A0adoption=C2=A0of this document.

Regards,
=C2=A0Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

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


--001a114e5222c6e95d056a14a08c-- From nobody Tue Apr 17 22:33:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ECA12D72F for ; Tue, 17 Apr 2018 22:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjeBn0C9b6Gx for ; Tue, 17 Apr 2018 22:33:49 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688611201F8 for ; Tue, 17 Apr 2018 22:33:48 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 3464A17EA45; Wed, 18 Apr 2018 14:33:47 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id AC9E14E0046; Wed, 18 Apr 2018 14:33:46 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w3I5XkqZ005648; Wed, 18 Apr 2018 14:33:46 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id w3I5XkKg005647; Wed, 18 Apr 2018 14:33:46 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w3I5XkXX008231; Wed, 18 Apr 2018 14:33:46 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w3I5XkK1008230; Wed, 18 Apr 2018 14:33:46 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w3I5Xk4p008227; Wed, 18 Apr 2018 14:33:46 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Apr 2018 14:33:44 +0900 Received: from APC01-PU1-obe.outbound.protection.outlook.com (65.55.88.24) by ex.nri.co.jp (192.51.23.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Apr 2018 14:33:44 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yWqhsVjtxwPDwt3X4/bM0MHcPRKw2KXwPtXM6348m6g=; b=kmP2UFpMau45ZUfLs1Z5s25egDlHLBF4zgT141O0y0Dg4+4A2CpjTpliQVRiTP3woLE9dHesEAPMOwzmB0RzKlYyVgU6BO0WhHJ7xdErjxxeJcFbh3BSlwmBu0H3TtRkyx8zpM2/EOgLUNruCMGa0TyTNXMpC/ETJ909iJCbdLA= Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com (52.133.184.14) by TY2PR01MB2218.jpnprd01.prod.outlook.com (52.133.184.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Wed, 18 Apr 2018 05:33:42 +0000 Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::5573:a8cf:2ffb:1ef7]) by TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::5573:a8cf:2ffb:1ef7%13]) with mapi id 15.20.0696.011; Wed, 18 Apr 2018 05:33:38 +0000 From: n-sakimura To: Dick Hardt , n-sakimura CC: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXAAC0wAgAAcFChAB/jIZAAAHQ9wXQ== Date: Wed, 18 Apr 2018 05:33:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cu.nri.co.jp; x-originating-ip: [58.49.31.53] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB2218; 7:UQ/L3zoI22SiARBN/LC1lD5/qHfmcBFd9yJnqG85VA/Mq1xz4z6ExUQlSU37Lo1o4BiWS1mvFbDEitF89cz9mDuptAR8vl/eIMOotxaHy/qqDSLJAeE9xKhBl6fiJC4sxJv45mbmE7qDEyg5vcmT4Y218H2WdebwalhyEjMVOxVMeZdeJvramVl/BE8Gh3uUuzZk8Ek1BHA1WV0Y3TfRg73CFSfZg/DfhDhxMyC5vQZT8Lu1fLjExmRVWUwNdDpX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB2218; x-ms-traffictypediagnostic: TY2PR01MB2218: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123564045)(20161123560045)(20161123562045)(2016111802025)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:TY2PR01MB2218; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB2218; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(39840400004)(376002)(346002)(40434004)(53754006)(365934003)(66066001)(186003)(5660300001)(6436002)(55016002)(53936002)(39060400002)(26005)(74482002)(53946003)(54896002)(9686003)(6246003)(236005)(6306002)(76176011)(3660700001)(93886005)(33656002)(966005)(97736004)(19627405001)(8936002)(229853002)(102836004)(3280700002)(6606003)(14454004)(7696005)(86362001)(4326008)(25786009)(6116002)(478600001)(53546011)(5250100002)(81166006)(8676002)(6506007)(2906002)(606006)(11346002)(3846002)(110136005)(99286004)(2900100001)(476003)(316002)(446003)(54906003)(74316002)(5890100001)(7736002)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB2218; H:TY2PR01MB2297.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; x-microsoft-antispam-message-info: LRESJ8rzKqio494tYhQfJxs633BlQmfzZ1hri6s8tFNOBU2l00J42cyR35vXajvuzhKJ5mf3oLzA6CFDxtKIQiVLQVsMXXS8+ocP/86AkdeWAuoekNTFvcdrlki95U8swqE2ZUNEEetyzGdl3eacO1D9Vi23wSJJFaHVyCJg/uB2xGzpyJJzoL00pL6aVcjG spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB2297C4899D098F0B9341D84BF9B60TY2PR01MB2297jpnp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9d18f102-e45d-475f-9151-08d5a4edf05e X-MS-Exchange-CrossTenant-Network-Message-Id: 9d18f102-e45d-475f-9151-08d5a4edf05e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 05:33:38.8946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2218 X-OrganizationHeadersPreserved: TY2PR01MB2218.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:33:53 -0000 --_000_TY2PR01MB2297C4899D098F0B9341D84BF9B60TY2PR01MB2297jpnp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I support the idea. Adding to it, perhaps we can do an ad-hoc before Montre= al so that we can come up with a combined draft. Nat Sakimura -- PLEASE READ: This e-mail is confidential and intended for the named recipie= nt only. If you are not an intended recipient, please notify the sender and= delete this e-mail. ________________________________ =1B$B:9=3DP?M=1B(B: Dick Hardt =1B$BAw?.F|;~=1B(B: 2018=1B$BG/=1B(B4=1B$B7n=1B(B18=1B$BF|=1B(B 0:40:20 =1B$B08@h=1B(B: n-sakimura CC: Rifaat Shekh-Yusef; oauth =1B$B7oL>=1B(B: Re: [OAUTH-WG] Call for agenda items ****************************************************************** =1B$BK\%a!<%k$O%U%j!<%a!<%k$+$iFO$$$F$$$^$9!#I8E*7?967b%a!<%k$O%U%j!<%a=1B(= B =1B$B!<%k$+$iFO$/$3$H$,$"$j$^$9$N$G$4Cm0U$/$@$5$$!#?H$K3P$($N$J$$%a!<%k=1B(= B =1B$B$G$"$l$PE:IU%U%!%$%k$d=1B(BURL=1B$B$r3+$+$:!"0J2<$K7G:\$5$l$F$$$k$C=1B(B =1B$B$FBP1~$r$*4j$$$7$^$9!#=1B(B =1B$B6&M->pJs=1B(B>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B>=1B$B2x$7$$%a!<%k$,= FO$$$?$i=1B(B =1B$B$^$?$O!"=1B(B NRI Group Security Portal>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B >=1B$B2x$7$$%a!<%k$,FO$$$?$i=1B(B ****************************************************************** I'd like to coordinate a side meeting with Nat, Brian, myself and other int= erested parties in Montreal to discuss Distributed OAuth. If we have two meetings, I'd like a timeslot in the second to summarize the= side meeting and discuss next steps (if any). Separately, I'd like a time slot for an update on Reciprocal OAuth. On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura > wrote: No, not really. I was thinking of more informal thing. The session is suppo= sed to be Wednesday afternoon, so I was thinking that it might be a good id= ea to do a bit of recap among contributors to draw up a battle plan towards= IETF 102. Nat From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] Sent: Wednesday, March 07, 2018 9:22 PM To: n-sakimura > Cc: Brian Campbell >; oauth > Subject: Re: [OAUTH-WG] Call for agenda items Nat, Are you asking for an interim meeting? We could schedule the Distributed OAuth discussion for the Wednesday meetin= g; that will give you guys sometime to discuss these face-to-face in London= . Regards, Rifaat On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura > wrote: Then let us do it. We need to put all the proposals on the table and strate= gize the design. Perhaps we need a side meeting as well. nat From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Campbell Sent: Wednesday, March 07, 2018 1:31 AM To: Rifaat Shekh-Yusef = > Cc: oauth > Subject: Re: [OAUTH-WG] Call for agenda items I hadn't previously been planning on it but am happy to do so. On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: Nat, During the interim meeting, 3 drafts mentioned in the context of Distribute= d OAuth: https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 Brian, Hannes, Are you planning on presenting your documents? Regards, Rifaat On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura > wrote: I would be interested in hearing that. Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of = the previous drafts on the similar topic as we discussed in the interim? i.= e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oau= th-meta)? Best, Nat On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: Hannes & Rifaat, I would like the opportunity to present on OAuth 2.0 Incremental Authorizat= ion (draft-wdenniss-oauth-incremental-auth) [an update for which will be po= sted today] and "OAuth 2.0 Device Posture Signals" (draft-wdenniss-oauth-de= vice-posture). I can also give an update on the status of Device Flow (draft-ietf-oauth-de= vice-flow). I expect that to be short now that WGLC has concluded and the d= ocument has advanced. Little late to this thread and I see we already have 2 sessions in the draf= t agenda, but I'd like to add my support to keeping both sessions, there's = always a lot to discuss and in the past we've been able to use any spare ti= me to discuss the security topics of the day. Regards, William On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig > wrote: Hi all, It is time already to think about the agenda for the next IETF meeting. Rif= aat and I were wondering whether we need one or two sessions. We would like= to make the decision based on the topics we will discuss. Below you can fi= nd a first version of the agenda with a few remarks. Let us know if you hav= e comments or suggestions for additional agenda items. Ciao Hannes & Rifaat OAuth Agenda ------------ - Welcome and Status Update (Chairs) * OAuth Security Workshop Report * Documents in IESG processing # draft-ietf-oauth-device-flow-07 # draft-ietf-oauth-discovery-08 # draft-ietf-oauth-jwsreq-15 # draft-ietf-oauth-token-exchange-11 Remark: Status updates only if needed. - JSON Web Token Best Current Practices # draft-ietf-oauth-jwt-bcp-00 Remark: We are lacking reviews on this document. Most likely we will not get them during the f2f meeting but rather by reaching out to individuals ahead of time. - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access = Tokens # draft-ietf-oauth-mtls-06 Remark: Could be completed by the time of the IETF meeting. - OAuth Security Topics # draft-ietf-oauth-security-topics-04 Remark: We could do a consensus call on parts of the document soon. - OAuth 2.0 Token Binding # draft-ietf-oauth-token-binding-05 Remark: Document is moving along but we are lacking implementations. - OAuth 2.0 Device Posture Signals # draft-wdenniss-oauth-device-posture-01 Remark: Interest in the work but we are lacking content (maybe even expertise in the group) - Reciprocal OAuth # draft-hardt-oauth-mutual-02 Remark: We had a virtual interim meeting on this topic and there is interest in this work and apparently no competing solutions. The plan is to run a call for adoption once we are allowed to add a new milestone to our charter. - Distributed OAuth # draft-hardt-oauth-distributed-00 Remark: We had a virtual interim meeting on this topic and there is interest in this work. Further work on the scope is needed. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura Chairman of the Board, OpenID Foundation _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_TY2PR01MB2297C4899D098F0B9341D84BF9B60TY2PR01MB2297jpnp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I support the idea. Adding to it,= perhaps we can do an ad-hoc before Montreal so that we can come up with a = combined draft. 


Nat Sakimura

--

PLEASE READ: This e-mail = is confidential and intended for the named recipient only. If you are not a= n intended recipient, please notify the sender and delete this e-mail.





=1B$B:9=3DP?M=1B(B: Dick Ha= rdt <dick.hardt@gmail.com>
=1B$BAw?.F|;~=1B(B: 2018=1B$BG/=1B(B4=1B$B7n=1B(B18=1B$BF|=1B(B 0:40= :20
=1B$B08@h=1B(B: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=1B$B7oL>=1B(B: Re: [OAUTH-WG] Call for agenda items
 
******************************************************************
=1B$BK\%a!<%k$O%U%j!<%a!<%k$+$iFO$$$F$$$^$9!#I8E*7?967b%a!<%k$O%U%j!<%a=1B(= B
=1B$B!<%k$+$iFO$/$3$H$,$"$j$^$9$N$G$4Cm0U$/$@$5$$!#?H$K3P$($N$J$$%a!<%k=1B(= B
=1B$B$G$"$l$PE:IU%U%!%$%k$d=1B(BURL=1B$B$r3+$+$:!"0J2<$K7G:\$5$l$F$$$k$C=1B(B
=1B$B$FBP1~$r$*4j$$$7$^$9!#=1B(B

=1B$B6&M->pJs=1B(B>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B>=1B$B2x$7$$%a= !<%k$,FO$$$?$i=1B(B
=1B$B$^$?$O!"=1B(B
NRI Group Security Portal>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B
>=1B$B2x$7$$%a!<%k$,FO$$$?$i=1B(B
******************************************************************
I'd like to coordinate a side meeting with Nat, Brian, mys= elf and other interested parties in Montreal to discuss Distributed OAuth.

If we have two meetings, I'd like a timeslot in the second to summariz= e the side meeting and discuss next steps (if any).

Separately, I'd like a time slot for an update on Reciprocal OAuth.

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura@nr= i.co.jp> wrote:

No, not really. I wa= s thinking of more informal thing. The session is supposed to be Wednesday = afternoon, so I was thinking that it might be a good idea to do a bit of recap among contributors to draw up a battle plan= towards IETF 102.

 =

Nat

 =

From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for agenda items

 

Nat,

 

Are you asking for an interim= meeting?

We could schedule the Distrib= uted OAuth discussion for the Wednesday meeting; that will give you guys so= metime to discuss these face-to-face in London.

 

Regards,=

 Rifaat

 

 

 

On Wed, Mar 7, 2018 at 2:00 A= M, n-sakimura <n-sakimura@nri.co.jp> wrote:

Then let us do it. W= e need to put all the proposals on the table and strategize the design.

Perhaps we need a si= de meeting as well.

 

nat

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

 

I hadn't previously been plan= ning on it but am happy to do so.

 

On Tue, Mar 6, 2018 at 8:22 A= M, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Nat,

 

Brian, Hannes,<= span lang=3D"EN-US">

 

Are you planning on presentin= g your documents?

 

Regards,=

 Rifaat

 

 

 

 

 

 

On Mon, Mar 5, 2018 at 8:09 P= M, Nat Sakimura <sakimura@gmail.com> wrote:

I would be interested in hear= ing that. 

 

Also, as part of "Distri= buted OAuth", can we do a bit of re-cap on some of the previous drafts= on the similar topic as we discussed in the interim? i.e., Brian's draft (= where is the link now?) and my draft (dra= ft-sakimura-oauth-meta)? 

 

Best, 

 

Nat

 

On Tue, Mar 6, 2018 at 3:30 A= M William Denniss <wdenniss@google.com> wrote:

Hannes & Rifaat,


I would like the opportunity to present on OAuth 2.0 Incremental Authorization (draft-wden= niss-oauth-incremental-auth) [an update for which will be posted today] and "OAuth 2.0= Device Posture Signals" (draft-wdenniss-oauth-device-posture).

 

I can also give an update on = the status of Device Flow (draft-ietf-oauth-device-flow). I expect tha= t to be short now that WGLC has concluded and the document has advanced.=

 

Little late to this thread an= d I see we already have 2 sessions in the draft agenda, but I'd like to add= my support to keeping both sessions, there's always a lot to discuss and i= n the past we've been able to use any spare time to discuss the security topics of the day.=

 

Regards,=

William<= /p>

 

 

 

On Tue, Jan 30, 2018 at 4:40 = AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:<= /p>

Hi all,

 

It is time already to think a= bout the agenda for the next IETF meeting. Rifaat and I were wondering whet= her we need one or two sessions. We would like to make the decision based o= n the topics we will discuss. Below you can find a first version of the agenda with a few remarks. Let us know= if you have comments or suggestions for additional agenda items.

 

Ciao
Hannes & Rifaat

 

OAuth Agenda

------------

 

- Welcome and Status Update  (Chairs)

 

  * OAuth Security Workshop Report

 

  * Documents in IESG processing

     # draft-ietf-oauth-device-flow-07

     # draft-ietf-oauth-discovery= -08

     # draft-ietf-oauth-jwsreq-15=

     # draft-ietf-oauth-token-exc= hange-11

     

       Remark: Status update= s only if needed.

       

-  JSON Web Token Best Current Practices

   # draft-ietf-oauth-jwt-bcp-00

   

   Remark: We are lacking reviews on this d= ocument.

   Most likely we will not get them during the f= 2f meeting

   but rather by reaching out to individual= s ahead of time.

   

-  OAuth 2.0 Mutual TLS Client Authentication and Cer= tificate Bound Access Tokens

   # draft-ietf-oauth-mtls-06

 

   Remark: Could be completed by the time of the= IETF meeting.

   

- OAuth Security Topics=

  # draft-ietf-oauth-security-topics-04

  

  Remark: We could do a consensus call on parts = of the document soon.

  

- OAuth 2.0 Token Binding

  # draft-ietf-oauth-token-binding-05

 

  Remark: Document is moving along but we are la= cking implementations.

  

- OAuth 2.0 Device Posture Signals

  # draft-wdenniss-oauth-device-posture-01

  

  Remark: Interest in the work but we are lackin= g content (maybe even

  expertise in the group)

 

- Reciprocal OAuth

  # draft-hardt-oauth-mutual-02

 

  Remark: We had a virtual interim meeting on this to= pic and there is

  interest in this work and apparently no compet= ing solutions. The plan

  is to run a call for adoption once we are allowed t= o add a new milestone

  to our charter.

  

- Distributed OAuth<= /u>

  # draft-hardt-oauth-distributed-00

 

  Remark: We had a virtual interim meeting on this to= pic and there is

  interest in this work. Further work on the sco= pe is needed.

IMPORTANT NOTICE: The content= s of this email and any attachments are confidential and may also be privil= eged. If you are not the intended recipient, please notify the sender immed= iately and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura

Chairman of the Board, Open= ID Foundation


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may contain confidential a= nd privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by othe= rs is strictly prohibited.  If you have received this communication in= error, please notify the sender immediately by e-mail and delete the messa= ge and any file attachments from your computer. Thank you.

 


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


--_000_TY2PR01MB2297C4899D098F0B9341D84BF9B60TY2PR01MB2297jpnp_-- From nobody Tue Apr 17 22:37:41 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C79D12D72F for ; Tue, 17 Apr 2018 22:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TIYUSJZeBPZ for ; Tue, 17 Apr 2018 22:37:37 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512781201F8 for ; Tue, 17 Apr 2018 22:37:37 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f132so317871pgc.10 for ; Tue, 17 Apr 2018 22:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SjhsW0krjRVpskwfERkxtBUEJDADkkvfMcOV6C/vjbA=; b=ldx28nduIbSj9xLz4bZxSfwrxuenJOLlxYrleCvhaUKuzEmIksxb+ubrO3jkrHtYk/ k0iPy6lwjzsPKhCI9mWU9Boz01ayAK6vAEBLftLfBq//zo/QiJinElZ0SRN2HTuNstx9 XVjA64D/3vvQiBe0pZ4SYSt906GMfVWTdL2ZQkSTxj3Vj56iFHZioOgI3uvgVUWbZXaI HW+PAVGkhXXJG2IAUzFMPza6iWc24vWfJGfHfIbUI3SRPPNeyx1t0Ctq6D+qJ2zDZ1Td BjShdIbTk3Zqvkb0mQGWLrHLESyMX2qJS3abePjs8fTUgJKPyEbxK5m8HzVLP/kte8v0 Jf7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SjhsW0krjRVpskwfERkxtBUEJDADkkvfMcOV6C/vjbA=; b=CV8FTapbXv7Q4hegld5cAgI/HtP4ot1Y+VrJ0ij5z88x9R7NZYwkgVYQA3HyZ4Kt0G ooXy7Q8fKeNIJNdQBqJvk5dCWVG7Ytae0ijTp12gxhhpqEel0COXoACfD6gZ0n05C16Q u972/Skyrzenx10ely72usjhod8n5xusbjVKDPjmt+lvyMo+4VLtzhV3jA5a152TNEVh kjosZ02q4SW4iP4IOkOYOyMz0M9ALO4UJrS7FbZR3lDBt42AZs4HRnqLI2/2skNr/5ac ayAhJaI38WJFZHYLOWEhJMt2ta/OJP65xcKHzax3ioSyODuJbtjN/Egf7VG7IcxiUfEd uTlw== X-Gm-Message-State: ALQs6tBesN7umUvg+j9YcqvZwI+x5PeczKBmTk3EHdoVLB4fZ7NGJygk HqefAQdiCIYrb+oAmBboN1K70ZWPy7NAz4SP2WE= X-Google-Smtp-Source: AIpwx4+oHiNoGjegfzz+5uI1P41ESDmt90o62MBdXmyFYbvJd0qSnLyPPOMTTAPqdK50D3z5NEBOHZkIa+e9810dEA0= X-Received: by 10.98.13.151 with SMTP id 23mr700121pfn.231.1524029856512; Tue, 17 Apr 2018 22:37:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 18 Apr 2018 05:37:24 +0000 Message-ID: To: n-sakimura Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="001a11431aa0398114056a18da47" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 05:37:40 -0000 --001a11431aa0398114056a18da47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m open to an ad-hoc authors meeting prior. That may be more productive than a WG meeting. On Tue, Apr 17, 2018 at 10:33 PM n-sakimura wrote: > I support the idea. Adding to it, perhaps we can do an ad-hoc before > Montreal so that we can come up with a combined draft. > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > ------------------------------ > *=E5=B7=AE=E5=87=BA=E4=BA=BA:* Dick Hardt > *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82:* 2018=E5=B9=B44=E6=9C=8818=E6=97= =A5 0:40:20 > *=E5=AE=9B=E5=85=88:* n-sakimura > *CC:* Rifaat Shekh-Yusef; oauth > *=E4=BB=B6=E5=90=8D:* Re: [OAUTH-WG] Call for agenda items > > ****************************************************************** > =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3= =81=84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92= =83=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 > =E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8= =E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6= =B3=A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81= =AB=E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB > =E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1= =E3=82=A4=E3=83=AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81= =E4=BB=A5=E4=B8=8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3= =81=84=E3=82=8B=E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3 > =E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 > > =E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD= =E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3= =82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5= =B1=8A=E3=81=84=E3=81=9F=E3=82=89 > =E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81 > NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5= =E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9 > >=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A= =E3=81=84=E3=81=9F=E3=82=89 > ****************************************************************** > I'd like to coordinate a side meeting with Nat, Brian, myself and other > interested parties in Montreal to discuss Distributed OAuth. > > If we have two meetings, I'd like a timeslot in the second to summarize > the side meeting and discuss next steps (if any). > > Separately, I'd like a time slot for an update on Reciprocal OAuth. > > On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura wrote: > > No, not really. I was thinking of more informal thing. The session is > supposed to be Wednesday afternoon, so I was thinking that it might be a > good idea to do a bit of recap among contributors to draw up a battle pla= n > towards IETF 102. > > > > Nat > > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Wednesday, March 07, 2018 9:22 PM > *To:* n-sakimura > *Cc:* Brian Campbell ; oauth > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > Nat, > > > > Are you asking for an interim meeting? > > We could schedule the Distributed OAuth discussion for the Wednesday > meeting; that will give you guys sometime to discuss these face-to-face i= n > London. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distrib= uted > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some o= f > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for whic= h > will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC h= as > concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use an= y > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Acces= s > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new mileston= e > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11431aa0398114056a18da47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m open to an ad-hoc authors meeting prior.=

That may be more produc= tive than a WG meeting.

On Tue, Ap= r 17, 2018 at 10:33 PM n-sakimura <n-sakimura@nri.co.jp> wrote:

I support the idea. Adding to it,= perhaps we can do an ad-hoc before Montreal so that we can come up with a = combined draft.=C2=A0


Nat Sakimura

--

PLEASE READ: This e-mail i= s confidential and intended for the named recipient only. If you are not an= intended recipient, please notify the sender and delete this e-mail.





=E5=B7=AE=E5=87=BA=E4= =BA=BA: Dick Hardt <dick.hardt@gmail.com>
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2018=E5=B9=B44=E6=9C=8818=E6= =97=A5 0:40:20
=E5=AE=9B=E5=85=88: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] Call for agenda items
=C2=A0
******************************************************************
=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3=81= =84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92=83= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 =E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8=E3= =81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6=B3= =A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81=AB= =E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB =E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1=E3= =82=A4=E3=83=AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81=E4= =BB=A5=E4=B8=8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81= =84=E3=82=8B=E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3
=E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97=E3= =81=BE=E3=81=99=E3=80=82

=E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82= =AD=E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF= =E3=82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =8C=E5=B1=8A=E3=81=84=E3=81=9F=E3=82=89
=E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81
NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5= =E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9 >=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1= =8A=E3=81=84=E3=81=9F=E3=82=89
******************************************************************
I'd like to coordinate a side meeting with Nat, Brian, myself and = other interested parties in Montreal to discuss Distributed OAuth.

If we have two meetings, I'd like a timeslot in the second to summ= arize the side meeting and discuss next steps (if any).

Separately, I'd like a time slot for an update on Reciprocal OAuth= .

On Wed, Mar 7, 2018 at 5= :52 PM, n-sakimura <n-sakimura@nr= i.co.jp> wrote:

No, not really. I was thinking of more informal thing. The session is sup= posed to be Wednesday afternoon, so I was thinking that it might be a good idea to do a bit of recap among contributors to draw up a battle plan= towards IETF 102.

=C2=A0

Nat

=C2=A0

From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for agenda items

= =C2=A0

Nat,=

= =C2=A0

Are you= asking for an interim meeting?

We coul= d schedule the Distributed OAuth discussion for the Wednesday meeting; that= will give you guys sometime to discuss these face-to-face in London.

= =C2=A0

Regards= ,

=C2=A0R= ifaat

= =C2=A0

= =C2=A0

= =C2=A0

On Wed,= Mar 7, 2018 at 2:00 AM, n-sakimura <n-sakimura@nri.co.jp> wrote:

Then let us do it. We need to put all the proposals on the table and stra= tegize the design.

Perhaps we need a side meeting as well.

=C2=A0

nat

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0<= u>

I hadn&= #39;t previously been planning on it but am happy to do so.

=C2=A0<= u>

On Tue,= Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=

=C2=A0<= u>

On Mon,= Mar 5, 2018 at 8:09 PM, Nat Sakimura <sakimura@gmail.com> wrote:

I would= be interested in hearing that.=C2=A0

=C2=A0<= u>

Also, a= s part of "Distributed OAuth", can we do a bit of re-cap on some = of the previous drafts on the similar topic as we discussed in the interim?= i.e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oauth-meta)?=C2=A0=

=C2=A0<= u>

Best,= =C2=A0

=C2=A0<= u>

Nat<= /u>

=C2=A0<= u>

On Tue,= Mar 6, 2018 at 3:30 AM William Denniss <wdenniss@google.com> wrote:<= /span>

Hannes = & Rifaat,


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (draft-wdennis= s-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0= Device Posture Signals" (draft-wdenniss-oauth-device-posture).=

=C2=A0<= u>

I can a= lso give an update on the status of Device Flow (draft-ietf-oauth-device-fl= ow). I expect that to be short now that WGLC has concluded and the document= has advanced.

=C2=A0<= u>

Little = late to this thread and I see we already have 2 sessions in the draft agend= a, but I'd like to add my support to keeping both sessions, there's= always a lot to discuss and in the past we've been able to use any spare time to discuss the security topics of the day.=

=C2=A0<= u>

Regards= ,

William=

=C2=A0<= u>

=C2=A0<= u>

=C2=A0

On Tue,= Jan 30, 2018 at 4:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:=

Hi all,=

=C2=A0<= /span>

It is t= ime already to think about the agenda for the next IETF meeting. Rifaat and= I were wondering whether we need one or two sessions. We would like to mak= e the decision based on the topics we will discuss. Below you can find a first version of the agenda with a few remarks. Let us know= if you have comments or suggestions for additional agenda items.

=C2=A0<= /span>

Ciao Hannes & Rifaat

=C2=A0<= /span>

OAuth Agenda

------------

=C2=A0=

- Welcome and Status Update=C2=A0 = (Chairs)

=C2=A0=

=C2=A0 * OAuth Security Workshop R= eport

=C2=A0

=C2=A0=C2=A0* Documents in IESG pr= ocessing

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-i= etf-oauth-device-flow-07

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# dr= aft-ietf-oauth-discovery-08

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# dr= aft-ietf-oauth-jwsreq-15

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-i= etf-oauth-token-exchange-11

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0Remark: Status updates only if needed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0

-=C2=A0 JSON Web Token Best Curren= t Practices

=C2=A0=C2=A0 # draft-ietf-oauth-jw= t-bcp-00

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Remark: We are l= acking reviews on this document.<= /span>

=C2=A0=C2=A0 Most likely we will n= ot get them during the f2f meeting

=C2=A0=C2=A0=C2=A0but rather by re= aching out to individuals ahead of time.

=C2=A0=C2=A0=C2=A0

-=C2=A0 OAuth 2.0 Mutual TLS Clien= t Authentication and Certificate Bound Access Tokens

=C2=A0=C2=A0 # draft-ietf-oauth-mt= ls-06

=C2=A0=

=C2=A0=C2=A0 Remark: Could be comp= leted by the time of the IETF meeting.

=C2=A0=C2=A0=C2=A0

- OAuth Security Topics

=C2=A0 # draft-ietf-oauth-security= -topics-04

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: We could do a = consensus call on parts of the document soon.

=C2=A0=C2=A0

- OAuth 2.0 Token Binding

=C2=A0 # draft-ietf-oauth-token-bi= nding-05

=C2=A0

=C2=A0=C2=A0Remark: Document is mo= ving along but we are lacking implementations.

=C2=A0=C2=A0

- OAuth 2.0 Device Posture Signals=

=C2=A0 # draft-wdenniss-oauth-devi= ce-posture-01

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: Interest in th= e work but we are lacking content (maybe even

=C2=A0=C2=A0expertise in the group= )

=C2=A0

- Reciprocal OAuth

=C2=A0 # draft-hardt-oauth-mutual-= 02

=C2=A0=

=C2=A0 Remark: We had a virtual in= terim meeting on this topic and there is

=C2=A0=C2=A0interest in this work = and apparently no competing solutions. The plan=

=C2=A0 is to run a call for adopti= on once we are allowed to add a new milestone

=C2=A0=C2=A0to our charter.

=C2=A0=C2=A0

- Distributed OAuth

=C2=A0 # draft-hardt-oauth-distrib= uted-00

=C2=A0=

=C2=A0 Remark: We had a virtual in= terim meeting on this topic and there is

=C2=A0=C2=A0interest in this work.= Further work on the scope is needed.=

IMPORTA= NT NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, please n= otify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura

Chairman of the Board, Open= ID Foundation


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0<= u>


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0<= u>


CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by othe= rs is strictly prohibited.=C2=A0 If you have received this communication in= error, please notify the sender immediately by e-mail and delete the messa= ge and any file attachments from your computer. Thank you.

= =C2=A0


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


--001a11431aa0398114056a18da47-- From nobody Wed Apr 18 03:59:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884D127077 for ; Wed, 18 Apr 2018 03:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHXwboOHmxEU for ; Wed, 18 Apr 2018 03:59:20 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0048.outbound.protection.outlook.com [104.47.1.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769FC126DD9 for ; Wed, 18 Apr 2018 03:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3VaRYDUJEGraBHtlLgzvdOO1RNbnHAEIznlwVCKmrbo=; b=CajE0FmAppID4RAwZIfmM3TciVSiFcOceSH3zChW3B8LYkhEeEhZ8DadoaTmzMmD5qXj/6SfN31uDMpcI9pRffv0wldDg/BrRRPU7MIGqEQbDhY8rCMsBmD9rb4CjxDTW2ngBi8No5JDjZ6eX7By+ZYfx+YIsc94ycqqWzFTIIw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2000.eurprd08.prod.outlook.com (10.173.74.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.11; Wed, 18 Apr 2018 10:59:16 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Wed, 18 Apr 2018 10:59:15 +0000 From: Hannes Tschofenig To: n-sakimura , Dick Hardt CC: oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXAAC0wAgAAcFChAB/jIZAAAHQ9wXQALVCyw Date: Wed, 18 Apr 2018 10:59:15 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nri.co.jp; dkim=none (message not signed) header.d=none;nri.co.jp; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.115.223] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2000; 7:hI/mGxiSsbS4+EotwxCRmNCQHh8RolI/I2rLjkF8KQbAdVK9Ijneszhxujt5yRKEHr6uFKn/WsblLqrRZcxnX9auORH+ERlDJNJ/wO295jadRCpvtiSVrwXWOANcNkvJlEt2kpIXyE0AzfoOBkExnaY5OTVOMBr6pP/V+GoDd7ygBDxtxtRvYPy+qKDrNSKcDS5ThjaALWzx9vUoTJg02Ea/sDKgmtkRPoQDxdVePkOP/wpf/n1GJuwm+rBR1+fL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2000; x-ms-traffictypediagnostic: VI1PR0801MB2000: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231232)(944501327)(52105095)(6055026)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB2000; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2000; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39380400002)(39860400002)(366004)(346002)(365934003)(53754006)(40434004)(99286004)(478600001)(3846002)(6116002)(9686003)(6306002)(53946003)(236005)(966005)(55016002)(2906002)(2900100001)(54896002)(72206003)(186003)(53546011)(39060400002)(790700001)(14454004)(229853002)(11346002)(110136005)(606006)(3660700001)(26005)(53936002)(446003)(33656002)(5250100002)(3280700002)(476003)(86362001)(6506007)(5890100001)(74316002)(4326008)(7736002)(316002)(59450400001)(93886005)(25786009)(66066001)(81166006)(5660300001)(8936002)(97736004)(6436002)(7696005)(8676002)(6246003)(76176011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2000; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; x-microsoft-antispam-message-info: 7Kx6g5AIndOG+F9dSmWhXPahJLSxOvGMxJjPb3fAhg5T/+tUEOp/r877SpDR/yWyFyLFWiB19Cwn+CtUA/ZpMUpTAfkBvGsHqkw5P5aA/HoHoVAo9MpThqdnbD1pQ1rv1Rbrt9WAgdqE3xYYBAsUz4tNjXMr7AXZjmbzKfSWSxBhHUcZ5V4Oa/OOw+TvJ7dW spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112BC38B8A4ADF9A8ABFC89FAB60VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d1ab9624-8096-41f0-892d-08d5a51b6d44 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1ab9624-8096-41f0-892d-08d5a51b6d44 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 10:59:15.7295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2000 Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 10:59:24 -0000 --_000_VI1PR0801MB2112BC38B8A4ADF9A8ABFC89FAB60VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hey guys, I am trying to find out what you are planning here. Are you talking about scheduling a side meeting at the next IETF meeting or= a f2f meeting somewhere else? Rifaat and I had promised to schedule a conference call (virtual interim me= eting) about distributed OAuth and we are targeting May. While holding a f2= f interim meeting for OAuth is possible we have not discussed this so far. Ciao Hannes From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of n-sakimura Sent: 18 April 2018 07:34 To: Dick Hardt; n-sakimura Cc: oauth Subject: Re: [OAUTH-WG] Call for agenda items I support the idea. Adding to it, perhaps we can do an ad-hoc before Montre= al so that we can come up with a combined draft. Nat Sakimura -- PLEASE READ: This e-mail is confidential and intended for the named recipie= nt only. If you are not an intended recipient, please notify the sender and= delete this e-mail. ________________________________ =1B$B:9=3DP?M=1B(B: Dick Hardt > =1B$BAw?.F|;~=1B(B: 2018=1B$BG/=1B(B4=1B$B7n=1B(B18=1B$BF|=1B(B 0:40:20 =1B$B08@h=1B(B: n-sakimura CC: Rifaat Shekh-Yusef; oauth =1B$B7oL>=1B(B: Re: [OAUTH-WG] Call for agenda items ****************************************************************** =1B$BK\%a!<%k$O%U%j!<%a!<%k$+$iFO$$$F$$$^$9!#I8E*7?967b%a!<%k$O%U%j!<%a=1B(= B =1B$B!<%k$+$iFO$/$3$H$,$"$j$^$9$N$G$4Cm0U$/$@$5$$!#?H$K3P$($N$J$$%a!<%k=1B(= B =1B$B$G$"$l$PE:IU%U%!%$%k$d=1B(BURL=1B$B$r3+$+$:!"0J2<$K7G:\$5$l$F$$$k$C=1B(B =1B$B$FBP1~$r$*4j$$$7$^$9!#=1B(B =1B$B6&M->pJs=1B(B>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B>=1B$B2x$7$$%a!<%k$,= FO$$$?$i=1B(B =1B$B$^$?$O!"=1B(B NRI Group Security Portal>=1B$B>pJs%;%-%e%j%F%#%H%T%C%/%9=1B(B >=1B$B2x$7$$%a!<%k$,FO$$$?$i=1B(B ****************************************************************** I'd like to coordinate a side meeting with Nat, Brian, myself and other int= erested parties in Montreal to discuss Distributed OAuth. If we have two meetings, I'd like a timeslot in the second to summarize the= side meeting and discuss next steps (if any). Separately, I'd like a time slot for an update on Reciprocal OAuth. On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura > wrote: No, not really. I was thinking of more informal thing. The session is suppo= sed to be Wednesday afternoon, so I was thinking that it might be a good id= ea to do a bit of recap among contributors to draw up a battle plan towards= IETF 102. Nat From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] Sent: Wednesday, March 07, 2018 9:22 PM To: n-sakimura > Cc: Brian Campbell >; oauth > Subject: Re: [OAUTH-WG] Call for agenda items Nat, Are you asking for an interim meeting? We could schedule the Distributed OAuth discussion for the Wednesday meetin= g; that will give you guys sometime to discuss these face-to-face in London= . Regards, Rifaat On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura > wrote: Then let us do it. We need to put all the proposals on the table and strate= gize the design. Perhaps we need a side meeting as well. nat From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Brian Campbell Sent: Wednesday, March 07, 2018 1:31 AM To: Rifaat Shekh-Yusef = > Cc: oauth > Subject: Re: [OAUTH-WG] Call for agenda items I hadn't previously been planning on it but am happy to do so. On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: Nat, During the interim meeting, 3 drafts mentioned in the context of Distribute= d OAuth: https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 Brian, Hannes, Are you planning on presenting your documents? Regards, Rifaat On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura > wrote: I would be interested in hearing that. Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of = the previous drafts on the similar topic as we discussed in the interim? i.= e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oau= th-meta)? Best, Nat On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: Hannes & Rifaat, I would like the opportunity to present on OAuth 2.0 Incremental Authorizat= ion (draft-wdenniss-oauth-incremental-auth) [an update for which will be po= sted today] and "OAuth 2.0 Device Posture Signals" (draft-wdenniss-oauth-de= vice-posture). I can also give an update on the status of Device Flow (draft-ietf-oauth-de= vice-flow). I expect that to be short now that WGLC has concluded and the d= ocument has advanced. Little late to this thread and I see we already have 2 sessions in the draf= t agenda, but I'd like to add my support to keeping both sessions, there's = always a lot to discuss and in the past we've been able to use any spare ti= me to discuss the security topics of the day. Regards, William On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig > wrote: Hi all, It is time already to think about the agenda for the next IETF meeting. Rif= aat and I were wondering whether we need one or two sessions. We would like= to make the decision based on the topics we will discuss. Below you can fi= nd a first version of the agenda with a few remarks. Let us know if you hav= e comments or suggestions for additional agenda items. Ciao Hannes & Rifaat OAuth Agenda ------------ - Welcome and Status Update (Chairs) * OAuth Security Workshop Report * Documents in IESG processing # draft-ietf-oauth-device-flow-07 # draft-ietf-oauth-discovery-08 # draft-ietf-oauth-jwsreq-15 # draft-ietf-oauth-token-exchange-11 Remark: Status updates only if needed. - JSON Web Token Best Current Practices # draft-ietf-oauth-jwt-bcp-00 Remark: We are lacking reviews on this document. Most likely we will not get them during the f2f meeting but rather by reaching out to individuals ahead of time. - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access = Tokens # draft-ietf-oauth-mtls-06 Remark: Could be completed by the time of the IETF meeting. - OAuth Security Topics # draft-ietf-oauth-security-topics-04 Remark: We could do a consensus call on parts of the document soon. - OAuth 2.0 Token Binding # draft-ietf-oauth-token-binding-05 Remark: Document is moving along but we are lacking implementations. - OAuth 2.0 Device Posture Signals # draft-wdenniss-oauth-device-posture-01 Remark: Interest in the work but we are lacking content (maybe even expertise in the group) - Reciprocal OAuth # draft-hardt-oauth-mutual-02 Remark: We had a virtual interim meeting on this topic and there is interest in this work and apparently no competing solutions. The plan is to run a call for adoption once we are allowed to add a new milestone to our charter. - Distributed OAuth # draft-hardt-oauth-distributed-00 Remark: We had a virtual interim meeting on this topic and there is interest in this work. Further work on the scope is needed. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura Chairman of the Board, OpenID Foundation _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112BC38B8A4ADF9A8ABFC89FAB60VI1PR0801MB2112_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hey guys,

 <= /p>

I am trying to find out w= hat you are planning here.

 <= /p>

Are you talking about sch= eduling a side meeting at the next IETF meeting or a f2f meeting somewhere = else?

 <= /p>

Rifaat and I had promised= to schedule a conference call (virtual interim meeting) about distributed = OAuth and we are targeting May. While holding a f2f interim meeting for OAuth is possible we have not discussed this so far.

 <= /p>

Ciao
Hannes

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of n-sakimura
Sent: 18 April 2018 07:34
To: Dick Hardt; n-sakimura
Cc: oauth
Subject: Re: [OAUTH-WG] Call for agenda items

 

I support the idea. Adding to it, perhaps we can do an ad-hoc be= fore Montreal so that we can come up with a combined draft. 

 

Nat Sakimura

--

PLEASE READ: This e-mail is= confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete thi= s e-mail.

 

 

 

 

=1B$B:9=3DP?M=1B(B: Dick Hardt <dick.hardt@gmail.co= m>
=1B$BAw?= .F|;~=1B(B: 2018=1B$BG/=1B(B4=1B$B7n=1B(B18= =1B$BF|=1B(B 0:40:20
=1B$B08@= h=1B(B: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=1B$B7oL= >=1B(B: Re: [OAUTH-WG] Call for agenda items

 

****************************************************= **************
=1B$BK\%a!<%k$O%U%j!<%a!<%k$+$iFO$$$F$$$^$9!#I8E*7?967b%a= !<%k$O%U%j!<%a=1B(B
=1B$B!<%k$+$iFO$/$3$H$,$"$j$^$9$N$G$4Cm0U$/$@$5$$!#?H$K3P= $($N$J$$%a!<%k=1B(B
=1B$B$G$"$l$PE:IU%U%!%$%k$d=1B(BURL=1B$B$r3+$+$:!"0J2<$K7G:\$5$l$F$$$k$C=1B(B
=1B$B$FBP1~$r$*4j$$$7$^$9!#=1B(B

=1B$B6&M->pJs=1B(B>=1B$B>pJs%= ;%-%e%j%F%#%H%T%C%/%9=1B(B>=1B$B2x$7$$%a!<%k$,F= O$$$?$i=1B(B
=1B$B$^$?$O!"=1B(B
NRI Group Security Portal>=1B$B>pJs%;%-%e%j%F%#%H%T%C%= /%9=1B(B
>=1B$B2x$7$$%a!<%k$,FO$$$?$i=1B(B
******************************************************************

I'd like to coordinate a side meeting with Nat, Bria= n, myself and other interested parties in Montreal to discuss Distributed O= Auth.

 

If we have two meetings, I'd like a timeslot in the = second to summarize the side meeting and discuss next steps (if any).<= /o:p>

 

Separately, I'd like a time slot for an update on Re= ciprocal OAuth.

 

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura@nri.co.jp> wrote:

No, not rea= lly. I was thinking of more informal thing. The session is supposed to be W= ednesday afternoon, so I was thinking that it might be a good idea to do a bit of recap among contributors to draw up a battle plan towa= rds IETF 102.

 

Nat<= o:p>

 

From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for agenda items

 

Nat,

 

Are you asking for an interim = meeting?

We could schedule the Distribu= ted OAuth discussion for the Wednesday meeting; that will give you guys som= etime to discuss these face-to-face in London.

 

Regards,

 Rifaat=

 

 

 

On Wed, Mar 7, 2018 at 2:00 AM= , n-sakimura <= n-sakimura@nri.co.jp> wrote:

Then let us= do it. We need to put all the proposals on the table and strategize the de= sign.

Perhaps we = need a side meeting as well.

 

nat<= o:p>

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

 

I hadn't previously been plann= ing on it but am happy to do so.

 

On Tue, Mar 6, 2018 at 8:22 AM= , Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Nat,

 

Brian, Hannes,

 

Are you planning on presenting= your documents?

 

Regards,

 Rifaat=

 

 

 

 

 

 

On Mon, Mar 5, 2018 at 8:09 PM= , Nat Sakimura <= sakimura@gmail.com> wrote:

I would be interested in heari= ng that. 

 

Also, as part of "Distrib= uted OAuth", can we do a bit of re-cap on some of the previous drafts = on the similar topic as we discussed in the interim? i.e., Brian's draft (w= here is the link now?) and my draft (draft-sakimura-oauth-meta)? 

 

Best, <= /p>

 

Nat

 

On Tue, Mar 6, 2018 at 3:30 AM= William Denniss <wdenniss@google.com> wrote:

Hannes & Rifaat,


I would like the opportunity to present on OAuth 2.0 Incremental Authorization (d= raft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and "OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).=

 

I can also give an update on t= he status of Device Flow (draft-ietf-oauth-device-flow). I expect that to b= e short now that WGLC has concluded and the document has advanced.

 

Little late to this thread and= I see we already have 2 sessions in the draft agenda, but I'd like to add = my support to keeping both sessions, there's always a lot to discuss and in= the past we've been able to use any spare time to discuss the security topics of the day.

 

Regards,

William

 

 

 

On Tue, Jan 30, 2018 at 4:40 A= M Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

 

It is time already to think about the agenda for th= e next IETF meeting. Rifaat and I were wondering whether we need one or two= sessions. We would like to make the decision based on the topics we will d= iscuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

 

Ciao
Hannes & Rifaat

 

OAuth Agenda

------------

 

- Welcome and Status Update  (Chairs)

 

  * OAuth Security Workshop Report

 

  * Documents in IESG processing

     # draft-ietf-oauth-device-flow-07

     # draft-ietf-oauth-discovery-08

     # draft-ietf-oauth-jwsreq-15

     # draft-ietf-oauth-token-exchange-11<= /o:p>

     

       Remark: Status updates only if needed= .

       

-  JSON Web Token Best Current Practices

   # draft-ietf-oauth-jwt-bcp-00

   

   Remark: We are lacking reviews on this document.<= o:p>

   Most likely we will not get them during the f2f meeting

   but rather by reaching out to individuals ahead of time.

   

-  OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound A= ccess Tokens

   # draft-ietf-oauth-mtls-06

 

   Remark: Could be completed by the time of the IETF meeting.

   

- OAuth Security Topics

  # draft-ietf-oauth-security-topics-04

  

  Remark: We could do a consensus call on parts of the document = soon.

  

- OAuth 2.0 Token Binding

  # draft-ietf-oauth-token-binding-05

 

  Remark: Document is moving along but we are lacking implementa= tions.

  

- OAuth 2.0 Device Posture Signals

  # draft-wdenniss-oauth-device-posture-01

  

  Remark: Interest in the work but we are lacking content (maybe= even

  expertise in the group)

 

- Reciprocal OAuth

  # draft-hardt-oauth-mutual-02

 

  Remark: We had a virtual interim meeting on this topic and there is

  interest in this work and apparently no competing solutions. T= he plan

  is to run a call for adoption once we are allowed to add a new mile= stone

  to our charter.

  

- Distributed OAuth

  # draft-hardt-oauth-distributed-00

 

  Remark: We had a virtual interim meeting on this topic and there is

  interest in this work. Further work on the scope is needed.

IMPORTANT NOTICE: The contents of this email and an= y attachments are confidential and may also be privileged. If you are not t= he intended recipient, please notify the sender immediately and do not disc= lose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

______________________________= _________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

______________________________= _________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura

Chairman of the Board, Open= ID Foundation


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may contain confid= ential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.  If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112BC38B8A4ADF9A8ABFC89FAB60VI1PR0801MB2112_-- From nobody Wed Apr 18 07:15:34 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6480212D80F for ; Wed, 18 Apr 2018 07:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhEh-vKaCw2e for ; Wed, 18 Apr 2018 07:15:30 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0921112D80E for ; Wed, 18 Apr 2018 07:15:30 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id t22-v6so1204603plo.7 for ; Wed, 18 Apr 2018 07:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TqdeOH2K2f9No9wDpufqGcJPWHgV0XXwV60ylkpFcyI=; b=PZvmR7ehDXxLVxrpmph8OC4Q0X8Q0t7S26vz71E2mIw6TfEarksX+hi1Udx9KamudG UdEKtXbP0tIwKQCHMtwzDBpZKI5EG7IrCpzLaoI45NwmgucY4qcOfva6bCXi+s/8ukEo Y40keSMIATQz5l2Piyq8CF3hHh3C3MQn64bLW6iahZdHuV25TC3HMAoksh35bugALhDc x7dD+gntlUBcVQ4jkoCaeB8HjZD9tKW8Unxg8GCovibbnlYLZA6WhZ+RBIg7gr71685u vmuYAsPY3IbxaZ8kzmkDjAXUqlBfA67ueCLRlpfTjq9L1zTv4uLOan4Cd33qqeQQljp7 s9ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TqdeOH2K2f9No9wDpufqGcJPWHgV0XXwV60ylkpFcyI=; b=NYkg/ZN9WquSE5IvU9fzR+ZHqIyd2jJPHqDPIlI4spfygBaGbB+e3UYx18g6Q0123P yOUnl+OBFIPi5xIG49ckMqzAiykhLgMUwOOUVj02clQ8cDx5PKxZYOBmeKLoWZIV12ni jROUXgpKlDYGC8wtfHLiydi5J4QblzMZ7Zm3j6ApUiKDUO3xdNeRNeE7V7hxHgzOwXoP R0oLqgMNUDAGQcpqnf2IcYAq8bcBZMt0b+q/DKrURdXbNDcO4sRlodmg5hTPVIy8OwmZ 4E1OtTye92F9Txr7hoxBXRy+QlrHFei5XQMj7GggeVzhATnCRhDnbFsvQXetrfimZ/fc hbOA== X-Gm-Message-State: ALQs6tAkDjWmmfqhpvOZ7RMnaPoT8vMrNofmxbi2D66sUHHdd/nxfawt vErjOoq9zs3pBCZP+nJaF/uDBFfK/4KC4GTz67Q= X-Google-Smtp-Source: AIpwx482WRLBVUCquSiMXcwU9oURCbzI5eIqMIxo8TamuF64cF62tbPlZMG7T+zwPunuB0XOT1+OGHOUvLWjLBGJw+U= X-Received: by 2002:a17:902:bd41:: with SMTP id b1-v6mr2218339plx.302.1524060929338; Wed, 18 Apr 2018 07:15:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 18 Apr 2018 14:15:16 +0000 Message-ID: To: Hannes Tschofenig Cc: n-sakimura , oauth Content-Type: multipart/alternative; boundary="0000000000004f3319056a2016aa" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:15:33 -0000 --0000000000004f3319056a2016aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable F2F side/author meeting at Montreal Ad hock author meeting call prior Unclear to me the value of a WG intern meeting On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschofenig wrote: > Hey guys, > > > > I am trying to find out what you are planning here. > > > > Are you talking about scheduling a side meeting at the next IETF meeting > or a f2f meeting somewhere else? > > > > Rifaat and I had promised to schedule a conference call (virtual interim > meeting) about distributed OAuth and we are targeting May. While holding = a > f2f interim meeting for OAuth is possible we have not discussed this so > far. > > > > Ciao > Hannes > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *n-sakimura > *Sent:* 18 April 2018 07:34 > *To:* Dick Hardt; n-sakimura > *Cc:* oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I support the idea. Adding to it, perhaps we can do an ad-hoc before > Montreal so that we can come up with a combined draft. > > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > > > > > ------------------------------ > > *=E5=B7=AE=E5=87=BA=E4=BA=BA**:* Dick Hardt > *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82**:* 2018=E5=B9=B44=E6=9C=8818=E6=97= =A5 0:40:20 > *=E5=AE=9B=E5=85=88**:* n-sakimura > *CC:* Rifaat Shekh-Yusef; oauth > *=E4=BB=B6=E5=90=8D**:* Re: [OAUTH-WG] Call for agenda items > > > > ****************************************************************** > =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3= =81=84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92= =83=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 > =E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8= =E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6= =B3=A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81= =AB=E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB > =E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1= =E3=82=A4=E3=83=AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81= =E4=BB=A5=E4=B8=8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3= =81=84=E3=82=8B=E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3 > =E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 > > =E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD= =E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3= =82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5= =B1=8A=E3=81=84=E3=81=9F=E3=82=89 > =E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81 > NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5= =E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9 > >=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A= =E3=81=84=E3=81=9F=E3=82=89 > ****************************************************************** > > I'd like to coordinate a side meeting with Nat, Brian, myself and other > interested parties in Montreal to discuss Distributed OAuth. > > > > If we have two meetings, I'd like a timeslot in the second to summarize > the side meeting and discuss next steps (if any). > > > > Separately, I'd like a time slot for an update on Reciprocal OAuth. > > > > On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura wrote: > > No, not really. I was thinking of more informal thing. The session is > supposed to be Wednesday afternoon, so I was thinking that it might be a > good idea to do a bit of recap among contributors to draw up a battle pla= n > towards IETF 102. > > > > Nat > > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Wednesday, March 07, 2018 9:22 PM > *To:* n-sakimura > *Cc:* Brian Campbell ; oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > Nat, > > > > Are you asking for an interim meeting? > > We could schedule the Distributed OAuth discussion for the Wednesday > meeting; that will give you guys sometime to discuss these face-to-face i= n > London. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distrib= uted > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some o= f > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for whic= h > will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC h= as > concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use an= y > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Acces= s > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new mileston= e > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --0000000000004f3319056a2016aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
F2F side/author meeting at Montreal
Ad hock author meeting call prior

<= div dir=3D"auto">Unclear to me the value of a WG intern meeting

On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschof= enig <Hannes.Tschofenig@arm= .com> wrote:

Hey guys,

=C2=A0

I am trying to find out w= hat you are planning here.

=C2=A0

Are you talking about sch= eduling a side meeting at the next IETF meeting or a f2f meeting somewhere = else?

=C2=A0

Rifaat and I had promised= to schedule a conference call (virtual interim meeting) about distributed = OAuth and we are targeting May. While holding a f2f interim meeting for OAuth is possible we have not discussed this so far.

=C2=A0

Ciao
Hannes

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of n-sakimura
Sent: 18 April 2018 07:34
To: Dick Hardt; n-sakimura
Cc: oauth

=


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I support the idea. Adding to it, perhaps we can do an ad-hoc be= fore Montreal so that we can come up with a combined draft.=C2=A0=

=C2=A0

Nat Sakimura=

--

PLEASE READ: = This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete thi= s e-mail.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E5=B7=AE=E5=87=BA=E4=BA=BA:= Dick Hardt <d= ick.hardt@gmail.com>
=E9=80= =81=E4=BF=A1=E6=97=A5=E6=99=82: 2018=E5=B9=B44<= span lang=3D"JA" style=3D"font-size:11.0pt;color:black">=E6=9C=8818=E6=97=A5 0:40:20
=E5=AE= =9B=E5=85=88: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=E4=BB= =B6=E5=90=8D: Re: [OAUTH-WG] Call for agenda items

=C2=A0

****************************************************= **************
=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3= =83=AA=E3=83=BC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81= =84=E3=81=A6=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B= =E6=94=BB=E6=92=83=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3= =83=BC=E3=83=A1
=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3= =81=93=E3=81=A8=E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81= =A7=E3=81=94=E6=B3=A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82= =E8=BA=AB=E3=81=AB=E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3= =83=BC=E3=83=AB
=E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3= =83=95=E3=82=A1=E3=82=A4=E3=83=AB=E3=82=84URL=E3= =82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81=E4=BB=A5=E4=B8=8B=E3=81=AB=E6=8E= =B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=89=8B=E9=A0=86= =E3=81=AB=E5=BE=93=E3=81=A3
=E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3= =81=84=E3=81=97=E3=81=BE=E3=81=99=E3=80=82

=E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5=E3=83=AA=E3=83=86=E3= =82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1= =8A=E3=81=84=E3=81=9F=E3=82=89
=E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81
NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB= =E3=82=AD=E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3= =82=AF=E3=82=B9
>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83= =AB=E3=81=8C=E5=B1=8A=E3=81=84=E3=81=9F=E3=82=89
******************************************************************

I'd like to coordinate a side meeting with Nat, = Brian, myself and other interested parties in Montreal to discuss Distribut= ed OAuth.

=C2=A0

If we have two meetings, I'd like a timeslot in = the second to summarize the side meeting and discuss next steps (if any).

=C2=A0

Separately, I'd like a time slot for an update o= n Reciprocal OAuth.

=C2=A0

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura@nri.co.jp> wrote:

No, not really. I was thinking of more informal thing. The session= is supposed to be Wednesday afternoon, so I was thinking that it might be = a good idea to do a bit of recap among contributors to draw up a battle plan towa= rds IETF 102.

=C2=A0

Nat

=C2=A0

From: Rifaat Shekh-Yusef [mailto:<= a href=3D"mailto:rifaat.ietf@gmail.com" target=3D"_blank">rifaat.ietf@gmail= .com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org><= /u>


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

Nat,

=C2=A0

Are you as= king for an interim meeting?

We could s= chedule the Distributed OAuth discussion for the Wednesday meeting; that wi= ll give you guys sometime to discuss these face-to-face in London.

=C2=A0

Regards,

=C2=A0Rifa= at

=C2=A0

=C2=A0

=C2=A0

On Wed, Ma= r 7, 2018 at 2:00 AM, n-sakimura <n-sakimura@nri.co.jp> wrote:

Then let us do it. We need to put all the proposals on the table a= nd strategize the design.

Perhaps we need a side meeting as well.

=C2=A0

nat

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I hadn'= ;t previously been planning on it but am happy to do so.

=C2=A0

On Tue, Ma= r 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:=

Nat,

=C2=A0

Brian, = Hannes,

=C2=A0

Are you pl= anning on presenting your documents?

=C2=A0

Regards,

=C2=A0Rifa= at

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Ma= r 5, 2018 at 8:09 PM, Nat Sakimura <sakimura@gmail.com> wrote:<= /p>

I would be= interested in hearing that.=C2=A0

=C2=A0

Also, as p= art of "Distributed OAuth", can we do a bit of re-cap on some of = the previous drafts on the similar topic as we discussed in the interim? i.= e., Brian's draft (where is the link now?) and my draft (= draft-sakimura-oauth-meta)?=C2=A0<= /span>

=C2=A0

Best,=C2= =A0

=C2=A0

Nat=

=C2=A0

On Tue, Ma= r 6, 2018 at 3:30 AM William Denniss <wdenniss@google.com> wrote:<= /u>

Hannes &am= p; Rifaat,


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (d= raft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).

=C2=A0

I can also= give an update on the status of Device Flow (draft-ietf-oauth-device-flow)= . I expect that to be short now that WGLC has concluded and the document ha= s advanced.

=C2=A0

Little lat= e to this thread and I see we already have 2 sessions in the draft agenda, = but I'd like to add my support to keeping both sessions, there's al= ways a lot to discuss and in the past we've been able to use any spare time to discuss the security topics of the day.=

=C2=A0

Regards,

William

=C2=A0

=C2=A0

= =C2=A0

On Tue, Ja= n 30, 2018 at 4:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think abo= ut the agenda for the next IETF meeting. Rifaat and I were wondering whethe= r we need one or two sessions. We would like to make the decision based on = the topics we will discuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

OAuth Agenda

------------

=C2=A0

- Welcome and Status Update=C2=A0 (Chairs)

=C2=A0

=C2=A0 * OAuth Security Workshop Report<= u>

=C2=A0

=C2=A0=C2=A0* Documents in IESG processing

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flo= w-07

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-disco= very-08

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsre= q-15

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-exch= ange-11

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status up= dates only if needed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=

-=C2=A0 JSON Web Token Best Current Practices

=C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on th= is document.

=C2=A0=C2=A0 Most likely we will not get them during t= he f2f meeting

=C2=A0=C2=A0=C2=A0but rather by reaching out to indivi= duals ahead of time.

=C2=A0=C2=A0=C2=A0

-=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and= Certificate Bound Access Tokens

=C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

=C2=A0

=C2=A0=C2=A0 Remark: Could be completed by the time of= the IETF meeting.

=C2=A0=C2=A0=C2=A0

- OAuth Security Topics

=C2=A0 # draft-ietf-oauth-security-topics-04

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: We could do a consensus call on pa= rts of the document soon.

=C2=A0=C2=A0

- OAuth 2.0 Token Binding

=C2=A0 # draft-ietf-oauth-token-binding-05

=C2=A0

=C2=A0=C2=A0Remark: Document is moving along but we ar= e lacking implementations.

=C2=A0=C2=A0

- OAuth 2.0 Device Posture Signals

=C2=A0 # draft-wdenniss-oauth-device-posture-01

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: Interest in the work but we are la= cking content (maybe even

=C2=A0=C2=A0expertise in the group)

=C2=A0

- Reciprocal OAuth

=C2=A0 # draft-hardt-oauth-mutual-02

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on thi= s topic and there is

=C2=A0=C2=A0interest in this work and apparently no co= mpeting solutions. The plan

=C2=A0 is to run a call for adoption once we are allow= ed to add a new milestone

=C2=A0=C2=A0to our charter.

=C2=A0=C2=A0

- Distributed OAuth

=C2=A0 # draft-hardt-oauth-distributed-00

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on thi= s topic and there is

=C2=A0=C2=A0interest in this work. Further work on the= scope is needed.

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

<= span lang=3D"EN-US" style=3D"color:#888888">--

Nat Sakimura<= u>

Chairman of the Board, Open= ID Foundation

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confid= ential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.=C2=A0 If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--0000000000004f3319056a2016aa-- From nobody Wed Apr 18 07:21:15 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2512D80F for ; Wed, 18 Apr 2018 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHfywq5w_LhO for ; Wed, 18 Apr 2018 07:21:09 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10068.outbound.protection.outlook.com [40.107.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A1012D80E for ; Wed, 18 Apr 2018 07:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uWdl66c1D9wrmX+jtM/v2ZNxEg16miYLeytle+5vWUk=; b=TJ18sTyYIeOFs895JHLBtVLAqnZzHZnZ/vf31ihwd890ejSqw/x9sGuVXaUWXb3yEqHOePjbuUFsHQpfnU7k7TMw2Jiud7a1iJyj8nSsEMvE1SkXByHU1e+Umg4tVffxBzX8CB7xOQxL6YTkVppYzyjfNgJykpfukVBUELAuqgY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1551.eurprd08.prod.outlook.com (10.167.210.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.12; Wed, 18 Apr 2018 14:21:04 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Wed, 18 Apr 2018 14:21:04 +0000 From: Hannes Tschofenig To: Dick Hardt CC: n-sakimura , oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXAAC0wAgAAcFChAB/jIZAAAHQ9wXQALVCywAAbucAAAACgj4A== Date: Wed, 18 Apr 2018 14:21:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.115.223] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1551; 7:lK80OX4SB4dD7gPifbghpBCK+BdidEQYvSffzf6/WZuqssrZUYCr3/J6bubiyKPiGCWEz3F9KTUMfVuie0/4e+fZGbK2gJvu2u+r9DbSHLTuIdyW93IBJh7XZsXFo2uFnveH/ygBstCZqgbicB9leVsDqDCBtwx3MEdFjPtYfEo1ZMvGfW4gW6m49ujV9I+BVHZ1hICl3PahT9UK7HQ5YxIOkCJZvxFUQECAODjy/jtnkXhDbMT1aL+k56BJ1XIe x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1551; x-ms-traffictypediagnostic: VI1PR0801MB1551: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501368)(52105095)(6055026)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB1551; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1551; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(39860400002)(346002)(376002)(365934003)(40434004)(53754006)(8676002)(316002)(68736007)(99286004)(93886005)(3660700001)(3280700002)(7696005)(6916009)(6436002)(102836004)(76176011)(6246003)(66066001)(790700001)(3846002)(25786009)(6116002)(81166006)(2906002)(54906003)(5250100002)(8936002)(9686003)(106356001)(5890100001)(72206003)(53946003)(86362001)(478600001)(6306002)(236005)(11346002)(39060400002)(2900100001)(55016002)(6506007)(9326002)(54896002)(966005)(53546011)(7736002)(229853002)(59450400001)(476003)(74316002)(186003)(26005)(14454004)(53936002)(5660300001)(33656002)(606006)(446003)(4326008)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1551; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; x-microsoft-antispam-message-info: 9Jb8MG1/3DfBdfoVNNKhOhOsy6N20WdB4lDt+YWqR0RL2MRgu5cJDGBRwvq2sRd39Axfo+PUFI1wR3s8k0XTnrA8PaYWXB+nAf1Dk6FuWi0wEx11uSUx3g9lPK2stMVGBzdcZb1FywLx8PdwUCcuRQidlByk26hsrnRhL4C6jmD5y8heQ3/KWJ3VS2ZX3bAC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112819E94AB2E3302B4F75DFAB60VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2cf33225-4636-41c0-258a-08d5a5379e6a X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2cf33225-4636-41c0-258a-08d5a5379e6a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 14:21:04.1552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1551 Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:21:14 -0000 --_000_VI1PR0801MB2112819E94AB2E3302B4F75DFAB60VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGljaywNCg0KVGhlIHZhbHVlIG9mIGEgY29uZmVyZW5jZSBjYWxsIGFzIHBhcnQgb2YgdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAgaXMgdGhhdCB5b3UgaW52b2x2ZSBvdGhlciBpbnRlcmVzdGVk IHBhcnRpZXMgdG8gdGhlIGRpc2N1c3Npb24sIGFuZCB0aGF0IHlvdSBkbyBub3QgaGF2ZSB0byBy ZXBlYXQgeW91ciBwcml2YXRlIGNvbnZlcnNhdGlvbnMgbGF0ZXIgYWdhaW4gb24gdGhlIG1haWxp bmcgbGlzdC4NClRoYXTigJlzIHByZXR0eSBjb252aW5jaW5nIHRvIG1lIDstKQ0KDQpDaWFvDQpI YW5uZXMNCg0KDQpGcm9tOiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21d DQpTZW50OiAxOCBBcHJpbCAyMDE4IDE2OjE1DQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBu LXNha2ltdXJhOyBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRh IGl0ZW1zDQoNCkYyRiBzaWRlL2F1dGhvciBtZWV0aW5nIGF0IE1vbnRyZWFsDQpBZCBob2NrIGF1 dGhvciBtZWV0aW5nIGNhbGwgcHJpb3INCg0KVW5jbGVhciB0byBtZSB0aGUgdmFsdWUgb2YgYSBX RyBpbnRlcm4gbWVldGluZw0KDQpPbiBXZWQsIEFwciAxOCwgMjAxOCBhdCAzOjU5IEFNIEhhbm5l cyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNj aG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIZXkgZ3V5cywNCg0KSSBhbSB0cnlpbmcgdG8gZmlu ZCBvdXQgd2hhdCB5b3UgYXJlIHBsYW5uaW5nIGhlcmUuDQoNCkFyZSB5b3UgdGFsa2luZyBhYm91 dCBzY2hlZHVsaW5nIGEgc2lkZSBtZWV0aW5nIGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBvciBh IGYyZiBtZWV0aW5nIHNvbWV3aGVyZSBlbHNlPw0KDQpSaWZhYXQgYW5kIEkgaGFkIHByb21pc2Vk IHRvIHNjaGVkdWxlIGEgY29uZmVyZW5jZSBjYWxsICh2aXJ0dWFsIGludGVyaW0gbWVldGluZykg YWJvdXQgZGlzdHJpYnV0ZWQgT0F1dGggYW5kIHdlIGFyZSB0YXJnZXRpbmcgTWF5LiBXaGlsZSBo b2xkaW5nIGEgZjJmIGludGVyaW0gbWVldGluZyBmb3IgT0F1dGggaXMgcG9zc2libGUgd2UgaGF2 ZSBub3QgZGlzY3Vzc2VkIHRoaXMgc28gZmFyLg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIG4tc2FraW11cmENClNlbnQ6IDE4IEFwcmlsIDIwMTggMDc6 MzQNClRvOiBEaWNrIEhhcmR0OyBuLXNha2ltdXJhDQpDYzogb2F1dGgNCg0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCg0KSSBzdXBwb3J0IHRoZSBpZGVh LiBBZGRpbmcgdG8gaXQsIHBlcmhhcHMgd2UgY2FuIGRvIGFuIGFkLWhvYyBiZWZvcmUgTW9udHJl YWwgc28gdGhhdCB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgY29tYmluZWQgZHJhZnQuDQoNCg0KTmF0 IFNha2ltdXJhDQotLQ0KUExFQVNFIFJFQUQ6IFRoaXMgZS1tYWlsIGlzIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4gSWYgeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIGUtbWFpbC4NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQrlt67lh7rkuro6IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT4+DQrpgIHkv6Hml6XmmYI6IDIwMTjlubQ05pyIMTjml6UgMDo0 MDoyMA0K5a6b5YWIOiBuLXNha2ltdXJhDQpDQzogUmlmYWF0IFNoZWtoLVl1c2VmOyBvYXV0aA0K 5Lu25ZCNOiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXMNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQrmnKzjg6Hjg7zjg6vjga/jg5Xjg6rjg7zjg6Hjg7zjg6vjgYvjgonlsYrjgYTjgabjgYTjgb7j gZnjgILmqJnnmoTlnovmlLvmkoPjg6Hjg7zjg6vjga/jg5Xjg6rjg7zjg6ENCuODvOODq+OBi+OC ieWxiuOBj+OBk+OBqOOBjOOBguOCiuOBvuOBmeOBruOBp+OBlOazqOaEj+OBj+OBoOOBleOBhOOA gui6q+OBq+immuOBiOOBruOBquOBhOODoeODvOODqw0K44Gn44GC44KM44Gw5re75LuY44OV44Kh 44Kk44Or44KEVVJM44KS6ZaL44GL44Ga44CB5Lul5LiL44Gr5o6y6LyJ44GV44KM44Gm44GE44KL 5omL6aCG44Gr5b6T44GjDQrjgablr77lv5zjgpLjgYrpoZjjgYTjgZfjgb7jgZnjgIINCg0K5YWx 5pyJ5oOF5aCxPuaDheWgseOCu+OCreODpeODquODhuOCo+ODiOODlOODg+OCr+OCuT7mgKrjgZfj gYTjg6Hjg7zjg6vjgYzlsYrjgYTjgZ/jgokNCuOBvuOBn+OBr+OAgQ0KTlJJIEdyb3VwIFNlY3Vy aXR5IFBvcnRhbD7mg4XloLHjgrvjgq3jg6Xjg6rjg4bjgqPjg4jjg5Tjg4Pjgq/jgrkNCj7mgKrj gZfjgYTjg6Hjg7zjg6vjgYzlsYrjgYTjgZ/jgokNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KSSdkIGxpa2UgdG8gY29v cmRpbmF0ZSBhIHNpZGUgbWVldGluZyB3aXRoIE5hdCwgQnJpYW4sIG15c2VsZiBhbmQgb3RoZXIg aW50ZXJlc3RlZCBwYXJ0aWVzIGluIE1vbnRyZWFsIHRvIGRpc2N1c3MgRGlzdHJpYnV0ZWQgT0F1 dGguDQoNCklmIHdlIGhhdmUgdHdvIG1lZXRpbmdzLCBJJ2QgbGlrZSBhIHRpbWVzbG90IGluIHRo ZSBzZWNvbmQgdG8gc3VtbWFyaXplIHRoZSBzaWRlIG1lZXRpbmcgYW5kIGRpc2N1c3MgbmV4dCBz dGVwcyAoaWYgYW55KS4NCg0KU2VwYXJhdGVseSwgSSdkIGxpa2UgYSB0aW1lIHNsb3QgZm9yIGFu IHVwZGF0ZSBvbiBSZWNpcHJvY2FsIE9BdXRoLg0KDQpPbiBXZWQsIE1hciA3LCAyMDE4IGF0IDU6 NTIgUE0sIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2ltdXJh QG5yaS5jby5qcD4+IHdyb3RlOg0KDQpObywgbm90IHJlYWxseS4gSSB3YXMgdGhpbmtpbmcgb2Yg bW9yZSBpbmZvcm1hbCB0aGluZy4gVGhlIHNlc3Npb24gaXMgc3VwcG9zZWQgdG8gYmUgV2VkbmVz ZGF5IGFmdGVybm9vbiwgc28gSSB3YXMgdGhpbmtpbmcgdGhhdCBpdCBtaWdodCBiZSBhIGdvb2Qg aWRlYSB0byBkbyBhIGJpdCBvZiByZWNhcCBhbW9uZyBjb250cmlidXRvcnMgdG8gZHJhdyB1cCBh IGJhdHRsZSBwbGFuIHRvd2FyZHMgSUVURiAxMDIuDQoNCg0KDQpOYXQNCg0KDQoNCkZyb206IFJp ZmFhdCBTaGVraC1ZdXNlZiBbbWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlm YWF0LmlldGZAZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggOToy MiBQTQ0KVG86IG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2lt dXJhQG5yaS5jby5qcD4+DQpDYzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+OyBvYXV0aCA8b2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCg0KDQpOYXQsDQoNCg0KDQpBcmUgeW91IGFza2lu ZyBmb3IgYW4gaW50ZXJpbSBtZWV0aW5nPw0KDQpXZSBjb3VsZCBzY2hlZHVsZSB0aGUgRGlzdHJp YnV0ZWQgT0F1dGggZGlzY3Vzc2lvbiBmb3IgdGhlIFdlZG5lc2RheSBtZWV0aW5nOyB0aGF0IHdp bGwgZ2l2ZSB5b3UgZ3V5cyBzb21ldGltZSB0byBkaXNjdXNzIHRoZXNlIGZhY2UtdG8tZmFjZSBp biBMb25kb24uDQoNCg0KDQpSZWdhcmRzLA0KDQogUmlmYWF0DQoNCg0KDQoNCg0KDQoNCk9uIFdl ZCwgTWFyIDcsIDIwMTggYXQgMjowMCBBTSwgbi1zYWtpbXVyYSA8bi1zYWtpbXVyYUBucmkuY28u anA8bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwPj4gd3JvdGU6DQoNClRoZW4gbGV0IHVzIGRv IGl0LiBXZSBuZWVkIHRvIHB1dCBhbGwgdGhlIHByb3Bvc2FscyBvbiB0aGUgdGFibGUgYW5kIHN0 cmF0ZWdpemUgdGhlIGRlc2lnbi4NCg0KUGVyaGFwcyB3ZSBuZWVkIGEgc2lkZSBtZWV0aW5nIGFz IHdlbGwuDQoNCg0KDQpuYXQNCg0KDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBC cmlhbiBDYW1wYmVsbA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxOCAxOjMxIEFNDQpU bzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFh dC5pZXRmQGdtYWlsLmNvbT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRl bXMNCg0KDQoNCkkgaGFkbid0IHByZXZpb3VzbHkgYmVlbiBwbGFubmluZyBvbiBpdCBidXQgYW0g aGFwcHkgdG8gZG8gc28uDQoNCg0KDQpPbiBUdWUsIE1hciA2LCAyMDE4IGF0IDg6MjIgQU0sIFJp ZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0 ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KTmF0LA0KDQoNCg0KRHVyaW5nIHRoZSBpbnRlcmltIG1l ZXRpbmcsIDMgZHJhZnRzIG1lbnRpb25lZCBpbiB0aGUgY29udGV4dCBvZiBEaXN0cmlidXRlZCBP QXV0aDoNCg0KDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1v YXV0aC1tZXRhLTA4PGh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJhZnQtc2FraW11cmEt b2F1dGgtbWV0YS0wOD4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBi ZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDI8aHR0cHM6Ly90b29scy5pZXRmLi5vcmcv aHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyPg0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0w MDxodHRwczovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVk aWVuY2UtMDA+DQoNCg0KDQoNCg0KQnJpYW4sIEhhbm5lcywNCg0KDQoNCkFyZSB5b3UgcGxhbm5p bmcgb24gcHJlc2VudGluZyB5b3VyIGRvY3VtZW50cz8NCg0KDQoNClJlZ2FyZHMsDQoNCiBSaWZh YXQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gTW9uLCBNYXIgNSwgMjAxOCBhdCA4OjA5 IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h aWwuY29tPj4gd3JvdGU6DQoNCkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHRoYXQu DQoNCg0KDQpBbHNvLCBhcyBwYXJ0IG9mICJEaXN0cmlidXRlZCBPQXV0aCIsIGNhbiB3ZSBkbyBh IGJpdCBvZiByZS1jYXAgb24gc29tZSBvZiB0aGUgcHJldmlvdXMgZHJhZnRzIG9uIHRoZSBzaW1p bGFyIHRvcGljIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJpbT8gaS5lLiwgQnJpYW4ncyBk cmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5kIG15IGRyYWZ0IChkcmFmdC1zYWtpbXVy YS1vYXV0aC1tZXRhPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc2FraW11cmEtb2F1 dGgtbWV0YS0wOC50eHQ+KT8NCg0KDQoNCkJlc3QsDQoNCg0KDQpOYXQNCg0KDQoNCk9uIFR1ZSwg TWFyIDYsIDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5j b208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KSGFubmVzICYgUmlmYWF0 LA0KDQpJIHdvdWxkIGxpa2UgdGhlIG9wcG9ydHVuaXR5IHRvIHByZXNlbnQgb24gT0F1dGggMi4w IEluY3JlbWVudGFsIEF1dGhvcml6YXRpb24gKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWluY3JlbWVu dGFsLWF1dGgpIFthbiB1cGRhdGUgZm9yIHdoaWNoIHdpbGwgYmUgcG9zdGVkIHRvZGF5XSBhbmQg Ik9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzIiAoZHJhZnQtd2Rlbm5pc3Mtb2F1dGgt ZGV2aWNlLXBvc3R1cmUpLg0KDQoNCg0KSSBjYW4gYWxzbyBnaXZlIGFuIHVwZGF0ZSBvbiB0aGUg c3RhdHVzIG9mIERldmljZSBGbG93IChkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93KS4gSSBl eHBlY3QgdGhhdCB0byBiZSBzaG9ydCBub3cgdGhhdCBXR0xDIGhhcyBjb25jbHVkZWQgYW5kIHRo ZSBkb2N1bWVudCBoYXMgYWR2YW5jZWQuDQoNCg0KDQpMaXR0bGUgbGF0ZSB0byB0aGlzIHRocmVh ZCBhbmQgSSBzZWUgd2UgYWxyZWFkeSBoYXZlIDIgc2Vzc2lvbnMgaW4gdGhlIGRyYWZ0IGFnZW5k YSwgYnV0IEknZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRvIGtlZXBpbmcgYm90aCBzZXNzaW9u cywgdGhlcmUncyBhbHdheXMgYSBsb3QgdG8gZGlzY3VzcyBhbmQgaW4gdGhlIHBhc3Qgd2UndmUg YmVlbiBhYmxlIHRvIHVzZSBhbnkgc3BhcmUgdGltZSB0byBkaXNjdXNzIHRoZSBzZWN1cml0eSB0 b3BpY3Mgb2YgdGhlIGRheS4NCg0KDQoNClJlZ2FyZHMsDQoNCldpbGxpYW0NCg0KDQoNCg0KDQoN Cg0KT24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0MCBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+ IHdyb3RlOg0KDQpIaSBhbGwsDQoNCg0KDQpJdCBpcyB0aW1lIGFscmVhZHkgdG8gdGhpbmsgYWJv dXQgdGhlIGFnZW5kYSBmb3IgdGhlIG5leHQgSUVURiBtZWV0aW5nLiBSaWZhYXQgYW5kIEkgd2Vy ZSB3b25kZXJpbmcgd2hldGhlciB3ZSBuZWVkIG9uZSBvciB0d28gc2Vzc2lvbnMuIFdlIHdvdWxk IGxpa2UgdG8gbWFrZSB0aGUgZGVjaXNpb24gYmFzZWQgb24gdGhlIHRvcGljcyB3ZSB3aWxsIGRp c2N1c3MuIEJlbG93IHlvdSBjYW4gZmluZCBhIGZpcnN0IHZlcnNpb24gb2YgdGhlIGFnZW5kYSB3 aXRoIGEgZmV3IHJlbWFya3MuIExldCB1cyBrbm93IGlmIHlvdSBoYXZlIGNvbW1lbnRzIG9yIHN1 Z2dlc3Rpb25zIGZvciBhZGRpdGlvbmFsIGFnZW5kYSBpdGVtcy4NCg0KDQoNCkNpYW8NCkhhbm5l cyAmIFJpZmFhdA0KDQoNCg0KT0F1dGggQWdlbmRhDQoNCi0tLS0tLS0tLS0tLQ0KDQoNCg0KLSBX ZWxjb21lIGFuZCBTdGF0dXMgVXBkYXRlICAoQ2hhaXJzKQ0KDQoNCg0KICAqIE9BdXRoIFNlY3Vy aXR5IFdvcmtzaG9wIFJlcG9ydA0KDQoNCg0KICAqIERvY3VtZW50cyBpbiBJRVNHIHByb2Nlc3Np bmcNCg0KICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDcNCg0KICAgICAjIGRy YWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA4DQoNCiAgICAgIyBkcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS0xNQ0KDQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMQ0KDQoN Cg0KICAgICAgIFJlbWFyazogU3RhdHVzIHVwZGF0ZXMgb25seSBpZiBuZWVkZWQuDQoNCg0KDQot ICBKU09OIFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzDQoNCiAgICMgZHJhZnQtaWV0 Zi1vYXV0aC1qd3QtYmNwLTAwDQoNCg0KDQogICBSZW1hcms6IFdlIGFyZSBsYWNraW5nIHJldmll d3Mgb24gdGhpcyBkb2N1bWVudC4NCg0KICAgTW9zdCBsaWtlbHkgd2Ugd2lsbCBub3QgZ2V0IHRo ZW0gZHVyaW5nIHRoZSBmMmYgbWVldGluZw0KDQogICBidXQgcmF0aGVyIGJ5IHJlYWNoaW5nIG91 dCB0byBpbmRpdmlkdWFscyBhaGVhZCBvZiB0aW1lLg0KDQoNCg0KLSAgT0F1dGggMi4wIE11dHVh bCBUTFMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBDZXJ0aWZpY2F0ZSBCb3VuZCBBY2Nlc3Mg VG9rZW5zDQoNCiAgICMgZHJhZnQtaWV0Zi1vYXV0aC1tdGxzLTA2DQoNCg0KDQogICBSZW1hcms6 IENvdWxkIGJlIGNvbXBsZXRlZCBieSB0aGUgdGltZSBvZiB0aGUgSUVURiBtZWV0aW5nLg0KDQoN Cg0KLSBPQXV0aCBTZWN1cml0eSBUb3BpY3MNCg0KICAjIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJp dHktdG9waWNzLTA0DQoNCg0KDQogIFJlbWFyazogV2UgY291bGQgZG8gYSBjb25zZW5zdXMgY2Fs bCBvbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgc29vbi4NCg0KDQoNCi0gT0F1dGggMi4wIFRva2Vu IEJpbmRpbmcNCg0KICAjIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tYmluZGluZy0wNQ0KDQoNCg0K ICBSZW1hcms6IERvY3VtZW50IGlzIG1vdmluZyBhbG9uZyBidXQgd2UgYXJlIGxhY2tpbmcgaW1w bGVtZW50YXRpb25zLg0KDQoNCg0KLSBPQXV0aCAyLjAgRGV2aWNlIFBvc3R1cmUgU2lnbmFscw0K DQogICMgZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCg0KDQoNCiAgUmVt YXJrOiBJbnRlcmVzdCBpbiB0aGUgd29yayBidXQgd2UgYXJlIGxhY2tpbmcgY29udGVudCAobWF5 YmUgZXZlbg0KDQogIGV4cGVydGlzZSBpbiB0aGUgZ3JvdXApDQoNCg0KDQotIFJlY2lwcm9jYWwg T0F1dGgNCg0KICAjIGRyYWZ0LWhhcmR0LW9hdXRoLW11dHVhbC0wMg0KDQoNCg0KICBSZW1hcms6 IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJl IGlzDQoNCiAgaW50ZXJlc3QgaW4gdGhpcyB3b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGlu ZyBzb2x1dGlvbnMuIFRoZSBwbGFuDQoNCiAgaXMgdG8gcnVuIGEgY2FsbCBmb3IgYWRvcHRpb24g b25jZSB3ZSBhcmUgYWxsb3dlZCB0byBhZGQgYSBuZXcgbWlsZXN0b25lDQoNCiAgdG8gb3VyIGNo YXJ0ZXIuDQoNCg0KDQotIERpc3RyaWJ1dGVkIE9BdXRoDQoNCiAgIyBkcmFmdC1oYXJkdC1vYXV0 aC1kaXN0cmlidXRlZC0wMA0KDQoNCg0KICBSZW1hcms6IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJp bSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJlIGlzDQoNCiAgaW50ZXJlc3QgaW4gdGhp cyB3b3JrLiBGdXJ0aGVyIHdvcmsgb24gdGhlIHNjb3BlIGlzIG5lZWRlZC4NCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K LS0NCg0KTmF0IFNha2ltdXJhDQoNCkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5k YXRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KQ09ORklERU5USUFMSVRZ IE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVn ZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMp LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5p Y2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkg ZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZy b20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112819E94AB2E3302B4F75DFAB60VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGlj IjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290 aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBj bTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0 OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAubTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwsIGxpLm05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsLCBkaXYubTk1 NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6bV85NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLm05NTY2NjMzMjIyNzE4Mzk5NTZ4bS00MzQxNzgwNTA5Nzc2MDg2MjI1bTYx OTM1MTE0MDUxMTQ1NzY2NTVtMjQyNDM5MDQ0MDM3Mjk3Nzk4OGhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTptXzk1NjY2MzMyMjI3MTgzOTk1NnhtLTQzNDE3ODA1MDk3NzYwODYyMjVtNjE5MzUxMTQw NTExNDU3NjY1NW0yNDI0MzkwNDQwMzcyOTc3OTg4aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4 NjIyMDM4MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTcyOTUxMjg4OCAxOTEzNDM3MzM4IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgw NzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIERpY2ssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB2YWx1ZSBvZiBhIGNvbmZlcmVu Y2UgY2FsbCBhcyBwYXJ0IG9mIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGlzIHRoYXQgeW91IGlu dm9sdmUgb3RoZXIgaW50ZXJlc3RlZCBwYXJ0aWVzIHRvIHRoZSBkaXNjdXNzaW9uLCBhbmQgdGhh dCB5b3UgZG8gbm90IGhhdmUgdG8NCiByZXBlYXQgeW91ciBwcml2YXRlIGNvbnZlcnNhdGlvbnMg bGF0ZXIgYWdhaW4gb24gdGhlIG1haWxpbmcgbGlzdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgcHJldHR5IGNvbnZpbmNp bmcgdG8gbWUgOy0pPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiAxOCBBcHJpbCAyMDE4IDE2OjE1PGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCjxiPkNjOjwvYj4gbi1zYWtpbXVyYTsgb2F1dGg8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkYyRiBzaWRlL2F1dGhvciBtZWV0aW5nIGF0IE1v bnRyZWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BZCBob2NrIGF1dGhvciBtZWV0aW5nIGNhbGwgcHJpb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5jbGVhciB0byBtZSB0aGUgdmFsdWUg b2YgYSBXRyBpbnRlcm4gbWVldGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMTgsIDIwMTggYXQgMzo1OSBBTSBIYW5uZXMgVHNjaG9m ZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iPkhhbm5l cy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGV5IGd1eXMsDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGFtIHRyeWluZyB0byBmaW5kIG91dCB3aGF0IHlvdSBhcmUgcGxhbm5pbmcgaGVy ZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB5b3UgdGFsa2luZyBhYm91dCBzY2hlZHVsaW5nIGEgc2lk ZSBtZWV0aW5nIGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBvciBhIGYyZiBtZWV0aW5nIHNvbWV3 aGVyZQ0KIGVsc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmlmYWF0IGFuZCBJIGhhZCBwcm9taXNlZCB0byBz Y2hlZHVsZSBhIGNvbmZlcmVuY2UgY2FsbCAodmlydHVhbCBpbnRlcmltIG1lZXRpbmcpIGFib3V0 IGRpc3RyaWJ1dGVkDQogT0F1dGggYW5kIHdlIGFyZSB0YXJnZXRpbmcgTWF5LiBXaGlsZSBob2xk aW5nIGEgZjJmIGludGVyaW0gbWVldGluZyBmb3IgT0F1dGggaXMgcG9zc2libGUgd2UgaGF2ZSBu b3QgZGlzY3Vzc2VkIHRoaXMgc28gZmFyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxicj4NCkhhbm5l czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0i bV85NTY2NjMzMjIyNzE4Mzk5NTZfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoDQogW21h aWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5uLXNh a2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+IDE4IEFwcmlsIDIwMTggMDc6MzQ8YnI+DQo8Yj5Ubzo8 L2I+IERpY2sgSGFyZHQ7IG4tc2FraW11cmE8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0i bV85NTY2NjMzMjIyNzE4Mzk5NTZkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5JIHN1cHBvcnQgdGhlIGlkZWEuIEFkZGluZyB0byBpdCwgcGVyaGFwcyB3 ZSBjYW4gZG8gYW4gYWQtaG9jIGJlZm9yZSBNb250cmVhbCBzbyB0aGF0IHdlIGNhbiBjb21lIHVw IHdpdGggYSBjb21iaW5lZCBkcmFmdC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 IGlkPSJtXzk1NjY2MzMyMjI3MTgzOTk1NlNpZ25hdHVyZSI+DQo8ZGl2IGlkPSJtXzk1NjY2MzMy MjI3MTgzOTk1NmRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TmF0 IFNha2ltdXJhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS08L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UExFQVNFIFJFQUQ6IFRoaXMg ZS1tYWlsIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGll bnQgb25seS4gSWYNCiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMi IHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzk1NjY2MzMy MjI3MTgzOTk1NmRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg R290aGljJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7lt67lh7rk uro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiBE aWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPumAgeS/ oeaXpeaZgjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pg0KIDIwMTg8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpKQSI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+NDwvc3Bhbj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4xODwvc3Bhbj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4NCiAwOjQwOjIwPGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuWum+WFiDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KIG4tc2FraW11cmE8YnI+DQo8Yj5DQzo8L2I+ IFJpZmFhdCBTaGVraC1ZdXNlZjsgb2F1dGg8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iSkEi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+5Lu25ZCNPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQogUmU6IFtPQVVUSC1XR10g Q2FsbCBmb3IgYWdlbmRhIGl0ZW1zPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8c3Bh biBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpKQSI+5pys44Oh44O844Or44Gv44OV44Oq44O844Oh44O844Or44GL 44KJ5bGK44GE44Gm44GE44G+44GZ44CC5qiZ55qE5Z6L5pS75pKD44Oh44O844Or44Gv44OV44Oq 44O844OhPC9zcGFuPjxicj4NCjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7jg7zjg6vjgYvjgonl sYrjgY/jgZPjgajjgYzjgYLjgorjgb7jgZnjga7jgafjgZTms6jmhI/jgY/jgaDjgZXjgYTjgILo uqvjgavopprjgYjjga7jgarjgYTjg6Hjg7zjg6s8L3NwYW4+PGJyPg0KPHNwYW4gbGFuZz0iSkEi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6SkEiPuOBp+OBguOCjOOBsOa3u+S7mOODleOCoeOCpOODq+OChDwvc3Bhbj5VUkw8c3Bh biBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpKQSI+44KS6ZaL44GL44Ga44CB5Lul5LiL44Gr5o6y6LyJ44GV44KM 44Gm44GE44KL5omL6aCG44Gr5b6T44GjPC9zcGFuPjxicj4NCjxzcGFuIGxhbmc9IkpBIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OkpBIj7jgablr77lv5zjgpLjgYrpoZjjgYTjgZfjgb7jgZnjgII8L3NwYW4+PGJyPg0KPGJyPg0K PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuWFseacieaDheWgsTwvc3Bhbj4mZ3Q7PHNwYW4gbGFu Zz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPuaDheWgseOCu+OCreODpeODquODhuOCo+ODiOODlOODg+OCr+OCuTwv c3Bhbj4mZ3Q7PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro aWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuaAquOBl+OBhOODoeODvOODq+OBjOWx iuOBhOOBn+OCiTwvc3Bhbj48YnI+DQo8c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+44G+44Gf44Gv 44CBPC9zcGFuPjxicj4NCk5SSSBHcm91cCBTZWN1cml0eSBQb3J0YWwmZ3Q7PHNwYW4gbGFuZz0i SkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6SkEiPuaDheWgseOCu+OCreODpeODquODhuOCo+ODiOODlOODg+OCr+OCuTwvc3Bh bj48YnI+DQomZ3Q7PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuaAquOBl+OBhOODoeODvOODq+OB jOWxiuOBhOOBn+OCiTwvc3Bhbj48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdkIGxpa2UgdG8gY29vcmRpbmF0ZSBh IHNpZGUgbWVldGluZyB3aXRoIE5hdCwgQnJpYW4sIG15c2VsZiBhbmQgb3RoZXIgaW50ZXJlc3Rl ZCBwYXJ0aWVzIGluIE1vbnRyZWFsIHRvIGRpc2N1c3MgRGlzdHJpYnV0ZWQgT0F1dGguDQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3ZSBoYXZl IHR3byBtZWV0aW5ncywgSSdkIGxpa2UgYSB0aW1lc2xvdCBpbiB0aGUgc2Vjb25kIHRvIHN1bW1h cml6ZSB0aGUgc2lkZSBtZWV0aW5nIGFuZCBkaXNjdXNzIG5leHQgc3RlcHMgKGlmIGFueSkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5T ZXBhcmF0ZWx5LCBJJ2QgbGlrZSBhIHRpbWUgc2xvdCBmb3IgYW4gdXBkYXRlIG9uIFJlY2lwcm9j YWwgT0F1dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIE1hciA3LCAyMDE4IGF0IDU6NTIgUE0sIG4tc2FraW11cmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4t c2FraW11cmFAbnJpLmNvLmpwPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8sIG5vdCByZWFs bHkuIEkgd2FzIHRoaW5raW5nIG9mIG1vcmUgaW5mb3JtYWwgdGhpbmcuIFRoZSBzZXNzaW9uIGlz IHN1cHBvc2VkIHRvIGJlIFdlZG5lc2RheSBhZnRlcm5vb24sIHNvIEkgd2FzIHRoaW5raW5nIHRo YXQNCiBpdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBkbyBhIGJpdCBvZiByZWNhcCBhbW9uZyBj b250cmlidXRvcnMgdG8gZHJhdyB1cCBhIGJhdHRsZSBwbGFuIHRvd2FyZHMgSUVURiAxMDIuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29u b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TmF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2 NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUmlmYWF0IFNoZWtoLVl1c2VmIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFh dC5pZXRmQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJj aCAwNywgMjAxOCA5OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBuLXNha2ltdXJhICZsdDs8YSBocmVm PSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2ltdXJh QG5yaS5jby5qcDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozsgb2F1dGggJmx0OzxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZn dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5k YSBpdGVtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QXJlIHlvdSBhc2tpbmcgZm9yIGFuIGludGVyaW0gbWVldGluZz88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBjb3VsZCBzY2hlZHVsZSB0aGUg RGlzdHJpYnV0ZWQgT0F1dGggZGlzY3Vzc2lvbiBmb3IgdGhlIFdlZG5lc2RheSBtZWV0aW5nOyB0 aGF0IHdpbGwgZ2l2ZSB5b3UgZ3V5cyBzb21ldGltZSB0byBkaXNjdXNzIHRoZXNlIGZhY2UtdG8t ZmFjZSBpbiBMb25kb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05 NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtSaWZhYXQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1z b25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBXZWQsIE1hciA3LCAyMDE4IGF0IDI6MDAgQU0sIG4tc2FraW11cmEgJmx0 OzxhIGhyZWY9Im1haWx0bzpuLXNha2ltdXJhQG5yaS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsiPm4t c2FraW11cmFAbnJpLmNvLmpwPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbiBsZXQgdXMg ZG8gaXQuIFdlIG5lZWQgdG8gcHV0IGFsbCB0aGUgcHJvcG9zYWxzIG9uIHRoZSB0YWJsZSBhbmQg c3RyYXRlZ2l6ZSB0aGUgZGVzaWduLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXJoYXBzIHdlIG5lZWQgYSBzaWRlIG1lZXRp bmcgYXMgd2VsbC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5uYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggMTozMSBBTTxi cj4NCjxiPlRvOjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlm YWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGhhZG4ndCBwcmV2aW91c2x5IGJlZW4gcGxhbm5pbmcgb24gaXQgYnV0IGFtIGhhcHB5IHRv IGRvIHNvLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05 NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBN YXIgNiwgMjAxOCBhdCA4OjIyIEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1h aWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OYXQsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkR1cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCAzIGRyYWZ0 cyBtZW50aW9uZWQgaW4gdGhlIGNvbnRleHQgb2YNCjxiPkRpc3RyaWJ1dGVkIE9BdXRoPC9iPjo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYuLm9yZy9o dG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wODwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRv cnMtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29u b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYuLm9y Zy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UtMDAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRp ZW5jZS0wMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5CcmlhbiwgSGFubmVzLDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5B cmUgeW91IHBsYW5uaW5nIG9uIHByZXNlbnRpbmcgeW91ciBkb2N1bWVudHM/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDtSaWZhYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1 Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2 NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1z b25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgTWFyIDUsIDIwMTggYXQgODowOSBQ TSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgdGhhdC4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsc28sIGFzIHBhcnQgb2YgJnF1b3Q7RGlzdHJpYnV0ZWQg T0F1dGgmcXVvdDssIGNhbiB3ZSBkbyBhIGJpdCBvZiByZS1jYXAgb24gc29tZSBvZiB0aGUgcHJl dmlvdXMgZHJhZnRzIG9uIHRoZSBzaW1pbGFyIHRvcGljIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUg aW50ZXJpbT8gaS5lLiwgQnJpYW4ncyBkcmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5k DQogbXkgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc2Fr aW11cmEtb2F1dGgtbWV0YS0wOC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojNDQwMDg4Ij5kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhPC9z cGFuPjwvYT4pPyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJt OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsJm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2 NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TmF0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIE1hciA2LCAyMDE4IGF0IDM6MzAg QU0gV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IYW5uZXMgJmFtcDsgUmlmYWF0 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYz MzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkkgd291bGQg bGlrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBvbiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hp dGUiPk9BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1v YXV0aC1pbmNyZW1lbnRhbC1hdXRoKSBbYW4gdXBkYXRlIGZvciB3aGljaCB3aWxsDQogYmUgcG9z dGVkIHRvZGF5XSBhbmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZxdW90O09BdXRo IDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzJnF1b3Q7IChkcmFmdC13ZGVubmlzcy1vYXV0aC1k ZXZpY2UtcG9zdHVyZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05 NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBjYW4gYWxz byBnaXZlIGFuIHVwZGF0ZSBvbiB0aGUgc3RhdHVzIG9mIERldmljZSBGbG93IChkcmFmdC1pZXRm LW9hdXRoLWRldmljZS1mbG93KS4gSSBleHBlY3QgdGhhdCB0byBiZSBzaG9ydCBub3cgdGhhdCBX R0xDIGhhcyBjb25jbHVkZWQgYW5kIHRoZSBkb2N1bWVudCBoYXMgYWR2YW5jZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGl0dGxlIGxhdGUgdG8gdGhpcyB0aHJlYWQgYW5kIEkg c2VlIHdlIGFscmVhZHkgaGF2ZSAyIHNlc3Npb25zIGluIHRoZSBkcmFmdCBhZ2VuZGEsIGJ1dCBJ J2QgbGlrZSB0byBhZGQgbXkgc3VwcG9ydCB0byBrZWVwaW5nIGJvdGggc2Vzc2lvbnMsIHRoZXJl J3MgYWx3YXlzIGEgbG90IHRvIGRpc2N1c3MgYW5kIGluIHRoZSBwYXN0IHdlJ3ZlIGJlZW4NCiBh YmxlIHRvIHVzZSBhbnkgc3BhcmUgdGltZSB0byBkaXNjdXNzIHRoZSBzZWN1cml0eSB0b3BpY3Mg b2YgdGhlIGRheS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2 MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldpbGxpYW08L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgSmFuIDMwLCAyMDE4IGF0IDQ6 NDAgQU0gSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9m ZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+SGkgYWxsLCA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPkl0IGlz IHRpbWUgYWxyZWFkeSB0byB0aGluayBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgbmV4dCBJRVRG IG1lZXRpbmcuIFJpZmFhdCBhbmQgSSB3ZXJlIHdvbmRlcmluZyB3aGV0aGVyIHdlIG5lZWQgb25l IG9yIHR3byBzZXNzaW9ucy4gV2Ugd291bGQgbGlrZSB0byBtYWtlIHRoZSBkZWNpc2lvbiBiYXNl ZCBvbiB0aGUgdG9waWNzIHdlIHdpbGwgZGlzY3Vzcy4gQmVsb3cgeW91DQogY2FuIGZpbmQgYSBm aXJzdCB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEgd2l0aCBhIGZldyByZW1hcmtzLiBMZXQgdXMga25v dyBpZiB5b3UgaGF2ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBmb3IgYWRkaXRpb25hbCBhZ2Vu ZGEgaXRlbXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgUmlmYWF0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9BdXRoIEFn ZW5kYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2 MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gV2VsY29tZSBhbmQgU3RhdHVzIFVwZGF0ZSZuYnNw OyAoQ2hhaXJzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2 MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICogT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgUmVwb3J0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNv bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyogRG9jdW1lbnRzIGluIElFU0cgcHJvY2Vzc2luZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA3DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29u b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IyBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVy eS0wOA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS0xMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7UmVtYXJrOiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlm IG5lZWRlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0mbmJzcDsg SlNPTiBXZWIgVG9rZW4gQmVzdCBDdXJyZW50IFByYWN0aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgIyBkcmFm dC1pZXRmLW9hdXRoLWp3dC1iY3AtMDANCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7UmVtYXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1lbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBNb3N0IGxpa2VseSB3ZSB3aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcgdGhlIGYy ZiBtZWV0aW5nDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YnV0IHJhdGhlciBieSByZWFjaGluZyBvdXQg dG8gaW5kaXZpZHVhbHMgYWhlYWQgb2YgdGltZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSZuYnNw OyBPQXV0aCAyLjAgTXV0dWFsIFRMUyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIENlcnRpZmlj YXRlIEJvdW5kIEFjY2VzcyBUb2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1t dGxzLTA2DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBSZW1hcms6IENvdWxkIGJlIGNvbXBsZXRlZCBi eSB0aGUgdGltZSBvZiB0aGUgSUVURiBtZWV0aW5nLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9B dXRoIFNlY3VyaXR5IFRvcGljczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2 NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRv cGljcy0wNA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtSZW1hcms6IFdlIGNvdWxkIGRvIGEg Y29uc2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPi0gT0F1dGggMi4wIFRva2VuIEJpbmRpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC10 b2tlbi1iaW5kaW5nLTA1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazogRG9jdW1lbnQgaXMg bW92aW5nIGFsb25nIGJ1dCB3ZSBhcmUgbGFja2luZyBpbXBsZW1lbnRhdGlvbnMuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPi0gT0F1dGggMi4wIERldmljZSBQb3N0dXJlIFNpZ25hbHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQt d2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7UmVtYXJrOiBJbnRlcmVzdCBpbiB0aGUgd29yayBidXQgd2UgYXJlIGxhY2tpbmcgY29udGVu dCAobWF5YmUgZXZlbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO2V4cGVydGlzZSBpbiB0aGUgZ3JvdXApPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPi0gUmVjaXByb2NhbCBPQXV0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1oYXJkdC1vYXV0aC1tdXR1YWwt MDINCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7IFJlbWFyazogV2UgaGFkIGEgdmlydHVhbCBpbnRlcmltIG1lZXRp bmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtpbnRlcmVzdCBpbiB0 aGlzIHdvcmsgYW5kIGFwcGFyZW50bHkgbm8gY29tcGV0aW5nIHNvbHV0aW9ucy4gVGhlIHBsYW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29u b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7IGlzIHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFsbG93ZWQg dG8gYWRkIGEgbmV3IG1pbGVzdG9uZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO3RvIG91ciBjaGFydGVyLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4tIERpc3RyaWJ1dGVkIE9BdXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRyYWZ0LWhhcmR0LW9hdXRo LWRpc3RyaWJ1dGVkLTAwDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2 MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBSZW1hcms6IFdlIGhhZCBhIHZpcnR1YWwg aW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJlIGlzDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 aW50ZXJlc3QgaW4gdGhpcyB3b3JrLiBGdXJ0aGVyIHdvcmsgb24gdGhlIHNjb3BlIGlzIG5lZWRl ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMNCiB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0ibTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGNsYXNzPSJtOTU2 NjYzMzIyMjcxODM5OTU2eG0tNDM0MTc4MDUwOTc3NjA4NjIyNW02MTkzNTExNDA1MTE0NTc2NjU1 bTI0MjQzOTA0NDAzNzI5Nzc5ODhob2VuemIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+LS0NCjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5OYXQgU2FraW11cmE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb248L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5 OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5 OTU2eG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTU2NjYz MzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNv bm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQNCiByZWNpcGllbnQocykuIEFueSByZXZp ZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv dXIgY29tcHV0ZXIuDQogVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLA0KIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMg b2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Ns b3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJw b3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB2112819E94AB2E3302B4F75DFAB60VI1PR0801MB2112_-- From nobody Wed Apr 18 07:29:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7E126B72 for ; Wed, 18 Apr 2018 07:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzXhUfs7zL28 for ; Wed, 18 Apr 2018 07:29:21 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0BC124F57 for ; Wed, 18 Apr 2018 07:29:21 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id j11so954017pgf.2 for ; Wed, 18 Apr 2018 07:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tqKNf7TXGHNXIr2Bo0srMZ849pxFubgnxYGN4srctxA=; b=XoGhCvxD/L+LWTIJ8KMfNgUjdC/6nRPZNiEsJhYCV+BIt8A5wEj+9DGHoocqcPBcKe v+RBeWqjItj9FmMBCXQJywMqFL19coO3D+eN26Fqo0Tj7AxyOtmODl7yvfuksYQaueQ8 KWKP1jG8CaP1tXV3wEISGAFNznR9/ZUG57Su16ZG2fJCadPLGU72uQfP70JXd2RfRLW+ uoYL42qJvoWy8ohNGyUXOA+wm6oviBzNusnwUH8hP70SjdjAreH/o7rlT2n44jYFr3US LqbXfHfoYm8hdl/LEa08pLAQcLDLegs8wGe8yp++htT0CwrT0iKYzg+zothQQlLkTXjz SZ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tqKNf7TXGHNXIr2Bo0srMZ849pxFubgnxYGN4srctxA=; b=DiUgkPp2TSwNOjofKsNlmqZoRSrhhMrXvDC4fdmHxD3rqEfa6NG8uvP04iSAkPNAS0 UY0I+CmCzHIOspfeFC6l8+Zo4zLsly0muVbSjU24ft05oau1vozJoQpMqjsdruUd5x8F o6dBgozADdeEMUdz/xJfF73MjPo+NgAUd+2VgAS+vXq37sLEtLsy7opbJN+f0xbhC4G7 G/mGUBKL5JXlQiFdOGbn79/f+uT+bhvbVVC6ANyp0uRYHU4waQ/XA7Oo+GsLnVm4LP74 mTWxf7tjWEMVXOH4wr/AeBu0vsfCVn+9X0HXMaB5KB3QcY+c4G2X5fKbDZHbaUHwqy1W aSYQ== X-Gm-Message-State: ALQs6tC513MquzLjWGCJ58i4b/KBN8DikYtpxCR/Jo3wpn2Hwjdo0A9j IkdrAj3rQGHNa6vmWBQ7foHo00ZGowa61B+iWzc= X-Google-Smtp-Source: AIpwx49lF29yEhcid4pXTR6L1dQ+oid0gW9oHJW3NTjOW3KHa7opvLYQzbJMphxTEoIFlck4AHsZnvyUb99bKnkLVY0= X-Received: by 10.99.109.200 with SMTP id i191mr1865195pgc.291.1524061760512; Wed, 18 Apr 2018 07:29:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 18 Apr 2018 14:29:08 +0000 Message-ID: To: Hannes Tschofenig Cc: n-sakimura , oauth Content-Type: multipart/alternative; boundary="f403045c0500da047a056a2047ba" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:29:24 -0000 --f403045c0500da047a056a2047ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The last interm meeting was not very productive. The value I got was that it would be useful to see if Nat, Brian and I could coalesce. On Wed, Apr 18, 2018 at 7:21 AM Hannes Tschofenig wrote: > Hi Dick, > > > > The value of a conference call as part of the OAuth working group is that > you involve other interested parties to the discussion, and that you do n= ot > have to repeat your private conversations later again on the mailing list= . > > That=E2=80=99s pretty convincing to me ;-) > > > > Ciao > > Hannes > > > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* 18 April 2018 16:15 > *To:* Hannes Tschofenig > *Cc:* n-sakimura; oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > F2F side/author meeting at Montreal > > Ad hock author meeting call prior > > > > Unclear to me the value of a WG intern meeting > > > > On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hey guys, > > > > I am trying to find out what you are planning here. > > > > Are you talking about scheduling a side meeting at the next IETF meeting > or a f2f meeting somewhere else? > > > > Rifaat and I had promised to schedule a conference call (virtual interim > meeting) about distributed OAuth and we are targeting May. While holding = a > f2f interim meeting for OAuth is possible we have not discussed this so > far. > > > > Ciao > Hannes > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *n-sakimura > *Sent:* 18 April 2018 07:34 > *To:* Dick Hardt; n-sakimura > *Cc:* oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I support the idea. Adding to it, perhaps we can do an ad-hoc before > Montreal so that we can come up with a combined draft. > > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > > > > > ------------------------------ > > *=E5=B7=AE=E5=87=BA=E4=BA=BA**:* Dick Hardt > *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82**:* 2018=E5=B9=B44=E6=9C=8818=E6=97= =A5 0:40:20 > *=E5=AE=9B=E5=85=88**:* n-sakimura > *CC:* Rifaat Shekh-Yusef; oauth > *=E4=BB=B6=E5=90=8D**:* Re: [OAUTH-WG] Call for agenda items > > > > ****************************************************************** > =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3= =81=84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92= =83=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 > =E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8= =E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6= =B3=A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81= =AB=E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB > =E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1= =E3=82=A4=E3=83=AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81= =E4=BB=A5=E4=B8=8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3= =81=84=E3=82=8B=E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3 > =E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 > > =E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD= =E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3= =82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5= =B1=8A=E3=81=84=E3=81=9F=E3=82=89 > =E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81 > NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5= =E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9 > >=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A= =E3=81=84=E3=81=9F=E3=82=89 > ****************************************************************** > > I'd like to coordinate a side meeting with Nat, Brian, myself and other > interested parties in Montreal to discuss Distributed OAuth. > > > > If we have two meetings, I'd like a timeslot in the second to summarize > the side meeting and discuss next steps (if any). > > > > Separately, I'd like a time slot for an update on Reciprocal OAuth. > > > > On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura wrote: > > No, not really. I was thinking of more informal thing. The session is > supposed to be Wednesday afternoon, so I was thinking that it might be a > good idea to do a bit of recap among contributors to draw up a battle pla= n > towards IETF 102. > > > > Nat > > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Wednesday, March 07, 2018 9:22 PM > *To:* n-sakimura > *Cc:* Brian Campbell ; oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > Nat, > > > > Are you asking for an interim meeting? > > We could schedule the Distributed OAuth discussion for the Wednesday > meeting; that will give you guys sometime to discuss these face-to-face i= n > London. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distrib= uted > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some o= f > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for whic= h > will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC h= as > concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use an= y > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Acces= s > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new mileston= e > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --f403045c0500da047a056a2047ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The last interm meeting was not very productive. The= value I got was that it would be useful to see if Nat, Brian and I could c= oalesce.

On Wed, Apr 18, 2018 at 7= :21 AM Hannes Tschofenig <H= annes.Tschofenig@arm.com> wrote:

Hi Dick,

=C2=A0

The value of a conference= call as part of the OAuth working group is that you involve other interest= ed parties to the discussion, and that you do not have to repeat your private conversations later again on the mailing list. =

That=E2=80=99s pretty convincing to me ;-)<= u>

=C2=A0

Ciao=

Hannes

=C2=A0

=C2=A0

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: 18 April 2018 16:15
To: Hannes Tschofenig
Cc: n-sakimura; oauth


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

F2F side/author meeting at Montreal

Ad hock author meeting call prior

=C2=A0

Unclear to me the value of a WG intern meeting

=C2=A0

On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hey guys,

=C2=A0

I am trying to find out w= hat you are planning here.

=C2=A0

Are you talking about sch= eduling a side meeting at the next IETF meeting or a f2f meeting somewhere else?

=C2=A0

Rifaat and I had promised= to schedule a conference call (virtual interim meeting) about distributed OAuth and we are targeting May. While holding a f2f interim meeting for OA= uth is possible we have not discussed this so far.

=C2=A0

Ciao
Hannes

=C2=A0

From: OAuth [mailto:oauth-= bounces@ietf.org] On Behalf Of n-sakimura
Sent: 18 April 2018 07:34
To: Dick Hardt; n-sakimura
Cc: oauth


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I support the idea. Adding to it, perhaps we can do an ad-hoc be= fore Montreal so that we can come up with a combined draft.=C2=A0=

=C2=A0

Nat Sakimura=

--

PLEASE READ: = This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete thi= s e-mail.

=C2=A0

=C2=A0<= /u>

=C2=A0

=C2=A0

=E5=B7=AE=E5=87=BA=E4=BA=BA: Dick Hardt <d= ick.hardt@gmail.com>
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2018=E5=B9=B44=E6=9C=8818=E6=97=A5 0:40:20
=E5=AE=9B=E5=85=88: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] Call for agenda items

=C2=A0

****************************************************= **************
=E6=9C=AC=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1=E3=83= =BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92=83=E3=83=A1=E3= =83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1
=E3=83=BC=E3= =83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8=E3=81=8C=E3=81= =82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6=B3=A8=E6=84=8F= =E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81=AB=E8=A6=9A=E3= =81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB
=E3=81=A7=E3= =81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1=E3=82=A4=E3=83= =AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81=E4=BB=A5=E4=B8=8B=E3= =81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=89= =8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3
=E3=81=A6=E5= =AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97=E3=81=BE=E3=81= =99=E3=80=82

=E5=85=B1=E6= =9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5=E3=83= =AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9&g= t;=E6=80=AA= =E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A=E3=81=84=E3= =81=9F=E3=82=89
=E3=81=BE=E3= =81=9F=E3=81=AF=E3=80=81
NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5=E3=83=AA=E3= =83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9
>=E6=80=AA= =E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A=E3=81=84=E3= =81=9F=E3=82=89
******************************************************************

I'd like to coordinate a side meeting with Nat, = Brian, myself and other interested parties in Montreal to discuss Distribut= ed OAuth.

=C2=A0

If we have two meetings, I'd like a timeslot in = the second to summarize the side meeting and discuss next steps (if any).

=C2=A0

Separately, I'd like a time slot for an update o= n Reciprocal OAuth.

=C2=A0

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura@nri.co.jp> wrote:

No, not really. I was thinking of more inform= al thing. The session is supposed to be Wednesday afternoon, so I was think= ing that it might be a good idea to do a bit of recap among contributors to draw up= a battle plan towards IETF 102.

=C2=A0

Nat

=C2=A0

From: Rifaat She= kh-Yusef [mailto:rifaat.ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org><= /u>


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

Nat,

=C2=A0

Are you asking for an interim meeting?

We could schedule the Distributed OAuth discussion for the Wedne= sday meeting; that will give you guys sometime to discuss these face-to-fac= e in London.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura <n-sakimura@nri.co.jp> wrote= :

Then let us do it. We need to put all the pro= posals on the table and strategize the design.

Perhaps we need a side meeting as well.

=C2=A0

nat

=C2=A0

From: OAuth [mai= lto:oauth-bounc= es@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I hadn't previously been planning on it but am happy to do s= o.

=C2=A0

On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

=C2=A0

On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura <sakimura@gmail.com> wrote:<= /span>

I would be interested in hearing that.=C2=A0

=C2=A0

Also, as part of "Distributed OAuth", can we do a bit = of re-cap on some of the previous drafts on the similar topic as we discuss= ed in the interim? i.e., Brian's draft (where is the link now?) and my draft (dra= ft-sakimura-oauth-meta)?=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

On Tue, Mar 6, 2018 at 3:30 AM William Denniss <wdenniss@google.com> wro= te:

Hannes & Rifaat,


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (d= raft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).

=C2=A0

I can also give an update on the status of Device Flow (draft-ie= tf-oauth-device-flow). I expect that to be short now that WGLC has conclude= d and the document has advanced.

=C2=A0

Little late to this thread and I see we already have 2 sessions = in the draft agenda, but I'd like to add my support to keeping both ses= sions, there's always a lot to discuss and in the past we've been able to use any spare time to discuss the security topics of the day.

=C2=A0

Regards,

William

=C2=A0

=C2=A0

=C2=A0

On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.= com> wrote:

Hi all, =

=C2=A0

It is time = already to think about the agenda for the next IETF meeting. Rifaat and I w= ere wondering whether we need one or two sessions. We would like to make th= e decision based on the topics we will discuss. Below you can find a first version of the agenda with a few remarks. Let us know if = you have comments or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

OAuth Agenda<= /p>

------------<= /p>

=C2=A0

- Welcome and Status Update=C2=A0 = (Chairs)

=C2=A0

=C2=A0 * OAuth Security Workshop R= eport

=C2=A0

=C2=A0=C2=A0* Documents in IESG pr= ocessing

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-i= etf-oauth-device-flow-07

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# dr= aft-ietf-oauth-discovery-08

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# dr= aft-ietf-oauth-jwsreq-15

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-i= etf-oauth-token-exchange-11

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0Remark: Status updates only if needed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0

-=C2=A0 JSON Web Token Best Curren= t Practices

=C2=A0=C2=A0 # draft-ietf-oauth-jw= t-bcp-00

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Remark: We are l= acking reviews on this document.

=C2=A0=C2=A0 Most likely we will n= ot get them during the f2f meeting

=C2=A0=C2=A0=C2=A0but rather by re= aching out to individuals ahead of time.

=C2=A0=C2=A0=C2=A0

-=C2=A0 OAuth 2.0 Mutual TLS Clien= t Authentication and Certificate Bound Access Tokens

=C2=A0=C2=A0 # draft-ietf-oauth-mt= ls-06

=C2=A0

=C2=A0=C2=A0 Remark: Could be comp= leted by the time of the IETF meeting.

=C2=A0=C2=A0=C2=A0

- OAuth Security Topics<= /u>

=C2=A0 # draft-ietf-oauth-security= -topics-04

=C2=A0=C2=A0<= /p>

=C2=A0=C2=A0Remark: We could do a = consensus call on parts of the document soon.

=C2=A0=C2=A0<= /p>

- OAuth 2.0 Token Binding

=C2=A0 # draft-ietf-oauth-token-bi= nding-05

=C2=A0

=C2=A0=C2=A0Remark: Document is mo= ving along but we are lacking implementations.

=C2=A0=C2=A0<= /p>

- OAuth 2.0 Device Posture Signals=

=C2=A0 # draft-wdenniss-oauth-devi= ce-posture-01

=C2=A0=C2=A0<= /p>

=C2=A0=C2=A0Remark: Interest in th= e work but we are lacking content (maybe even

=C2=A0=C2=A0expertise in the group= )

=C2=A0

- Reciprocal OAuth

=C2=A0 # draft-hardt-oauth-mutual-= 02

=C2=A0

=C2=A0 Remark: We had a virtual in= terim meeting on this topic and there is

=C2=A0=C2=A0interest in this work = and apparently no competing solutions. The plan

=C2=A0 is to run a call for adopti= on once we are allowed to add a new milestone

=C2=A0=C2=A0to our charter.

=C2=A0=C2=A0<= /p>

- Distributed OAuth<= u>

=C2=A0 # draft-hardt-oauth-distrib= uted-00

=C2=A0

=C2=A0 Remark: We had a virtual in= terim meeting on this topic and there is

=C2=A0=C2=A0interest in this work.= Further work on the scope is needed.

IMPORTANT N= OTICE: The contents of this email and any attachments are confidential and = may also be privileged. If you are not the intended recipient, please notif= y the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura<= u>

Chairman of the Board, Open= ID Foundation


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confid= ential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.=C2=A0 If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--f403045c0500da047a056a2047ba-- From nobody Wed Apr 18 08:17:52 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E8E126BF3 for ; Wed, 18 Apr 2018 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL0QUSpgya_t for ; Wed, 18 Apr 2018 08:17:49 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D19127337 for ; Wed, 18 Apr 2018 08:17:48 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id v13-v6so2857287iob.6 for ; Wed, 18 Apr 2018 08:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oRjw0BuxPrAx4QwU8Ry5zg+Cc0JfNihubN73zVhJ+ek=; b=h65SPaehDeZ86j5WqktYQSEWLD+AUtui+blQZH0CxcsMweFZ7jIxsxBvad9ExHHHs7 fRmn5QXqBLPXNspl3COaiBl/zIgVVe4Db7G+voXNJfKTYKmgDtW0PeFpbWmx/CsqVHEf khLiVSEWH5axyVyS1Wt2xzDQz+q4/9p9bNeds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oRjw0BuxPrAx4QwU8Ry5zg+Cc0JfNihubN73zVhJ+ek=; b=cK6n+/LKubeUrvcFI4jzjIC19jnLTzgc17eDX9v2nh/bg0oCOQtF9sT9ewANLbYBAQ bjF4U2VnVcRO+WOnAsqI02vxovhy3nEn8MkTfJnuFl5Pd7a3HTS0NVjfjtFOZ9Nlpsl5 zT9YSd0jHTYQbCplUWntGpZ72GAJirFyVZBj7kog8WEH1ehf02gtRzVjuBYliWOybVUp di9htTIQjBMg3XejS7mb+7Cc312TtkOfdsmgJB83j3o3PXAe+leGcHufHV2P0ZijcZVO RQuz+9fIl1eJHtdQdcfsGN59pQTly+E1VJYOfA+VVZ+Pk25htG6wf6eO+3NXJYasBr7W 5Adw== X-Gm-Message-State: ALQs6tBxKxTum7Ki9vNfz3MlOp1UamxknMljsm+cgaCljXO8uGSuXM33 17VaJU1bJist767g6JxwxXRBggjk/KsuFgqw9JOMSzhvaKup1jdwAEOKUXHek6ufezvzTuFU4oV QdgTa3r55tMAgAg== X-Google-Smtp-Source: AB8JxZoiZO5QH9TkaLYH2u9Cd+B3/nrQmCosNOB+pI+BO27X49Odsqa2ktglSbIILmaxlxZF8+ROtF18XJ2DRRgOQZw= X-Received: by 2002:a6b:1458:: with SMTP id 85-v6mr2366403iou.218.1524064667929; Wed, 18 Apr 2018 08:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 08:17:17 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 18 Apr 2018 09:17:17 -0600 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="00000000000025cbcc056a20f543" Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:17:51 -0000 --00000000000025cbcc056a20f543 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The draft-ietf-oauth-token-exchange document makes use of scope and at some point in that work it came to light that, despite the concept of scope being used lots of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to have draft-ietf-oauth-token-exchange define and register a JWT claim for scope. It's kind of an awkward place for it really but that's how it came to be there. When I added it to the draft, I opted for the semi-convention of JWT using three letter short claim names. And decided to use a JSON array to convey multiple values rather than space delimiting. It seemed like a good idea at the time - more consistent with other JWT claim names and cleaner to use the facilities of JSON rather than a delimited string. That was the thinking at the time anyway and, as I recall, I asked the WG about doing it that way at one of the meetings and there was general, if somewhat absent, nodding in the room. Looking at this again in the context of the question from Torsten and his developers, I think using a different name and syntax for the JWT claim vs. the Introspection response member/parameter/claim is probably a mistake. While RFC 7662 Introspection response parameters aren't exactly the same as JWT claims, they are similar in many respects. So giving consistent treatment across them to something like scope is Therefore I propose that the JWT claim for representing scope in draft-ietf-oauth-token-exchange be changed to be consistent with the treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That effectively means changing the name from "scp" to "scope" and the value from a JSON array to a string delimited by spaces. I realize it's late in the process to make this change but believe doing so will significantly reduce confusion and issues in the long run. On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a = claim > =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC 7662 u= se a claim =E2=80=9Escope=E2=80=9C > for the same purpose. As far as I understand the text, the intension is t= o > represent a list of RFC6749 scopes. Is this correct? What=E2=80=99s the r= ationale > behind? > > Different claim names for representing scope values confuse people. I > realized that when one of our developers pointed out that difference > recently. > > best regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000025cbcc056a20f543 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The draft-ietf-oauth-token-exchange documen= t makes use of scope and at some point in that work it came to light that, = despite the concept of scope being used lots of places elsewhere, there was= no officially registered JWT claim for scope. As a result, we (the WG) dec= ided to have draft-ietf-oauth-token-exchange define and register a JWT= claim for scope. It's kind of an awkward place for it really but that&= #39;s how it came to be there.

When I added it to the draft, = I opted for the semi-convention of JWT using three letter short claim names= . And decided to use a JSON array to convey multiple values rather than spa= ce delimiting. It seemed like a good idea at the time - more consistent wit= h other JWT claim names and cleaner to use the facilities of JSON rather th= an a delimited string. That was the thinking at the time anyway and, as I r= ecall, I asked the WG about doing it that way at one of the meetings and th= ere was general, if somewhat absent, nodding in the room.

Looking at this again in the context of the question from Torsten and his= developers, I think using a different name and syntax for the JWT claim vs= . the Introspection response member/parameter/claim is probably a mistake.= =C2=A0 While RFC 7662 Introspection response parameters aren't exactly = the same as JWT claims, they are similar in many respects. So giving consis= tent treatment across them to something like scope is

Th= erefore I propose that the JWT claim for representing scope in draft-ietf-o= auth-token-exchange be changed to be consistent with the treatment of = scope in=C2=A0RFC 7662 OAuth 2.0 Token Introspection. That effectively mean= s changing the name from "scp" to "scope" and the value= from a JSON array to a string delimited by spaces.

I re= alize it's late in the process to make this change but believe doing so= will significantly reduce confusion and issues in the long run.=C2=A0
=

=C2=A0




On Sun, Apr 15, 2018 at 10:43 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines= a claim =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC= 7662 use a claim =E2=80=9Escope=E2=80=9C for the same purpose. As far as I= understand the text, the intension is to represent a list of RFC6749 scope= s. Is this correct? What=E2=80=99s the rationale behind?

Different claim names for representing scope values confuse people. I reali= zed that when one of our developers pointed out that difference recently. <= br>
best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000025cbcc056a20f543-- From nobody Wed Apr 18 08:23:17 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2F12D94B for ; Wed, 18 Apr 2018 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A5TzL4PA_Js for ; Wed, 18 Apr 2018 08:23:10 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCF12D864 for ; Wed, 18 Apr 2018 08:23:09 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id x144-v6so17950891itc.0 for ; Wed, 18 Apr 2018 08:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IyDhNREmpwWgmayRoqmTxK3szYwDLjHX0jTNoqGbRdA=; b=abpVCyoCtzMEecWaFUQbUPAqs7uJ+nG9maQsltJXNamgrZLN75tKJzJfw7STHW67Kr LbQho31wIwpXjFPOH6/nq1Omgl1B0Vgq7C6BJ/qj/T1WXm57TP+TR/w0zREIbrT8rVzl GBQk3Y8lxglXJA2Qw5vnXF9nVNhqe/mH5MzZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IyDhNREmpwWgmayRoqmTxK3szYwDLjHX0jTNoqGbRdA=; b=KkECafyozbM3ih3ghEW+FbWLHGIbXy3Bc4MNj+UE/1IDKAiflYiW8nmE+kpgkUr7lc 6m0SuSCyVA0D6eWtNAoj8xxRiLZyayTpElQvn2KwBZELkYak4MjI1iJRZxSdc5yd2f8k Lsw64RtvH2w1HJ++ZW8JGQOTp9c3m1+2RaM+n9K03wvOuYjyRpBwKBgktsHmnDJ33efI RJt60C/TxNglO2kNa8TljRg+PK/gqbbfT80E70rD1YcMGU90OPwcqnIZHxwP1xtqFGQq po+QmRSVzaprCTidAGUrJafVrowVtDLIL1AjULjYhj9L7D3JBe1s+0nZuJzlqv4Uv+aA 2H3Q== X-Gm-Message-State: ALQs6tC4pTHn5KSN0WozjvVzAO5XacuaRxxTxOnktsTZalIuiE+h5cPq 3kqF6QdS7W6P/8+kI/yer395Wzy5kr7lWFt8RxuCdIAz13yKP7ZPAOOKd1Bl13IyznLZ7Dkq7O+ SlK1i1zzgxJrwdQ== X-Google-Smtp-Source: AIpwx4+VZeZ4i195p6e/JBdojtzvosA1hUEa7M55nYZjXfSKbEOFQAKkDR5N8B6KqLcBIggN62lRrGlY6Z58khrANME= X-Received: by 2002:a24:e488:: with SMTP id o130-v6mr2798736ith.37.1524064988957; Wed, 18 Apr 2018 08:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 08:22:38 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 18 Apr 2018 09:22:38 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004830d3056a2108d2" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:23:15 -0000 --0000000000004830d3056a2108d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of OAuth 2.0 Incremental Authorization as a WG document. On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption = of > the *OAuth 2.0 Incremental Authorization* as a WG document > https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ > > Please, let us know if you support or object to the adoption of this > document. > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004830d3056a2108d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of OAuth 2.0 Incremental Authorization = as a WG document.

On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef <rifaat.= ietf@gmail.com> wrote:
All,

We= would like to get a confirmation on the mailing list for the=C2=A0adoption= =C2=A0of the=C2=A0OAuth 2.0 Incremental Authorization=C2=A0as a = WG document

Please, let us know if you support or obj= ect to the=C2=A0adoption=C2=A0of this document.<= /div>

Regards,
=C2=A0Rifaat & Hannes


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004830d3056a2108d2-- From nobody Wed Apr 18 08:35:03 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA4127337 for ; Wed, 18 Apr 2018 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7AmrAS4tB6Q for ; Wed, 18 Apr 2018 08:34:55 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F011200A0 for ; Wed, 18 Apr 2018 08:34:55 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f22-v6so826406ioc.11 for ; Wed, 18 Apr 2018 08:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jcq42eCOS8GvDslx5JQW0s7e5Y0+C3YyI2Fi7zT5zfI=; b=LyqQT5y4zcu/mh1UjfxN8QZ+vXBjOrHHS5kGElC4Fo7LvR77/rwc9B/xnK1CtVwEvV k8DH1x6l4wyWeowZGQhWgpTzbrU6sEGs2awUZyTsXW2duveqqgo62VDA1S6ibG8bxZ+B iYpMLLbY/3U1/iiHtSxVjREiWtqtNTwF95TUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jcq42eCOS8GvDslx5JQW0s7e5Y0+C3YyI2Fi7zT5zfI=; b=oiercVRix3r5MIg/dhMsTqD6Tyte48BXyID5CfUGmVq7dC8JU0wmmB4/2i4DkB0RHZ tGLh0fnjBq3FxxopfXeVqEI1B7DrXzbNoswEB3XeYuti67YwkSmsSrAkGBUkIADx/LH4 7neHSddQOVIqpesWLmNbeXGIzzD/1ATmKP9DuO0y5nBme27LTTz5qZ3P+LjxS11wuPGl LtnqcrFEDaIfcJjueQ6vZqdth67o8zpZjQa8De1NXHIsOPiJ7pFgfuXmfBWopKc8UuU5 qS7vbzr8wT5lL8csT9M25UaTh4SJX4Io+onbMlmdaJ44k7GYdlD1mA9OSGLP1+ut/aru SwVw== X-Gm-Message-State: ALQs6tAcFTr66q72Oloo/TSHT2D24Y5VRBBJJjENXYQ3fLPA/ydTnw/D 8zh8waOdr/pNmzP9RojU9wim+FCr0to+GXiPf2AVgNKGBDSMBinLSQW+ixr7Ftnp2P22QK/voQt CLGF+yQKTBQOA4g== X-Google-Smtp-Source: AB8JxZopcF52ElQiFPphYMP9IhmFIyNIXPfUwVCJweT9VqxZmqs7GpauYZYWkM2v3iFxD7L9IA+SWn612bXSfeDEp8U= X-Received: by 2002:a6b:1c0f:: with SMTP id c15-v6mr2634993ioc.247.1524065694488; Wed, 18 Apr 2018 08:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 08:34:23 -0700 (PDT) In-Reply-To: <20180417141329.GS54168@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <20180417141329.GS54168@kduck.kaduk.org> From: Brian Campbell Date: Wed, 18 Apr 2018 09:34:23 -0600 Message-ID: To: Benjamin Kaduk Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="00000000000055c781056a21321e" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:35:02 -0000 --00000000000055c781056a21321e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the text, Neil. And the nit on the text, Ben. I'll include it in the next draft. Ben, bit of a procedural question for you: can or should I include those references (https://www.cryptologie.net/article/374/common-x509-certificate= - validationcreation-pitfalls/ & http://www.cs.utexas.edu/~ shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as informational? Or? I'm honestly not sure if it's okay to cite a blog post or university paper. On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk wrote: > Picking nits, but maybe "established and well-tested X.509 library > (such as one used by an established TLS library)", noting that TLS > 1.3 has added a new protocol feature that allows for TLS and X.509 > library capabilities to be separately indicated (as would be needed > if they were organizationally separate). > > -Ben > > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote: > > OK, here=E2=80=99s a stab at a new security considerations section on X= .509 > parsing and validation: > > > > --- > > 5.3 X.509 Certificate Parsing and Validation Complexity > > > > Parsing and validation of X.509 certificates and certificate chains is > complex and implementation mistakes have previously exposed security > vulnerabilities. Complexities of validation include (but are not limited > to) [1][2][3]: > > - checking of Basic Constraints, basic and extended Key Usage > constraints, validity periods, and critical extensions; > > - handling of null-terminator bytes and non-canonical string > representations in subject names; > > - handling of wildcard patterns in subject names; > > - recursive verification of certificate chains and checking certificate > revocation. > > For these reasons, implementors SHOULD use an established and > well-tested TLS library for validation of X.509 certificate chains and > SHOULD NOT attempt to write their own X.509 certificate validation > procedures. > > > > [1] https://www.cryptologie.net/article/374/common-x509-certificate- > validationcreation-pitfalls/ article/374/common-x509-certificate-validationcreation-pitfalls/> > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf < > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf> > > [3] https://tools.ietf.org/html/rfc5280 rfc5280> > > > > --- > > > > NB - this blog post [1] is the best concise summary of attacks I could > find. Most of these attacks have been published as Black Hat talks and I > can=E2=80=99t seem to find definitive references or good survey papers (b= eyond [2], > which is a little older). > > > > Let me know what you think, > > > > Neil > > > > > > > On 12 Apr 2018, at 20:42, Brian Campbell > wrote: > > > > > > Thanks Neil. > > > > > > Other than the potential metadata changes, which I'd like more WG > input on and may raise in a new thread, I think I've got enough to make > updates addressing your comments. But please do send text for that > Security Considerations bit, if you come up with something. > > > > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden < > neil.madden@forgerock.com > wrote: > > > Hi Brian, > > > > > > Thanks for the detailed responses. Comments in line below (marked wit= h > ***). > > > > > > Neil > > > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > bcampbell@pingidentity.com > wrote: > > > Thanks for the review and feedback, Neil. I apologize for my being > slow to respond. As I said to Justin recently < > https://mailarchive.ietf.org/arch/msg/oauth/cNmk8fSuxp37L-z8Rvr6_EnyCug>, > I've been away from things for a while. Also there's a lot here to get > through so took me some time. > > > > > > It looks like John touched on some of your comments but not all. I'll > try and reply to them as best I can inline below. > > > > > > > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden < > neil.madden@forgerock.com > wrote: > > > Hi, > > > > > > I have reviewed this draft and have a number of comments, below. > ForgeRock have not yet implemented this draft, but there is interest in > implementing it at some point. (Disclaimer: We have no firm commitments o= n > this at the moment, I do not speak for ForgeRock, etc). > > > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 < > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1> defines > a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is a= lready a > confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key= , which itself can > contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax a= nd semantics. The > draft proposes: > > > > > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80= =9C=E2=80=A6=E2=80=9D } } > > > > > > but you can already do: > > > > > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6= , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } > > > > > > If the intent is just to save some space and avoid the mandatory > fields of the existing JWK types, maybe this would be better addressed by > defining a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty= =E2=80=9D: =E2=80=9Cx5t=E2=80=9D, > =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }. > > > > > > The intent of the x5t#S256 confirmation method was to be space > efficient and straightforward while utilizing the framework and registry > that RFC 7800 gives. Even a new JWK type like that would still use more > space. And I'd argue that the new confirmation method is considerably mor= e > straightforward than registering a new JWK type (and the implications tha= t > would have on JWK implementations in general) in order to use the existin= g > "jwk" confirmation method. > > > > > > *** > > > OK, that is reasonable. Given that the draft says SHOULD rather than > MUST for using this confirmation key method, I think it is currently > allowed to use either representation. > > > > > > > > > > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS= =E2=80=9D a bit of a misnomer: it=E2=80=99s > really only the client authentication that we are interested here, and th= e > fact that the server also authenticates with a certificate is not hugely > relevant to this particular spec (although it is to the overall security = of > OAuth). Also, TLS defines non-certificate based authentication mechanisms > (e.g. TLS-SRP extension for password authenticated key exchange, PSK for > pre-shared key authentication) and even non-X.509 certificate types ( > https://www.iana.org/assignments/tls-extensiontype- > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 < > https://www.iana.org/assignments/tls-extensiontype- > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3>). I=E2= =80=99d > prefer that the draft explicitly referred to =E2=80=9CX.509 Client Certif= icate > Authentication=E2=80=9D rather than mutual TLS, and changed identifiers l= ike > =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf= -oauth-mtls-07# > section-2.1.1 section-2.1.1>) to something more explicit like > =E2=80=98tls_x509_pki_client_auth=E2=80=99. > > > > > > This is especially confusing in section 3 on sender constrained acces= s > tokens, as there are two different servers involved: the AS and the > protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authe= ntication between > them, only between each of them and the client. > > > > > > Choosing names and terminology is difficult and the "right" wording i= s > often subjective. I believe that the current wording sufficiently conveys > what is going on in the draft to most readers. Most readers thus far seem > to agree. There is some text now that does say that the mutual auth in th= e > draft is in fact X.509 client cert authn but, in the next revision, I'll > look for other opportunities where it could be stated more clearly. > > > > > > *** Thanks. > > > > > > > > > > > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 > RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? T= he > wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be u= sed with > TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. > > > > > > The reference to BCP 195 (which unfortunately the original OAuth 2.0 > RFC doesn't have because it didn't exist then) is meant to account for > changing versions and recommendations around TLS. Currently that BCP says > TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't outright > prohibit them. > > > > > > *** OK, that seems good to me. > > > > > > > > > > > > 4. It might be useful to have a discussion for implementors of whethe= r > TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact t= he > use of client certificates, if at all? > > > > > > That might well be useful but I don't myself know what it would say. > I've (maybe naively) figured those are deployment details that will just > work out. Perhaps you could propose some text around such a discussion th= at > the WG could consider? > > > > > > *** > > > To be honest, when I raised this it was because I didn=E2=80=99t real= ly know > what the implications were. I=E2=80=99ve done some reading around and I t= hink it > should all just work - both session resumption and PSK-based resumption > preserve the original client and server authentication context so we can > assume that any presented client cert is still valid for the resumed > session. So I think we can leave out any discussion of this and assume it > works as expected. > > > > > > > > > > > > 5. Section 3 defines sender-constrained access tokens in terms of the > confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 > Pop Architecture draft defines sender constraint and key confirmation as > different things (https://tools.ietf.org/html/draft-ietf-oauth-pop- > architecture-08#section-6.2 draft-ietf-oauth-pop-architecture-08#section-6.2>). The draft should > decide which of those it is implementing and if sender constraint is > intended, then reusing the confirmation key claims seems misleading. (I > think this mTLS draft is doing key confirmation so should drop the langua= ge > about sender constrained tokens). > > > > > > I will say again that choosing names and terminology is difficult... > > > > > > Although I must admit that I started using "sender constrained" > somewhat indiscriminately at first and it's just sort of stuck. At the ti= me > I was trying to incorporate bits of draft-sakimura-oauth-jpop in a way th= at > might help bring on and keep the authors of that draft onboard with this > mtls draft. In retrospect it looks like I did that part wrong anyway. But > that was the thinking at the time and the history, for whatever it's wort= h. > More recently, Nat was requesting that "sender constrained" be included i= n > the title. So there's that too. > > > > > > In defense of my mistake, however, if there's a line between "sender > constrained" and "key confirmation" tokens, it's a bit of a fuzzy line. A= nd > I'd argue that what this draft is doing pretty close to the line. > > > > > > But ultimately I think you are right that what this mtls draft is > doing with access tokens is more accurately described with the key > confirmation term. > > > > > > So, yes, the draft should probably drop (or at least minimize) the > language about sender constrained. I'll do that in the next draft version= , > barring big objections from the WG. > > > > > > The tricky thing with making that change is that there a client and > server metadata parameters with the name "mutual_tls_sender_constrained_a= ccess_tokens" > that should probably also change. But that would be a breaking change (of > sorts anyway), which shouldn't be taken lightly at this stage. I feel tha= t > some explicit okays from the WG are needed before doing so (rough consens= us > stye) . Any WG members want to weigh in here and help get a "sense of the > group" concerning changing those metadata names? > > > > > > *** Thanks. I agree this might cause compatibility issues. It is not = a > big issue for us, but might cause some confusion. > > > > > > > > > > > > 6. The OAuth 2.0 PoP Architecture draft says ( > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5 > architecture-08#section-5>): > > > > > > Strong, fresh session keys: > > > > > > Session keys MUST be strong and fresh. Each session > deserves an > > > independent session key, i.e., one that is generated > specifically > > > for the intended use. In context of OAuth this means > that keying > > > material is created in such a way that can only be > used by the > > > combination of a client instance, protected resource, > and > > > authorization scope. > > > > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/ > draft-ietf-oauth-mtls-07#section-3 draft-ietf-oauth-mtls-07#section-3>) says: > > > > > > The client makes protected resource requests as described in > > > [RFC6750], however, those requests MUST be made over a mutual= ly > > > authenticated TLS connection using the same certificate that > was used > > > for mutual TLS at the token endpoint. > > > > > > These two statements are contradictory: the OAuth 2.0 PoP architectur= e > effectively requires a fresh key-pair to be used for every access token > request, whereas this draft proposes reusing the same long-lived client > certificate for every single access token and every resource server. > > > > > > In the self-signed case (and even in the CA case, with a bit of work = - > e.g., https://www.vaultproject.io/docs/secrets/pki/index.html < > https://www.vaultproject.io/docs/secrets/pki/index.html>) it is perfectly > possible for the client to generate a fresh key-pair for each access toke= n > and include the certificate on the token request (e.g., as per > https://tools.ietf.org/html/draft-ietf-oauth-pop-key- > distribution-03#section-5.1 draft-ietf-oauth-pop-key-distribution-03#section-5.1> - in which case an > appropriate =E2=80=9Calg=E2=80=9D value should probably be described). Th= is should probably > at least be an option. > > > > > > This draft doesn't necessarily seek to align with the (long expired) > PoP architecture draft. Rather it is aiming to provide a pragmatic > solution for PoP style access tokens and OAuth client auth using mTLS > client certificates. > > > > > > That said, with the current draft, it's certainly possible for a > client to update its cert more frequently, even so far as using a new one > for each access token. The details of how that would work will vary some > based on the token endpoint authentication method. But it's not precluded= . > > > > > > *** You are right, the text doesn=E2=80=99t preclude that. I am happy= with > that solution. I suspect most people will deploy and be happy with reusin= g > a long-lived cert for every access token, so this may not matter in > practice. > > > > > > > > > 7. The use of a single client certificate with every resource server > (RS) should be called out in a Privacy Considerations section, as it allo= ws > correlation of activity. > > > > > > Practically speaking the access tokens being presented likely already > have correlatable info in them about the client as well as the user. I > don't know that there's much of a (new) concern in reality. If you feel > this concern is unique and import enough though, perhaps there's some tex= t > you'd like to propose for a Privacy Considerations section that the WG > could consider? I mean, I guess it doesn't hurt to mention it but I would > like to avoid overstating the issue. > > > > > > *** On reflection, I am going to withdraw this comment. As you say > there are other ways to correlate clients. The privacy issue would mainly > arise in the context of dynamic client registration e.g., a pattern I=E2= =80=99ve > seen described where every instance of a mobile app does dynamic client > registration to avoid including credentials directly in the app bundle. > This would make clients one-to-one with users. But (a) those apps are > fairly unlikely to be using TLS certs, and (b) that is more of a privacy > consideration for dynamic client registration rather than this draft. > > > > > > > > > > > > 8. This is maybe a more general point, but RFC 6750 defines the > Authorization: Bearer scheme (https://tools.ietf.org/html/ > rfc6750#section-2 ) for a > client to communicate it=E2=80=99s access token to the RS in a standard w= ay. As > sender-constrained access tokens are not strictly bearer tokens any more, > should this draft also register a new scheme for that? Should there be a > generic PoP scheme? > > > > > > The thinking and general consensus (in this draft as well as the OAut= h > token binding work) has been that continuing to use the RFC 6750 scheme > while putting the "not strictly bearer" stuff in (or referenced by) the > token itself will be easier on deployment and implementation. And better > for adoption as a result. I believe some early implementation work has > borne that out too. > > > > > > *** OK. > > > > > > > > > 9. The Security Considerations should really make some mention of the > long history of attacks against X.509 certificate chain validation, e.g. > failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, e= rrors in parsing > DNs, etc. It should be strongly suggested to use an existing TLS library = to > perform these checks rather than implementing your own checks. This relat= es > to Justin=E2=80=99s comments around DN parsing and normalisation. > > > > > > Suggesting to use an existing TLS library is certainly sound advice > and I sort of felt is implied in the draft. But saying so more > strongly/explicitly might be worthwhile. And pointing to historical > reasons to do so would probably be good too. Could you propose a new > Security Considerations section or maybe augmentation of =C2=A75.2 with t= hat > content? > > > > > > *** I=E2=80=99ll try and come up with some text. > > > > > > > > > > > > 10. The PKI client authentication method (https://tools.ietf.org/html= / > draft-ietf-oauth-mtls-07#section-2.1 draft-ietf-oauth-mtls-07#section-2.1>) makes no mention at all of > certificate revocation and how to handle checking for that (CRLs, OCSP - > with stapling?). Neither does the Security Considerations. If this is a > detail to be agreed between then AS and the CA (or just left up to the AS > TLS stack) then that should perhaps be made explicit. Again, there are > privacy considerations with some of these mechanisms, as OCSP requests ar= e > typically sent in the clear (plain HTTP) and so allow an observer to see > which clients are connecting to which AS. > > > > > > I didn't think that a TLS client could do OCSP stapling? > > > > > > *** I think you are right about this. I always assumed it was > symmetric (and I think it technically could work), but the spec only talk= s > about stapling in the server-side of the handshake. > > > > > > That aside, revocation checking (how and even if) is something that's > at the discretion of the AS. I can add something in =C2=A72.1 to say that= more > explicitly. > > > > > > *** Thanks. > > > > > > > > > > > > 11. The same comment applies to how the protected resource checks for > revocation of the certificate presented during sender constrained access > token usage. Should the RS make its own revocation checks based on the > information in the certificate presented, or should it trust the > certificate while the access token is still valid? If the latter case, is > the AS responsible for revoking any access tokens whose certificate have > been revoked (if so, should it be doing an OCSP call on every token > introspection request, and should the RS be passing on the > certificate/serial number on that request)? If the Client request uses OC= SP > Stapling (https://en.wikipedia.org/wiki/OCSP_stapling < > https://en.wikipedia.org/wiki/OCSP_stapling>) how can the RS verify the > signature on that if it does not have a separate trust relationship with > the CA already? > > > > > > The draft effectively uses cert mtls at the RS as a > proof-of-possession method only and not as authentication. So revocation > checking isn't really applicable. In specific deployment situations, I > suppose an RS could check revocation. But that'd be a deployment decision > for the RS that's beyond the scope of this draft. > > > > > > *** OK, that is an interesting observation. If either the client or A= S > suspect the key has been compromised they can revoke the access token(s) > instead. > > > > > > > > > > > > 12. The use of only SHA-256 fingerprints means that the security > strength of the sender-constrained access tokens is limited by the > collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - wi= thout a > new specification for a new thumbprint algorithm. An implication of this = is > that is is fairly pointless for the protected resource TLS stack to ever > negotiate cipher suites/keys with a higher level of security. In more > crystal ball territory, if a practical quantum computer becomes a > possibility within the lifetime of this spec, then the expected collision > resistance of SHA-256 would drop quadratically, allowing an attacker to > find a colliding certificate in ~2^64 effort. If we are going to pick jus= t > one thumbprint hash algorithm, I would prefer we pick SHA-512. > > > > > > The idea behind haveing just one thumbprint hash algorithm was to kee= p > things simple. And SHA-256 seems good enough for the reasonably foreseeab= le > future (and space aware). Also a new little spec to register a different > hash algorithm, should the need arise, didn't seem particularity onerous. > > > > > > That was the thinking anyway. Maybe it is too short sighted though? > > > > > > I do think SHA-256 should stay regardless. > > > > > > But the draft could also define SHA-512 (and maybe others). What do > you and WG folks think about that? > > > > > > *** Yes please. > > > > > > It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to > change from just boolean values to something to convey what hash alg/cnf > method the client expects and the list of what the server supports. That'= s > maybe something that should be done anyway. That'd be a breaking change t= o > the metadata. But there's already another potential breaking change > identified earlier in this message. So maybe it's worth doing... > > > > > > How do folks feel about making this kind of change? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > Neil > > > > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote: > > > > > > > > All, > > > > > > > > As discussed during the meeting today, we are starting a WGLC on th= e > MTLS document: > > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 < > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07> > > > > > > > > Please, review the document and provide feedback on any issues you > see with the document. > > > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > > > Regards, > > > > Rifaat and Hannes > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000055c781056a21321e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the text, Neil. And the nit on the text, B= en. I'll include it in the next draft.

Ben, bit of a = procedural question for you: can or should I include those references (https://www.cryptologie.ne= t/article/374/common-x509-certificate-validationcreation-pitfalls= / & http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf) th= at Neil had with the text in the draft as informational? Or? I'm honest= ly not sure if it's okay to cite a blog post or university paper.
<= br>


<= /div>



On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Picking nits, but may= be "established and well-tested X.509 library
(such as one used by an established TLS library)", noting that TLS
1.3 has added a new protocol feature that allows for TLS and X.509
library capabilities to be separately indicated (as would be needed
if they were organizationally separate).

-Ben

On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote:
> OK, here=E2=80=99s a stab at a new security considerations section on = X.509 parsing and validation:
>
> ---
> 5.3 X.509 Certificate Parsing and Validation Complexity
>
> Parsing and validation of X.509 certificates and certificate chains is= complex and implementation mistakes have previously exposed security vulne= rabilities. Complexities of validation include (but are not limited to) [1]= [2][3]:
> - checking of Basic Constraints, basic and extended Key Usage constrai= nts, validity periods, and critical extensions;
> - handling of null-terminator bytes and non-canonical string represent= ations in subject names;
> - handling of wildcard patterns in subject names;
> - recursive verification of certificate chains and checking certificat= e revocation.
> For these reasons, implementors SHOULD use an established and well-tes= ted TLS library for validation of X.509 certificate chains and SHOULD NOT a= ttempt to write their own X.509 certificate validation procedures.
>
> [1] https://www.cryptologie.net/article/374/common-x509-certi= ficate-validationcreation-pitfalls/ <https://www.cryptologie.net/a= rticle/374/common-x509-certificate-validationcreation-pitfalls/>
> [2] http://www.cs.utexas.edu/~shmat/shmat_c= cs12.pdf <http://www.cs.utexas.edu/~shmat= /shmat_ccs12.pdf>
> [3] https://tools.ietf.org/html/rfc5280 <https://tools.ietf.org/html/rfc5280>
>
> ---
>
> NB - this blog post [1] is the best concise summary of attacks I could= find. Most of these attacks have been published as Black Hat talks and I c= an=E2=80=99t seem to find definitive references or good survey papers (beyo= nd [2], which is a little older).
>
> Let me know what you think,
>
> Neil
>
>
> > On 12 Apr 2018, at 20:42, Brian Campbell <bcampbell@pingidentity.com> wrote:
> >
> > Thanks Neil.
> >
> > Other than the potential metadata changes, which I'd like mor= e WG input on and may raise in a new thread, I think I've got enough to= make updates addressing your comments.=C2=A0 But please do send text for t= hat Security Considerations bit, if you come up with something.=C2=A0
> >
> > On Thu, Apr 12, 2018 at 3:03 AM, Neil Mad= den <neil.madden@forgerock.= com <mailto:neil.madden= @forgerock.com>> wrote:
> > Hi Brian,
> >
> > Thanks for the detailed responses. Comments in line below (marked= with ***).
> >
> > Neil
> >
> > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell <= bcampbell@pingidentity.com <mailto:bcampbell@p= ingidentity.com>> wrote:
> > Thanks for the review and feedback, Neil. I apologize for my bein= g slow to respond. As I said to Justin recently <https://mailarchive.ietf.org/arch/msg/oauth/cNm= k8fSuxp37L-z8Rvr6_EnyCug>, I've been away from things for a= while. Also there's a lot here to get through so took me some time. > >
> > It looks like John touched on some of your comments but not all. = I'll try and reply to them as best I can inline below.
> >
> >
> > On Thu, Mar 29, 2018 at 9:18 AM, Neil Mad= den <neil.madden@forgerock.= com <mailto:neil.madden= @forgerock.com>> wrote:
> > Hi,
> >
> > I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in imp= lementing it at some point. (Disclaimer: We have no firm commitments on thi= s at the moment, I do not speak for ForgeRock, etc).
> >
> > 1. https://tools.ie= tf.org/html/draft-ietf-oauth-mtls-07#section-3.1 <https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07#section-3.1> defines a new confirmation method= =E2=80=9Cx5t#S256=E2=80=9D. However, there is already a confirmation metho= d =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web Key, which itself can c= ontain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax and = semantics. The draft proposes:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ =E2=80=9Ccnf=E2=80=9D: { =E2= =80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } }
> >
> > but you can already do:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ =E2=80=9Ccnf=E2=80=9D: { =E2= =80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2= =80=A6=E2=80=9D } } }
> >
> > If the intent is just to save some space and avoid the mandatory = fields of the existing JWK types, maybe this would be better addressed by d= efining a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2= =80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80= =A6=E2=80=9D }.
> >
> > The intent of the x5t#S256 confirmation method was to be space ef= ficient and straightforward while utilizing the framework and registry that= RFC 7800 gives.=C2=A0 Even a new JWK type like that would still use more s= pace. And I'd argue that the new confirmation method is considerably mo= re straightforward than registering a new JWK type (and the implications th= at would have on JWK implementations in general) in order to use the existi= ng "jwk" confirmation method.=C2=A0
> >
> > ***
> > OK, that is reasonable. Given that the draft says SHOULD rather t= han MUST for using this confirmation key method, I think it is currently al= lowed to use either representation.
> >
> >=C2=A0
> >
> > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2= =80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really only the clien= t authentication that we are interested here, and the fact that the server = also authenticates with a certificate is not hugely relevant to this partic= ular spec (although it is to the overall security of OAuth). Also, TLS defi= nes non-certificate based authentication mechanisms (e.g. TLS-SRP extension= for password authenticated key exchange, PSK for pre-shared key authentica= tion) and even non-X.509 certificate types (https://www.iana= .org/assignments/tls-extensiontype-values/tls-extensiontype-= values.xhtml#tls-extensiontype-values-3 <https:/= /www.iana.org/assignments/tls-extensiontype-values/tls-extensiont= ype-values.xhtml#tls-extensiontype-values-3>). I=E2=80=99d= prefer that the draft explicitly referred to =E2=80=9CX.509 Client Certifi= cate Authentication=E2=80=9D rather than mutual TLS, and changed identifier= s like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#sect= ion-2.1.1 <https://tools.ie= tf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1>) to so= mething more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.
> >
> > This is especially confusing in section 3 on sender constrained a= ccess tokens, as there are two different servers involved: the AS and the p= rotected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authenti= cation between them, only between each of them and the client.
> >
> > Choosing names and terminology is difficult and the "right&q= uot; wording is often subjective. I believe that the current wording suffic= iently conveys what is going on in the draft to most readers. Most readers = thus far seem to agree. There is some text now that does say that the mutua= l auth in the draft is in fact X.509 client cert authn but, in the next rev= ision, I'll look for other opportunities where it could be stated more = clearly.
> >
> > *** Thanks.
> >
> >=C2=A0
> >
> > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2= .0 RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? = The wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be= used with TLS 1.0 or 1.1, or whether it is only referring to future TLS ve= rsions.
> >
> > The reference to BCP 195 (which unfortunately the original OAuth = 2.0 RFC doesn't have because it didn't exist then) is meant to acco= unt for changing versions and recommendations around TLS. Currently that BC= P says TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't= outright prohibit them.
> >
> > *** OK, that seems good to me.
> >
> >=C2=A0
> >
> > 4. It might be useful to have a discussion for implementors of wh= ether TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impa= ct the use of client certificates, if at all?
> >
> > That might well be useful but I don't myself know what it wou= ld say. I've (maybe naively) figured those are deployment details that = will just work out. Perhaps you could propose some text around such a discu= ssion that the WG could consider?
> >
> >=C2=A0 ***
> > To be honest, when I raised this it was because I didn=E2=80=99t = really know what the implications were. I=E2=80=99ve done some reading arou= nd and I think it should all just work - both session resumption and PSK-ba= sed resumption preserve the original client and server authentication conte= xt so we can assume that any presented client cert is still valid for the r= esumed session. So I think we can leave out any discussion of this and assu= me it works as expected.
> >
> >
> >
> > 5. Section 3 defines sender-constrained access tokens in t= erms of the confirmation key claims (e.g., RFC 7800 for JWT). However, the = OAuth 2.0 Pop Architecture draft defines sender constraint and key confirma= tion as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 8#section-6.2 <ht= tps://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#se= ction-6.2>). The draft should decide which of those it is implementi= ng and if sender constraint is intended, then reusing the confirmation key = claims seems misleading. (I think this mTLS draft is doing key confirmation= so should drop the language about sender constrained tokens).
> >
> > I will say again that choosing names and terminology is difficult= ...
> >
> > Although I must admit that I started using "sender constrain= ed" somewhat indiscriminately at first and it's just sort of stuck= . At the time I was trying to incorporate bits of draft-sakimura-oauth-jpop= in a way that might help bring on and keep the authors of that draft onboa= rd with this mtls draft. In retrospect it looks like I did that part wrong = anyway. But that was the thinking at the time and the history, for whatever= it's worth. More recently, Nat was requesting that "sender constr= ained" be included in the title. So there's that too.=C2=A0
> >
> > In defense of my mistake, however, if there's a line between = "sender constrained" and "key confirmation" tokens, it&= #39;s a bit of a fuzzy line. And I'd argue that what this draft is doin= g pretty close to the line.
> >
> > But ultimately I think you are right that what this mtls draft is= doing with access tokens is more accurately described with the key confirm= ation term.
> >
> > So, yes, the draft should probably drop (or at least minimize) th= e language about sender constrained. I'll do that in the next draft ver= sion, barring big objections from the WG.
> >
> > The tricky thing with making that change is that there a client a= nd server metadata parameters with the name "mutual_tls_sender_co= nstrained_access_tokens" that should probably also change. But that wo= uld be a breaking change (of sorts anyway), which shouldn't be taken li= ghtly at this stage. I feel that some explicit okays from the WG are needed= before doing so (rough consensus stye) . Any WG members want to weigh in h= ere and help get a "sense of the group" concerning changing those= metadata names?
> >
> > *** Thanks. I agree this might cause compatibility issues. It is = not a big issue for us, but might cause some confusion.
> >
> >=C2=A0
> >
> > 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/draft= -ietf-oauth-pop-architecture-08#section-5 <https://tools.ietf.org/html/draft-ietf-oa= uth-pop-architecture-08#section-5>):
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Strong, fresh session keys:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sess= ion keys MUST be strong and fresh.=C2=A0 Each session deserves an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inde= pendent session key, i.e., one that is generated specifically
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for = the intended use.=C2=A0 In context of OAuth this means that keying
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mate= rial is created in such a way that can only be used by the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comb= ination of a client instance, protected resource, and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auth= orization scope.
> >
> >
> > However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-= oauth-mtls-07#section-3 <h= ttps://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3= >) says:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The client makes protected resou= rce requests as described in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6750], however, those reques= ts MUST be made over a mutually
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authenticated TLS connection usi= ng the same certificate that was used
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for mutual TLS at the token endp= oint.
> >
> > These two statements are contradictory: the OAuth 2.0 PoP archite= cture effectively requires a fresh key-pair to be used for every access tok= en request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server.
> >
> > In the self-signed case (and even in the CA case, with a b= it of work - e.g., https://www.vaultproject.i= o/docs/secrets/pki/index.html <ht= tps://www.vaultproject.io/docs/secrets/pki/index.html>) it is p= erfectly possible for the client to generate a fresh key-pair for each acce= ss token and include the certificate on the token request (e.g., as per https://tools.ietf.org/= html/draft-ietf-oauth-pop-key-distribution-03#section-5.1 <= ;https://tools.ietf.= org/html/draft-ietf-oauth-pop-key-distribution-03#section-5.1= > - in which case an appropriate =E2=80=9Calg=E2=80=9D value should prob= ably be described). This should probably at least be an option.
> >
> > This draft doesn't necessarily seek to align with the (long e= xpired) PoP architecture draft.=C2=A0 Rather it is aiming to provide a prag= matic solution for PoP style access tokens and OAuth client auth using mTLS= client certificates.
> >
> > That said, with the current draft, it's certainly possible fo= r a client to update its cert more frequently, even so far as using a new o= ne for each access token. The details of how that would work will vary some= based on the token endpoint authentication method. But it's not preclu= ded.
> >
> > *** You are right, the text doesn=E2=80=99t preclude that. I am h= appy with that solution. I suspect most people will deploy and be happy wit= h reusing a long-lived cert for every access token, so this may not matter = in practice.
> >=C2=A0
> >
> > 7. The use of a single client certificate with every resource ser= ver (RS) should be called out in a Privacy Considerations section, as it al= lows correlation of activity.
> >
> > Practically speaking the access tokens being presented likely alr= eady have correlatable info in them about the client as well as the user. I= don't know that there's much of a (new) concern in reality. If you= feel this concern is unique and import enough though, perhaps there's = some text you'd like to propose for a Privacy Considerations section th= at the WG could consider? I mean, I guess it doesn't hurt to mention it= but I would like to avoid overstating the issue.=C2=A0
> >
> > *** On reflection, I am going to withdraw this comment. As you sa= y there are other ways to correlate clients. The privacy issue would mainly= arise in the context of dynamic client registration e.g., a pattern I=E2= =80=99ve seen described where every instance of a mobile app does dynamic c= lient registration to avoid including credentials directly in the app bundl= e. This would make clients one-to-one with users. But (a) those apps are fa= irly unlikely to be using TLS certs, and (b) that is more of a privacy cons= ideration for dynamic client registration rather than this draft.
> >
> >=C2=A0
> >
> > 8. This is maybe a more general point, but RFC 6750 define= s the Authorization: Bearer scheme (https://tools.ietf.= org/html/rfc6750#section-2 <https://tools.i= etf.org/html/rfc6750#section-2>) for a client to communicate it= =E2=80=99s access token to the RS in a standard way. As sender-constrained = access tokens are not strictly bearer tokens any more, should this draft al= so register a new scheme for that? Should there be a generic PoP scheme? > >
> > The thinking and general consensus (in this draft as well as the = OAuth token binding work) has been that continuing to use the RFC 6750 sche= me while putting the "not strictly bearer" stuff in (or reference= d by) the token itself will be easier on deployment and implementation. And= better for adoption as a result. I believe some early implementation work = has borne that out too.
> >
> >=C2=A0 *** OK.
> >
> >
> > 9. The Security Considerations should really make some mention of= the long history of attacks against X.509 certificate chain validation, e.= g. failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an exist= ing TLS library to perform these checks rather than implementing your own c= hecks. This relates to Justin=E2=80=99s comments around DN parsing and norm= alisation.
> >
> > Suggesting to use an existing TLS library is certainly sound advi= ce and I sort of felt is implied in the draft. But saying so more strongly/= explicitly might be worthwhile.=C2=A0 And pointing to historical reasons to= do so would probably be good too.=C2=A0 Could you propose a new Security C= onsiderations section or maybe augmentation of =C2=A75.2 with that content?=
> >
> > *** I=E2=80=99ll try and come up with some text.
> >
> >=C2=A0
> >
> > 10. The PKI client authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mt= ls-07#section-2.1 <https= ://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1&g= t;) makes no mention at all of certificate revocation and how to handle che= cking for that (CRLs, OCSP - with stapling?). Neither does the Security Con= siderations. If this is a detail to be agreed between then AS and the CA (o= r just left up to the AS TLS stack) then that should perhaps be made explic= it. Again, there are privacy considerations with some of these mechanisms, = as OCSP requests are typically sent in the clear (plain HTTP) and so allow = an observer to see which clients are connecting to which AS.
> >
> > I didn't think that a TLS client could do OCSP stapling?
> >
> > *** I think you are right about this. I always assumed it was sym= metric (and I think it technically could work), but the spec only talks abo= ut stapling in the server-side of the handshake.
> >
> > That aside, revocation checking (how and even if) is something th= at's at the discretion of the AS. I can add something in =C2=A72.1 to s= ay that more explicitly.
> >
> > *** Thanks.
> >
> >
> >
> > 11. The same comment applies to how the protected resource= checks for revocation of the certificate presented during sender constrain= ed access token usage. Should the RS make its own revocation checks based o= n the information in the certificate presented, or should it trust the cert= ificate while the access token is still valid? If the latter case, is the A= S responsible for revoking any access tokens whose certificate have been re= voked (if so, should it be doing an OCSP call on every token introspection = request, and should the RS be passing on the certificate/serial number on t= hat request)? If the Client request uses OCSP Stapling (h= ttps://en.wikipedia.org/wiki/OCSP_stapling <h= ttps://en.wikipedia.org/wiki/OCSP_stapling>) how can the RS ver= ify the signature on that if it does not have a separate trust relationship= with the CA already?
> >
> > The draft effectively uses cert mtls at the RS as a proof-of-poss= ession method only and not as authentication. So revocation checking isn= 9;t really applicable. In specific deployment situations, I suppose an RS c= ould check revocation. But that'd be a deployment decision for the RS t= hat's beyond the scope of this draft.
> >
> > *** OK, that is an interesting observation. If either the client = or AS suspect the key has been compromised they can revoke the access token= (s) instead.
> >=C2=A0
> >
> >
> > 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the collisio= n resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without= a new specification for a new thumbprint algorithm. An implication of this= is that is is fairly pointless for the protected resource TLS stack to eve= r negotiate cipher suites/keys with a higher level of security. In more cry= stal ball territory, if a practical quantum computer becomes a possibility = within the lifetime of this spec, then the expected collision resistance of= SHA-256 would drop quadratically, allowing an attacker to find a colliding= certificate in ~2^64 effort. If we are going to pick just one thumbprint h= ash algorithm, I would prefer we pick SHA-512.
> >
> > The idea behind haveing just one thumbprint hash algorithm was to= keep things simple. And SHA-256 seems good enough for the reasonably fores= eeable future (and space aware). Also a new little spec to register a diffe= rent hash algorithm, should the need arise, didn't seem particularity o= nerous.
> >
> > That was the thinking anyway. Maybe it is too short sighted thoug= h?
> >
> > I do think SHA-256 should stay regardless.
> >
> > But the draft could also define SHA-512 (and maybe others). What = do you and WG folks think about that?
> >
> > *** Yes please.
> >
> > It would probably then be useful for the metadata in =C2=A73.3 an= d =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server supp= orts. That's maybe something that should be done anyway. That'd be = a breaking change to the metadata. But there's already another potentia= l breaking change identified earlier in this message. So maybe it's wor= th doing...
> >
> > How do folks feel about making this kind of change?
> >
> >
> >
> >
> >=C2=A0
> > Cheers,
> >
> > Neil
> >
> >
> > > On 19 Mar 2018, at 22:34, Rifaat She= kh-Yusef <rifaat.ietf@gmail.com= <mailto:rifaat.ietf@gmail.= com>> wrote:
> > >
> > > All,
> > >
> > > As discussed during the meeting today, we are starting a WGL= C on the MTLS document:
> > > https://tools.ietf.org/htm= l/draft-ietf-oauth-mtls-07 <https://= tools.ietf.org/html/draft-ietf-oauth-mtls-07>
> > >
> > > Please, review the document and provide feedback on any issu= es you see with the document.
> > >
> > > The WGLC will end in two weeks, on April 2, 2018.
> > >
> > > Regards,
> > >=C2=A0 Rifaat and Hannes
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org = <mailto:OAuth@ietf.org>
> > > https://www.ietf.org/mailman/listinf= o/oauth <https://www.ietf.org/mailman/listinf= o/oauth>
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:<= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oaut= h <https://www.ietf.org/mailman/listinfo/oaut= h>
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged material for the sole use of the intended recipient(s). Any revie= w, use, distribution or disclosure by others is strictly prohibited.=C2=A0 = If you have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments from = your computer. Thank you.
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged material for the sole use of the intended recipient(s). Any revie= w, use, distribution or disclosure by others is strictly prohibited.=C2=A0 = If you have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments from = your computer. Thank you.
>

> _______________________= ________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000055c781056a21321e-- From nobody Wed Apr 18 11:28:19 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7F126C2F for ; Wed, 18 Apr 2018 11:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj5gMJbrMbDm for ; Wed, 18 Apr 2018 11:28:14 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645351200FC for ; Wed, 18 Apr 2018 11:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1524076094; x=1555612094; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mdBy9o/VVKOjlTzpIcXb5JaVBbKSa/xGoTRyvYCWoi8=; b=u+59j88UCzMJJNZRKfxwRzuRNCZ29bsCJ3/4J9KQabLk8sz4Bi1vp9sN wOSuFdPTL/1RZvqwrsTRn9IwS94UK2gq1U3IdEo/EIq6vyQMX/kJpFt1I 9kplypv1A7XihoCBoyninrWvcrUJL3y70dr9fJsZgMb7twXiG6LH8otA2 Y=; X-IronPort-AV: E=Sophos;i="5.48,466,1517875200"; d="scan'208,217";a="675330788" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2b-859fe132.us-west-2.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2018 18:28:12 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2b-859fe132.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w3IISBuQ061769 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Apr 2018 18:28:12 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 18 Apr 2018 18:28:11 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 18 Apr 2018 18:28:11 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 18 Apr 2018 18:28:11 +0000 From: "Richard Backman, Annabelle" To: Brian Campbell , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization Thread-Index: AQHT1ZHqW1hD+SnbBUGMpzbfkx1iWaQGpwcA//++fgA= Date: Wed, 18 Apr 2018 18:28:11 +0000 Message-ID: <88C79981-4D1B-402F-A284-A636153DE082@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.180] Content-Type: multipart/alternative; boundary="_000_88C799814D1B402FA284A636153DE082amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 18:28:17 -0000 --_000_88C799814D1B402FA284A636153DE082amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIE9BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9u IGFzIGEgV0cgZG9jdW1lbnQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6 b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxOCBhdCA4OjIzIEFNDQpUbzog UmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQpDYzogb2F1dGggPG9h dXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246 IE9BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9uDQoNCkkgc3VwcG9ydCBhZG9wdGlv biBvZiBPQXV0aCAyLjAgSW5jcmVtZW50YWwgQXV0aG9yaXphdGlvbiBhcyBhIFdHIGRvY3VtZW50 Lg0KDQpPbiBNb24sIEFwciAxNiwgMjAxOCBhdCA4OjQ3IEFNLCBSaWZhYXQgU2hla2gtWXVzZWYg PHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3Jv dGU6DQpBbGwsDQoNCldlIHdvdWxkIGxpa2UgdG8gZ2V0IGEgY29uZmlybWF0aW9uIG9uIHRoZSBt YWlsaW5nIGxpc3QgZm9yIHRoZSBhZG9wdGlvbiBvZiB0aGUgT0F1dGggMi4wIEluY3JlbWVudGFs IEF1dGhvcml6YXRpb24gYXMgYSBXRyBkb2N1bWVudA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtaW5jcmVtZW50YWwtYXV0aC8NCg0KUGxlYXNl LCBsZXQgdXMga25vdyBpZiB5b3Ugc3VwcG9ydCBvciBvYmplY3QgdG8gdGhlIGFkb3B0aW9uIG9m IHRoaXMgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgSGFubmVzDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55 IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_88C799814D1B402FA284A636153DE082amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5tLTg4OTYzMzgyMjc3NDQ1MDE1ODFtLTgyMDgwMjk3ODkyMDQ4 NTQxMjBnbWFpbC1pbA0KCXttc28tc3R5bGUtbmFtZTptXy04ODk2MzM4MjI3NzQ0NTAxNTgxbV8t ODIwODAyOTc4OTIwNDg1NDEyMGdtYWlsLWlsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQg YWRvcHRpb24gb2YgT0F1dGggMi4wIEluY3JlbWVudGFsIEF1dGhvcml6YXRpb24gYXMgYSBXRyBk b2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpv biDigJMgSWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDE4LCAyMDE4IGF0 IDg6MjMgQU08YnI+DQo8Yj5UbzogPC9iPlJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0Lmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBDYWxsIGZvciBBZG9wdGlv bjogT0F1dGggMi4wIEluY3JlbWVudGFsIEF1dGhvcml6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls T3JpZ2luYWxCb2R5Ij5JIHN1cHBvcnQgYWRvcHRpb24gb2YgT0F1dGggMi4wIEluY3JlbWVudGFs IEF1dGhvcml6YXRpb24gYXMgYSBXRyBkb2N1bWVudC48bzpwPjwvbzpwPjwvYT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+T24gTW9uLCBBcHIgMTYsIDIwMTggYXQgODo0NyBBTSwgUmlmYWF0IFNoZWtoLVl1 c2VmICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tn cm91bmQ6d2hpdGUiPkFsbCw8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij5XZSB3b3VsZCBsaWtlIHRvIGdldCBhIGNvbmZpcm1hdGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0 IGZvciB0aGUmbmJzcDs8c3BhbiBjbGFzcz0ibS04ODk2MzM4MjI3NzQ0NTAxNTgxbS04MjA4MDI5 Nzg5MjA0ODU0MTIwZ21haWwtaWwiPmFkb3B0aW9uPC9zcGFuPiZuYnNwO29mDQogdGhlJm5ic3A7 PGI+T0F1dGggMi4wIEluY3JlbWVudGFsIEF1dGhvcml6YXRpb248L2I+Jm5ic3A7YXMgYSBXRyBk b2N1bWVudDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoLyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXdkZW5uaXNzLW9hdXRoLWluY3JlbWVudGFsLWF1dGgvPC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIi PlBsZWFzZSwgbGV0IHVzIGtub3cgaWYgeW91IHN1cHBvcnQgb3Igb2JqZWN0IHRvIHRoZSZuYnNw OzxzcGFuIGNsYXNzPSJtLTg4OTYzMzgyMjc3NDQ1MDE1ODFtLTgyMDgwMjk3ODkyMDQ4NTQxMjBn bWFpbC1pbCI+YWRvcHRpb248L3NwYW4+Jm5ic3A7b2YNCiB0aGlzIGRvY3VtZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+Jm5ic3A7UmlmYWF0 ICZhbXA7IEhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPk9BdXRoQGlldGYub3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsDQog Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9u IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWls IGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlDQogYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_88C799814D1B402FA284A636153DE082amazoncom_-- From nobody Wed Apr 18 12:44:53 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA78E126C26 for ; Wed, 18 Apr 2018 12:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfNSCv6RI7Q8 for ; Wed, 18 Apr 2018 12:44:47 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30047.outbound.protection.outlook.com [40.107.3.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E87D12426E for ; Wed, 18 Apr 2018 12:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mtgAf9iNHe1JVCftndEC3dcmiejAs2y8725ht1mtCBw=; b=BZRFYoHhY1sNdv3Eek3RXqJcicb6JNAigJ3jb35sdNx1CmGU38nbRJ3qRms00YSEZQg/zxAm0Y26YbuXqhZPZTiVUw3bG/ZfDd1bs81+BzEav6mRO+CSNRBScb0pFGnYLrL80oYGqea2hCNAfrm3M9rWMIWn9oUpoUj+0Khhrzk= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1392.eurprd08.prod.outlook.com (10.167.198.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.11; Wed, 18 Apr 2018 19:44:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Wed, 18 Apr 2018 19:44:43 +0000 From: Hannes Tschofenig To: Dick Hardt CC: n-sakimura , oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXAAC0wAgAAcFChAB/jIZAAAHQ9wXQALVCywAAbucAAAACgj4AAAU9gAAArvzdA= Date: Wed, 18 Apr 2018 19:44:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.115.223] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1392; 7:MG58KrU+Mm1+Jr7oXVICPkdts2ba1WzcfPumx1DcJcy16KsxIJVrfbEN5EIUq/5EF3ehmT/uATGFWg7Ux4HdX2QCbMrymCBwTvEtfv8BaQnC3XdriKG2Z3uQjMhrFdhEGAbXbHxE+r65ro2K63p2ZC6lM7/S0AUulQ8Y14aZD/xo1ARyJply6knyTZG+BAcU7QQtOae6/JhvH6Xr6mhb5lFBK6NNkH0vKP8eCBD2NiRvICPzLicALN/YP2eXgzJJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1392; x-ms-traffictypediagnostic: VI1PR0801MB1392: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231232)(944501368)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1392; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1392; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(376002)(346002)(396003)(366004)(40434004)(53754006)(365934003)(189003)(199004)(8936002)(8676002)(86362001)(81166006)(25786009)(229853002)(93886005)(4326008)(81156014)(478600001)(316002)(2900100001)(186003)(6916009)(26005)(11346002)(446003)(476003)(102836004)(54906003)(54896002)(6116002)(99286004)(5890100001)(5250100002)(74316002)(7736002)(53546011)(3280700002)(53936002)(6506007)(6246003)(14454004)(39060400002)(7696005)(53946003)(236005)(66066001)(966005)(9686003)(5660300001)(6306002)(790700001)(3846002)(55016002)(72206003)(6436002)(59450400001)(33656002)(76176011)(606006)(2906002)(3660700001)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1392; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; x-microsoft-antispam-message-info: uej2q2Zj2g628Gqyi8rMk5p+Ce4g3SRCHFBkQ/oEnIQtUX3e+8PGv37rog+K89+IKrOFliDJ+SlIuYPpadAwE34JcTyuMsTPmi0/bD7o/SH62g4Lloucl1l+d0hpl9XkR7DApMBD5uuHGS5ihx+DlCNNaQv6WoW8wNBxRbsAg5STQMgX5LmjtV7cs08UnM37 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21124163B1FBF63CFD8E2AF7FAB60VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 7a78e59b-4ff9-430a-259e-08d5a564d512 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a78e59b-4ff9-430a-259e-08d5a564d512 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 19:44:43.2060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1392 Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 19:44:52 -0000 --_000_VI1PR0801MB21124163B1FBF63CFD8E2AF7FAB60VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlmYWF0IGFuZCBJIGFyZSBhbHNvIE9LIHdpdGggbm90IGhhdmluZyB0byBvcmdhbml6ZSBhIGNv bmZlcmVuY2UgY2FsbCBvbiB0aGF0IHRvcGljIGlmIHlvdSBhbmQgdGhlIGdyb3VwIHRoaW5rIHRo YXQgbm8gc3VjaCBtZWV0aW5nIGlzIG5lY2Vzc2FyeS4NCg0KRnJvbTogRGljayBIYXJkdCBbbWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tXQ0KU2VudDogMTggQXByaWwgMjAxOCAxNjoyOQ0KVG86 IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogbi1zYWtpbXVyYTsgb2F1dGgNClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtcw0KDQpUaGUgbGFzdCBpbnRlcm0gbWVldGlu ZyB3YXMgbm90IHZlcnkgcHJvZHVjdGl2ZS4gVGhlIHZhbHVlIEkgZ290IHdhcyB0aGF0IGl0IHdv dWxkIGJlIHVzZWZ1bCB0byBzZWUgaWYgTmF0LCBCcmlhbiBhbmQgSSBjb3VsZCBjb2FsZXNjZS4N Cg0KT24gV2VkLCBBcHIgMTgsIDIwMTggYXQgNzoyMSBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+ IHdyb3RlOg0KSGkgRGljaywNCg0KVGhlIHZhbHVlIG9mIGEgY29uZmVyZW5jZSBjYWxsIGFzIHBh cnQgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgaXMgdGhhdCB5b3UgaW52b2x2ZSBvdGhlciBp bnRlcmVzdGVkIHBhcnRpZXMgdG8gdGhlIGRpc2N1c3Npb24sIGFuZCB0aGF0IHlvdSBkbyBub3Qg aGF2ZSB0byByZXBlYXQgeW91ciBwcml2YXRlIGNvbnZlcnNhdGlvbnMgbGF0ZXIgYWdhaW4gb24g dGhlIG1haWxpbmcgbGlzdC4NClRoYXTigJlzIHByZXR0eSBjb252aW5jaW5nIHRvIG1lIDstKQ0K DQpDaWFvDQpIYW5uZXMNCg0KDQpGcm9tOiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPl0NClNlbnQ6IDE4IEFwcmlsIDIw MTggMTY6MTUNClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IG4tc2FraW11cmE7IG9hdXRoDQoN ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtcw0KDQpGMkYgc2lk ZS9hdXRob3IgbWVldGluZyBhdCBNb250cmVhbA0KQWQgaG9jayBhdXRob3IgbWVldGluZyBjYWxs IHByaW9yDQoNClVuY2xlYXIgdG8gbWUgdGhlIHZhbHVlIG9mIGEgV0cgaW50ZXJuIG1lZXRpbmcN Cg0KT24gV2VkLCBBcHIgMTgsIDIwMTggYXQgMzo1OSBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+ IHdyb3RlOg0KSGV5IGd1eXMsDQoNCkkgYW0gdHJ5aW5nIHRvIGZpbmQgb3V0IHdoYXQgeW91IGFy ZSBwbGFubmluZyBoZXJlLg0KDQpBcmUgeW91IHRhbGtpbmcgYWJvdXQgc2NoZWR1bGluZyBhIHNp ZGUgbWVldGluZyBhdCB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgb3IgYSBmMmYgbWVldGluZyBzb21l d2hlcmUgZWxzZT8NCg0KUmlmYWF0IGFuZCBJIGhhZCBwcm9taXNlZCB0byBzY2hlZHVsZSBhIGNv bmZlcmVuY2UgY2FsbCAodmlydHVhbCBpbnRlcmltIG1lZXRpbmcpIGFib3V0IGRpc3RyaWJ1dGVk IE9BdXRoIGFuZCB3ZSBhcmUgdGFyZ2V0aW5nIE1heS4gV2hpbGUgaG9sZGluZyBhIGYyZiBpbnRl cmltIG1lZXRpbmcgZm9yIE9BdXRoIGlzIHBvc3NpYmxlIHdlIGhhdmUgbm90IGRpc2N1c3NlZCB0 aGlzIHNvIGZhci4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBuLXNha2ltdXJhDQpTZW50OiAxOCBBcHJpbCAyMDE4IDA3OjM0DQpUbzogRGljayBIYXJk dDsgbi1zYWtpbXVyYQ0KQ2M6IG9hdXRoDQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwg Zm9yIGFnZW5kYSBpdGVtcw0KDQoNCkkgc3VwcG9ydCB0aGUgaWRlYS4gQWRkaW5nIHRvIGl0LCBw ZXJoYXBzIHdlIGNhbiBkbyBhbiBhZC1ob2MgYmVmb3JlIE1vbnRyZWFsIHNvIHRoYXQgd2UgY2Fu IGNvbWUgdXAgd2l0aCBhIGNvbWJpbmVkIGRyYWZ0Lg0KDQoNCk5hdCBTYWtpbXVyYQ0KLS0NClBM RUFTRSBSRUFEOiBUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0 aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBlLW1haWwuDQoN Cg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5beu5Ye65Lq6OiBE aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20+Pg0K6YCB5L+h5pel5pmCOiAyMDE45bm0NOaciDE45pelIDA6NDA6MjANCuWum+WFiDogbi1z YWtpbXVyYQ0KQ0M6IFJpZmFhdCBTaGVraC1ZdXNlZjsgb2F1dGgNCuS7tuWQjTogUmU6IFtPQVVU SC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K5pys44Oh44O844Or44Gv 44OV44Oq44O844Oh44O844Or44GL44KJ5bGK44GE44Gm44GE44G+44GZ44CC5qiZ55qE5Z6L5pS7 5pKD44Oh44O844Or44Gv44OV44Oq44O844OhDQrjg7zjg6vjgYvjgonlsYrjgY/jgZPjgajjgYzj gYLjgorjgb7jgZnjga7jgafjgZTms6jmhI/jgY/jgaDjgZXjgYTjgILouqvjgavopprjgYjjga7j garjgYTjg6Hjg7zjg6sNCuOBp+OBguOCjOOBsOa3u+S7mOODleOCoeOCpOODq+OChFVSTOOCkumW i+OBi+OBmuOAgeS7peS4i+OBq+aOsui8ieOBleOCjOOBpuOBhOOCi+aJi+mghuOBq+W+k+OBow0K 44Gm5a++5b+c44KS44GK6aGY44GE44GX44G+44GZ44CCDQoNCuWFseacieaDheWgsT7mg4XloLHj grvjgq3jg6Xjg6rjg4bjgqPjg4jjg5Tjg4Pjgq/jgrk+5oCq44GX44GE44Oh44O844Or44GM5bGK 44GE44Gf44KJDQrjgb7jgZ/jga/jgIENCk5SSSBHcm91cCBTZWN1cml0eSBQb3J0YWw+5oOF5aCx 44K744Kt44Ol44Oq44OG44Kj44OI44OU44OD44Kv44K5DQo+5oCq44GX44GE44Oh44O844Or44GM 5bGK44GE44Gf44KJDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCkknZCBsaWtlIHRvIGNvb3JkaW5hdGUgYSBzaWRlIG1l ZXRpbmcgd2l0aCBOYXQsIEJyaWFuLCBteXNlbGYgYW5kIG90aGVyIGludGVyZXN0ZWQgcGFydGll cyBpbiBNb250cmVhbCB0byBkaXNjdXNzIERpc3RyaWJ1dGVkIE9BdXRoLg0KDQpJZiB3ZSBoYXZl IHR3byBtZWV0aW5ncywgSSdkIGxpa2UgYSB0aW1lc2xvdCBpbiB0aGUgc2Vjb25kIHRvIHN1bW1h cml6ZSB0aGUgc2lkZSBtZWV0aW5nIGFuZCBkaXNjdXNzIG5leHQgc3RlcHMgKGlmIGFueSkuDQoN ClNlcGFyYXRlbHksIEknZCBsaWtlIGEgdGltZSBzbG90IGZvciBhbiB1cGRhdGUgb24gUmVjaXBy b2NhbCBPQXV0aC4NCg0KT24gV2VkLCBNYXIgNywgMjAxOCBhdCA1OjUyIFBNLCBuLXNha2ltdXJh IDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+PiB3cm90 ZToNCg0KTm8sIG5vdCByZWFsbHkuIEkgd2FzIHRoaW5raW5nIG9mIG1vcmUgaW5mb3JtYWwgdGhp bmcuIFRoZSBzZXNzaW9uIGlzIHN1cHBvc2VkIHRvIGJlIFdlZG5lc2RheSBhZnRlcm5vb24sIHNv IEkgd2FzIHRoaW5raW5nIHRoYXQgaXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gZG8gYSBiaXQg b2YgcmVjYXAgYW1vbmcgY29udHJpYnV0b3JzIHRvIGRyYXcgdXAgYSBiYXR0bGUgcGxhbiB0b3dh cmRzIElFVEYgMTAyLg0KDQoNCg0KTmF0DQoNCg0KDQpGcm9tOiBSaWZhYXQgU2hla2gtWXVzZWYg W21haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNv bT5dDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA3LCAyMDE4IDk6MjIgUE0NClRvOiBuLXNha2lt dXJhIDxuLXNha2ltdXJhQG5yaS5jby5qcDxtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanA+Pg0K Q2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pjsgb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5k YSBpdGVtcw0KDQoNCg0KTmF0LA0KDQoNCg0KQXJlIHlvdSBhc2tpbmcgZm9yIGFuIGludGVyaW0g bWVldGluZz8NCg0KV2UgY291bGQgc2NoZWR1bGUgdGhlIERpc3RyaWJ1dGVkIE9BdXRoIGRpc2N1 c3Npb24gZm9yIHRoZSBXZWRuZXNkYXkgbWVldGluZzsgdGhhdCB3aWxsIGdpdmUgeW91IGd1eXMg c29tZXRpbWUgdG8gZGlzY3VzcyB0aGVzZSBmYWNlLXRvLWZhY2UgaW4gTG9uZG9uLg0KDQoNCg0K UmVnYXJkcywNCg0KIFJpZmFhdA0KDQoNCg0KDQoNCg0KDQpPbiBXZWQsIE1hciA3LCAyMDE4IGF0 IDI6MDAgQU0sIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNha2lt dXJhQG5yaS5jby5qcD4+IHdyb3RlOg0KDQpUaGVuIGxldCB1cyBkbyBpdC4gV2UgbmVlZCB0byBw dXQgYWxsIHRoZSBwcm9wb3NhbHMgb24gdGhlIHRhYmxlIGFuZCBzdHJhdGVnaXplIHRoZSBkZXNp Z24uDQoNClBlcmhhcHMgd2UgbmVlZCBhIHNpZGUgbWVldGluZyBhcyB3ZWxsLg0KDQoNCg0KbmF0 DQoNCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggMTozMSBBTQ0KVG86IFJpZmFhdCBTaGVraC1Z dXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+ Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCg0KDQpJIGhhZG4n dCBwcmV2aW91c2x5IGJlZW4gcGxhbm5pbmcgb24gaXQgYnV0IGFtIGhhcHB5IHRvIGRvIHNvLg0K DQoNCg0KT24gVHVlLCBNYXIgNiwgMjAxOCBhdCA4OjIyIEFNLCBSaWZhYXQgU2hla2gtWXVzZWYg PHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3Jv dGU6DQoNCk5hdCwNCg0KDQoNCkR1cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCAzIGRyYWZ0cyBt ZW50aW9uZWQgaW4gdGhlIGNvbnRleHQgb2YgRGlzdHJpYnV0ZWQgT0F1dGg6DQoNCg0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wODxodHRw czovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDg+DQoN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyPGh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJhZnQtY2FtcGJl bGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMj4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UtMDA8aHR0cHM6Ly90b29scy5p ZXRmLi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwPg0KDQoNCg0K DQoNCkJyaWFuLCBIYW5uZXMsDQoNCg0KDQpBcmUgeW91IHBsYW5uaW5nIG9uIHByZXNlbnRpbmcg eW91ciBkb2N1bWVudHM/DQoNCg0KDQpSZWdhcmRzLA0KDQogUmlmYWF0DQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCk9uIE1vbiwgTWFyIDUsIDIwMTggYXQgODowOSBQTSwgTmF0IFNha2ltdXJh IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0K DQpJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyB0aGF0Lg0KDQoNCg0KQWxzbywgYXMg cGFydCBvZiAiRGlzdHJpYnV0ZWQgT0F1dGgiLCBjYW4gd2UgZG8gYSBiaXQgb2YgcmUtY2FwIG9u IHNvbWUgb2YgdGhlIHByZXZpb3VzIGRyYWZ0cyBvbiB0aGUgc2ltaWxhciB0b3BpYyBhcyB3ZSBk aXNjdXNzZWQgaW4gdGhlIGludGVyaW0/IGkuZS4sIEJyaWFuJ3MgZHJhZnQgKHdoZXJlIGlzIHRo ZSBsaW5rIG5vdz8pIGFuZCBteSBkcmFmdCAoZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YTxodHRw czovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDgudHh0Pik/ DQoNCg0KDQpCZXN0LA0KDQoNCg0KTmF0DQoNCg0KDQpPbiBUdWUsIE1hciA2LCAyMDE4IGF0IDM6 MzAgQU0gV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlz c0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCkhhbm5lcyAmIFJpZmFhdCwNCg0KSSB3b3VsZCBsaWtl IHRoZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IG9uIE9BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRo b3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoKSBbYW4gdXBk YXRlIGZvciB3aGljaCB3aWxsIGJlIHBvc3RlZCB0b2RheV0gYW5kICJPQXV0aCAyLjAgRGV2aWNl IFBvc3R1cmUgU2lnbmFscyIgKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1wb3N0dXJlKS4N Cg0KDQoNCkkgY2FuIGFsc28gZ2l2ZSBhbiB1cGRhdGUgb24gdGhlIHN0YXR1cyBvZiBEZXZpY2Ug RmxvdyAoZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdykuIEkgZXhwZWN0IHRoYXQgdG8gYmUg c2hvcnQgbm93IHRoYXQgV0dMQyBoYXMgY29uY2x1ZGVkIGFuZCB0aGUgZG9jdW1lbnQgaGFzIGFk dmFuY2VkLg0KDQoNCg0KTGl0dGxlIGxhdGUgdG8gdGhpcyB0aHJlYWQgYW5kIEkgc2VlIHdlIGFs cmVhZHkgaGF2ZSAyIHNlc3Npb25zIGluIHRoZSBkcmFmdCBhZ2VuZGEsIGJ1dCBJJ2QgbGlrZSB0 byBhZGQgbXkgc3VwcG9ydCB0byBrZWVwaW5nIGJvdGggc2Vzc2lvbnMsIHRoZXJlJ3MgYWx3YXlz IGEgbG90IHRvIGRpc2N1c3MgYW5kIGluIHRoZSBwYXN0IHdlJ3ZlIGJlZW4gYWJsZSB0byB1c2Ug YW55IHNwYXJlIHRpbWUgdG8gZGlzY3VzcyB0aGUgc2VjdXJpdHkgdG9waWNzIG9mIHRoZSBkYXku DQoNCg0KDQpSZWdhcmRzLA0KDQpXaWxsaWFtDQoNCg0KDQoNCg0KDQoNCk9uIFR1ZSwgSmFuIDMw LCAyMDE4IGF0IDQ6NDAgQU0gSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90ZToNCg0KSGkgYWxs LA0KDQoNCg0KSXQgaXMgdGltZSBhbHJlYWR5IHRvIHRoaW5rIGFib3V0IHRoZSBhZ2VuZGEgZm9y IHRoZSBuZXh0IElFVEYgbWVldGluZy4gUmlmYWF0IGFuZCBJIHdlcmUgd29uZGVyaW5nIHdoZXRo ZXIgd2UgbmVlZCBvbmUgb3IgdHdvIHNlc3Npb25zLiBXZSB3b3VsZCBsaWtlIHRvIG1ha2UgdGhl IGRlY2lzaW9uIGJhc2VkIG9uIHRoZSB0b3BpY3Mgd2Ugd2lsbCBkaXNjdXNzLiBCZWxvdyB5b3Ug Y2FuIGZpbmQgYSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEgd2l0aCBhIGZldyByZW1hcmtz LiBMZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBmb3IgYWRk aXRpb25hbCBhZ2VuZGEgaXRlbXMuDQoNCg0KDQpDaWFvDQpIYW5uZXMgJiBSaWZhYXQNCg0KDQoN Ck9BdXRoIEFnZW5kYQ0KDQotLS0tLS0tLS0tLS0NCg0KDQoNCi0gV2VsY29tZSBhbmQgU3RhdHVz IFVwZGF0ZSAgKENoYWlycykNCg0KDQoNCiAgKiBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcCBSZXBv cnQNCg0KDQoNCiAgKiBEb2N1bWVudHMgaW4gSUVTRyBwcm9jZXNzaW5nDQoNCiAgICAgIyBkcmFm dC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA3DQoNCiAgICAgIyBkcmFmdC1pZXRmLW9hdXRoLWRp c2NvdmVyeS0wOA0KDQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMTUNCg0KICAgICAj IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTENCg0KDQoNCiAgICAgICBSZW1hcms6 IFN0YXR1cyB1cGRhdGVzIG9ubHkgaWYgbmVlZGVkLg0KDQoNCg0KLSAgSlNPTiBXZWIgVG9rZW4g QmVzdCBDdXJyZW50IFByYWN0aWNlcw0KDQogICAjIGRyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0w MA0KDQoNCg0KICAgUmVtYXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1l bnQuDQoNCiAgIE1vc3QgbGlrZWx5IHdlIHdpbGwgbm90IGdldCB0aGVtIGR1cmluZyB0aGUgZjJm IG1lZXRpbmcNCg0KICAgYnV0IHJhdGhlciBieSByZWFjaGluZyBvdXQgdG8gaW5kaXZpZHVhbHMg YWhlYWQgb2YgdGltZS4NCg0KDQoNCi0gIE9BdXRoIDIuMCBNdXR1YWwgVExTIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgQ2VydGlmaWNhdGUgQm91bmQgQWNjZXNzIFRva2Vucw0KDQogICAjIGRy YWZ0LWlldGYtb2F1dGgtbXRscy0wNg0KDQoNCg0KICAgUmVtYXJrOiBDb3VsZCBiZSBjb21wbGV0 ZWQgYnkgdGhlIHRpbWUgb2YgdGhlIElFVEYgbWVldGluZy4NCg0KDQoNCi0gT0F1dGggU2VjdXJp dHkgVG9waWNzDQoNCiAgIyBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wNA0KDQoN Cg0KICBSZW1hcms6IFdlIGNvdWxkIGRvIGEgY29uc2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhl IGRvY3VtZW50IHNvb24uDQoNCg0KDQotIE9BdXRoIDIuMCBUb2tlbiBCaW5kaW5nDQoNCiAgIyBk cmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmctMDUNCg0KDQoNCiAgUmVtYXJrOiBEb2N1bWVu dCBpcyBtb3ZpbmcgYWxvbmcgYnV0IHdlIGFyZSBsYWNraW5nIGltcGxlbWVudGF0aW9ucy4NCg0K DQoNCi0gT0F1dGggMi4wIERldmljZSBQb3N0dXJlIFNpZ25hbHMNCg0KICAjIGRyYWZ0LXdkZW5u aXNzLW9hdXRoLWRldmljZS1wb3N0dXJlLTAxDQoNCg0KDQogIFJlbWFyazogSW50ZXJlc3QgaW4g dGhlIHdvcmsgYnV0IHdlIGFyZSBsYWNraW5nIGNvbnRlbnQgKG1heWJlIGV2ZW4NCg0KICBleHBl cnRpc2UgaW4gdGhlIGdyb3VwKQ0KDQoNCg0KLSBSZWNpcHJvY2FsIE9BdXRoDQoNCiAgIyBkcmFm dC1oYXJkdC1vYXV0aC1tdXR1YWwtMDINCg0KDQoNCiAgUmVtYXJrOiBXZSBoYWQgYSB2aXJ0dWFs IGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFuZCB0aGVyZSBpcw0KDQogIGludGVyZXN0 IGluIHRoaXMgd29yayBhbmQgYXBwYXJlbnRseSBubyBjb21wZXRpbmcgc29sdXRpb25zLiBUaGUg cGxhbg0KDQogIGlzIHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFsbG93 ZWQgdG8gYWRkIGEgbmV3IG1pbGVzdG9uZQ0KDQogIHRvIG91ciBjaGFydGVyLg0KDQoNCg0KLSBE aXN0cmlidXRlZCBPQXV0aA0KDQogICMgZHJhZnQtaGFyZHQtb2F1dGgtZGlzdHJpYnV0ZWQtMDAN Cg0KDQoNCiAgUmVtYXJrOiBXZSBoYWQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlz IHRvcGljIGFuZCB0aGVyZSBpcw0KDQogIGludGVyZXN0IGluIHRoaXMgd29yay4gRnVydGhlciB3 b3JrIG9uIHRoZSBzY29wZSBpcyBuZWVkZWQuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCi0tDQoNCk5hdCBTYWtpbXVy YQ0KDQpDaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3VuZGF0aW9uDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55 IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0 aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsg eW91Lg0K --_000_VI1PR0801MB21124163B1FBF63CFD8E2AF7FAB60VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6 MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAy IDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5t MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsLCBsaS5tMTE5 NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsLCBkaXYubTExOTQ0 OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbA0KCXttc28tc3R5bGUt bmFtZTptXzExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5tMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bS00MzQxNzgwNTA5Nzc2MDg2MjI1bTYx OTM1MTE0MDUxMTQ1NzY2NTVtMjQyNDM5MDQ0MDM3Mjk3Nzk4OGhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTptXzExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG0tNDM0MTc4MDUw OTc3NjA4NjIyNW02MTkzNTExNDA1MTE0NTc2NjU1bTI0MjQzOTA0NDAzNzI5Nzc5ODhob2VuemI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SaWZhYXQgYW5kIEkgYXJlIGFsc28gT0sgd2l0aCBub3QgaGF2aW5nIHRvIG9yZ2Fu aXplIGEgY29uZmVyZW5jZSBjYWxsIG9uIHRoYXQgdG9waWMgaWYgeW91IGFuZCB0aGUgZ3JvdXAg dGhpbmsgdGhhdCBubyBzdWNoIG1lZXRpbmcgaXMgbmVjZXNzYXJ5Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERp Y2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiAxOCBBcHJpbCAyMDE4IDE2OjI5PGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxi cj4NCjxiPkNjOjwvYj4gbi1zYWtpbXVyYTsgb2F1dGg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsYXN0IGludGVybSBtZWV0aW5nIHdhcyBub3QgdmVy eSBwcm9kdWN0aXZlLiBUaGUgdmFsdWUgSSBnb3Qgd2FzIHRoYXQgaXQgd291bGQgYmUgdXNlZnVs IHRvIHNlZSBpZiBOYXQsIEJyaWFuIGFuZCBJIGNvdWxkIGNvYWxlc2NlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMTgsIDIwMTggYXQg NzoyMSBBTSBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb20iPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgRGljaywNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB2YWx1ZSBvZiBhIGNvbmZlcmVuY2UgY2Fs bCBhcyBwYXJ0IG9mIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGlzIHRoYXQgeW91IGludm9sdmUg b3RoZXIgaW50ZXJlc3RlZA0KIHBhcnRpZXMgdG8gdGhlIGRpc2N1c3Npb24sIGFuZCB0aGF0IHlv dSBkbyBub3QgaGF2ZSB0byByZXBlYXQgeW91ciBwcml2YXRlIGNvbnZlcnNhdGlvbnMgbGF0ZXIg YWdhaW4gb24gdGhlIG1haWxpbmcgbGlzdC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8xMTk0NDk2NzgwODk0ODMzNTU4X19NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXTi gJlzIHByZXR0eSBjb252aW5jaW5nIHRvIG1lIDstKTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFubmVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEaWNrDQogSGFyZHQgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNr LmhhcmR0QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTggQXByaWwgMjAxOCAx NjoxNTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5DYzo8L2I+IG4t c2FraW11cmE7IG9hdXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBD YWxsIGZvciBhZ2VuZGEgaXRlbXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkYyRiBzaWRlL2F1dGhv ciBtZWV0aW5nIGF0IE1vbnRyZWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFkIGhvY2sgYXV0aG9yIG1lZXRpbmcgY2FsbCBwcmlvcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VW5j bGVhciB0byBtZSB0aGUgdmFsdWUgb2YgYSBXRyBpbnRlcm4gbWVldGluZzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXByIDE4LCAyMDE4 IGF0IDM6NTkgQU0gSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJt LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGV5IGd1eXMsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIHRyeWluZyB0byBmaW5kIG91dCB3aGF0 IHlvdSBhcmUgcGxhbm5pbmcgaGVyZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB5b3UgdGFsa2luZyBh Ym91dCBzY2hlZHVsaW5nIGEgc2lkZSBtZWV0aW5nIGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBv ciBhIGYyZiBtZWV0aW5nIHNvbWV3aGVyZQ0KIGVsc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmlmYWF0IGFu ZCBJIGhhZCBwcm9taXNlZCB0byBzY2hlZHVsZSBhIGNvbmZlcmVuY2UgY2FsbCAodmlydHVhbCBp bnRlcmltIG1lZXRpbmcpIGFib3V0IGRpc3RyaWJ1dGVkDQogT0F1dGggYW5kIHdlIGFyZSB0YXJn ZXRpbmcgTWF5LiBXaGlsZSBob2xkaW5nIGEgZjJmIGludGVyaW0gbWVldGluZyBmb3IgT0F1dGgg aXMgcG9zc2libGUgd2UgaGF2ZSBub3QgZGlzY3Vzc2VkIHRoaXMgc28gZmFyLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2lhbzxicj4NCkhhbm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8xMTk0NDk2NzgwODk0ODMzNTU4X21fOTU2NjYzMzIyMjcx ODM5OSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBPQXV0aA0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+bi1zYWtpbXVyYTxicj4NCjxiPlNlbnQ6PC9iPiAxOCBBcHJp bCAyMDE4IDA3OjM0PGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0OyBuLXNha2ltdXJhPGJyPg0K PGI+Q2M6PC9iPiBvYXV0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZv ciBhZ2VuZGEgaXRlbXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fMTE5NDQ5Njc4MDg5NDgzMzU1OG1fOTU2NjYzMzIy MjcxODM5OTU2ZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SSBzdXBwb3J0IHRoZSBpZGVhLiBBZGRpbmcgdG8gaXQsIHBlcmhhcHMgd2UgY2FuIGRvIGFu IGFkLWhvYyBiZWZvcmUgTW9udHJlYWwgc28gdGhhdCB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgY29t YmluZWQgZHJhZnQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV8xMTk0 NDk2NzgwODk0ODMzNTU4bV85NTY2NjMzMjIyNzE4Mzk5NTZTaWduYXR1cmUiPg0KPGRpdiBpZD0i bV8xMTk0NDk2NzgwODk0ODMzNTU4bV85NTY2NjMzMjIyNzE4Mzk5NTZkaXZ0YWdkZWZhdWx0d3Jh cHBlciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5hdCBTYWtpbXVyYTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlBMRUFTRSBSRUFEOiBUaGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuIElmDQogeW91IGFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIGUtbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl eHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVy Ij4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8xMTk0NDk2NzgwODk0ODMzNTU4bV85NTY2NjMzMjIyNzE4 Mzk5NTZkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFu Zz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+5beu5Ye65Lq6PC9z cGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQogRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBs YW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7pgIHkv6Hml6Xm mYI8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAy MDE4PC9zcGFuPjxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6SkEiPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjQ8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpKQSI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ MTg8L3NwYW4+PHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpKQSI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ DQogMDo0MDoyMDxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkpBIj7lrpvlhYg8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiBuLXNha2ltdXJhPGJyPg0KPGI+Q0M6PC9iPiBSaWZh YXQgU2hla2gtWXVzZWY7IG9hdXRoPGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkpBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuS7tuWQjTwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KIFJlOiBbT0FVVEgtV0ddIENhbGwg Zm9yIGFnZW5kYSBpdGVtczwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPHNwYW4gbGFu Zz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPuacrOODoeODvOODq+OBr+ODleODquODvOODoeODvOODq+OBi+OCieWx iuOBhOOBpuOBhOOBvuOBmeOAguaomeeahOWei+aUu+aSg+ODoeODvOODq+OBr+ODleODquODvOOD oTwvc3Bhbj48YnI+DQo8c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01T IEdvdGhpYyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+44O844Or44GL44KJ5bGK44GP 44GT44Go44GM44GC44KK44G+44GZ44Gu44Gn44GU5rOo5oSP44GP44Gg44GV44GE44CC6Lqr44Gr 6Kaa44GI44Gu44Gq44GE44Oh44O844OrPC9zcGFuPjxicj4NCjxzcGFuIGxhbmc9IkpBIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OkpBIj7jgafjgYLjgozjgbDmt7vku5jjg5XjgqHjgqTjg6vjgoQ8L3NwYW4+VVJMPHNwYW4gbGFu Zz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6SkEiPuOCkumWi+OBi+OBmuOAgeS7peS4i+OBq+aOsui8ieOBleOCjOOBpuOB hOOCi+aJi+mghuOBq+W+k+OBozwvc3Bhbj48YnI+DQo8c3BhbiBsYW5nPSJKQSIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+ 44Gm5a++5b+c44KS44GK6aGY44GE44GX44G+44GZ44CCPC9zcGFuPjxicj4NCjxicj4NCjxzcGFu IGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOkpBIj7lhbHmnInmg4XloLE8L3NwYW4+Jmd0OzxzcGFuIGxhbmc9IkpB IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOkpBIj7mg4XloLHjgrvjgq3jg6Xjg6rjg4bjgqPjg4jjg5Tjg4Pjgq/jgrk8L3NwYW4+ Jmd0OzxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7mgKrjgZfjgYTjg6Hjg7zjg6vjgYzlsYrjgYTj gZ/jgok8L3NwYW4+PGJyPg0KPHNwYW4gbGFuZz0iSkEiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SkEiPuOBvuOBn+OBr+OAgTwv c3Bhbj48YnI+DQpOUkkgR3JvdXAgU2VjdXJpdHkgUG9ydGFsJmd0OzxzcGFuIGxhbmc9IkpBIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOkpBIj7mg4XloLHjgrvjgq3jg6Xjg6rjg4bjgqPjg4jjg5Tjg4Pjgq/jgrk8L3NwYW4+PGJy Pg0KJmd0OzxzcGFuIGxhbmc9IkpBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkpBIj7mgKrjgZfjgYTjg6Hjg7zjg6vjgYzlsYrj gYTjgZ/jgok8L3NwYW4+PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknZCBsaWtlIHRvIGNvb3JkaW5hdGUgYSBzaWRl IG1lZXRpbmcgd2l0aCBOYXQsIEJyaWFuLCBteXNlbGYgYW5kIG90aGVyIGludGVyZXN0ZWQgcGFy dGllcyBpbiBNb250cmVhbCB0byBkaXNjdXNzIERpc3RyaWJ1dGVkIE9BdXRoLg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2UgaGF2ZSB0d28g bWVldGluZ3MsIEknZCBsaWtlIGEgdGltZXNsb3QgaW4gdGhlIHNlY29uZCB0byBzdW1tYXJpemUg dGhlIHNpZGUgbWVldGluZyBhbmQgZGlzY3VzcyBuZXh0IHN0ZXBzIChpZiBhbnkpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VwYXJh dGVseSwgSSdkIGxpa2UgYSB0aW1lIHNsb3QgZm9yIGFuIHVwZGF0ZSBvbiBSZWNpcHJvY2FsIE9B dXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gV2VkLCBNYXIgNywgMjAxOCBhdCA1OjUyIFBNLCBuLXNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2lt dXJhQG5yaS5jby5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Tm8sIG5vdCByZWFsbHkuIEkgd2FzIHRoaW5raW5nIG9mIG1vcmUgaW5mb3JtYWwgdGhpbmcu IFRoZSBzZXNzaW9uIGlzIHN1cHBvc2VkIHRvIGJlIFdlZG5lc2RheSBhZnRlcm5vb24sDQogc28g SSB3YXMgdGhpbmtpbmcgdGhhdCBpdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBkbyBhIGJpdCBv ZiByZWNhcCBhbW9uZyBjb250cmlidXRvcnMgdG8gZHJhdyB1cCBhIGJhdHRsZSBwbGFuIHRvd2Fy ZHMgSUVURiAxMDIuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3 ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk5hdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBSaWZhYXQgU2hla2gtWXVzZWYNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyaWZh YXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggOToyMiBQ TTxicj4NCjxiPlRvOjwvYj4gbi1zYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm4tc2FraW11 cmFAbnJpLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+bi1zYWtpbXVyYUBucmkuY28uanA8L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPC9hPiZndDs7IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4 MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+TmF0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0 OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QXJlIHlvdSBhc2tpbmcgZm9yIGFuIGludGVyaW0gbWVldGluZz88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3 ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPldlIGNvdWxkIHNjaGVkdWxlIHRoZSBEaXN0cmlidXRlZCBPQXV0aCBkaXNjdXNzaW9uIGZv ciB0aGUgV2VkbmVzZGF5IG1lZXRpbmc7IHRoYXQgd2lsbCBnaXZlIHlvdSBndXlzIHNvbWV0aW1l IHRvIGRpc2N1c3MgdGhlc2UgZmFjZS10by1mYWNlIGluIExvbmRvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2 NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5 NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i bTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwO1JpZmFhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4 MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gV2VkLCBNYXIgNywgMjAxOCBhdCAyOjAwIEFNLCBuLXNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2lt dXJhQG5yaS5jby5qcDwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhlbiBsZXQgdXMgZG8gaXQuIFdlIG5lZWQgdG8gcHV0IGFsbCB0aGUgcHJvcG9zYWxzIG9u IHRoZSB0YWJsZSBhbmQgc3RyYXRlZ2l6ZSB0aGUgZGVzaWduLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlBlcmhhcHMgd2UgbmVlZCBhIHNpZGUgbWVldGluZyBhcyB3ZWxsLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5uYXQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzo8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1w YmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA3LCAyMDE4IDE6MzEgQU08 YnI+DQo8Yj5Ubzo8L2I+IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp ZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYz MzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGFkbid0IHByZXZp b3VzbHkgYmVlbiBwbGFubmluZyBvbiBpdCBidXQgYW0gaGFwcHkgdG8gZG8gc28uDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJt MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gVHVlLCBNYXIgNiwgMjAxOCBhdCA4OjIyIEFNLCBSaWZhYXQgU2hl a2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NTht OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkR1cmluZyB0 aGUgaW50ZXJpbSBtZWV0aW5nLCAzIGRyYWZ0cyBtZW50aW9uZWQgaW4gdGhlIGNvbnRleHQgb2YN CjxiPkRpc3RyaWJ1dGVkIE9BdXRoPC9iPjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEt MDg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LWNh bXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5k aWNhdG9ycy0wMjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwv ZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAw PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4 MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi PkJyaWFuLCBIYW5uZXMsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcmUgeW91IHBsYW5uaW5nIG9uIHBy ZXNlbnRpbmcgeW91ciBkb2N1bWVudHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMz NTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDtSaWZhYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i bTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgz OTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2 NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5 NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBNYXIgNSwgMjAxOCBh dCA4OjA5IFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2 NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgYmUg aW50ZXJlc3RlZCBpbiBoZWFyaW5nIHRoYXQuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5 NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxzbywgYXMgcGFydCBvZiAmcXVvdDtE aXN0cmlidXRlZCBPQXV0aCZxdW90OywgY2FuIHdlIGRvIGEgYml0IG9mIHJlLWNhcCBvbiBzb21l IG9mIHRoZSBwcmV2aW91cyBkcmFmdHMgb24gdGhlIHNpbWlsYXIgdG9waWMgYXMgd2UgZGlzY3Vz c2VkIGluIHRoZSBpbnRlcmltPyBpLmUuLCBCcmlhbidzIGRyYWZ0ICh3aGVyZSBpcw0KIHRoZSBs aW5rIG5vdz8pIGFuZCBteSBkcmFmdCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM0NDAwODgiPmRyYWZ0LXNha2ltdXJhLW9h dXRoLW1ldGE8L3NwYW4+PC9hPik/Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1 Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYz MzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QsJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2Nzgw ODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i bTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk5hdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2 NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgTWFy IDYsIDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1haWx0bzp3 ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SGFubmVzICZhbXA7IFJpZmFhdCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYz MzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkkgd291bGQg bGlrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBvbiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hp dGUiPk9BdXRoIDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1v YXV0aC1pbmNyZW1lbnRhbC1hdXRoKSBbYW4gdXBkYXRlIGZvciB3aGljaCB3aWxsDQogYmUgcG9z dGVkIHRvZGF5XSBhbmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZxdW90O09BdXRo IDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzJnF1b3Q7IChkcmFmdC13ZGVubmlzcy1vYXV0aC1k ZXZpY2UtcG9zdHVyZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgY2FuIGFsc28gZ2l2ZSBhbiB1cGRhdGUg b24gdGhlIHN0YXR1cyBvZiBEZXZpY2UgRmxvdyAoZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxv dykuIEkgZXhwZWN0IHRoYXQgdG8gYmUgc2hvcnQgbm93IHRoYXQgV0dMQyBoYXMgY29uY2x1ZGVk IGFuZCB0aGUgZG9jdW1lbnQgaGFzIGFkdmFuY2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1 NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MaXR0bGUgbGF0 ZSB0byB0aGlzIHRocmVhZCBhbmQgSSBzZWUgd2UgYWxyZWFkeSBoYXZlIDIgc2Vzc2lvbnMgaW4g dGhlIGRyYWZ0IGFnZW5kYSwgYnV0IEknZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRvIGtlZXBp bmcgYm90aCBzZXNzaW9ucywgdGhlcmUncyBhbHdheXMgYSBsb3QgdG8gZGlzY3VzcyBhbmQNCiBp biB0aGUgcGFzdCB3ZSd2ZSBiZWVuIGFibGUgdG8gdXNlIGFueSBzcGFyZSB0aW1lIHRvIGRpc2N1 c3MgdGhlIHNlY3VyaXR5IHRvcGljcyBvZiB0aGUgZGF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4 bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+V2lsbGlhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnht c29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgSmFuIDMwLCAyMDE4IGF0IDQ6NDAgQU0g SGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJt MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj5IaSBhbGws IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPkl0IGlzIHRp bWUgYWxyZWFkeSB0byB0aGluayBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgbmV4dCBJRVRGIG1l ZXRpbmcuIFJpZmFhdCBhbmQgSSB3ZXJlIHdvbmRlcmluZyB3aGV0aGVyIHdlIG5lZWQgb25lIG9y IHR3byBzZXNzaW9ucy4gV2Ugd291bGQgbGlrZSB0byBtYWtlIHRoZSBkZWNpc2lvbiBiYXNlZCBv biB0aGUgdG9waWNzIHdlIHdpbGwNCiBkaXNjdXNzLiBCZWxvdyB5b3UgY2FuIGZpbmQgYSBmaXJz dCB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEgd2l0aCBhIGZldyByZW1hcmtzLiBMZXQgdXMga25vdyBp ZiB5b3UgaGF2ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBmb3IgYWRkaXRpb25hbCBhZ2VuZGEg aXRlbXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05 NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj5D aWFvPGJyPg0KSGFubmVzICZhbXA7IFJpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3 MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+T0F1dGggQWdlbmRhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS0tLS0tLS0t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1 NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBXZWxjb21l IGFuZCBTdGF0dXMgVXBkYXRlJm5ic3A7IChDaGFpcnMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4 bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICogT0F1dGggU2VjdXJpdHkgV29ya3Nob3Ag UmVwb3J0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMz NTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsqIERvY3VtZW50cyBpbiBJRVNHIHByb2Nlc3Npbmc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2 eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1m bG93LTA3DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4 MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsjIGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA4DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsjIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1 NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0 Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1JlbWFyazogU3RhdHVzIHVwZGF0ZXMgb25seSBpZiBuZWVk ZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1 NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMz NTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSZuYnNwOyBKU09OIFdlYiBUb2tlbiBCZXN0IEN1 cnJlbnQgUHJhY3RpY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2 NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICMgZHJhZnQt aWV0Zi1vYXV0aC1qd3QtYmNwLTAwDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1 NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtSZW1hcms6IFdlIGFy ZSBsYWNraW5nIHJldmlld3Mgb24gdGhpcyBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgTW9zdCBsaWtlbHkgd2Ugd2lsbCBub3QgZ2V0IHRoZW0gZHVyaW5nIHRoZSBm MmYgbWVldGluZw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2Nzgw ODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YnV0IHJh dGhlciBieSByZWFjaGluZyBvdXQgdG8gaW5kaXZpZHVhbHMgYWhlYWQgb2YgdGltZS4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0m bmJzcDsgT0F1dGggMi4wIE11dHVhbCBUTFMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBDZXJ0 aWZpY2F0ZSBCb3VuZCBBY2Nlc3MgVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1tdGxzLTA2DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NTht OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUmVtYXJrOiBDb3VsZCBiZSBjb21w bGV0ZWQgYnkgdGhlIHRpbWUgb2YgdGhlIElFVEYgbWVldGluZy4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gT0F1dGggU2VjdXJp dHkgVG9waWNzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0 ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1z ZWN1cml0eS10b3BpY3MtMDQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5 NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazogV2UgY291bGQgZG8gYSBjb25zZW5z dXMgY2FsbCBvbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgc29vbi4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gT0F1dGggMi4wIFRva2VuIEJp bmRpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1 NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWJpbmRpbmctMDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4 OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwO1JlbWFyazogRG9jdW1lbnQgaXMgbW92aW5nIGFsb25nIGJ1dCB3ZSBh cmUgbGFja2luZyBpbXBsZW1lbnRhdGlvbnMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1 NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWdu YWxzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4 bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2 aWNlLXBvc3R1cmUtMDENCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5 Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazogSW50ZXJlc3QgaW4gdGhlIHdvcmsgYnV0 IHdlIGFyZSBsYWNraW5nIGNvbnRlbnQgKG1heWJlIGV2ZW4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNv bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwO2V4cGVydGlzZSBpbiB0aGUgZ3JvdXApPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29u b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4 MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIFJlY2lwcm9jYWwgT0F1dGg8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1oYXJkdC1vYXV0aC1tdXR1YWwtMDINCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIy NzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5 NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBSZW1hcms6IFdl IGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJlIGlz DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NTht OTU2NjYzMzIyMjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtpbnRlcmVzdCBpbiB0aGlzIHdvcmsg YW5kIGFwcGFyZW50bHkgbm8gY29tcGV0aW5nIHNvbHV0aW9ucy4gVGhlIHBsYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgaXMgdG8gcnVuIGEgY2FsbCBmb3IgYWRvcHRpb24gb25jZSB3ZSBh cmUgYWxsb3dlZCB0byBhZGQgYSBuZXcgbWlsZXN0b25lDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5OTU2eG1zb25v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDt0byBvdXIgY2hhcnRlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1 OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gRGlzdHJpYnV0ZWQgT0F1dGg8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5 OTU2eG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC0wMA0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMy MjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IFJlbWFyazog V2UgaGFkIGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUg aXMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1 OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO2ludGVyZXN0IGluIHRoaXMgd29y ay4gRnVydGhlciB3b3JrIG9uIHRoZSBzY29wZSBpcyBuZWVkZWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcx ODM5OTU2eG1zb25vcm1hbCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdA0KIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4 bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2 MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2 NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiPjxzcGFuIGNsYXNzPSJt MTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4Mzk5NTZ4bS00MzQxNzgwNTA5Nzc2MDg2 MjI1bTYxOTM1MTE0MDUxMTQ1NzY2NTVtMjQyNDM5MDQ0MDM3Mjk3Nzk4OGhvZW56YiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0KPC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPk5hdCBTYWtpbXVyYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Q2hhaXJtYW4gb2YgdGhlIEJvYXJkLCBPcGVu SUQgRm91bmRhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0x MTk0NDk2NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMz MjIyNzE4Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0xMTk0NDk2 NzgwODk0ODMzNTU4bTk1NjY2MzMyMjI3MTgzOTk1Nnhtc29ub3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtMTE5NDQ5Njc4MDg5NDgzMzU1OG05NTY2NjMzMjIyNzE4 Mzk5NTZ4bXNvbm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIy MjcxODM5OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTU1NTU1 O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxl Z2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkDQogcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNo bWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLg0KIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0ibTExOTQ0OTY3ODA4OTQ4MzM1NThtOTU2NjYzMzIyMjcxODM5 OTU2eG1zb25vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5DQogYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sDQogdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB21124163B1FBF63CFD8E2AF7FAB60VI1PR0801MB2112_-- From nobody Wed Apr 18 12:53:55 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD303126DEE for ; Wed, 18 Apr 2018 12:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAp32pCBfVqu for ; Wed, 18 Apr 2018 12:53:50 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA7812426E for ; Wed, 18 Apr 2018 12:53:50 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id t12so1342883pgp.13 for ; Wed, 18 Apr 2018 12:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k1O/bBZG4HZ60BSRvcxBdqA55XS2aLsRURR3hdT0Wzg=; b=kTS0LDD9Q/yR5ZOtxNrFZOHgva+32UFr0Iv+9/KjuETSM7p7RJsj6GNmrTvLlTuSyC zH8aLt8Kfna42znkl7ij/TrtuuekXdZXT6xJiUHaqBL64mqvD/rEO67DeYr0h6xFbxpX vcbuyaN30MNVKHMETzzJR1lON/X6i7VVcC4SE4/gpSLA7uRnUFPCiSZBJZ2OxGEcxcM0 9SHHhVhoA7IDEeElampLMdb/C6thb8r/dNzRq3ZW90QEXyJ+MIL94+/uMpdD278Vp/1m 0fk7nox59OSFt5Mp5Kzat5xbHjQUzt+aC75Z80ghPRlxNHqxELc0Qi46ccC1Lv15WRvW ezIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k1O/bBZG4HZ60BSRvcxBdqA55XS2aLsRURR3hdT0Wzg=; b=XeLES81XIDtE6u0c7ArMI7Rfa/vhg7RHBGffMwAP6KE/4Sqc37j2+8PGT+XCZjpIOz 1G2KYTHLfvb2znYp/pqkxqKHgARGJwcsz7MUMmgGAcqq983mlPN0Ospc3tS3Spj7VoaV qPenzsi4AqF7x+qwqvHOPjgp6Lw7QsK3OHXE8HGNE7lpD5MtljrjaTBh5L1bi574+sWB GkPLXJKYHNvZh3DXApMMhA9sADMoXMGU46PXBaf/nuiuqusXQr8WOQLJqljoluMfNko9 FtxtF6b1TjLGV1ifunK6y7YRoje3t9MSas1Fn+GQxgHMAljVxIgnmt4ssPILN0LfI/dS ZO1Q== X-Gm-Message-State: ALQs6tAYuwR5OAiph0hIhwFLSnBLlH1K6JhxwubNGDJ7+OsyOTiGgISP WtDkjTVo9PqyzW/3T0ozzFyUJ/Q3XsAb5QSBbgU= X-Google-Smtp-Source: AIpwx4+aXsqmyAwooipYKr1NgoCACggffWkaTxujdgPqhizxCGX0wCpltFz5W8ZSqzhp6Httqzed24wgBl9i4fiCas4= X-Received: by 10.101.86.8 with SMTP id l8mr2668064pgs.182.1524081229379; Wed, 18 Apr 2018 12:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.226.131 with HTTP; Wed, 18 Apr 2018 12:53:28 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Wed, 18 Apr 2018 12:53:28 -0700 Message-ID: To: Hannes Tschofenig Cc: n-sakimura , oauth Content-Type: multipart/alternative; boundary="089e08234a50493e6e056a24d004" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 19:53:54 -0000 --089e08234a50493e6e056a24d004 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it would be useful if we had a draft and we wanted to accelerate next steps, which may have been what would have happened in the last interm meeting. But it was not, it was clear there was not consensus on the problem, so I'm hoping Nat, Brian and myself can get consensus, and then bring that back to the WG. I'll take an action item to coordinate with Nat and Brian. Anyone else interested in participating is also welcome to join! On Wed, Apr 18, 2018 at 12:44 PM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Rifaat and I are also OK with not having to organize a conference call on > that topic if you and the group think that no such meeting is necessary. > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* 18 April 2018 16:29 > > *To:* Hannes Tschofenig > *Cc:* n-sakimura; oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > The last interm meeting was not very productive. The value I got was that > it would be useful to see if Nat, Brian and I could coalesce. > > > > On Wed, Apr 18, 2018 at 7:21 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi Dick, > > > > The value of a conference call as part of the OAuth working group is that > you involve other interested parties to the discussion, and that you do n= ot > have to repeat your private conversations later again on the mailing list= . > > That=E2=80=99s pretty convincing to me ;-) > > > > Ciao > > Hannes > > > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* 18 April 2018 16:15 > *To:* Hannes Tschofenig > *Cc:* n-sakimura; oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > F2F side/author meeting at Montreal > > Ad hock author meeting call prior > > > > Unclear to me the value of a WG intern meeting > > > > On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hey guys, > > > > I am trying to find out what you are planning here. > > > > Are you talking about scheduling a side meeting at the next IETF meeting > or a f2f meeting somewhere else? > > > > Rifaat and I had promised to schedule a conference call (virtual interim > meeting) about distributed OAuth and we are targeting May. While holding = a > f2f interim meeting for OAuth is possible we have not discussed this so > far. > > > > Ciao > Hannes > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *n-sakimura > *Sent:* 18 April 2018 07:34 > *To:* Dick Hardt; n-sakimura > *Cc:* oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I support the idea. Adding to it, perhaps we can do an ad-hoc before > Montreal so that we can come up with a combined draft. > > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > > > > > ------------------------------ > > *=E5=B7=AE=E5=87=BA=E4=BA=BA**:* Dick Hardt > *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82**:* 2018=E5=B9=B44=E6=9C=8818=E6=97= =A5 0:40:20 > *=E5=AE=9B=E5=85=88**:* n-sakimura > *CC:* Rifaat Shekh-Yusef; oauth > *=E4=BB=B6=E5=90=8D**:* Re: [OAUTH-WG] Call for agenda items > > > > ****************************************************************** > =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3= =81=84=E3=81=BE=E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92= =83=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 > =E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8= =E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6= =B3=A8=E6=84=8F=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81= =AB=E8=A6=9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB > =E3=81=A7=E3=81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1= =E3=82=A4=E3=83=AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81= =E4=BB=A5=E4=B8=8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3= =81=84=E3=82=8B=E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3 > =E3=81=A6=E5=AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 > > =E5=85=B1=E6=9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD= =E3=83=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3= =82=B9>=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5= =B1=8A=E3=81=84=E3=81=9F=E3=82=89 > =E3=81=BE=E3=81=9F=E3=81=AF=E3=80=81 > NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5= =E3=83=AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9 > >=E6=80=AA=E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A= =E3=81=84=E3=81=9F=E3=82=89 > ****************************************************************** > > I'd like to coordinate a side meeting with Nat, Brian, myself and other > interested parties in Montreal to discuss Distributed OAuth. > > > > If we have two meetings, I'd like a timeslot in the second to summarize > the side meeting and discuss next steps (if any). > > > > Separately, I'd like a time slot for an update on Reciprocal OAuth. > > > > On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura wrote: > > No, not really. I was thinking of more informal thing. The session is > supposed to be Wednesday afternoon, so I was thinking that it might be a > good idea to do a bit of recap among contributors to draw up a battle pla= n > towards IETF 102. > > > > Nat > > > > *From:* Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] > *Sent:* Wednesday, March 07, 2018 9:22 PM > *To:* n-sakimura > *Cc:* Brian Campbell ; oauth > > > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > Nat, > > > > Are you asking for an interim meeting? > > We could schedule the Distributed OAuth discussion for the Wednesday > meeting; that will give you guys sometime to discuss these face-to-face i= n > London. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distrib= uted > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some o= f > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for > which will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC > has concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use an= y > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Acces= s > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new mileston= e > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --089e08234a50493e6e056a24d004 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it would be useful if we had a draft and we wanted= to accelerate next steps, which may have been what would have happened in = the last interm meeting. But it was not, it was clear there was not consens= us on the problem, so I'm hoping Nat, Brian and myself can get consensu= s, and then bring that back to the WG.

I'll take an = action item to coordinate with Nat and Brian.

Anyo= ne else interested in participating is also welcome to join!

=

On We= d, Apr 18, 2018 at 12:44 PM, Hannes Tschofenig <Hannes.Tschofenig@= arm.com> wrote:

Rifaat and I are also OK = with not having to organize a conference call on that topic if you and the = group think that no such meeting is necessary.

=C2=A0

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: 18 April 2018 16:29


To: Hannes Tschofenig
Cc: n-sakimura; oauth
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

The last interm meeting was not very productive. The= value I got was that it would be useful to see if Nat, Brian and I could c= oalesce.

=C2=A0

On Wed, Apr 18, 2018 at 7:21 AM Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hi Dick,

=C2=A0

The value of a conference= call as part of the OAuth working group is that you involve other interest= ed parties to the discussion, and that you do not have to repeat your private= conversations later again on the mailing list.

That=E2=80=99s pretty convi= ncing to me ;-)

=C2=A0

Ciao=

Hannes

=C2=A0

=C2=A0

From: Dick Hardt [mailto:di= ck.hardt@gmail.com]
Sent: 18 April 2018 16:15
To: Hannes Tschofenig
Cc: n-sakimura; oauth


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

F2F side/author meeting at Montreal

Ad hock author meeting call prior

=C2=A0

Unclear to me the value of a WG intern meeting

=C2=A0

On Wed, Apr 18, 2018 at 3:59 AM Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hey guys,

=C2=A0

I am trying to find out w= hat you are planning here.

=C2=A0

Are you talking about sch= eduling a side meeting at the next IETF meeting or a f2f meeting somewhere else?

=C2=A0

Rifaat and I had promised= to schedule a conference call (virtual interim meeting) about distributed OAuth and we are targeting May. While holding a f2f interim meeting for OA= uth is possible we have not discussed this so far.

=C2=A0

Ciao
Hannes

=C2=A0=

From: OAuth [mailto:oauth-= bounces@ietf.org] On Behalf Of n-sakimura
Sent: 18 April 2018 07:34
To: Dick Hardt; n-sakimura
Cc: oauth


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I support the idea. Adding to it, perhaps we can do an ad-hoc be= fore Montreal so that we can come up with a combined draft.=C2=A0=

=C2=A0

Nat Sakimura=

--

PLEASE READ: = This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete thi= s e-mail.

=C2=A0

=C2=A0<= /u>

=C2=A0

=C2=A0

=E5=B7=AE=E5=87=BA=E4=BA=BA: Dick Hardt <d= ick.hardt@gmail.com>
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2018=E5=B9=B44=E6=9C=8818=E6=97=A5 0:40:20
=E5=AE=9B=E5=85=88: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] Call for agenda items

=C2=A0

***********************************************= *******************
=E6=9C=AC=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1=E3=83= =BC=E3=83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=84=E3=81=A6=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82=E6=A8=99=E7=9A=84=E5=9E=8B=E6=94=BB=E6=92=83=E3=83= =A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=83=95=E3=83=AA=E3=83=BC=E3=83=A1 =E3=83=BC=E3= =83=AB=E3=81=8B=E3=82=89=E5=B1=8A=E3=81=8F=E3=81=93=E3=81=A8=E3=81=8C=E3=81= =82=E3=82=8A=E3=81=BE=E3=81=99=E3=81=AE=E3=81=A7=E3=81=94=E6=B3=A8=E6=84=8F= =E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=80=82=E8=BA=AB=E3=81=AB=E8=A6= =9A=E3=81=88=E3=81=AE=E3=81=AA=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB =E3=81=A7=E3= =81=82=E3=82=8C=E3=81=B0=E6=B7=BB=E4=BB=98=E3=83=95=E3=82=A1=E3=82=A4=E3=83= =AB=E3=82=84URL=E3=82=92=E9=96=8B=E3=81=8B=E3=81=9A=E3=80=81=E4=BB=A5=E4=B8= =8B=E3=81=AB=E6=8E=B2=E8=BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B= =E6=89=8B=E9=A0=86=E3=81=AB=E5=BE=93=E3=81=A3
=E3=81=A6=E5= =AF=BE=E5=BF=9C=E3=82=92=E3=81=8A=E9=A1=98=E3=81=84=E3=81=97=E3=81=BE=E3=81= =99=E3=80=82

=E5=85=B1=E6= =9C=89=E6=83=85=E5=A0=B1>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5=E3=83= =AA=E3=83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9&g= t;=E6=80=AA= =E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A=E3=81=84=E3= =81=9F=E3=82=89
=E3=81=BE=E3= =81=9F=E3=81=AF=E3=80=81
NRI Group Security Portal>=E6=83=85=E5=A0=B1=E3=82=BB=E3=82=AD=E3=83=A5=E3=83=AA=E3= =83=86=E3=82=A3=E3=83=88=E3=83=94=E3=83=83=E3=82=AF=E3=82=B9
>=E6=80=AA= =E3=81=97=E3=81=84=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8C=E5=B1=8A=E3=81=84=E3= =81=9F=E3=82=89
*****************************************************************= *

I'd like to coordinate a side meeting with Nat, = Brian, myself and other interested parties in Montreal to discuss Distribut= ed OAuth.

=C2=A0

If we have two meetings, I'd like a timeslot in = the second to summarize the side meeting and discuss next steps (if any).

=C2=A0

Separately, I'd like a time slot for an update o= n Reciprocal OAuth.

=C2=A0

On Wed, Mar 7, 2018 at 5:52 PM, n-sakimura <n-sakimura@nri.co.jp> wrote:

No, not really. I was thi= nking of more informal thing. The session is supposed to be Wednesday after= noon, so I was thinking that it might be a good idea to do a bit of recap among = contributors to draw up a battle plan towards IETF 102.

=C2=A0

Nat<= /p>

=C2=A0

From: Rifaat Shekh-Yusef [mailto:rifaat.= ietf@gmail.com]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Brian Campbell <bcampbell@pingidentity.com>; oauth <oauth@ietf.org><= /u>


Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

Nat,

=C2=A0

Are you asking for an interim meeting?

We could schedule the Distributed OAuth disc= ussion for the Wednesday meeting; that will give you guys sometime to discu= ss these face-to-face in London.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura &= lt;n-sakimura@nri= .co.jp> wrote:

Then let us do it. We nee= d to put all the proposals on the table and strategize the design.

Perhaps we need a side me= eting as well.

=C2=A0

nat<= /p>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I hadn't previously been planning on it = but am happy to do so.

=C2=A0

On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh= -Yusef <rifaa= t.ietf@gmail.com> wrote:

Nat,

=C2=A0

Brian, Hannes,

=C2=A0

Are you planning on presenting your document= s?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura= <sakimura@gmail= .com> wrote:

I would be interested in hearing that.=C2=A0=

=C2=A0

Also, as part of "Distributed OAuth&quo= t;, can we do a bit of re-cap on some of the previous drafts on the similar= topic as we discussed in the interim? i.e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oauth-meta)?=C2=A0<= u>

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

On Tue, Mar 6, 2018 at 3:30 AM William Denni= ss <wdenniss@go= ogle.com> wrote:

Hannes & Rifaat,


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (d= raft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).=

=C2=A0

I can also give an update on the status of D= evice Flow (draft-ietf-oauth-device-flow). I expect that to be short n= ow that WGLC has concluded and the document has advanced.<= /u>

=C2=A0

Little late to this thread and I see we alre= ady have 2 sessions in the draft agenda, but I'd like to add my support= to keeping both sessions, there's always a lot to discuss and in the past we've been able to use any spare time to discuss the secur= ity topics of the day.

=C2=A0

Regards,

William

=C2=A0

=C2=A0

=C2=A0

On Tue, Jan 30, 2018 at 4:40 AM Hannes Tscho= fenig <Ha= nnes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think about the agenda for the next IETF me= eting. Rifaat and I were wondering whether we need one or two sessions. We = would like to make the decision based on the topics we will discuss. Below you can find a first version of the agenda with a few remar= ks. Let us know if you have comments or suggestions for additional agenda i= tems.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

OAuth Agenda<= /span>

------------<= /span>

=C2=A0=

- Welcome and= Status Update=C2=A0 (Chairs)

=C2=A0=

=C2=A0 * OAut= h Security Workshop Report

=C2=A0

=C2=A0=C2=A0*= Documents in IESG processing

=C2=A0=C2=A0= =C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-08

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

=C2=A0=C2=A0= =C2=A0=C2=A0 # draft-ietf-oauth-token-exchange-11=

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates only if needed.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0

-=C2=A0 JSON = Web Token Best Current Practices

=C2=A0=C2=A0 = # draft-ietf-oauth-jwt-bcp-00

=C2=A0=C2=A0= =C2=A0

=C2=A0=C2=A0= =C2=A0Remark: We are lacking reviews on this document.=

=C2=A0=C2=A0 = Most likely we will not get them during the f2f meeting

=C2=A0=C2=A0= =C2=A0but rather by reaching out to individuals ahead of time.

=C2=A0=C2=A0= =C2=A0

-=C2=A0 OAuth= 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

=C2=A0=C2=A0 = # draft-ietf-oauth-mtls-06

=C2=A0=

=C2=A0=C2=A0 = Remark: Could be completed by the time of the IETF meeting.

=C2=A0=C2=A0= =C2=A0

- OAuth Secur= ity Topics

=C2=A0 # draf= t-ietf-oauth-security-topics-04

=C2=A0=C2=A0<= /span>

=C2=A0=C2=A0R= emark: We could do a consensus call on parts of the document soon.

=C2=A0=C2=A0<= /span>

- OAuth 2.0 T= oken Binding

=C2=A0 # draf= t-ietf-oauth-token-binding-05

=C2=A0

=C2=A0=C2=A0R= emark: Document is moving along but we are lacking implementations.

=C2=A0=C2=A0<= /span>

- OAuth 2.0 D= evice Posture Signals

=C2=A0 # draf= t-wdenniss-oauth-device-posture-01

=C2=A0=C2=A0<= /span>

=C2=A0=C2=A0R= emark: Interest in the work but we are lacking content (maybe even

=C2=A0=C2=A0e= xpertise in the group)

=C2=A0

- Reciprocal = OAuth

=C2=A0 # draf= t-hardt-oauth-mutual-02

=C2=A0=

=C2=A0 Remark= : We had a virtual interim meeting on this topic and there is

=C2=A0=C2=A0i= nterest in this work and apparently no competing solutions. The plan=

=C2=A0 is to = run a call for adoption once we are allowed to add a new milestone

=C2=A0=C2=A0t= o our charter.

=C2=A0=C2=A0<= /span>

- Distributed= OAuth

=C2=A0 # draf= t-hardt-oauth-distributed-00

=C2=A0=

=C2=A0 Remark= : We had a virtual interim meeting on this topic and there is

=C2=A0=C2=A0i= nterest in this work. Further work on the scope is needed.=

IMPORTANT NOTICE: The contents of this email and any attachments = are confidential and may also be privileged. If you are not the intended re= cipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or stor= e or copy the information in any medium. Thank you.

_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura<= u>

Chairman of the Board, Open= ID Foundation


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confid= ential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.=C2=A0 If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpo= se, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--089e08234a50493e6e056a24d004-- From nobody Wed Apr 18 15:12:37 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615151241F3 for ; Wed, 18 Apr 2018 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4c7T-MGNZfP for ; Wed, 18 Apr 2018 15:12:32 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C41120047 for ; Wed, 18 Apr 2018 15:12:32 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id d6-v6so4324259iog.1 for ; Wed, 18 Apr 2018 15:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c4kRafq3CF6nyVmwEiILBLdvJdqdYmHmdAi2aw9WL6I=; b=NVPUeGKr/ZrJiGjZOu+nT5uyQHLA1Mo6E2YcE14CjsBHCwdtQUtrTyZce2tCUgxEDg ib7ZbCogWKTphEDfyoHKXqOlrvmvzJ24sBIfcZLbCWKtynI9VUqIsXDhlpqKSh1WEa3d tn6ENu47CssHiqVPJU66VdVYnkgPdDa1XhYJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c4kRafq3CF6nyVmwEiILBLdvJdqdYmHmdAi2aw9WL6I=; b=BLh3WqPtS8Xovx2m7OPSWzxnBLYTkUVS4nxTpxsvc1lfU6AgMdpVvZkvI3tqQ1WPmW Ud1cRygUnMGpr2EFyfrYwbQOmvX+/kHe5zMavclPyJd3q8tqXuTZjc0Wu4hJ+SZwv2K/ GQAP/KutCUhzW6xB2cHdiwx8xeA3RjbFThfbuOAUkwJHIZfCseC/gBGTpJXr4LEerOQR BWr0RtjfBmIeRpymEDBQ6qbsIcAE+FWLsfIP5VBKUjdCDwwOzQp/WYM+2CVHbO7Vjqdf MIM29eqz05ZJn5jVMvpY2Au8vrgqKABTwzNj44XfeU1t7siDNNWJ9boUQok+LrrSY17F YULQ== X-Gm-Message-State: ALQs6tA8NC2j6EtbLFFNBhU8g/B24cX/aX3wMQTQhR5FMZZgcsaMZc9s vvXIP49fOisI7STUvDS2+P2mxemUZxXHOwjwcpIE5as/EwTuVFOGW2fyH50/F7ohj7ogSqDaavG VYiBp0y/oeChFyg== X-Google-Smtp-Source: AIpwx49e8D8ZdXOx5fEOBD7c61CKYHtqg/oSL8VbvrunnWrFfqN5C9PwwdFRNwMkbBtN14RxGWeOYW8fS73Rp6HxkyA= X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr1298370iof.282.1524089551618; Wed, 18 Apr 2018 15:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 15:12:01 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 18 Apr 2018 16:12:01 -0600 Message-ID: To: Eric Rescorla Cc: oauth Content-Type: multipart/alternative; boundary="000000000000549fe4056a26c09c" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 22:12:35 -0000 --000000000000549fe4056a26c09c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric, I realize you weren't particularly impressed by my prior statements about the actor claim but, for lack of knowing what else to say, I'm going to kind of repeat what I said about it over in the Phabricator tool and add a little color. The actor claim is intended as a way to express that delegation has happened and identify the entities involved. Access control or other decisions based on it are at the discretion of the consumer of the token based on whatever policy might be in place. There are JWT claims that have concise processing rules with respect to whether or not the JWT can be accepted as valid. Some examples are "aud" (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519. E.g. if the token is expired or was intended for someone or something else, reject it. And there are JWT claims that appropriately don't specify such processing rules and are solely statements of fact or circumstance. Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are good examples of such. There might be application or policy specific rules applied to the content of those kinds of claims (e.g. only subjects from a particular organization are able to access tenant specific data or, less realistic but still possible, disallow access for tokens issued outside of regular business hours) but that's all outside the scope of a specification's definition of the claim. The actor claim falls into the latter category. It's a way for the issuer of the token to tell the consumer of the token what is going on. But any action to take (or not) based on that information is at the discretion of the token consumer. I honestly don't know it could be anything more. And don't think it should be. There are two main expected uses of the actor claim (that I'm aware of anyway) that describing here might help. Maybe. One is a human to human delegation case like a customer service rep doing something on behalf of an end user. The subject would be that user and the actor would be the customer service rep. And there wouldn't be any chaining or nesting of the actor. The other case is so called service chaining where a system might exchange a token it receives for a new token that it can use to call a downstream service. And that service in turn might do another exchange to get a new token suitable to call yet another downstream service. And again and so on and turtles all the way. I'm not necessarily endorsing that level of granularity in chaining but it's bound to happen somewhere/sometime. The nested actor claim is able to express that all that has happened with the top level or outermost one being the system currently using the token and prior systems being nested. What actually gets done with that information is up to the respective systems involved. There might be policy about what system is allowed to call what other system that is enforced. Or maybe the info is just written to an audit log somewhere. Or something else. I don't know. But whatever it is application/deployment/policy dependent and not specifiable by a spec. On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: > Hi folks, > > I've gone over draft-ietf-oauth-token-exchange-12 and things seem > generally OK. I do still have one remaining concern, which is about > the actor claim. Specifically, what is the RP supposed to do when they > encounter it? This seems kind of underspecified. > > In particular: > > 1. What facts am I supposed to know here? Merely that everyone in > the chain signed off on the next person in the chain acting as them? > > 2. Am I just supposed to pretend that the person presenting the token > is the identity at the top of the chain? Say I have the > delegation A -> B -> C, and there is some resource which > B can access but A and C cannot, should I give access? > > I think the first question definitely needs an answer. The second > question I guess we could make not answer, but it's pretty hard > to know how to make a system with this left open.. > > -Ekr > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000549fe4056a26c09c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eric, I realize you weren't partic= ularly impressed by my prior statements about the actor claim but, for lack= of knowing what else to say, I'm going to kind of repeat what I said about it over in the Phabricator tool and add a little co= lor.

The actor claim is intended as a way to express that delegatio= n has happened and identify the entities involved. Access control or other = decisions based on it are at the discretion of the consumer of the token ba= sed on whatever policy might be in place.

There are JWT claim= s that have concise processing rules with respect to whether or not the JWT= can be accepted as valid. Some examples are "aud" (Audience), &q= uot;exp" (Expiration Time), and "nbf" (Not Before) from RFC = 7519. E.g. if the token is expired or was intended for someone or something= else, reject it.

And there are JWT claims that appropriately= don't specify such processing rules and are solely statements of fact = or circumstance. Also from RFC 7519, the "sub" (Subject) and &quo= t;iat" (Issued At) claims are good examples of such. There might be ap= plication or policy specific rules applied to the content of those kinds of= claims (e.g. only subjects from a particular organization are able to acce= ss tenant specific data or, less realistic but still possible, disallow acc= ess for tokens issued outside of regular business hours) but that's all= outside the scope of a specification's definition of the claim.
The actor claim falls into the latter category. It's a way for = the issuer of the token to tell the consumer of the token what is going on.= But any action to take (or not) based on that information is at the discre= tion of the token consumer. I honestly don't know it could be anything = more. And don't think it should be.

There are two main exp= ected uses of the actor claim (that I'm aware of anyway) that describin= g here might help. Maybe. One is a human to human delegation case like a cu= stomer service rep doing something on behalf of an end user. The subject wo= uld be that user and the actor would be the customer service rep. And there= wouldn't be any chaining or nesting of the actor. The other case is so= called service chaining where a system might exchange a token it receives = for a new token that it can use to call a downstream service. And that serv= ice in turn might do another exchange to get a new token suitable to call y= et another downstream service. And again and so on and turtles all the way.= I'm not necessarily endorsing that level of granularity in chaining bu= t it's bound to happen somewhere/sometime. The nested actor claim is ab= le to express that all that has happened with the top level or outermost on= e being the system currently using the token and prior systems being nested= . What actually gets done with that information is up to the respective sys= tems involved. There might be policy about what system is allowed to call w= hat other system that is enforced. Or maybe the info is just written to an = audit log somewhere. Or something else. I don't know. But whatever it i= s application/deployment/policy dependent and not specifiable by a spec.






On Fri, A= pr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

I've gon= e over draft-ietf-oauth-token-exchange-12 and things seem
generally= OK. I do still have one remaining concern, which is about
the actor cla= im. Specifically, what is the RP supposed to do when they
encounter it? = This seems kind of underspecified.

In particular:

1. What fac= ts am I supposed to know here? Merely that everyone in
=C2=A0=C2=A0 the = chain signed off on the next person in the chain acting as them?

2. = Am I just supposed to pretend that the person presenting the token
=C2= =A0=C2=A0 is the identity at the top of the chain? Say I have the
=C2=A0= =C2=A0 delegation A -> B -> C, and there is some resource which
= =C2=A0=C2=A0 B can access but A and C cannot, should I give access?

= I think the first question definitely needs an answer. The second
questi= on I guess we could make not answer, but it's pretty hard
to know ho= w to make a system with this left open..

-Ekr


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000549fe4056a26c09c-- From nobody Wed Apr 18 15:58:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584F8127909 for ; Wed, 18 Apr 2018 15:58:52 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P7Em9A9i6Iz for ; Wed, 18 Apr 2018 15:58:49 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0120.outbound.protection.outlook.com [104.47.37.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9C4126D05 for ; Wed, 18 Apr 2018 15:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nKmJDqLsg+R+JxVXtdK3PMes0e0g/zRbWtafOT01Ba0=; b=RoI9koxfqDdv3PAjlj05jgXxq1qr97n47fY+682PI/KdyDL4mLa0ly27QPtIN54Oe7jGs1XIKq/l7W006h+tBHFd36fXBlFVaLXWylZ1vCx44ab0FiQp+u6CMC61TcVP+P3PdZWRwT2DfTqDKfftTcBSDy3cfl3HFwPPp6cebTo= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (2603:10b6:302:8::29) by MW2PR00MB0396.namprd00.prod.outlook.com (2603:10b6:302:9::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.732.0; Wed, 18 Apr 2018 22:58:46 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::14fe:50f9:a696:970d]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::14fe:50f9:a696:970d%4]) with mapi id 15.20.0733.000; Wed, 18 Apr 2018 22:58:46 +0000 From: Mike Jones To: Brian Campbell , Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 Thread-Index: AQHT1NjgJy8mHwoFFk6XUY9K9SCN+aQGpvqAgACAzaA= Date: Wed, 18 Apr 2018 22:58:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.204.119.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0396; 7:ZPnPxrVzuTxPoANxJd70D8xb3dXnTbTwn7paDUUO773l483HeGrOqbytfjoqfLxg6td2+zbuUcenM/t1sko1/886UlK4ojCKjKmZnAJztwGiJlqidmZgGOfoGQHxBg4hU5810Xf1MB83hyJKuXSQQd2vxyqwR8WCVkpnk4nuEYb/ROsYpnqDvC3Kr2HcNwagXuAQoAlTwHE5mP+NGZbmkPsLIU19mnyFrz3gXVKyRt+y6Gngfr5TALmT4RPdMlM9; 20:AmvOYFFRImCy0+KQV9z1jYePBhDPt5sCMdI2u3K7mkYL8qddmT4GrS+P3ir1W7QI4nSfovI81pOFiO7hsyIwNAhenAsIbBSh7z77LbPg77L0M2bQnuUyLbQxEJikm5CDLIpitqjbixYmt4wbpmX7pZqhzXk/su43K72tJl4N2zc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:MW2PR00MB0396; x-ms-traffictypediagnostic: MW2PR00MB0396: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(61425038)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(10201501046)(3002001)(3231232)(944501368)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MW2PR00MB0396; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0396; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39380400002)(39860400002)(53754006)(19609705001)(7736002)(8990500004)(74316002)(5660300001)(81166006)(10090500001)(8676002)(5890100001)(102836004)(5250100002)(7696005)(11346002)(52396003)(76176011)(59450400001)(53546011)(26005)(6506007)(86612001)(6116002)(790700001)(3846002)(186003)(446003)(8936002)(606006)(476003)(86362001)(99286004)(6436002)(966005)(72206003)(10290500003)(229853002)(22452003)(25786009)(316002)(33656002)(110136005)(54896002)(2900100001)(53936002)(236005)(66066001)(9686003)(6246003)(6306002)(4326008)(478600001)(14454004)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0396; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: kYnSsToplTQxgJuI4QkgiofEBLo/LmUffOWyeDZMXHt35Mv18urEK5zvGcIKfPhNM9uOBn/URoaQ3u8EwDXpyYjwQraKTHonkzu2rMxcp+l2UFGBqcBMgBjhkIvoInP391Gj84dZ8f1ZIoUbH9iLf7vdIfUm2YkL3T2iBmg6rWC76bO4u91GOCnQpezgniaK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB029825EA57103F4FFD0DB57DF5B60MW2PR00MB0298namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a88b3dd0-4232-44c2-ee5c-08d5a57ff11f X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a88b3dd0-4232-44c2-ee5c-08d5a57ff11f X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 22:58:46.5342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0396 Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 22:58:52 -0000 --_000_MW2PR00MB029825EA57103F4FFD0DB57DF5B60MW2PR00MB0298namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gT0sgd2l0aCB0aGlzIGNoYW5nZSwgZ2l2ZW4gaXQgbWFrZXMgdGhlIE9BdXRoIHN1aXRl IG9mIHNwZWNzIG1vcmUgc2VsZi1jb25zaXN0ZW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8 b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50 OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDE4IDg6MTcgQU0NClRvOiBUb3JzdGVuIExvZGRlcnN0 ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBzY3AgY2xhaW0gaW4gZHJhZnQtaWV0Zi1vYXV0aC10 b2tlbi1leGNoYW5nZS0xMg0KDQpUaGUgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBk b2N1bWVudCBtYWtlcyB1c2Ugb2Ygc2NvcGUgYW5kIGF0IHNvbWUgcG9pbnQgaW4gdGhhdCB3b3Jr IGl0IGNhbWUgdG8gbGlnaHQgdGhhdCwgZGVzcGl0ZSB0aGUgY29uY2VwdCBvZiBzY29wZSBiZWlu ZyB1c2VkIGxvdHMgb2YgcGxhY2VzIGVsc2V3aGVyZSwgdGhlcmUgd2FzIG5vIG9mZmljaWFsbHkg cmVnaXN0ZXJlZCBKV1QgY2xhaW0gZm9yIHNjb3BlLiBBcyBhIHJlc3VsdCwgd2UgKHRoZSBXRykg ZGVjaWRlZCB0byBoYXZlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgZGVmaW5lIGFu ZCByZWdpc3RlciBhIEpXVCBjbGFpbSBmb3Igc2NvcGUuIEl0J3Mga2luZCBvZiBhbiBhd2t3YXJk IHBsYWNlIGZvciBpdCByZWFsbHkgYnV0IHRoYXQncyBob3cgaXQgY2FtZSB0byBiZSB0aGVyZS4N CldoZW4gSSBhZGRlZCBpdCB0byB0aGUgZHJhZnQsIEkgb3B0ZWQgZm9yIHRoZSBzZW1pLWNvbnZl bnRpb24gb2YgSldUIHVzaW5nIHRocmVlIGxldHRlciBzaG9ydCBjbGFpbSBuYW1lcy4uIEFuZCBk ZWNpZGVkIHRvIHVzZSBhIEpTT04gYXJyYXkgdG8gY29udmV5IG11bHRpcGxlIHZhbHVlcyByYXRo ZXIgdGhhbiBzcGFjZSBkZWxpbWl0aW5nLiBJdCBzZWVtZWQgbGlrZSBhIGdvb2QgaWRlYSBhdCB0 aGUgdGltZSAtIG1vcmUgY29uc2lzdGVudCB3aXRoIG90aGVyIEpXVCBjbGFpbSBuYW1lcyBhbmQg Y2xlYW5lciB0byB1c2UgdGhlIGZhY2lsaXRpZXMgb2YgSlNPTiByYXRoZXIgdGhhbiBhIGRlbGlt aXRlZCBzdHJpbmcuIFRoYXQgd2FzIHRoZSB0aGlua2luZyBhdCB0aGUgdGltZSBhbnl3YXkgYW5k LCBhcyBJIHJlY2FsbCwgSSBhc2tlZCB0aGUgV0cgYWJvdXQgZG9pbmcgaXQgdGhhdCB3YXkgYXQg b25lIG9mIHRoZSBtZWV0aW5ncyBhbmQgdGhlcmUgd2FzIGdlbmVyYWwsIGlmIHNvbWV3aGF0IGFi c2VudCwgbm9kZGluZyBpbiB0aGUgcm9vbS4NCkxvb2tpbmcgYXQgdGhpcyBhZ2FpbiBpbiB0aGUg Y29udGV4dCBvZiB0aGUgcXVlc3Rpb24gZnJvbSBUb3JzdGVuIGFuZCBoaXMgZGV2ZWxvcGVycywg SSB0aGluayB1c2luZyBhIGRpZmZlcmVudCBuYW1lIGFuZCBzeW50YXggZm9yIHRoZSBKV1QgY2xh aW0gdnMuLiB0aGUgSW50cm9zcGVjdGlvbiByZXNwb25zZSBtZW1iZXIvcGFyYW1ldGVyL2NsYWlt IGlzIHByb2JhYmx5IGEgbWlzdGFrZS4gIFdoaWxlIFJGQyA3NjYyIEludHJvc3BlY3Rpb24gcmVz cG9uc2UgcGFyYW1ldGVycyBhcmVuJ3QgZXhhY3RseSB0aGUgc2FtZSBhcyBKV1QgY2xhaW1zLCB0 aGV5IGFyZSBzaW1pbGFyIGluIG1hbnkgcmVzcGVjdHMuIFNvIGdpdmluZyBjb25zaXN0ZW50IHRy ZWF0bWVudCBhY3Jvc3MgdGhlbSB0byBzb21ldGhpbmcgbGlrZSBzY29wZSBpcw0KVGhlcmVmb3Jl IEkgcHJvcG9zZSB0aGF0IHRoZSBKV1QgY2xhaW0gZm9yIHJlcHJlc2VudGluZyBzY29wZSBpbiBk cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGJlIGNoYW5nZWQgdG8gYmUgY29uc2lzdGVu dCB3aXRoIHRoZSB0cmVhdG1lbnQgb2Ygc2NvcGUgaW4gUkZDIDc2NjIgT0F1dGggMi4wIFRva2Vu IEludHJvc3BlY3Rpb24uIFRoYXQgZWZmZWN0aXZlbHkgbWVhbnMgY2hhbmdpbmcgdGhlIG5hbWUg ZnJvbSAic2NwIiB0byAic2NvcGUiIGFuZCB0aGUgdmFsdWUgZnJvbSBhIEpTT04gYXJyYXkgdG8g YSBzdHJpbmcgZGVsaW1pdGVkIGJ5IHNwYWNlcy4NCkkgcmVhbGl6ZSBpdCdzIGxhdGUgaW4gdGhl IHByb2Nlc3MgdG8gbWFrZSB0aGlzIGNoYW5nZSBidXQgYmVsaWV2ZSBkb2luZyBzbyB3aWxsIHNp Z25pZmljYW50bHkgcmVkdWNlIGNvbmZ1c2lvbiBhbmQgaXNzdWVzIGluIHRoZSBsb25nIHJ1bi4N Cg0KDQoNCg0KDQpPbiBTdW4sIEFwciAxNSwgMjAxOCBhdCAxMDo0MyBBTSwgVG9yc3RlbiBMb2Rk ZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCkkgSeKAmW0gd29uZGVyaW5nIHdoeSBkcmFmdC1p ZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEyIGRlZmluZXMgYSBjbGFpbSDigJ5zY3DigJwgdG8g Y2Fycnkgc2NvcGUgdmFsdWVzIHdoaWxlIFJGQyA3NTkxIGFuZCBSRkMgNzY2MiB1c2UgYSBjbGFp bSDigJ5zY29wZeKAnCBmb3IgdGhlIHNhbWUgcHVycG9zZS4gQXMgZmFyIGFzIEkgdW5kZXJzdGFu ZCB0aGUgdGV4dCwgdGhlIGludGVuc2lvbiBpcyB0byByZXByZXNlbnQgYSBsaXN0IG9mIFJGQzY3 NDkgc2NvcGVzLiBJcyB0aGlzIGNvcnJlY3Q/IFdoYXTigJlzIHRoZSByYXRpb25hbGUgYmVoaW5k Pw0KDQpEaWZmZXJlbnQgY2xhaW0gbmFtZXMgZm9yIHJlcHJlc2VudGluZyBzY29wZSB2YWx1ZXMg Y29uZnVzZSBwZW9wbGUuIEkgcmVhbGl6ZWQgdGhhdCB3aGVuIG9uZSBvZiBvdXIgZGV2ZWxvcGVy cyBwb2ludGVkIG91dCB0aGF0IGRpZmZlcmVuY2UgcmVjZW50bHkuDQoNCmJlc3QgcmVnYXJkcywN ClRvcnN0ZW4uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KQ09O RklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJl IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_MW2PR00MB029825EA57103F4FFD0DB57DF5B60MW2PR00MB0298namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJltIE9LIHdpdGggdGhp cyBjaGFuZ2UsIGdpdmVuIGl0IG1ha2VzIHRoZSBPQXV0aCBzdWl0ZSBvZiBzcGVjcyBtb3JlIHNl bGYtY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxm IE9mIDwvYj4NCkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXBy aWwgMTgsIDIwMTggODoxNyBBTTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAm bHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHNj cCBjbGFpbSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+VGhlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgZG9jdW1lbnQgbWFrZXMg dXNlIG9mIHNjb3BlIGFuZCBhdCBzb21lIHBvaW50IGluIHRoYXQgd29yayBpdCBjYW1lIHRvIGxp Z2h0IHRoYXQsIGRlc3BpdGUgdGhlIGNvbmNlcHQgb2Ygc2NvcGUgYmVpbmcgdXNlZCBsb3RzIG9m IHBsYWNlcyBlbHNld2hlcmUsIHRoZXJlIHdhcyBubyBvZmZpY2lhbGx5DQogcmVnaXN0ZXJlZCBK V1QgY2xhaW0gZm9yIHNjb3BlLiBBcyBhIHJlc3VsdCwgd2UgKHRoZSBXRykgZGVjaWRlZCB0byBo YXZlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgZGVmaW5lIGFuZCByZWdpc3RlciBh IEpXVCBjbGFpbSBmb3Igc2NvcGUuIEl0J3Mga2luZCBvZiBhbiBhd2t3YXJkIHBsYWNlIGZvciBp dCByZWFsbHkgYnV0IHRoYXQncyBob3cgaXQgY2FtZSB0byBiZSB0aGVyZS4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPldoZW4gSSBhZGRlZCBpdCB0byB0aGUgZHJhZnQsIEkgb3B0ZWQgZm9yIHRoZSBzZW1p LWNvbnZlbnRpb24gb2YgSldUIHVzaW5nIHRocmVlIGxldHRlciBzaG9ydCBjbGFpbSBuYW1lcy4u IEFuZCBkZWNpZGVkIHRvIHVzZSBhIEpTT04gYXJyYXkgdG8gY29udmV5IG11bHRpcGxlIHZhbHVl cyByYXRoZXIgdGhhbiBzcGFjZSBkZWxpbWl0aW5nLiBJdCBzZWVtZWQgbGlrZQ0KIGEgZ29vZCBp ZGVhIGF0IHRoZSB0aW1lIC0gbW9yZSBjb25zaXN0ZW50IHdpdGggb3RoZXIgSldUIGNsYWltIG5h bWVzIGFuZCBjbGVhbmVyIHRvIHVzZSB0aGUgZmFjaWxpdGllcyBvZiBKU09OIHJhdGhlciB0aGFu IGEgZGVsaW1pdGVkIHN0cmluZy4gVGhhdCB3YXMgdGhlIHRoaW5raW5nIGF0IHRoZSB0aW1lIGFu eXdheSBhbmQsIGFzIEkgcmVjYWxsLCBJIGFza2VkIHRoZSBXRyBhYm91dCBkb2luZyBpdCB0aGF0 IHdheSBhdCBvbmUgb2YgdGhlIG1lZXRpbmdzDQogYW5kIHRoZXJlIHdhcyBnZW5lcmFsLCBpZiBz b21ld2hhdCBhYnNlbnQsIG5vZGRpbmcgaW4gdGhlIHJvb20uIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5Mb29raW5nIGF0IHRoaXMgYWdhaW4gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHF1ZXN0aW9u IGZyb20gVG9yc3RlbiBhbmQgaGlzIGRldmVsb3BlcnMsIEkgdGhpbmsgdXNpbmcgYSBkaWZmZXJl bnQgbmFtZSBhbmQgc3ludGF4IGZvciB0aGUgSldUIGNsYWltIHZzLi4gdGhlIEludHJvc3BlY3Rp b24gcmVzcG9uc2UgbWVtYmVyL3BhcmFtZXRlci9jbGFpbSBpcyBwcm9iYWJseQ0KIGEgbWlzdGFr ZS4mbmJzcDsgV2hpbGUgUkZDIDc2NjIgSW50cm9zcGVjdGlvbiByZXNwb25zZSBwYXJhbWV0ZXJz IGFyZW4ndCBleGFjdGx5IHRoZSBzYW1lIGFzIEpXVCBjbGFpbXMsIHRoZXkgYXJlIHNpbWlsYXIg aW4gbWFueSByZXNwZWN0cy4gU28gZ2l2aW5nIGNvbnNpc3RlbnQgdHJlYXRtZW50IGFjcm9zcyB0 aGVtIHRvIHNvbWV0aGluZyBsaWtlIHNjb3BlIGlzDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VGhlcmVmb3JlIEkgcHJvcG9zZSB0aGF0IHRoZSBKV1QgY2xhaW0gZm9yIHJlcHJlc2VudGluZyBz Y29wZSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGJlIGNoYW5nZWQgdG8gYmUg Y29uc2lzdGVudCB3aXRoIHRoZSB0cmVhdG1lbnQgb2Ygc2NvcGUgaW4mbmJzcDtSRkMgNzY2MiBP QXV0aCAyLjAgVG9rZW4gSW50cm9zcGVjdGlvbi4gVGhhdCBlZmZlY3RpdmVseQ0KIG1lYW5zIGNo YW5naW5nIHRoZSBuYW1lIGZyb20gJnF1b3Q7c2NwJnF1b3Q7IHRvICZxdW90O3Njb3BlJnF1b3Q7 IGFuZCB0aGUgdmFsdWUgZnJvbSBhIEpTT04gYXJyYXkgdG8gYSBzdHJpbmcgZGVsaW1pdGVkIGJ5 IHNwYWNlcy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSByZWFsaXplIGl0J3MgbGF0ZSBpbiB0aGUgcHJvY2VzcyB0byBtYWtlIHRoaXMgY2hh bmdlIGJ1dCBiZWxpZXZlIGRvaW5nIHNvIHdpbGwgc2lnbmlmaWNhbnRseSByZWR1Y2UgY29uZnVz aW9uIGFuZCBpc3N1ZXMgaW4gdGhlIGxvbmcgcnVuLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBBcHIgMTUsIDIw MTggYXQgMTA6NDMgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0K PGJyPg0KSSBJ4oCZbSB3b25kZXJpbmcgd2h5IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFu Z2UtMTIgZGVmaW5lcyBhIGNsYWltIOKAnnNjcOKAnCB0byBjYXJyeSBzY29wZSB2YWx1ZXMgd2hp bGUgUkZDIDc1OTEgYW5kIFJGQyA3NjYyIHVzZSBhIGNsYWltIOKAnnNjb3Bl4oCcIGZvciB0aGUg c2FtZSBwdXJwb3NlLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSB0ZXh0LCB0aGUgaW50ZW5z aW9uIGlzIHRvIHJlcHJlc2VudCBhIGxpc3Qgb2YgUkZDNjc0OSBzY29wZXMuDQogSXMgdGhpcyBj b3JyZWN0PyBXaGF04oCZcyB0aGUgcmF0aW9uYWxlIGJlaGluZD88YnI+DQo8YnI+DQpEaWZmZXJl bnQgY2xhaW0gbmFtZXMgZm9yIHJlcHJlc2VudGluZyBzY29wZSB2YWx1ZXMgY29uZnVzZSBwZW9w bGUuIEkgcmVhbGl6ZWQgdGhhdCB3aGVuIG9uZSBvZiBvdXIgZGV2ZWxvcGVycyBwb2ludGVkIG91 dCB0aGF0IGRpZmZlcmVuY2UgcmVjZW50bHkuDQo8YnI+DQo8YnI+DQpiZXN0IHJlZ2FyZHMsPGJy Pg0KVG9yc3Rlbi48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVz c2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5 b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_MW2PR00MB029825EA57103F4FFD0DB57DF5B60MW2PR00MB0298namp_-- From nobody Thu Apr 19 06:38:27 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9312D9FF for ; Thu, 19 Apr 2018 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znpiS3dNk-Zs for ; Thu, 19 Apr 2018 06:38:22 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7A012DA00 for ; Thu, 19 Apr 2018 06:38:21 -0700 (PDT) Received: from [79.253.45.21] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f99lS-0002Oz-Al; Thu, 19 Apr 2018 15:38:18 +0200 From: Torsten Lodderstedt Message-Id: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_6A7FC40B-B4F2-4417-91B3-2DCEAD5DBC0A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 15:38:16 +0200 In-Reply-To: Cc: Brian Campbell , oauth To: Mike Jones References: X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 13:38:26 -0000 --Apple-Mail=_6A7FC40B-B4F2-4417-91B3-2DCEAD5DBC0A Content-Type: multipart/alternative; boundary="Apple-Mail=_2105C504-22B2-4508-ADEF-E990E5D751EC" --Apple-Mail=_2105C504-22B2-4508-ADEF-E990E5D751EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 - It will makes thinks much simpler. > Am 19.04.2018 um 00:58 schrieb Mike Jones = : >=20 > I=E2=80=99m OK with this change, given it makes the OAuth suite of = specs more self-consistent. > =20 > -- Mike > =20 > From: OAuth On Behalf Of Brian Campbell > Sent: Wednesday, April 18, 2018 8:17 AM > To: Torsten Lodderstedt > Cc: oauth > Subject: Re: [OAUTH-WG] scp claim in = draft-ietf-oauth-token-exchange-12 > =20 > The draft-ietf-oauth-token-exchange document makes use of scope and at = some point in that work it came to light that, despite the concept of = scope being used lots of places elsewhere, there was no officially = registered JWT claim for scope. As a result, we (the WG) decided to have = draft-ietf-oauth-token-exchange define and register a JWT claim for = scope. It's kind of an awkward place for it really but that's how it = came to be there. >=20 > When I added it to the draft, I opted for the semi-convention of JWT = using three letter short claim names.. And decided to use a JSON array = to convey multiple values rather than space delimiting. It seemed like a = good idea at the time - more consistent with other JWT claim names and = cleaner to use the facilities of JSON rather than a delimited string. = That was the thinking at the time anyway and, as I recall, I asked the = WG about doing it that way at one of the meetings and there was general, = if somewhat absent, nodding in the room. >=20 > Looking at this again in the context of the question from Torsten and = his developers, I think using a different name and syntax for the JWT = claim vs.. the Introspection response member/parameter/claim is probably = a mistake. While RFC 7662 Introspection response parameters aren't = exactly the same as JWT claims, they are similar in many respects. So = giving consistent treatment across them to something like scope is >=20 > Therefore I propose that the JWT claim for representing scope in = draft-ietf-oauth-token-exchange be changed to be consistent with the = treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That = effectively means changing the name from "scp" to "scope" and the value = from a JSON array to a string delimited by spaces. >=20 > I realize it's late in the process to make this change but believe = doing so will significantly reduce confusion and issues in the long run.=20= >=20 > =20 > =20 >=20 > =20 > =20 > On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt = > wrote: > Hi all, >=20 > I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines = a claim =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and = RFC 7662 use a claim =E2=80=9Escope=E2=80=9C for the same purpose. As = far as I understand the text, the intension is to represent a list of = RFC6749 scopes. Is this correct? What=E2=80=99s the rationale behind? >=20 > Different claim names for representing scope values confuse people. I = realized that when one of our developers pointed out that difference = recently.=20 >=20 > best regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_2105C504-22B2-4508-ADEF-E990E5D751EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = - It will makes thinks much simpler.

Am = 19.04.2018 um 00:58 schrieb Mike Jones <Michael.Jones@microsoft.com>:

I=E2=80=99m OK with this change, = given it makes the OAuth suite of specs more self-consistent.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of = Brian Campbell
Sent: Wednesday, April 18, 2018 8:17 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] scp claim in = draft-ietf-oauth-token-exchange-12

 

The = draft-ietf-oauth-token-exchange document makes use of scope and at some = point in that work it came to light that, despite the concept of scope = being used lots of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to = have draft-ietf-oauth-token-exchange define and register a JWT claim for = scope. It's kind of an awkward place for it really but that's how it = came to be there.

When I added = it to the draft, I opted for the semi-convention of JWT using three = letter short claim names.. And decided to use a JSON array to convey = multiple values rather than space delimiting. It seemed like a good idea at the time - more consistent with other JWT claim names = and cleaner to use the facilities of JSON rather than a delimited = string. That was the thinking at the time anyway and, as I recall, I = asked the WG about doing it that way at one of the meetings and there was general, if somewhat absent, nodding in the room.

Looking at this again in the context of = the question from Torsten and his developers, I think using a different = name and syntax for the JWT claim vs.. the Introspection response = member/parameter/claim is probably a mistake.  While RFC 7662 Introspection response parameters = aren't exactly the same as JWT claims, they are similar in many = respects. So giving consistent treatment across them to something like = scope is

Therefore I propose that the JWT claim = for representing scope in draft-ietf-oauth-token-exchange be changed to = be consistent with the treatment of scope in RFC 7662 OAuth 2.0 = Token Introspection. That effectively means changing the name from "scp" to "scope" and the value from a JSON = array to a string delimited by spaces.

I realize it's late in the = process to make this change but believe doing so will significantly = reduce confusion and issues in the long run. 


 

 

 

 

On Sun, Apr 15, 2018 at 10:43 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi = all,

I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a = claim =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC = 7662 use a claim =E2=80=9Escope=E2=80=9C for the same purpose. As far as = I understand the text, the intension is to represent a list of RFC6749 = scopes. Is this correct? What=E2=80=99s the rationale behind?

Different claim names for representing scope values confuse people. I = realized that when one of our developers pointed out that difference = recently.

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may = contain confidential and privileged material for the sole use of the = intended recipient(s). Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.


= --Apple-Mail=_2105C504-22B2-4508-ADEF-E990E5D751EC-- --Apple-Mail=_6A7FC40B-B4F2-4417-91B3-2DCEAD5DBC0A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNDE5MTMzODE3WjAjBgkqhkiG9w0BCQQxFgQU0fTuEKFyhK/b w36Tpirg4w+UCJUwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBADJf4HDGzlgJaWggJspgwu0Xq5WFxcIPb7JW0npUvpARd9lf26QG 0eatZ4WRxgJEDNNkqUeTi22oW3DeQeiv6H5ZCLaGP2hSGDlvh6CoF6d9VRU7H1FlX093UdwXm9HW 5XbuBe+jM4RDBFg9+USqQgS2WtLLQEw3Bbnm3OpMulwZk5AzlfA7slhYErRNDLon+Y9K0AezEFJf 7lABpf8PJNx+nZq5gtoRmQMg5skMRg4MAHdo0fv0BEF7gfxC/k8BvtcPvcrBl1D0ayhtJqtThCjl YO/YxOVkj3oUlIUvRr2vP0QzMLv1MiW2phg0gp8n5C4lqfHYBXkw08TP3MCCnKgAAAAAAAA= --Apple-Mail=_6A7FC40B-B4F2-4417-91B3-2DCEAD5DBC0A-- From nobody Thu Apr 19 07:57:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199FE12741D for ; Thu, 19 Apr 2018 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUZf_EwnArbG for ; Thu, 19 Apr 2018 07:57:47 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3465E126DFF for ; Thu, 19 Apr 2018 07:57:47 -0700 (PDT) X-AuditID: 12074424-eb9ff700000039e1-e8-5ad8ae682d3f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 18.7F.14817.86EA8DA5; Thu, 19 Apr 2018 10:57:45 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w3JEvg2o015595; Thu, 19 Apr 2018 10:57:43 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3JEvdsS021314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Apr 2018 10:57:41 -0400 Date: Thu, 19 Apr 2018 09:57:39 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: Neil Madden , oauth Message-ID: <20180419145738.GO54168@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <20180417141329.GS54168@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrJu57kaUwdcVYhar/99ktJgz7xeb xcm3r9gcmD1utC1g9Fiy5CeTx92jF1kCmKO4bFJSczLLUov07RK4MtpP/2IpaLvCWHHu/HK2 Bsatyxm7GDk5JARMJGYdvcjcxcjFISSwmEmiZ8MWFghnI6NE29FmJgjnKpPE9Y+v2EFaWARU JU6uuwxmswmoSDR0X2YGsUUE9CVuP50DFGfnYBZwluj3B4kKC1hInHr0gwnE5gVadn43RLWQ wDtmiaZXqhBxQYmTM5+wgNjMAuoSf+ZdAqrhALKlJZb/44AIy0s0b50N1sopECix6vgGsPtF BZQl9vYdYp/AKDgLyaRZSCbNQpg0C8mkBYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIz S/RSU0o3MYJCnd1FZQdjd4/3IUYBDkYlHt4dgdejhFgTy4orcw8xSnIwKYnyHpt8I0qILyk/ pTIjsTgjvqg0J7X4EKMEB7OSCK93O1CONyWxsiq1KB8mJc3BoiTOu3j/3ighgfTEktTs1NSC 1CKYrAwHh5IEb/FaoEbBotT01Iq0zJwShDQTByfIcB6g4TEgNbzFBYm5xZnpEPlTjJYc05b1 9DBzzHsJIr9t/93DLMSSl5+XKiXOGwvSIADSkFGaBzcTlLoksvfXvGIUB3pRmLcOpIoHmPbg pr4CWsgEtNBABWxhSSJCSqqBsSDIbjHzn+7OW++/Mx94ksO66vq7wytqkhSSGVdtqJILdRAz 2FG/bllsxBeF6zMWzvWZFfZ/40Thvm2n87VOT8lY+Cvnwi3Dw2vOTG5saZqWbxKyZJ1ZgZHz S6HTnIydS8NtPHepX12TqFC89h+LlWmnzaklN27uUzUul3XSOPT85My8F90V/UosxRmJhlrM RcWJAGcBgXU4AwAA Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 14:57:51 -0000 I would go ahead and put them in. The blog post might get some pushback, but I think there's plenty of precedent for academic papers. -Ben On Wed, Apr 18, 2018 at 09:34:23AM -0600, Brian Campbell wrote: > Thanks for the text, Neil. And the nit on the text, Ben. I'll include it in > the next draft. > > Ben, bit of a procedural question for you: can or should I include those > references (https://www.cryptologie.net/article/374/common-x509-certificate- > validationcreation-pitfalls/ & http://www.cs.utexas.edu/~ > shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as > informational? Or? I'm honestly not sure if it's okay to cite a blog post > or university paper. > > > > > > > > On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk wrote: > > > Picking nits, but maybe "established and well-tested X.509 library > > (such as one used by an established TLS library)", noting that TLS > > 1.3 has added a new protocol feature that allows for TLS and X.509 > > library capabilities to be separately indicated (as would be needed > > if they were organizationally separate). > > > > -Ben > > > > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote: > > > OK, here’s a stab at a new security considerations section on X.509 > > parsing and validation: > > > > > > --- > > > 5.3 X.509 Certificate Parsing and Validation Complexity > > > > > > Parsing and validation of X.509 certificates and certificate chains is > > complex and implementation mistakes have previously exposed security > > vulnerabilities. Complexities of validation include (but are not limited > > to) [1][2][3]: > > > - checking of Basic Constraints, basic and extended Key Usage > > constraints, validity periods, and critical extensions; > > > - handling of null-terminator bytes and non-canonical string > > representations in subject names; > > > - handling of wildcard patterns in subject names; > > > - recursive verification of certificate chains and checking certificate > > revocation. > > > For these reasons, implementors SHOULD use an established and > > well-tested TLS library for validation of X.509 certificate chains and > > SHOULD NOT attempt to write their own X.509 certificate validation > > procedures. > > > > > > [1] https://www.cryptologie.net/article/374/common-x509-certificate- > > validationcreation-pitfalls/ > article/374/common-x509-certificate-validationcreation-pitfalls/> > > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf < > > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf> > > > [3] https://tools.ietf.org/html/rfc5280 > rfc5280> > > > > > > --- > > > > > > NB - this blog post [1] is the best concise summary of attacks I could > > find. Most of these attacks have been published as Black Hat talks and I > > can’t seem to find definitive references or good survey papers (beyond [2], > > which is a little older). > > > > > > Let me know what you think, > > > > > > Neil > > > > > > > > > > On 12 Apr 2018, at 20:42, Brian Campbell > > wrote: > > > > > > > > Thanks Neil. > > > > > > > > Other than the potential metadata changes, which I'd like more WG > > input on and may raise in a new thread, I think I've got enough to make > > updates addressing your comments. But please do send text for that > > Security Considerations bit, if you come up with something. > > > > > > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden < > > neil.madden@forgerock.com > wrote: > > > > Hi Brian, > > > > > > > > Thanks for the detailed responses. Comments in line below (marked with > > ***). > > > > > > > > Neil > > > > > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > > bcampbell@pingidentity.com > wrote: > > > > Thanks for the review and feedback, Neil. I apologize for my being > > slow to respond. As I said to Justin recently < > > https://mailarchive.ietf.org/arch/msg/oauth/cNmk8fSuxp37L-z8Rvr6_EnyCug>, > > I've been away from things for a while. Also there's a lot here to get > > through so took me some time. > > > > > > > > It looks like John touched on some of your comments but not all. I'll > > try and reply to them as best I can inline below. > > > > > > > > > > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden < > > neil.madden@forgerock.com > wrote: > > > > Hi, > > > > > > > > I have reviewed this draft and have a number of comments, below. > > ForgeRock have not yet implemented this draft, but there is interest in > > implementing it at some point. (Disclaimer: We have no firm commitments on > > this at the moment, I do not speak for ForgeRock, etc). > > > > > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 < > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1> defines > > a new confirmation method “x5t#S256”. However, there is already a > > confirmation method “jwk” that can contain a JSON Web Key, which itself can > > contain a “x5t#S526” claim with exactly the same syntax and semantics. The > > draft proposes: > > > > > > > > { “cnf”: { “x5t#S256”: “…” } } > > > > > > > > but you can already do: > > > > > > > > { “cnf”: { “jwk”: { … , “x5t#S256”: “…” } } } > > > > > > > > If the intent is just to save some space and avoid the mandatory > > fields of the existing JWK types, maybe this would be better addressed by > > defining a new JWK type which only has a thumbprint? e.g., { “kty”: “x5t”, > > “x5t#S256”: “…” }. > > > > > > > > The intent of the x5t#S256 confirmation method was to be space > > efficient and straightforward while utilizing the framework and registry > > that RFC 7800 gives. Even a new JWK type like that would still use more > > space. And I'd argue that the new confirmation method is considerably more > > straightforward than registering a new JWK type (and the implications that > > would have on JWK implementations in general) in order to use the existing > > "jwk" confirmation method. > > > > > > > > *** > > > > OK, that is reasonable. Given that the draft says SHOULD rather than > > MUST for using this confirmation key method, I think it is currently > > allowed to use either representation. > > > > > > > > > > > > > > > > 2. I find the naming “mutual TLS” and “mTLS” a bit of a misnomer: it’s > > really only the client authentication that we are interested here, and the > > fact that the server also authenticates with a certificate is not hugely > > relevant to this particular spec (although it is to the overall security of > > OAuth). Also, TLS defines non-certificate based authentication mechanisms > > (e.g. TLS-SRP extension for password authenticated key exchange, PSK for > > pre-shared key authentication) and even non-X.509 certificate types ( > > https://www.iana.org/assignments/tls-extensiontype- > > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 < > > https://www.iana.org/assignments/tls-extensiontype- > > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3>). I’d > > prefer that the draft explicitly referred to “X.509 Client Certificate > > Authentication” rather than mutual TLS, and changed identifiers like > > ‘tls_client_auth’ (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07# > > section-2.1.1 > section-2.1.1>) to something more explicit like > > ‘tls_x509_pki_client_auth’. > > > > > > > > This is especially confusing in section 3 on sender constrained access > > tokens, as there are two different servers involved: the AS and the > > protected resource server, but there is no “mutual” authentication between > > them, only between each of them and the client. > > > > > > > > Choosing names and terminology is difficult and the "right" wording is > > often subjective. I believe that the current wording sufficiently conveys > > what is going on in the draft to most readers. Most readers thus far seem > > to agree. There is some text now that does say that the mutual auth in the > > draft is in fact X.509 client cert authn but, in the next revision, I'll > > look for other opportunities where it could be stated more clearly. > > > > > > > > *** Thanks. > > > > > > > > > > > > > > > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 > > RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The > > wording in Section 5.1 doesn’t seem clear if this could also be used with > > TLS 1.0 or 1.1, or whether it is only referring to future TLS versions. > > > > > > > > The reference to BCP 195 (which unfortunately the original OAuth 2.0 > > RFC doesn't have because it didn't exist then) is meant to account for > > changing versions and recommendations around TLS. Currently that BCP says > > TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't outright > > prohibit them. > > > > > > > > *** OK, that seems good to me. > > > > > > > > > > > > > > > > 4. It might be useful to have a discussion for implementors of whether > > TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact the > > use of client certificates, if at all? > > > > > > > > That might well be useful but I don't myself know what it would say. > > I've (maybe naively) figured those are deployment details that will just > > work out. Perhaps you could propose some text around such a discussion that > > the WG could consider? > > > > > > > > *** > > > > To be honest, when I raised this it was because I didn’t really know > > what the implications were. I’ve done some reading around and I think it > > should all just work - both session resumption and PSK-based resumption > > preserve the original client and server authentication context so we can > > assume that any presented client cert is still valid for the resumed > > session. So I think we can leave out any discussion of this and assume it > > works as expected. > > > > > > > > > > > > > > > > 5. Section 3 defines sender-constrained access tokens in terms of the > > confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 > > Pop Architecture draft defines sender constraint and key confirmation as > > different things (https://tools.ietf.org/html/draft-ietf-oauth-pop- > > architecture-08#section-6.2 > draft-ietf-oauth-pop-architecture-08#section-6.2>). The draft should > > decide which of those it is implementing and if sender constraint is > > intended, then reusing the confirmation key claims seems misleading. (I > > think this mTLS draft is doing key confirmation so should drop the language > > about sender constrained tokens). > > > > > > > > I will say again that choosing names and terminology is difficult... > > > > > > > > Although I must admit that I started using "sender constrained" > > somewhat indiscriminately at first and it's just sort of stuck. At the time > > I was trying to incorporate bits of draft-sakimura-oauth-jpop in a way that > > might help bring on and keep the authors of that draft onboard with this > > mtls draft. In retrospect it looks like I did that part wrong anyway. But > > that was the thinking at the time and the history, for whatever it's worth. > > More recently, Nat was requesting that "sender constrained" be included in > > the title. So there's that too. > > > > > > > > In defense of my mistake, however, if there's a line between "sender > > constrained" and "key confirmation" tokens, it's a bit of a fuzzy line. And > > I'd argue that what this draft is doing pretty close to the line. > > > > > > > > But ultimately I think you are right that what this mtls draft is > > doing with access tokens is more accurately described with the key > > confirmation term. > > > > > > > > So, yes, the draft should probably drop (or at least minimize) the > > language about sender constrained. I'll do that in the next draft version, > > barring big objections from the WG. > > > > > > > > The tricky thing with making that change is that there a client and > > server metadata parameters with the name "mutual_tls_sender_constrained_access_tokens" > > that should probably also change. But that would be a breaking change (of > > sorts anyway), which shouldn't be taken lightly at this stage. I feel that > > some explicit okays from the WG are needed before doing so (rough consensus > > stye) . Any WG members want to weigh in here and help get a "sense of the > > group" concerning changing those metadata names? > > > > > > > > *** Thanks. I agree this might cause compatibility issues. It is not a > > big issue for us, but might cause some confusion. > > > > > > > > > > > > > > > > 6. The OAuth 2.0 PoP Architecture draft says ( > > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-5 > > > architecture-08#section-5>): > > > > > > > > Strong, fresh session keys: > > > > > > > > Session keys MUST be strong and fresh. Each session > > deserves an > > > > independent session key, i.e., one that is generated > > specifically > > > > for the intended use. In context of OAuth this means > > that keying > > > > material is created in such a way that can only be > > used by the > > > > combination of a client instance, protected resource, > > and > > > > authorization scope. > > > > > > > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/ > > draft-ietf-oauth-mtls-07#section-3 > draft-ietf-oauth-mtls-07#section-3>) says: > > > > > > > > The client makes protected resource requests as described in > > > > [RFC6750], however, those requests MUST be made over a mutually > > > > authenticated TLS connection using the same certificate that > > was used > > > > for mutual TLS at the token endpoint. > > > > > > > > These two statements are contradictory: the OAuth 2.0 PoP architecture > > effectively requires a fresh key-pair to be used for every access token > > request, whereas this draft proposes reusing the same long-lived client > > certificate for every single access token and every resource server. > > > > > > > > In the self-signed case (and even in the CA case, with a bit of work - > > e.g., https://www.vaultproject.io/docs/secrets/pki/index.html < > > https://www.vaultproject.io/docs/secrets/pki/index.html>) it is perfectly > > possible for the client to generate a fresh key-pair for each access token > > and include the certificate on the token request (e.g., as per > > https://tools.ietf.org/html/draft-ietf-oauth-pop-key- > > distribution-03#section-5.1 > draft-ietf-oauth-pop-key-distribution-03#section-5.1> - in which case an > > appropriate “alg” value should probably be described). This should probably > > at least be an option. > > > > > > > > This draft doesn't necessarily seek to align with the (long expired) > > PoP architecture draft. Rather it is aiming to provide a pragmatic > > solution for PoP style access tokens and OAuth client auth using mTLS > > client certificates. > > > > > > > > That said, with the current draft, it's certainly possible for a > > client to update its cert more frequently, even so far as using a new one > > for each access token. The details of how that would work will vary some > > based on the token endpoint authentication method. But it's not precluded. > > > > > > > > *** You are right, the text doesn’t preclude that. I am happy with > > that solution. I suspect most people will deploy and be happy with reusing > > a long-lived cert for every access token, so this may not matter in > > practice. > > > > > > > > > > > > 7. The use of a single client certificate with every resource server > > (RS) should be called out in a Privacy Considerations section, as it allows > > correlation of activity. > > > > > > > > Practically speaking the access tokens being presented likely already > > have correlatable info in them about the client as well as the user. I > > don't know that there's much of a (new) concern in reality. If you feel > > this concern is unique and import enough though, perhaps there's some text > > you'd like to propose for a Privacy Considerations section that the WG > > could consider? I mean, I guess it doesn't hurt to mention it but I would > > like to avoid overstating the issue. > > > > > > > > *** On reflection, I am going to withdraw this comment. As you say > > there are other ways to correlate clients. The privacy issue would mainly > > arise in the context of dynamic client registration e.g., a pattern I’ve > > seen described where every instance of a mobile app does dynamic client > > registration to avoid including credentials directly in the app bundle. > > This would make clients one-to-one with users. But (a) those apps are > > fairly unlikely to be using TLS certs, and (b) that is more of a privacy > > consideration for dynamic client registration rather than this draft. > > > > > > > > > > > > > > > > 8. This is maybe a more general point, but RFC 6750 defines the > > Authorization: Bearer scheme (https://tools.ietf.org/html/ > > rfc6750#section-2 ) for a > > client to communicate it’s access token to the RS in a standard way. As > > sender-constrained access tokens are not strictly bearer tokens any more, > > should this draft also register a new scheme for that? Should there be a > > generic PoP scheme? > > > > > > > > The thinking and general consensus (in this draft as well as the OAuth > > token binding work) has been that continuing to use the RFC 6750 scheme > > while putting the "not strictly bearer" stuff in (or referenced by) the > > token itself will be easier on deployment and implementation. And better > > for adoption as a result. I believe some early implementation work has > > borne that out too. > > > > > > > > *** OK. > > > > > > > > > > > > 9. The Security Considerations should really make some mention of the > > long history of attacks against X.509 certificate chain validation, e.g. > > failure to check the “CA” bit in the basic constraints, errors in parsing > > DNs, etc. It should be strongly suggested to use an existing TLS library to > > perform these checks rather than implementing your own checks. This relates > > to Justin’s comments around DN parsing and normalisation. > > > > > > > > Suggesting to use an existing TLS library is certainly sound advice > > and I sort of felt is implied in the draft. But saying so more > > strongly/explicitly might be worthwhile. And pointing to historical > > reasons to do so would probably be good too. Could you propose a new > > Security Considerations section or maybe augmentation of §5.2 with that > > content? > > > > > > > > *** I’ll try and come up with some text. > > > > > > > > > > > > > > > > 10. The PKI client authentication method (https://tools.ietf.org/html/ > > draft-ietf-oauth-mtls-07#section-2.1 > draft-ietf-oauth-mtls-07#section-2.1>) makes no mention at all of > > certificate revocation and how to handle checking for that (CRLs, OCSP - > > with stapling?). Neither does the Security Considerations. If this is a > > detail to be agreed between then AS and the CA (or just left up to the AS > > TLS stack) then that should perhaps be made explicit. Again, there are > > privacy considerations with some of these mechanisms, as OCSP requests are > > typically sent in the clear (plain HTTP) and so allow an observer to see > > which clients are connecting to which AS. > > > > > > > > I didn't think that a TLS client could do OCSP stapling? > > > > > > > > *** I think you are right about this. I always assumed it was > > symmetric (and I think it technically could work), but the spec only talks > > about stapling in the server-side of the handshake. > > > > > > > > That aside, revocation checking (how and even if) is something that's > > at the discretion of the AS. I can add something in §2.1 to say that more > > explicitly. > > > > > > > > *** Thanks. > > > > > > > > > > > > > > > > 11. The same comment applies to how the protected resource checks for > > revocation of the certificate presented during sender constrained access > > token usage. Should the RS make its own revocation checks based on the > > information in the certificate presented, or should it trust the > > certificate while the access token is still valid? If the latter case, is > > the AS responsible for revoking any access tokens whose certificate have > > been revoked (if so, should it be doing an OCSP call on every token > > introspection request, and should the RS be passing on the > > certificate/serial number on that request)? If the Client request uses OCSP > > Stapling (https://en.wikipedia.org/wiki/OCSP_stapling < > > https://en.wikipedia.org/wiki/OCSP_stapling>) how can the RS verify the > > signature on that if it does not have a separate trust relationship with > > the CA already? > > > > > > > > The draft effectively uses cert mtls at the RS as a > > proof-of-possession method only and not as authentication. So revocation > > checking isn't really applicable. In specific deployment situations, I > > suppose an RS could check revocation. But that'd be a deployment decision > > for the RS that's beyond the scope of this draft. > > > > > > > > *** OK, that is an interesting observation. If either the client or AS > > suspect the key has been compromised they can revoke the access token(s) > > instead. > > > > > > > > > > > > > > > > 12. The use of only SHA-256 fingerprints means that the security > > strength of the sender-constrained access tokens is limited by the > > collision resistance of SHA-256 - roughly “128-bit security" - without a > > new specification for a new thumbprint algorithm. An implication of this is > > that is is fairly pointless for the protected resource TLS stack to ever > > negotiate cipher suites/keys with a higher level of security. In more > > crystal ball territory, if a practical quantum computer becomes a > > possibility within the lifetime of this spec, then the expected collision > > resistance of SHA-256 would drop quadratically, allowing an attacker to > > find a colliding certificate in ~2^64 effort. If we are going to pick just > > one thumbprint hash algorithm, I would prefer we pick SHA-512. > > > > > > > > The idea behind haveing just one thumbprint hash algorithm was to keep > > things simple. And SHA-256 seems good enough for the reasonably foreseeable > > future (and space aware). Also a new little spec to register a different > > hash algorithm, should the need arise, didn't seem particularity onerous. > > > > > > > > That was the thinking anyway. Maybe it is too short sighted though? > > > > > > > > I do think SHA-256 should stay regardless. > > > > > > > > But the draft could also define SHA-512 (and maybe others). What do > > you and WG folks think about that? > > > > > > > > *** Yes please. > > > > > > > > It would probably then be useful for the metadata in §3.3 and §3.4 to > > change from just boolean values to something to convey what hash alg/cnf > > method the client expects and the list of what the server supports. That's > > maybe something that should be done anyway. That'd be a breaking change to > > the metadata. But there's already another potential breaking change > > identified earlier in this message. So maybe it's worth doing... > > > > > > > > How do folks feel about making this kind of change? > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Neil > > > > > > > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > > wrote: > > > > > > > > > > All, > > > > > > > > > > As discussed during the meeting today, we are starting a WGLC on the > > MTLS document: > > > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 < > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07> > > > > > > > > > > Please, review the document and provide feedback on any issues you > > see with the document. > > > > > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > > > > > Regards, > > > > > Rifaat and Hannes > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth < > > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth < > > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibited. > > If you have received this communication in error, please notify the sender > > immediately by e-mail and delete the message and any file attachments from > > your computer. Thank you. > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibited. > > If you have received this communication in error, please notify the sender > > immediately by e-mail and delete the message and any file attachments from > > your computer. Thank you. > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.  If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ From nobody Thu Apr 19 08:03:44 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14C124235 for ; Thu, 19 Apr 2018 08:03:42 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv8BoH0iK8sZ for ; Thu, 19 Apr 2018 08:03:36 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21925124D68 for ; Thu, 19 Apr 2018 08:03:36 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d6-v6so6979464iog.1 for ; Thu, 19 Apr 2018 08:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CXAx2TG0UaUOrh66SUJDU+iLC29nBFFHWXHFCzXHGb4=; b=QCvbG7zcPRMiIS7drcM2+dLa+kuXjISit4cFJ8IZU0IltJFBbNVIjgol6Yxkvms9+f J4odgPZiAbbIgOyvcKPeJHghIVLFz4y6ODO3glqeQ6FtUCxflN13c2ls6GjoNkf3LFCn UjEUI29hMCybVaz0XC0/dOR4J4NuuEdiFnXcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CXAx2TG0UaUOrh66SUJDU+iLC29nBFFHWXHFCzXHGb4=; b=pQl3NtHXAe6/1yW0wiPErNOTkpBn3tXa/3Su+dkFH+rfbB1oM/nCAwIuImHPoV6aHS 6QVOfnXyfWOfDo+Tw046vP+Y+6ZU3rcho09MmZFRKWwMLaaZTiReE68jow057pH5S38H GKX/HsW3of18koFvdQdT90qIfZ2iVY4CvGotqzacM5yBqlkB1/NVDvKNJccd9B7CmTd4 TMGDm4S6tl4z8nPwTAnRY7q8MWdGy9X96+BRwMGGLsTz7hRhxrRoCYn/eMDCd/LBhrBW L19JKn3KLiGNYYBi3JKfndnrorVoLjLwNGwtk0j4BgzOGz9Y7a/4M5Wn3HCWvUQ7nPI/ nFVQ== X-Gm-Message-State: ALQs6tBxeZzwFnA6rb2jxMPJ1Cy3MzPQRTlZc9GfEfY0y9GvLDCzeHom RDfpNF5HjWsN8m1msz0CAF4QiaIZ/7BZzq14QHhgqehLhJAWGu7YHUf5a1U4uhhLBxDv6XgggIX AuZLD/aJ+d2b0Uw== X-Google-Smtp-Source: AB8JxZp/nUl03EzTcoAi7PLF36unawrhU/D9lplMLpIkTew/WEQ8UwCs9Oyw74MWHQn1YemhnzNKw9t7HuiKvjK+II4= X-Received: by 2002:a6b:1458:: with SMTP id 85-v6mr6458841iou.218.1524150215009; Thu, 19 Apr 2018 08:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 08:03:04 -0700 (PDT) In-Reply-To: <20180419145738.GO54168@kduck.kaduk.org> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <20180417141329.GS54168@kduck.kaduk.org> <20180419145738.GO54168@kduck.kaduk.org> From: Brian Campbell Date: Thu, 19 Apr 2018 09:03:04 -0600 Message-ID: To: Benjamin Kaduk Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="0000000000002680c9056a34e015" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 15:03:42 -0000 --0000000000002680c9056a34e015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. Will do. On Thu, Apr 19, 2018 at 8:57 AM, Benjamin Kaduk wrote: > I would go ahead and put them in. The blog post might get some > pushback, but I think there's plenty of precedent for academic > papers. > > -Ben > > On Wed, Apr 18, 2018 at 09:34:23AM -0600, Brian Campbell wrote: > > Thanks for the text, Neil. And the nit on the text, Ben. I'll include i= t > in > > the next draft. > > > > Ben, bit of a procedural question for you: can or should I include thos= e > > references (https://www.cryptologie.net/article/374/common-x509- > certificate- > > validationcreation-pitfalls/ & http://www.cs.utexas.edu/~ > > shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as > > informational? Or? I'm honestly not sure if it's okay to cite a blog po= st > > or university paper. > > > > > > validationcreation-pitfalls/> > > > > > > > > > > On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk wrote: > > > > > Picking nits, but maybe "established and well-tested X.509 library > > > (such as one used by an established TLS library)", noting that TLS > > > 1.3 has added a new protocol feature that allows for TLS and X.509 > > > library capabilities to be separately indicated (as would be needed > > > if they were organizationally separate). > > > > > > -Ben > > > > > > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote: > > > > OK, here=E2=80=99s a stab at a new security considerations section = on X.509 > > > parsing and validation: > > > > > > > > --- > > > > 5.3 X.509 Certificate Parsing and Validation Complexity > > > > > > > > Parsing and validation of X.509 certificates and certificate chains > is > > > complex and implementation mistakes have previously exposed security > > > vulnerabilities. Complexities of validation include (but are not > limited > > > to) [1][2][3]: > > > > - checking of Basic Constraints, basic and extended Key Usage > > > constraints, validity periods, and critical extensions; > > > > - handling of null-terminator bytes and non-canonical string > > > representations in subject names; > > > > - handling of wildcard patterns in subject names; > > > > - recursive verification of certificate chains and checking > certificate > > > revocation. > > > > For these reasons, implementors SHOULD use an established and > > > well-tested TLS library for validation of X.509 certificate chains an= d > > > SHOULD NOT attempt to write their own X.509 certificate validation > > > procedures. > > > > > > > > [1] https://www.cryptologie.net/article/374/common-x509-certificate= - > > > validationcreation-pitfalls/ > > article/374/common-x509-certificate-validationcreation-pitfalls/> > > > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf < > > > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf> > > > > [3] https://tools.ietf.org/html/rfc5280 < > https://tools.ietf.org/html/ > > > rfc5280> > > > > > > > > --- > > > > > > > > NB - this blog post [1] is the best concise summary of attacks I > could > > > find. Most of these attacks have been published as Black Hat talks an= d > I > > > can=E2=80=99t seem to find definitive references or good survey paper= s (beyond > [2], > > > which is a little older). > > > > > > > > Let me know what you think, > > > > > > > > Neil > > > > > > > > > > > > > On 12 Apr 2018, at 20:42, Brian Campbell < > bcampbell@pingidentity.com> > > > wrote: > > > > > > > > > > Thanks Neil. > > > > > > > > > > Other than the potential metadata changes, which I'd like more WG > > > input on and may raise in a new thread, I think I've got enough to ma= ke > > > updates addressing your comments. But please do send text for that > > > Security Considerations bit, if you come up with something. > > > > > > > > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden < > > > neil.madden@forgerock.com > wrote: > > > > > Hi Brian, > > > > > > > > > > Thanks for the detailed responses. Comments in line below (marked > with > > > ***). > > > > > > > > > > Neil > > > > > > > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell < > > > bcampbell@pingidentity.com > wrote= : > > > > > Thanks for the review and feedback, Neil. I apologize for my bein= g > > > slow to respond. As I said to Justin recently < > > > https://mailarchive.ietf.org/arch/msg/oauth/cNmk8fSuxp37L- > z8Rvr6_EnyCug>, > > > I've been away from things for a while. Also there's a lot here to ge= t > > > through so took me some time. > > > > > > > > > > It looks like John touched on some of your comments but not all. > I'll > > > try and reply to them as best I can inline below. > > > > > > > > > > > > > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden < > > > neil.madden@forgerock.com > wrote: > > > > > Hi, > > > > > > > > > > I have reviewed this draft and have a number of comments, below. > > > ForgeRock have not yet implemented this draft, but there is interest = in > > > implementing it at some point. (Disclaimer: We have no firm > commitments on > > > this at the moment, I do not speak for ForgeRock, etc). > > > > > > > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07# > section-3.1 < > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1> > defines > > > a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there = is already a > > > confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON Web= Key, which > itself can > > > contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same synt= ax and semantics. > The > > > draft proposes: > > > > > > > > > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D } } > > > > > > > > > > but you can already do: > > > > > > > > > > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2= =80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } > > > > > > > > > > If the intent is just to save some space and avoid the mandatory > > > fields of the existing JWK types, maybe this would be better addresse= d > by > > > defining a new JWK type which only has a thumbprint? e.g., { =E2=80= =9Ckty=E2=80=9D: > =E2=80=9Cx5t=E2=80=9D, > > > =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }. > > > > > > > > > > The intent of the x5t#S256 confirmation method was to be space > > > efficient and straightforward while utilizing the framework and > registry > > > that RFC 7800 gives. Even a new JWK type like that would still use > more > > > space. And I'd argue that the new confirmation method is considerably > more > > > straightforward than registering a new JWK type (and the implications > that > > > would have on JWK implementations in general) in order to use the > existing > > > "jwk" confirmation method. > > > > > > > > > > *** > > > > > OK, that is reasonable. Given that the draft says SHOULD rather > than > > > MUST for using this confirmation key method, I think it is currently > > > allowed to use either representation. > > > > > > > > > > > > > > > > > > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmT= LS=E2=80=9D a bit of a misnomer: > it=E2=80=99s > > > really only the client authentication that we are interested here, an= d > the > > > fact that the server also authenticates with a certificate is not > hugely > > > relevant to this particular spec (although it is to the overall > security of > > > OAuth). Also, TLS defines non-certificate based authentication > mechanisms > > > (e.g. TLS-SRP extension for password authenticated key exchange, PSK > for > > > pre-shared key authentication) and even non-X.509 certificate types ( > > > https://www.iana.org/assignments/tls-extensiontype- > > > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 < > > > https://www.iana.org/assignments/tls-extensiontype- > > > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3>). > I=E2=80=99d > > > prefer that the draft explicitly referred to =E2=80=9CX.509 Client Ce= rtificate > > > Authentication=E2=80=9D rather than mutual TLS, and changed identifie= rs like > > > =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/ > draft-ietf-oauth-mtls-07# > > > section-2.1.1 > > section-2.1.1>) to something more explicit like > > > =E2=80=98tls_x509_pki_client_auth=E2=80=99. > > > > > > > > > > This is especially confusing in section 3 on sender constrained > access > > > tokens, as there are two different servers involved: the AS and the > > > protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D a= uthentication > between > > > them, only between each of them and the client. > > > > > > > > > > Choosing names and terminology is difficult and the "right" > wording is > > > often subjective. I believe that the current wording sufficiently > conveys > > > what is going on in the draft to most readers. Most readers thus far > seem > > > to agree. There is some text now that does say that the mutual auth i= n > the > > > draft is in fact X.509 client cert authn but, in the next revision, > I'll > > > look for other opportunities where it could be stated more clearly. > > > > > > > > > > *** Thanks. > > > > > > > > > > > > > > > > > > > > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2= .0 > > > RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is > required? The > > > wording in Section 5.1 doesn=E2=80=99t seem clear if this could also = be used > with > > > TLS 1.0 or 1.1, or whether it is only referring to future TLS version= s. > > > > > > > > > > The reference to BCP 195 (which unfortunately the original OAuth > 2.0 > > > RFC doesn't have because it didn't exist then) is meant to account fo= r > > > changing versions and recommendations around TLS. Currently that BCP > says > > > TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn't outright > > > prohibit them. > > > > > > > > > > *** OK, that seems good to me. > > > > > > > > > > > > > > > > > > > > 4. It might be useful to have a discussion for implementors of > whether > > > TLS session resumption (and PSK in TLS 1.3) and/or renegotiation > impact the > > > use of client certificates, if at all? > > > > > > > > > > That might well be useful but I don't myself know what it would > say. > > > I've (maybe naively) figured those are deployment details that will > just > > > work out. Perhaps you could propose some text around such a discussio= n > that > > > the WG could consider? > > > > > > > > > > *** > > > > > To be honest, when I raised this it was because I didn=E2=80=99t = really > know > > > what the implications were. I=E2=80=99ve done some reading around and= I think > it > > > should all just work - both session resumption and PSK-based resumpti= on > > > preserve the original client and server authentication context so we > can > > > assume that any presented client cert is still valid for the resumed > > > session. So I think we can leave out any discussion of this and assum= e > it > > > works as expected. > > > > > > > > > > > > > > > > > > > > 5. Section 3 defines sender-constrained access tokens in terms of > the > > > confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth > 2.0 > > > Pop Architecture draft defines sender constraint and key confirmation > as > > > different things (https://tools.ietf.org/html/draft-ietf-oauth-pop- > > > architecture-08#section-6.2 > > draft-ietf-oauth-pop-architecture-08#section-6.2>). The draft should > > > decide which of those it is implementing and if sender constraint is > > > intended, then reusing the confirmation key claims seems misleading. = (I > > > think this mTLS draft is doing key confirmation so should drop the > language > > > about sender constrained tokens). > > > > > > > > > > I will say again that choosing names and terminology is > difficult... > > > > > > > > > > Although I must admit that I started using "sender constrained" > > > somewhat indiscriminately at first and it's just sort of stuck. At th= e > time > > > I was trying to incorporate bits of draft-sakimura-oauth-jpop in a wa= y > that > > > might help bring on and keep the authors of that draft onboard with > this > > > mtls draft. In retrospect it looks like I did that part wrong anyway. > But > > > that was the thinking at the time and the history, for whatever it's > worth. > > > More recently, Nat was requesting that "sender constrained" be > included in > > > the title. So there's that too. > > > > > > > > > > In defense of my mistake, however, if there's a line between > "sender > > > constrained" and "key confirmation" tokens, it's a bit of a fuzzy > line. And > > > I'd argue that what this draft is doing pretty close to the line. > > > > > > > > > > But ultimately I think you are right that what this mtls draft is > > > doing with access tokens is more accurately described with the key > > > confirmation term. > > > > > > > > > > So, yes, the draft should probably drop (or at least minimize) th= e > > > language about sender constrained. I'll do that in the next draft > version, > > > barring big objections from the WG. > > > > > > > > > > The tricky thing with making that change is that there a client a= nd > > > server metadata parameters with the name "mutual_tls_sender_ > constrained_access_tokens" > > > that should probably also change. But that would be a breaking change > (of > > > sorts anyway), which shouldn't be taken lightly at this stage. I feel > that > > > some explicit okays from the WG are needed before doing so (rough > consensus > > > stye) . Any WG members want to weigh in here and help get a "sense of > the > > > group" concerning changing those metadata names? > > > > > > > > > > *** Thanks. I agree this might cause compatibility issues. It is > not a > > > big issue for us, but might cause some confusion. > > > > > > > > > > > > > > > > > > > > 6. The OAuth 2.0 PoP Architecture draft says ( > > > https://tools.ietf.org/html/draft-ietf-oauth-pop- > architecture-08#section-5 > > > > > architecture-08#section-5>): > > > > > > > > > > Strong, fresh session keys: > > > > > > > > > > Session keys MUST be strong and fresh. Each > session > > > deserves an > > > > > independent session key, i.e., one that is > generated > > > specifically > > > > > for the intended use. In context of OAuth this > means > > > that keying > > > > > material is created in such a way that can only b= e > > > used by the > > > > > combination of a client instance, protected > resource, > > > and > > > > > authorization scope. > > > > > > > > > > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/ > > > draft-ietf-oauth-mtls-07#section-3 > > draft-ietf-oauth-mtls-07#section-3>) says: > > > > > > > > > > The client makes protected resource requests as described > in > > > > > [RFC6750], however, those requests MUST be made over a > mutually > > > > > authenticated TLS connection using the same certificate > that > > > was used > > > > > for mutual TLS at the token endpoint. > > > > > > > > > > These two statements are contradictory: the OAuth 2.0 PoP > architecture > > > effectively requires a fresh key-pair to be used for every access tok= en > > > request, whereas this draft proposes reusing the same long-lived clie= nt > > > certificate for every single access token and every resource server. > > > > > > > > > > In the self-signed case (and even in the CA case, with a bit of > work - > > > e.g., https://www.vaultproject.io/docs/secrets/pki/index.html < > > > https://www.vaultproject.io/docs/secrets/pki/index.html>) it is > perfectly > > > possible for the client to generate a fresh key-pair for each access > token > > > and include the certificate on the token request (e.g., as per > > > https://tools.ietf.org/html/draft-ietf-oauth-pop-key- > > > distribution-03#section-5.1 > > draft-ietf-oauth-pop-key-distribution-03#section-5.1> - in which case > an > > > appropriate =E2=80=9Calg=E2=80=9D value should probably be described)= . This should > probably > > > at least be an option. > > > > > > > > > > This draft doesn't necessarily seek to align with the (long > expired) > > > PoP architecture draft. Rather it is aiming to provide a pragmatic > > > solution for PoP style access tokens and OAuth client auth using mTLS > > > client certificates. > > > > > > > > > > That said, with the current draft, it's certainly possible for a > > > client to update its cert more frequently, even so far as using a new > one > > > for each access token. The details of how that would work will vary > some > > > based on the token endpoint authentication method. But it's not > precluded. > > > > > > > > > > *** You are right, the text doesn=E2=80=99t preclude that. I am h= appy with > > > that solution. I suspect most people will deploy and be happy with > reusing > > > a long-lived cert for every access token, so this may not matter in > > > practice. > > > > > > > > > > > > > > > 7. The use of a single client certificate with every resource > server > > > (RS) should be called out in a Privacy Considerations section, as it > allows > > > correlation of activity. > > > > > > > > > > Practically speaking the access tokens being presented likely > already > > > have correlatable info in them about the client as well as the user. = I > > > don't know that there's much of a (new) concern in reality. If you fe= el > > > this concern is unique and import enough though, perhaps there's some > text > > > you'd like to propose for a Privacy Considerations section that the W= G > > > could consider? I mean, I guess it doesn't hurt to mention it but I > would > > > like to avoid overstating the issue. > > > > > > > > > > *** On reflection, I am going to withdraw this comment. As you sa= y > > > there are other ways to correlate clients. The privacy issue would > mainly > > > arise in the context of dynamic client registration e.g., a pattern > I=E2=80=99ve > > > seen described where every instance of a mobile app does dynamic clie= nt > > > registration to avoid including credentials directly in the app bundl= e. > > > This would make clients one-to-one with users. But (a) those apps are > > > fairly unlikely to be using TLS certs, and (b) that is more of a > privacy > > > consideration for dynamic client registration rather than this draft. > > > > > > > > > > > > > > > > > > > > 8. This is maybe a more general point, but RFC 6750 defines the > > > Authorization: Bearer scheme (https://tools.ietf.org/html/ > > > rfc6750#section-2 ) > for a > > > client to communicate it=E2=80=99s access token to the RS in a standa= rd way. As > > > sender-constrained access tokens are not strictly bearer tokens any > more, > > > should this draft also register a new scheme for that? Should there b= e > a > > > generic PoP scheme? > > > > > > > > > > The thinking and general consensus (in this draft as well as the > OAuth > > > token binding work) has been that continuing to use the RFC 6750 sche= me > > > while putting the "not strictly bearer" stuff in (or referenced by) t= he > > > token itself will be easier on deployment and implementation. And > better > > > for adoption as a result. I believe some early implementation work ha= s > > > borne that out too. > > > > > > > > > > *** OK. > > > > > > > > > > > > > > > 9. The Security Considerations should really make some mention of > the > > > long history of attacks against X.509 certificate chain validation, > e.g. > > > failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraint= s, errors in > parsing > > > DNs, etc. It should be strongly suggested to use an existing TLS > library to > > > perform these checks rather than implementing your own checks. This > relates > > > to Justin=E2=80=99s comments around DN parsing and normalisation. > > > > > > > > > > Suggesting to use an existing TLS library is certainly sound advi= ce > > > and I sort of felt is implied in the draft. But saying so more > > > strongly/explicitly might be worthwhile. And pointing to historical > > > reasons to do so would probably be good too. Could you propose a new > > > Security Considerations section or maybe augmentation of =C2=A75.2 wi= th that > > > content? > > > > > > > > > > *** I=E2=80=99ll try and come up with some text. > > > > > > > > > > > > > > > > > > > > 10. The PKI client authentication method ( > https://tools.ietf.org/html/ > > > draft-ietf-oauth-mtls-07#section-2.1 > > draft-ietf-oauth-mtls-07#section-2.1>) makes no mention at all of > > > certificate revocation and how to handle checking for that (CRLs, OCS= P > - > > > with stapling?). Neither does the Security Considerations. If this is= a > > > detail to be agreed between then AS and the CA (or just left up to th= e > AS > > > TLS stack) then that should perhaps be made explicit. Again, there ar= e > > > privacy considerations with some of these mechanisms, as OCSP request= s > are > > > typically sent in the clear (plain HTTP) and so allow an observer to > see > > > which clients are connecting to which AS. > > > > > > > > > > I didn't think that a TLS client could do OCSP stapling? > > > > > > > > > > *** I think you are right about this. I always assumed it was > > > symmetric (and I think it technically could work), but the spec only > talks > > > about stapling in the server-side of the handshake. > > > > > > > > > > That aside, revocation checking (how and even if) is something > that's > > > at the discretion of the AS. I can add something in =C2=A72.1 to say = that > more > > > explicitly. > > > > > > > > > > *** Thanks. > > > > > > > > > > > > > > > > > > > > 11. The same comment applies to how the protected resource checks > for > > > revocation of the certificate presented during sender constrained > access > > > token usage. Should the RS make its own revocation checks based on th= e > > > information in the certificate presented, or should it trust the > > > certificate while the access token is still valid? If the latter case= , > is > > > the AS responsible for revoking any access tokens whose certificate > have > > > been revoked (if so, should it be doing an OCSP call on every token > > > introspection request, and should the RS be passing on the > > > certificate/serial number on that request)? If the Client request use= s > OCSP > > > Stapling (https://en.wikipedia.org/wiki/OCSP_stapling < > > > https://en.wikipedia.org/wiki/OCSP_stapling>) how can the RS verify > the > > > signature on that if it does not have a separate trust relationship > with > > > the CA already? > > > > > > > > > > The draft effectively uses cert mtls at the RS as a > > > proof-of-possession method only and not as authentication. So > revocation > > > checking isn't really applicable. In specific deployment situations, = I > > > suppose an RS could check revocation. But that'd be a deployment > decision > > > for the RS that's beyond the scope of this draft. > > > > > > > > > > *** OK, that is an interesting observation. If either the client > or AS > > > suspect the key has been compromised they can revoke the access > token(s) > > > instead. > > > > > > > > > > > > > > > > > > > > 12. The use of only SHA-256 fingerprints means that the security > > > strength of the sender-constrained access tokens is limited by the > > > collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" = - without > a > > > new specification for a new thumbprint algorithm. An implication of > this is > > > that is is fairly pointless for the protected resource TLS stack to > ever > > > negotiate cipher suites/keys with a higher level of security. In more > > > crystal ball territory, if a practical quantum computer becomes a > > > possibility within the lifetime of this spec, then the expected > collision > > > resistance of SHA-256 would drop quadratically, allowing an attacker = to > > > find a colliding certificate in ~2^64 effort. If we are going to pick > just > > > one thumbprint hash algorithm, I would prefer we pick SHA-512. > > > > > > > > > > The idea behind haveing just one thumbprint hash algorithm was to > keep > > > things simple. And SHA-256 seems good enough for the reasonably > foreseeable > > > future (and space aware). Also a new little spec to register a > different > > > hash algorithm, should the need arise, didn't seem particularity > onerous. > > > > > > > > > > That was the thinking anyway. Maybe it is too short sighted thoug= h? > > > > > > > > > > I do think SHA-256 should stay regardless. > > > > > > > > > > But the draft could also define SHA-512 (and maybe others). What = do > > > you and WG folks think about that? > > > > > > > > > > *** Yes please. > > > > > > > > > > It would probably then be useful for the metadata in =C2=A73.3 an= d =C2=A73.4 > to > > > change from just boolean values to something to convey what hash > alg/cnf > > > method the client expects and the list of what the server supports. > That's > > > maybe something that should be done anyway. That'd be a breaking > change to > > > the metadata. But there's already another potential breaking change > > > identified earlier in this message. So maybe it's worth doing... > > > > > > > > > > How do folks feel about making this kind of change? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Neil > > > > > > > > > > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com > > > > wrote: > > > > > > > > > > > > All, > > > > > > > > > > > > As discussed during the meeting today, we are starting a WGLC o= n > the > > > MTLS document: > > > > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 < > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07> > > > > > > > > > > > > Please, review the document and provide feedback on any issues > you > > > see with the document. > > > > > > > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > > > > > > > Regards, > > > > > > Rifaat and Hannes > > > > > > > > > > > > _______________________________________________ > > > > > > OAuth mailing list > > > > > > OAuth@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/oauth < > > > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth < > > > https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > > privileged material for the sole use of the intended recipient(s). An= y > > > review, use, distribution or disclosure by others is strictly > prohibited. > > > If you have received this communication in error, please notify the > sender > > > immediately by e-mail and delete the message and any file attachments > from > > > your computer. Thank you. > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > > privileged material for the sole use of the intended recipient(s). An= y > > > review, use, distribution or disclosure by others is strictly > prohibited. > > > If you have received this communication in error, please notify the > sender > > > immediately by e-mail and delete the message and any file attachments > from > > > your computer. Thank you. > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > _CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use= , > > distribution or disclosure by others is strictly prohibited. If you > have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you._ > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002680c9056a34e015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. Will do.

=
On Thu, Apr 19, 2018 at 8:57 AM, Benjamin Kaduk = <ka= duk@mit.edu> wrote:
I would= go ahead and put them in.=C2=A0 The blog post might get some
pushback, but I think there's plenty of precedent for academic
papers.

-Ben

On Wed, Apr 18, 2018 at 09:34:23AM -0600, Brian Campbell wrote:
> Thanks for the text, Neil. And the nit on the text, Ben. I'll incl= ude it in
> the next draft.
>
> Ben, bit of a procedural question for you: can or should I include tho= se
> references (https://www.cryptol= ogie.net/article/374/common-x509-certificate-
> validationcreation-pitfalls/ & http://www.cs.utexas.edu/~
> shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as
> informational? Or? I'm honestly not sure if it's okay to cite = a blog post
> or university paper.
>
>
> <https://www.cryptologie.net/article/374/common-x509-certi= ficate-validationcreation-pitfalls/>
>
>
>
>
> On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Picking nits, but maybe "established and well-tested X.509 l= ibrary
> > (such as one used by an established TLS library)", noting th= at TLS
> > 1.3 has added a new protocol feature that allows for TLS and X.50= 9
> > library capabilities to be separately indicated (as would be need= ed
> > if they were organizationally separate).
> >
> > -Ben
> >
> > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote:
> > > OK, here=E2=80=99s a stab at a new security considerations s= ection on X.509
> > parsing and validation:
> > >
> > > ---
> > > 5.3 X.509 Certificate Parsing and Validation Complexity
> > >
> > > Parsing and validation of X.509 certificates and certificate= chains is
> > complex and implementation mistakes have previously exposed secur= ity
> > vulnerabilities. Complexities of validation include (but are not = limited
> > to) [1][2][3]:
> > > - checking of Basic Constraints, basic and extended Key Usag= e
> > constraints, validity periods, and critical extensions;
> > > - handling of null-terminator bytes and non-canonical string=
> > representations in subject names;
> > > - handling of wildcard patterns in subject names;
> > > - recursive verification of certificate chains and checking = certificate
> > revocation.
> > > For these reasons, implementors SHOULD use an established an= d
> > well-tested TLS library for validation of X.509 certificate chain= s and
> > SHOULD NOT attempt to write their own X.509 certificate validatio= n
> > procedures.
> > >
> > > [1] https://www.crypt= ologie.net/article/374/common-x509-certificate-
> > validationcreation-pitfalls/ <https://www.cryptologie.net/<= /a>
> > article/374/common-x509-certificate-validationcreation-= pitfalls/>
> > > [2] http://www.cs.utexas.edu/~shm= at/shmat_ccs12.pdf <
> > http://www.cs.utexas.edu/~shmat/shma= t_ccs12.pdf>
> > > [3] https://tools.ietf.org/html/rfc5280 &= lt;https://tools.ietf.org/html/
> > rfc5280>
> > >
> > > ---
> > >
> > > NB - this blog post [1] is the best concise summary of attac= ks I could
> > find. Most of these attacks have been published as Black Hat talk= s and I
> > can=E2=80=99t seem to find definitive references or good survey p= apers (beyond [2],
> > which is a little older).
> > >
> > > Let me know what you think,
> > >
> > > Neil
> > >
> > >
> > > > On 12 Apr 2018, at 20:42, Brian Campbell <bcampbell@pingidentity.com>
> > wrote:
> > > >
> > > > Thanks Neil.
> > > >
> > > > Other than the potential metadata changes, which I'= d like more WG
> > input on and may raise in a new thread, I think I've got enou= gh to make
> > updates addressing your comments.=C2=A0 But please do send text f= or that
> > Security Considerations bit, if you come up with something.
> > > >
> > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden <
> > neil.madden@forgeroc= k.com <mailto:neil.madd= en@forgerock.com>> wrote:
> > > > Hi Brian,
> > > >
> > > > Thanks for the detailed responses. Comments in line bel= ow (marked with
> > ***).
> > > >
> > > > Neil
> > > >
> > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell &= lt;
> > bcampbell@pingident= ity.com <mailto:bcampb= ell@pingidentity.com>> wrote:
> > > > Thanks for the review and feedback, Neil. I apologize f= or my being
> > slow to respond. As I said to Justin recently <
> > https://mailarchive= .ietf.org/arch/msg/oauth/cNmk8fSuxp37L-z8Rvr6_EnyCug>,
> > I've been away from things for a while. Also there's a lo= t here to get
> > through so took me some time.
> > > >
> > > > It looks like John touched on some of your comments but= not all. I'll
> > try and reply to them as best I can inline below.
> > > >
> > > >
> > > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden <
> > neil.madden@forgeroc= k.com <mailto:neil.madd= en@forgerock.com>> wrote:
> > > > Hi,
> > > >
> > > > I have reviewed this draft and have a number of comment= s, below.
> > ForgeRock have not yet implemented this draft, but there is inter= est in
> > implementing it at some point. (Disclaimer: We have no firm commi= tments on
> > this at the moment, I do not speak for ForgeRock, etc).
> > > >
> > > > 1. https://tools= .ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 <
> > https://tools.ietf.org/htm= l/draft-ietf-oauth-mtls-07#section-3.1> defines
> > a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, th= ere is already a
> > confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON= Web Key, which itself can
> > contain a =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same = syntax and semantics. The
> > draft proposes:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ =E2=80=9Ccnf=E2=80= =9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } }
> > > >
> > > > but you can already do:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ =E2=80=9Ccnf=E2=80= =9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2= =80=9C=E2=80=A6=E2=80=9D } } }
> > > >
> > > > If the intent is just to save some space and avoid the = mandatory
> > fields of the existing JWK types, maybe this would be better addr= essed by
> > defining a new JWK type which only has a thumbprint? e.g., { =E2= =80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D,
> > =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }.
> > > >
> > > > The intent of the x5t#S256 confirmation method was to b= e space
> > efficient and straightforward while utilizing the framework and r= egistry
> > that RFC 7800 gives.=C2=A0 Even a new JWK type like that would st= ill use more
> > space. And I'd argue that the new confirmation method is cons= iderably more
> > straightforward than registering a new JWK type (and the implicat= ions that
> > would have on JWK implementations in general) in order to use the= existing
> > "jwk" confirmation method.
> > > >
> > > > ***
> > > > OK, that is reasonable. Given that the draft says SHOUL= D rather than
> > MUST for using this confirmation key method, I think it is curren= tly
> > allowed to use either representation.
> > > >
> > > >
> > > >
> > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and = =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s
> > really only the client authentication that we are interested here= , and the
> > fact that the server also authenticates with a certificate is not= hugely
> > relevant to this particular spec (although it is to the overall s= ecurity of
> > OAuth). Also, TLS defines non-certificate based authentication me= chanisms
> > (e.g. TLS-SRP extension for password authenticated key exchange, = PSK for
> > pre-shared key authentication) and even non-X.509 certificate typ= es (
> > https://www.iana.org/assignments/t= ls-extensiontype-
> > values/tls-extensiontype-values.xhtml#tls-extensiontype= -values-3 <
> > https://www.iana.org/assignments/t= ls-extensiontype-
> > values/tls-extensiontype-values.xhtml#tls-extensiontype= -values-3>). I=E2=80=99d
> > prefer that the draft explicitly referred to =E2=80=9CX.509 Clien= t Certificate
> > Authentication=E2=80=9D rather than mutual TLS, and changed ident= ifiers like
> > =E2=80=98tls_client_auth=E2=80=99 (ht= tps://tools.ietf.org/html/draft-ietf-oauth-mtls-07#
> > section-2.1.1 <https://tools.ietf.= org/html/draft-ietf-oauth-mtls-07#
> > section-2.1.1>) to something more explicit like
> > =E2=80=98tls_x509_pki_client_auth=E2=80=99.
> > > >
> > > > This is especially confusing in section 3 on sender con= strained access
> > tokens, as there are two different servers involved: the AS and t= he
> > protected resource server, but there is no =E2=80=9Cmutual=E2=80= =9D authentication between
> > them, only between each of them and the client.
> > > >
> > > > Choosing names and terminology is difficult and the &qu= ot;right" wording is
> > often subjective. I believe that the current wording sufficiently= conveys
> > what is going on in the draft to most readers. Most readers thus = far seem
> > to agree. There is some text now that does say that the mutual au= th in the
> > draft is in fact X.509 client cert authn but, in the next revisio= n, I'll
> > look for other opportunities where it could be stated more clearl= y.
> > > >
> > > > *** Thanks.
> > > >
> > > >
> > > >
> > > > 3. The draft links to the TLS 1.2 RFC, while the origin= al OAuth 2.0
> > RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is req= uired? The
> > wording in Section 5.1 doesn=E2=80=99t seem clear if this could a= lso be used with
> > TLS 1.0 or 1.1, or whether it is only referring to future TLS ver= sions.
> > > >
> > > > The reference to BCP 195 (which unfortunately the origi= nal OAuth 2.0
> > RFC doesn't have because it didn't exist then) is meant t= o account for
> > changing versions and recommendations around TLS. Currently that = BCP says
> > TLS 1.2 is a must and suggests against 1.1 & 1.0 but doesn= 9;t outright
> > prohibit them.
> > > >
> > > > *** OK, that seems good to me.
> > > >
> > > >
> > > >
> > > > 4. It might be useful to have a discussion for implemen= tors of whether
> > TLS session resumption (and PSK in TLS 1.3) and/or renegotiation = impact the
> > use of client certificates, if at all?
> > > >
> > > > That might well be useful but I don't myself know w= hat it would say.
> > I've (maybe naively) figured those are deployment details tha= t will just
> > work out. Perhaps you could propose some text around such a discu= ssion that
> > the WG could consider?
> > > >
> > > >=C2=A0 ***
> > > > To be honest, when I raised this it was because I didn= =E2=80=99t really know
> > what the implications were. I=E2=80=99ve done some reading around= and I think it
> > should all just work - both session resumption and PSK-based resu= mption
> > preserve the original client and server authentication context so= we can
> > assume that any presented client cert is still valid for the resu= med
> > session. So I think we can leave out any discussion of this and a= ssume it
> > works as expected.
> > > >
> > > >
> > > >
> > > > 5. Section 3 defines sender-constrained access tokens i= n terms of the
> > confirmation key claims (e.g., RFC 7800 for JWT). However, the OA= uth 2.0
> > Pop Architecture draft defines sender constraint and key confirma= tion as
> > different things (https://tools.ietf.org/= html/draft-ietf-oauth-pop-
> > architecture-08#section-6.2 <https://tools.ietf.org/html/
> > draft-ietf-oauth-pop-architecture-08#section-6.2>). The d= raft should
> > decide which of those it is implementing and if sender constraint= is
> > intended, then reusing the confirmation key claims seems misleadi= ng. (I
> > think this mTLS draft is doing key confirmation so should drop th= e language
> > about sender constrained tokens).
> > > >
> > > > I will say again that choosing names and terminology is= difficult...
> > > >
> > > > Although I must admit that I started using "sender= constrained"
> > somewhat indiscriminately at first and it's just sort of stuc= k. At the time
> > I was trying to incorporate bits of draft-sakimura-oauth-jpop in = a way that
> > might help bring on and keep the authors of that draft onboard wi= th this
> > mtls draft. In retrospect it looks like I did that part wrong any= way. But
> > that was the thinking at the time and the history, for whatever i= t's worth.
> > More recently, Nat was requesting that "sender constrained&q= uot; be included in
> > the title. So there's that too.
> > > >
> > > > In defense of my mistake, however, if there's a lin= e between "sender
> > constrained" and "key confirmation" tokens, it'= ;s a bit of a fuzzy line. And
> > I'd argue that what this draft is doing pretty close to the l= ine.
> > > >
> > > > But ultimately I think you are right that what this mtl= s draft is
> > doing with access tokens is more accurately described with the ke= y
> > confirmation term.
> > > >
> > > > So, yes, the draft should probably drop (or at least mi= nimize) the
> > language about sender constrained. I'll do that in the next d= raft version,
> > barring big objections from the WG.
> > > >
> > > > The tricky thing with making that change is that there = a client and
> > server metadata parameters with the name "mutual_tls_sender_= constrained_access_tokens"
> > that should probably also change. But that would be a breaking ch= ange (of
> > sorts anyway), which shouldn't be taken lightly at this stage= . I feel that
> > some explicit okays from the WG are needed before doing so (rough= consensus
> > stye) . Any WG members want to weigh in here and help get a "= ;sense of the
> > group" concerning changing those metadata names?
> > > >
> > > > *** Thanks. I agree this might cause compatibility issu= es. It is not a
> > big issue for us, but might cause some confusion.
> > > >
> > > >
> > > >
> > > > 6. The OAuth 2.0 PoP Architecture draft says (
> > https://tools.ie= tf.org/html/draft-ietf-oauth-pop-architecture-08#section-5 > > <https://tools.ietf.org/html/draf= t-ietf-oauth-pop-
> > architecture-08#section-5>):
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Strong, fresh session= keys:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Session keys MUST be strong and fresh.=C2=A0 Each session
> > deserves an
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0independent session key, i.e., one that is generated
> > specifically
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0for the intended use.=C2=A0 In context of OAuth this means
> > that keying
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0material is created in such a way that can only be
> > used by the
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0combination of a client instance, protected resource,
> > and
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0authorization scope.
> > > >
> > > >
> > > > However, the mTLS draft section 3 (https://tools.iet= f.org/html/
> > draft-ietf-oauth-mtls-07#section-3 <https://tools.ietf= .org/html/
> > draft-ietf-oauth-mtls-07#section-3>) says:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The client makes prote= cted resource requests as described in
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6750], however, th= ose requests MUST be made over a mutually
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authenticated TLS conn= ection using the same certificate that
> > was used
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for mutual TLS at the = token endpoint.
> > > >
> > > > These two statements are contradictory: the OAuth 2.0 P= oP architecture
> > effectively requires a fresh key-pair to be used for every access= token
> > request, whereas this draft proposes reusing the same long-lived = client
> > certificate for every single access token and every resource serv= er.
> > > >
> > > > In the self-signed case (and even in the CA case, with = a bit of work -
> > e.g., https://www.vaultproject.io/<= wbr>docs/secrets/pki/index.html <
> > https://www.vaultproject.io/do= cs/secrets/pki/index.html>) it is perfectly
> > possible for the client to generate a fresh key-pair for each acc= ess token
> > and include the certificate on the token request (e.g., as per > > https://tools.ietf.org/html/draf= t-ietf-oauth-pop-key-
> > distribution-03#section-5.1 <https://tools.ietf.org/html/
> > draft-ietf-oauth-pop-key-distribution-03#section-5.1> - i= n which case an
> > appropriate =E2=80=9Calg=E2=80=9D value should probably be descri= bed). This should probably
> > at least be an option.
> > > >
> > > > This draft doesn't necessarily seek to align with t= he (long expired)
> > PoP architecture draft.=C2=A0 Rather it is aiming to provide a pr= agmatic
> > solution for PoP style access tokens and OAuth client auth using = mTLS
> > client certificates.
> > > >
> > > > That said, with the current draft, it's certainly p= ossible for a
> > client to update its cert more frequently, even so far as using a= new one
> > for each access token. The details of how that would work will va= ry some
> > based on the token endpoint authentication method. But it's n= ot precluded.
> > > >
> > > > *** You are right, the text doesn=E2=80=99t preclude th= at. I am happy with
> > that solution. I suspect most people will deploy and be happy wit= h reusing
> > a long-lived cert for every access token, so this may not matter = in
> > practice.
> > > >
> > > >
> > > > 7. The use of a single client certificate with every re= source server
> > (RS) should be called out in a Privacy Considerations section, as= it allows
> > correlation of activity.
> > > >
> > > > Practically speaking the access tokens being presented = likely already
> > have correlatable info in them about the client as well as the us= er. I
> > don't know that there's much of a (new) concern in realit= y. If you feel
> > this concern is unique and import enough though, perhaps there= 9;s some text
> > you'd like to propose for a Privacy Considerations section th= at the WG
> > could consider? I mean, I guess it doesn't hurt to mention it= but I would
> > like to avoid overstating the issue.
> > > >
> > > > *** On reflection, I am going to withdraw this comment.= As you say
> > there are other ways to correlate clients. The privacy issue woul= d mainly
> > arise in the context of dynamic client registration e.g., a patte= rn I=E2=80=99ve
> > seen described where every instance of a mobile app does dynamic = client
> > registration to avoid including credentials directly in the app b= undle.
> > This would make clients one-to-one with users. But (a) those apps= are
> > fairly unlikely to be using TLS certs, and (b) that is more of a = privacy
> > consideration for dynamic client registration rather than this dr= aft.
> > > >
> > > >
> > > >
> > > > 8. This is maybe a more general point, but RFC 6750 def= ines the
> > Authorization: Bearer scheme (https://tools.ietf.org/html/=
> > rfc6750#section-2 <https://tools.ietf.org/= html/rfc6750#section-2>) for a
> > client to communicate it=E2=80=99s access token to the RS in a st= andard way. As
> > sender-constrained access tokens are not strictly bearer tokens a= ny more,
> > should this draft also register a new scheme for that? Should the= re be a
> > generic PoP scheme?
> > > >
> > > > The thinking and general consensus (in this draft as we= ll as the OAuth
> > token binding work) has been that continuing to use the RFC 6750 = scheme
> > while putting the "not strictly bearer" stuff in (or re= ferenced by) the
> > token itself will be easier on deployment and implementation. And= better
> > for adoption as a result. I believe some early implementation wor= k has
> > borne that out too.
> > > >
> > > >=C2=A0 *** OK.
> > > >
> > > >
> > > > 9. The Security Considerations should really make some = mention of the
> > long history of attacks against X.509 certificate chain validatio= n, e.g.
> > failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constr= aints, errors in parsing
> > DNs, etc. It should be strongly suggested to use an existing TLS = library to
> > perform these checks rather than implementing your own checks. Th= is relates
> > to Justin=E2=80=99s comments around DN parsing and normalisation.=
> > > >
> > > > Suggesting to use an existing TLS library is certainly = sound advice
> > and I sort of felt is implied in the draft. But saying so more > > strongly/explicitly might be worthwhile.=C2=A0 And pointing to hi= storical
> > reasons to do so would probably be good too.=C2=A0 Could you prop= ose a new
> > Security Considerations section or maybe augmentation of =C2=A75.= 2 with that
> > content?
> > > >
> > > > *** I=E2=80=99ll try and come up with some text.
> > > >
> > > >
> > > >
> > > > 10. The PKI client authentication method (https://to= ols.ietf.org/html/
> > draft-ietf-oauth-mtls-07#section-2.1 <https://tools.ie= tf.org/html/
> > draft-ietf-oauth-mtls-07#section-2.1>) makes no mention a= t all of
> > certificate revocation and how to handle checking for that (CRLs,= OCSP -
> > with stapling?). Neither does the Security Considerations. If thi= s is a
> > detail to be agreed between then AS and the CA (or just left up t= o the AS
> > TLS stack) then that should perhaps be made explicit. Again, ther= e are
> > privacy considerations with some of these mechanisms, as OCSP req= uests are
> > typically sent in the clear (plain HTTP) and so allow an observer= to see
> > which clients are connecting to which AS.
> > > >
> > > > I didn't think that a TLS client could do OCSP stap= ling?
> > > >
> > > > *** I think you are right about this. I always assumed = it was
> > symmetric (and I think it technically could work), but the spec o= nly talks
> > about stapling in the server-side of the handshake.
> > > >
> > > > That aside, revocation checking (how and even if) is so= mething that's
> > at the discretion of the AS. I can add something in =C2=A72.1 to = say that more
> > explicitly.
> > > >
> > > > *** Thanks.
> > > >
> > > >
> > > >
> > > > 11. The same comment applies to how the protected resou= rce checks for
> > revocation of the certificate presented during sender constrained= access
> > token usage. Should the RS make its own revocation checks based o= n the
> > information in the certificate presented, or should it trust the<= br> > > certificate while the access token is still valid? If the latter = case, is
> > the AS responsible for revoking any access tokens whose certifica= te have
> > been revoked (if so, should it be doing an OCSP call on every tok= en
> > introspection request, and should the RS be passing on the
> > certificate/serial number on that request)? If the Client request= uses OCSP
> > Stapling (https://en.wikipedia.org/wiki/OC= SP_stapling <
> > https://en.wikipedia.org/wiki/OCSP_staplin= g>) how can the RS verify the
> > signature on that if it does not have a separate trust relationsh= ip with
> > the CA already?
> > > >
> > > > The draft effectively uses cert mtls at the RS as a
> > proof-of-possession method only and not as authentication. So rev= ocation
> > checking isn't really applicable. In specific deployment situ= ations, I
> > suppose an RS could check revocation. But that'd be a deploym= ent decision
> > for the RS that's beyond the scope of this draft.
> > > >
> > > > *** OK, that is an interesting observation. If either t= he client or AS
> > suspect the key has been compromised they can revoke the access t= oken(s)
> > instead.
> > > >
> > > >
> > > >
> > > > 12. The use of only SHA-256 fingerprints means that the= security
> > strength of the sender-constrained access tokens is limited by th= e
> > collision resistance of SHA-256 - roughly =E2=80=9C128-bit securi= ty" - without a
> > new specification for a new thumbprint algorithm. An implication = of this is
> > that is is fairly pointless for the protected resource TLS stack = to ever
> > negotiate cipher suites/keys with a higher level of security. In = more
> > crystal ball territory, if a practical quantum computer becomes a=
> > possibility within the lifetime of this spec, then the expected c= ollision
> > resistance of SHA-256 would drop quadratically, allowing an attac= ker to
> > find a colliding certificate in ~2^64 effort. If we are going to = pick just
> > one thumbprint hash algorithm, I would prefer we pick SHA-512. > > > >
> > > > The idea behind haveing just one thumbprint hash algori= thm was to keep
> > things simple. And SHA-256 seems good enough for the reasonably f= oreseeable
> > future (and space aware). Also a new little spec to register a di= fferent
> > hash algorithm, should the need arise, didn't seem particular= ity onerous.
> > > >
> > > > That was the thinking anyway. Maybe it is too short sig= hted though?
> > > >
> > > > I do think SHA-256 should stay regardless.
> > > >
> > > > But the draft could also define SHA-512 (and maybe othe= rs). What do
> > you and WG folks think about that?
> > > >
> > > > *** Yes please.
> > > >
> > > > It would probably then be useful for the metadata in = =C2=A73.3 and =C2=A73.4 to
> > change from just boolean values to something to convey what hash = alg/cnf
> > method the client expects and the list of what the server support= s. That's
> > maybe something that should be done anyway. That'd be a break= ing change to
> > the metadata. But there's already another potential breaking = change
> > identified earlier in this message. So maybe it's worth doing= ...
> > > >
> > > > How do folks feel about making this kind of change?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > Neil
> > > >
> > > >
> > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <<= a href=3D"mailto:rifaat.ietf@gmail.com">rifaat.ietf@gmail.com
> > <mailto:rifaat.ietf@g= mail.com>> wrote:
> > > > >
> > > > > All,
> > > > >
> > > > > As discussed during the meeting today, we are star= ting a WGLC on the
> > MTLS document:
> > > > > https://tools.ietf.org/= html/draft-ietf-oauth-mtls-07 <
> > https://tools.ietf.org/html/draft= -ietf-oauth-mtls-07>
> > > > >
> > > > > Please, review the document and provide feedback o= n any issues you
> > see with the document.
> > > > >
> > > > > The WGLC will end in two weeks, on April 2, 2018.<= br> > > > > >
> > > > > Regards,
> > > > >=C2=A0 Rifaat and Hannes
> > > > >
> > > > > _____________________________________________= __
> > > > > OAuth mailing list
> > > > > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > > > > https://www.ietf.org/mailman/listinfo/oauth <
> > https://www.ietf.org/mailman/listinfo/oaut= h>
> > > >
> > > >
> > > > _______________________________________________ > > > > OAuth mailing list
> > > > OAuth@ietf.org &l= t;mailto:OAuth@ietf.org>
> > > > https://www.ietf.org/mailman/lis= tinfo/oauth <
> > https://www.ietf.org/mailman/listinfo/oaut= h>
> > > >
> > > >
> > > >
> > > > CONFIDENTIALITY NOTICE: This email may contain confiden= tial and
> > privileged material for the sole use of the intended recipient(s)= . Any
> > review, use, distribution or disclosure by others is strictly pro= hibited.
> > If you have received this communication in error, please notify t= he sender
> > immediately by e-mail and delete the message and any file attachm= ents from
> > your computer. Thank you.
> > > >
> > > >
> > > > CONFIDENTIALITY NOTICE: This email may contain confiden= tial and
> > privileged material for the sole use of the intended recipient(s)= . Any
> > review, use, distribution or disclosure by others is strictly pro= hibited.
> > If you have received this communication in error, please notify t= he sender
> > immediately by e-mail and delete the message and any file attachm= ents from
> > your computer. Thank you.
> > >
> >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/oauth
> >
> >
>
> --
> _CONFIDENTIALITY NOTICE: This email may contain confidential and privi= leged
> material for the sole use of the intended recipient(s= ). Any review, use,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you._


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002680c9056a34e015-- From nobody Thu Apr 19 09:24:30 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63959120727 for ; Thu, 19 Apr 2018 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ihSbr3avxI for ; Thu, 19 Apr 2018 09:24:20 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423F31200E5 for ; Thu, 19 Apr 2018 09:24:20 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id x144-v6so607557itc.0 for ; Thu, 19 Apr 2018 09:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CX01L6iRm9ImaOai98TBFdKgEBNK3QP1V//kyIgab74=; b=itgEjiUHhhR71DCDY6HOfh1SVYuuL77xxyKZxWGhDQaJCIfD1nCbQ1XDj31aZ3EV7R t/Qg391ph5OOGu8V+vEAfEuS91a3IDQTdw5C2l1J4cI8EqY59SHSIC/wzSQdnBSJQpD1 24m2yp0//iudq+vON+JvUTgztr4p6lWtOsKBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CX01L6iRm9ImaOai98TBFdKgEBNK3QP1V//kyIgab74=; b=P2iFlx1RpsHIxL3phH1GeoyyKgcUrWFGDobQ+t9nNz4M+nOTyd5tp2yM7w+2XdhqpJ FoirqRkqv1iA3uwT89R348OdPkHDuz+3FhTOMpqWnd6CHB6qIrupMcG/UonM0XI57bdb f6vyG8uoQ8pwY0teV7muEb1w3ABcdDfEgoS2Cek3F0o4NvlwwdJhZ+Lv81f18TwpAgpl vCzbYwd5gOXEOqO6/I04EIfHoElIav4vE2yWYzUY+E7r8sARSDEkL3Y46y/GAgCLnLX/ WBycwX1sNeRd0mbA4zamlCpkrHiZRrlb8S5y0k0PcStXaVB9i7GwbwMcsvb1b8uivBDg L1Eg== X-Gm-Message-State: ALQs6tAJN2Ww+xoVYrvTPLJUMH/dNR83GQg9AhpLUXDlTflAwQ89/qxl J66xy8cPLHWcPvdUsgiudzatZT/FslK6NolatgeTKlHZZE7a36YFY/GV5BI/w65xm8P06ZEkk7A hoJTxYb9oL8i5PV0z X-Google-Smtp-Source: AIpwx4/1sRDuqaVGdroyYKUw+DTaFY3fWrfaaZJWU3tBuDOJNWeLC64nGGYrpC70UR55sTv+qHX/DJwvll9MDyBwevI= X-Received: by 2002:a24:3dcc:: with SMTP id n195-v6mr7067581itn.25.1524155059368; Thu, 19 Apr 2018 09:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 09:23:48 -0700 (PDT) In-Reply-To: <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> From: Brian Campbell Date: Thu, 19 Apr 2018 10:23:48 -0600 Message-ID: To: Neil Madden Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="000000000000e5bc66056a36002c" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 16:24:28 -0000 --000000000000e5bc66056a36002c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, so I retract the idea of metadata indicating the hash alg/cnf method (based on John pointing out that it doesn't really make sense). That still leaves the question of whether or not to define additional confirmation methods in this document (and if so, what they would be though x5t#S384 and x5t#S512 seem the most likely). There's some reasonable rational for both adding one or two new hash alg confirmation methods in the doc now vs. sticking with just SHA256 for now. I'll note again that the doc doesn't preclude using or later defining other confirmation methods. I'm kind of on the fence about it, to be honest. But that doesn't really matter because the draft should reflect rough WG consensus. So I'm looking to get a rough gauge of rough consensus. At this point there's one comment out of WGLC asking for additional confirmation method(s). I don't think that makes for consensus. But I'd ask others from the WG to chime in, if appropriate, to help me better gauge consensus. On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden wrote: > I=E2=80=99m not particularly wedded to SHA-512, just that it should be po= ssible to > use something else. At the moment, the draft seems pretty wedded to > SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on > many 64-bit machines) and provides a very wide security margin against an= y > future crypto advances (quantum or otherwise). I=E2=80=99d also be happy = with > SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely available. > > I don=E2=80=99t think short-lived access tokens is a help if the likeliho= od is > that certs will be reused for many access tokens. > > Public Web PKI certs tend to only use SHA-256 as it has broad support, an= d > I gather there were some compatibility issues with SHA-512 certs in TLS. > There are a handful of SHA-384 certs - e.g., the Comodo CA certs for > https://home.cern/ are signed with SHA-384 (although with RSA-2048, which > NSA estimates at only ~112-bit security). SHA-512 is used on some interna= l > networks where there is more control over components being used, which is > also where people are mostly likely to care about security beyond 128-bit > level (eg government internal networks). > > By the way, I just mentioned quantum attacks as an example of something > that might weaken the hash in future. Obviously, quantum attacks complete= ly > destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but i= t > provides a considerable margin to hedge against future quantum *or > classical* advances while allowing the paranoid to pick a stronger securi= ty > level now. We have customers that ask for 256-bit AES already. > > (I also misremembered the quantum attack - =E2=80=9CSerious Cryptography= =E2=80=9D by > Aumasson tells me the best known quantum attack against collision > resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) spac= e > so is impractical. I don=E2=80=99t know if that is the last word though). > > As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty broke= n now > with practical collisions having been demonstrated. The kind of attacks o= n > CA certs demonstrated for MD5 [1] are probably not too far off for SHA-1 > now. As far as I am aware, we=E2=80=99re nowhere near those kinds of atta= cks on > SHA-256, but I=E2=80=99d prefer that there was a backup plan in place alr= eady > rather than waiting to see (and waiting for everyone to have hard-coded > SHA-256 everywhere). > > Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 := -) > > [1] http://www.win.tue.nl/hashclash/rogue-ca/ > > Neil > > > On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley > wrote: > The WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals.= I am > unclear on who is going to work on it in what draft. > > If the client is doing mtls to both the Token endpoint and RS the > information in the confirmation method is not relevant to the client as > long as the AS and RS are in agreement like with most tokens. > > The hash on the certificate and length of the signing key are equally or > more vulnerable to any sort of attack. > At least with AT the tokens are not long lived. > > Doing anything better than SHA256 only makes sense if the cert is signed > by something stronger like SHA512 with a 2048bit RSA key. That seems so= rt > of unlikely in the near term. > > I prefer to wait to see what general fix is proposed before we jump the > gun with a bandade for a small part of the overall problem. > > People are typically using SHA1 fingerprints. We added SHA256 for JWT an= d > got push back on that as overkill. > I don=E2=80=99t think this is the correct place to be deciding this. > > We could say that if new thumbprints are defined the AS and RS can decide > to use them as necessary. > That is sort of the situation we have now. > > The correct solution may be a thousand rounds of PBKDF2 or something like > that to make finding collisions more difficult rather than longer hashes. > > John B. > > > On Apr 12, 2018, at 5:20 PM, Brian Campbell > wrote: > > > > That's true about it being opaque to the client. I was thinking of > client metadata (config or registration) as a way for the AS to decide if > to bind the AT to a cert. And moving from a boolean to a conf method as a= n > extension of that. It would be more meaningful in RS discovery, if there > was such a thing. > > > > I don=E2=80=99t know that SHA512 would be the best choice either but it= is > something that is stronger and could be included now. If there's consensu= s > to do more than SHA256 in this doc. > > > > > > > > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley wrote= : > > Inline > > > > Snip > > > >> > >> > >> 12. The use of only SHA-256 fingerprints means that the security > strength of the sender-constrained access tokens is limited by the > collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - wi= thout a > new specification for a new thumbprint algorithm. An implication of this = is > that is is fairly pointless for the protected resource TLS stack to ever > negotiate cipher suites/keys with a higher level of security. In more > crystal ball territory, if a practical quantum computer becomes a > possibility within the lifetime of this spec, then the expected collision > resistance of SHA-256 would drop quadratically, allowing an attacker to > find a colliding certificate in ~2^64 effort. If we are going to pick jus= t > one thumbprint hash algorithm, I would prefer we pick SHA-512. > >> > >> The idea behind haveing just one thumbprint hash algorithm was to keep > things simple. And SHA-256 seems good enough for the reasonably foreseeab= le > future (and space aware). Also a new little spec to register a different > hash algorithm, should the need arise, didn't seem particularity onerous. > >> > >> That was the thinking anyway. Maybe it is too short sighted though? > >> > >> I do think SHA-256 should stay regardless. > >> > >> But the draft could also define SHA-512 (and maybe others). What do yo= u > and WG folks think about that? > >> > >> *** Yes please. > >> > >> It would probably then be useful for the metadata in =C2=A73.3 and =C2= =A73.4 to > change from just boolean values to something to convey what hash alg/cnf > method the client expects and the list of what the server supports. That'= s > maybe something that should be done anyway. That'd be a breaking change t= o > the metadata. But there's already another potential breaking change > identified earlier in this message. So maybe it's worth doing... > >> > >> How do folks feel about making this kind of change? > >> > >> > > The confirmation method is opaque to the client. I don=E2=80=99t think= adding > hash algs to discovery will really help. > > The AS selection needs to be based on what the RS can support. > > > > If anyplace it should be in RS discovery. > > > > As a practical matter you art going to find a client certificate with > more than a SHA256 hash anytime in the near future. > > So for a short lived access token 128bits of collision resistance is > quite good. We are going to have issues with certificates long before > this becomes a problem. > > > > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RSA > keys, but again that is over the long term. > > We are using short lived access tokens. People should rotate the > certificate more often than once a year if this is a real issue. > > > > I am not against new hash for the fingerprint, but I also don=E2=80=99t= know > that SHA512 would be the best choice if we are concerned about quantum > crypto resistance. That is a issue beyond mtls and should be addressed = by > CFRG etc. > > > > Regards > > John B. > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e5bc66056a36002c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, so I retract the idea of metadata ind= icating the hash alg/cnf method (based on John pointing out that = it doesn't really make sense).

That stil= l leaves the question of whether or not to define additional confirmation methods in this document (and if so, what they would = be though x5t#S384 and x5t#S512 seem the most likely= ).

There's some reasonable rational for = both adding one or two new hash alg = confirmation methods in the doc now vs.= sticking with just SHA256 for now. I'll note again that the doc doesn&= #39;t preclude using or later defining other confirmation methods.

<= /span>
I'm kind of on the fence about it, to be honest. = But that doesn't really matter because the draft should reflect rough W= G consensus. So I'm looking to get a rough gauge of rough c= onsensus. At this point there's one comment out of WGLC asking f= or additional confirmation method(s). I don't think that makes for consensus. But I'd ask others from the WG= to chime in, if appropriate, to help me better gauge c= onsensus.

On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m not particularly wedded to SHA-512, just that it sho= uld be possible to use something else. At the moment, the draft seems prett= y wedded to SHA-256. SHA-512 may be overkill, but it is fast (faster than S= HA-256 on many 64-bit machines) and provides a very wide security margin ag= ainst any future crypto advances (quantum or otherwise). I=E2=80=99d also b= e happy with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely = available.

I don=E2=80=99t think short-lived access tokens is a help if the likelihood= is that certs will be reused for many access tokens.

Public Web PKI certs tend to only use SHA-256 as it has broad support, and = I gather there were some compatibility issues with SHA-512 certs in TLS. Th= ere are a handful of SHA-384 certs - e.g., the Comodo CA certs for https://home.c= ern/ are signed with SHA-384 (although with RSA-2048, which NSA estimat= es at only ~112-bit security). SHA-512 is used on some internal networks wh= ere there is more control over components being used, which is also where p= eople are mostly likely to care about security beyond 128-bit level (eg gov= ernment internal networks).

By the way, I just mentioned quantum attacks as an example of something tha= t might weaken the hash in future. Obviously, quantum attacks completely de= stroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it pr= ovides a considerable margin to hedge against future quantum *or classical*= advances while allowing the paranoid to pick a stronger security level now= . We have customers that ask for 256-bit AES already.

(I also misremembered the quantum attack - =E2=80=9CSerious Cryptography=E2= =80=9D by Aumasson tells me the best known quantum attack against collision= resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) space= so is impractical. I don=E2=80=99t know if that is the last word though).= =C2=A0

As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty broken = now with practical collisions having been demonstrated. The kind of attacks= on CA certs demonstrated for MD5 [1] are probably not too far off for SHA-= 1 now. As far as I am aware, we=E2=80=99re nowhere near those kinds of atta= cks on SHA-256, but I=E2=80=99d prefer that there was a backup plan in plac= e already rather than waiting to see (and waiting for everyone to have hard= -coded SHA-256 everywhere).

Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 :-)=

[1] http://www.win.tue.nl/hashclash/rogue-ca/

Neil


On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:
The WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals.= =C2=A0 =C2=A0I am unclear on who is going to work on it in what draft.

If the client is doing mtls to both the Token endpoint and RS the informati= on in the confirmation method is not relevant to the client as long as the = AS and RS are in agreement like with most tokens.

The hash on the certificate and length of the signing key are equally or mo= re vulnerable to any sort of attack.
At least with AT the tokens are not long lived.

Doing anything better than SHA256 only makes sense if the cert is signed by= something stronger like SHA512 with a 2048bit RSA key.=C2=A0 =C2=A0That se= ems sort of unlikely in the near term.=C2=A0

I prefer to wait to see what general fix is proposed before we jump the gun= with a bandade for a small part of the overall problem.

People are typically using SHA1 fingerprints.=C2=A0 We added SHA256 for JWT= and got push back on that as overkill.
I don=E2=80=99t think this is the correct place to be deciding this.=C2=A0 = =C2=A0

We could say that if new thumbprints are defined the AS and RS can decide t= o use them as necessary.
That is sort of the situation we have now.

The correct solution may be a thousand rounds of PBKDF2 or something like t= hat to make finding collisions more difficult rather than longer hashes.
John B.

> On Apr 12, 2018, at 5:20 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>
> That's true about it being opaque to the client. I was thinking of= client metadata (config or registration) as a way for the AS to decide if = to bind the AT to a cert. And moving from a boolean to a conf method as an = extension of that. It would be more meaningful in RS discovery, if there wa= s such a thing.
>
> I don=E2=80=99t know that SHA512 would be the best choice either but i= t is something that is stronger and could be included now. If there's c= onsensus to do more than SHA256 in this doc.=C2=A0
>
>
>
> On Thu, Apr 12, 2018 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Inline
>
> Snip
>
>>
>>
>> 12. The use of only SHA-256 fingerprints means that the security s= trength of the sender-constrained access tokens is limited by the collision= resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without = a new specification for a new thumbprint algorithm. An implication of this = is that is is fairly pointless for the protected resource TLS stack to ever= negotiate cipher suites/keys with a higher level of security. In more crys= tal ball territory, if a practical quantum computer becomes a possibility w= ithin the lifetime of this spec, then the expected collision resistance of = SHA-256 would drop quadratically, allowing an attacker to find a colliding = certificate in ~2^64 effort. If we are going to pick just one thumbprint ha= sh algorithm, I would prefer we pick SHA-512.
>>
>> The idea behind haveing just one thumbprint hash algorithm was to = keep things simple. And SHA-256 seems good enough for the reasonably forese= eable future (and space aware). Also a new little spec to register a differ= ent hash algorithm, should the need arise, didn't seem particularity on= erous.
>>
>> That was the thinking anyway. Maybe it is too short sighted though= ?
>>
>> I do think SHA-256 should stay regardless.
>>
>> But the draft could also define SHA-512 (and maybe others). What d= o you and WG folks think about that?
>>
>> *** Yes please.
>>
>> It would probably then be useful for the metadata in =C2=A73.3 and= =C2=A73.4 to change from just boolean values to something to convey what h= ash alg/cnf method the client expects and the list of what the server suppo= rts. That's maybe something that should be done anyway. That'd be a= breaking change to the metadata. But there's already another potential= breaking change identified earlier in this message. So maybe it's wort= h doing...
>>
>> How do folks feel about making this kind of change?
>>
>>
> The confirmation method is opaque to the client.=C2=A0 I don=E2=80=99t= think adding hash algs to discovery will really help.
> The AS selection needs to be based on what the RS can support.
>
> If anyplace it should be in RS discovery.
>
> As a practical matter you art going to find a client certificate with = more than a SHA256 hash anytime in the near future.
> So for a short lived access token 128bits of collision resistance is q= uite good.=C2=A0 =C2=A0We are going to have issues with certificates long b= efore this becomes a problem.
>
> SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RS= A keys, but again that is over the long term.=C2=A0
> We are using short lived access tokens.=C2=A0 People should rotate the= certificate more often than once a year if this is a real issue.
>
> I am not against new hash for the fingerprint, but I also don=E2=80=99= t know that SHA512 would be the best choice if we are concerned about quant= um crypto resistance.=C2=A0 =C2=A0That is a issue beyond mtls and should be= addressed by CFRG etc.
>
> Regards
> John B.
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e5bc66056a36002c-- From nobody Fri Apr 20 10:38:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17F612D88B for ; Fri, 20 Apr 2018 10:38:09 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmUShPko6e-k for ; Fri, 20 Apr 2018 10:38:06 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD10412D869 for ; Fri, 20 Apr 2018 10:38:05 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A6B39780373 for ; Fri, 20 Apr 2018 19:38:03 +0200 (CEST) To: oauth@ietf.org References: From: Denis Message-ID: Date: Fri, 20 Apr 2018 19:38:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7E5C840D06E869068E4F513F" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 17:38:10 -0000 This is a multi-part message in MIME format. --------------7E5C840D06E869068E4F513F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian, Eric said: "what is the RP supposed to do when they encounter it? This seems kind of under specified". After reading your explanations below, it looks like the RP can do anything he wants with the "actor". It is a "claimed actor" and, if we keep the concept, it should be called as such. Such a claim cannot be verified. A RP could copy and paste that claim in an audit log. No standard action related to the content of such a claim can be specified in the spec. If the content of a "claimed actor" is used by the RP, it should be only used as an hint and thus be subject to other verifications which are not specified in this specification. Denis > Eric, I realize you weren't particularly impressed by my prior > statements about the actor claim but, for lack of knowing what else to > say, I'm going to kind of repeat what I said about it over in the > Phabricator tool > and add > a little color. > > The actor claim is intended as a way to express that delegation has > happened and identify the entities involved. Access control or other > decisions based on it are at the discretion of the consumer of the > token based on whatever policy might be in place. > > There are JWT claims that have concise processing rules with respect > to whether or not the JWT can be accepted as valid. Some examples are > "aud" (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from > RFC 7519. E.g. if the token is expired or was intended for someone or > something else, reject it. > > And there are JWT claims that appropriately don't specify such > processing rules and are solely statements of fact or circumstance. > Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims > are good examples of such. There might be application or policy > specific rules applied to the content of those kinds of claims (e.g. > only subjects from a particular organization are able to access tenant > specific data or, less realistic but still possible, disallow access > for tokens issued outside of regular business hours) but that's all > outside the scope of a specification's definition of the claim. > > The actor claim falls into the latter category. It's a way for the > issuer of the token to tell the consumer of the token what is going > on. But any action to take (or not) based on that information is at > the discretion of the token consumer. I honestly don't know it could > be anything more. And don't think it should be. > > There are two main expected uses of the actor claim (that I'm aware of > anyway) that describing here might help. Maybe. One is a human to > human delegation case like a customer service rep doing something on > behalf of an end user. The subject would be that user and the actor > would be the customer service rep. And there wouldn't be any chaining > or nesting of the actor. The other case is so called service chaining > where a system might exchange a token it receives for a new token that > it can use to call a downstream service. And that service in turn > might do another exchange to get a new token suitable to call yet > another downstream service. And again and so on and turtles all the > way. I'm not necessarily endorsing that level of granularity in > chaining but it's bound to happen somewhere/sometime. The nested actor > claim is able to express that all that has happened with the top level > or outermost one being the system currently using the token and prior > systems being nested.. What actually gets done with that information > is up to the respective systems involved. There might be policy about > what system is allowed to call what other system that is enforced. Or > maybe the info is just written to an audit log somewhere. Or something > else. I don't know. But whatever it is application/deployment/policy > dependent and not specifiable by a spec. > > > > > > > On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla > wrote: > > Hi folks, > > I've gone over draft-ietf-oauth-token-exchange-12 and things seem > generally OK. I do still have one remaining concern, which is about > the actor claim. Specifically, what is the RP supposed to do when they > encounter it? This seems kind of underspecified. > > In particular: > > 1. What facts am I supposed to know here? Merely that everyone in >    the chain signed off on the next person in the chain acting as > them? > > 2. Am I just supposed to pretend that the person presenting the token >    is the identity at the top of the chain? Say I have the >    delegation A -> B -> C, and there is some resource which >    B can access but A and C cannot, should I give access? > > I think the first question definitely needs an answer. The second > question I guess we could make not answer, but it's pretty hard > to know how to make a system with this left open.. > > -Ekr > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------7E5C840D06E869068E4F513F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Brian,

Eric said: "what is the RP supposed to do when they encounter it? This seems kind of under specified".

After reading your explanations below, it looks like the RP can do anything he wants with the "actor".
It is a "claimed actor" and, if we keep the concept, it should be called as such. Such a claim cannot be verified.
A RP could copy and paste that claim in an audit log. No standard action related to the content of such a claim
can be specified in the spec. If the content of a "claimed actor" is used by the RP, it should be only used as an hint
and thus be subject to other verifications which are not specified in this specification.

Denis

Eric, I realize you weren't particularly impressed by my prior statements about the actor claim but, for lack of knowing what else to say, I'm going to kind of repeat what I said about it over in the Phabricator tool and add a little color.

The actor claim is intended as a way to express that delegation has happened and identify the entities involved. Access control or other decisions based on it are at the discretion of the consumer of the token based on whatever policy might be in place.

There are JWT claims that have concise processing rules with respect to whether or not the JWT can be accepted as valid. Some examples are "aud" (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519. E.g. if the token is expired or was intended for someone or something else, reject it.

And there are JWT claims that appropriately don't specify such processing rules and are solely statements of fact or circumstance. Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are good examples of such. There might be application or policy specific rules applied to the content of those kinds of claims (e.g. only subjects from a particular organization are able to access tenant specific data or, less realistic but still possible, disallow access for tokens issued outside of regular business hours) but that's all outside the scope of a specification's definition of the claim.

The actor claim falls into the latter category. It's a way for the issuer of the token to tell the consumer of the token what is going on. But any action to take (or not) based on that information is at the discretion of the token consumer. I honestly don't know it could be anything more. And don't think it should be.

There are two main expected uses of the actor claim (that I'm aware of anyway) that describing here might help. Maybe. One is a human to human delegation case like a customer service rep doing something on behalf of an end user. The subject would be that user and the actor would be the customer service rep. And there wouldn't be any chaining or nesting of the actor. The other case is so called service chaining where a system might exchange a token it receives for a new token that it can use to call a downstream service. And that service in turn might do another exchange to get a new token suitable to call yet another downstream service. And again and so on and turtles all the way. I'm not necessarily endorsing that level of granularity in chaining but it's bound to happen somewhere/sometime. The nested actor claim is able to express that all that has happened with the top level or outermost one being the system currently using the token and prior systems being nested.. What actually gets done with that information is up to the respective systems involved. There might be policy about what system is allowed to call what other system that is enforced. Or maybe the info is just written to an audit log somewhere. Or something else. I don't know. But whatever it is application/deployment/policy dependent and not specifiable by a spec.






On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

I've gone over draft-ietf-oauth-token-exchange-12 and things seem
generally OK. I do still have one remaining concern, which is about
the actor claim. Specifically, what is the RP supposed to do when they
encounter it? This seems kind of underspecified.

In particular:

1. What facts am I supposed to know here? Merely that everyone in
   the chain signed off on the next person in the chain acting as them?

2. Am I just supposed to pretend that the person presenting the token
   is the identity at the top of the chain? Say I have the
   delegation A -> B -> C, and there is some resource which
   B can access but A and C cannot, should I give access?

I think the first question definitely needs an answer. The second
question I guess we could make not answer, but it's pretty hard
to know how to make a system with this left open..

-Ekr


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



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

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


--------------7E5C840D06E869068E4F513F-- From nobody Fri Apr 20 15:43:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226F612420B for ; Fri, 20 Apr 2018 15:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hUdF1HBVYws for ; Fri, 20 Apr 2018 15:43:42 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3381241F3 for ; Fri, 20 Apr 2018 15:43:41 -0700 (PDT) X-AuditID: 12074422-bbdff700000047ff-bc-5ada6d196300 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 46.BD.18431.91D6ADA5; Fri, 20 Apr 2018 18:43:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w3KMhZXR002916; Fri, 20 Apr 2018 18:43:36 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3KMhXVR022267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Apr 2018 18:43:35 -0400 From: Justin Richer Message-Id: <1C26CD81-2DF2-4D9C-B5D6-F95761B426AE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_4C6570B4-4A11-4BFF-A60B-E151D4C6FD3D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 20 Apr 2018 18:43:33 -0400 In-Reply-To: Cc: Neil Madden , "" To: Brian Campbell References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsUixCmqrSuVeyvK4MVSaYvV/28yWsyZ94vN 4uTbV2wOzB432hYweixZ8pPJ4+7RiywBzFFcNimpOZllqUX6dglcGau2tLEUTJ/GVPG3aS97 A+PSd4xdjJwcEgImElcOPmDrYuTiEBJYzCTxc846dpCEkMBGRokDT0MhEteZJPrfHWMFSbAJ qEpMX9PCBGLzClhJfDrazgZiMwskScye18gOETeR2HGlDcwWFrCQOPXoB1g9C1DvjtNPwWxO gUCJr7sWMkP0Rko0r2oCu0hEQF/i9tM57BCLV7NIfH5+nx3iVCWJ/7uOME9g5J+FZN8sJPsg 4toSyxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzM Er3UlNJNjKCQZ3dR2sE48Z/XIUYBDkYlHt4bAreihFgTy4orcw8xSnIwKYnyBmcBhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwFgYC5XhTEiurUovyYVLSHCxK4ryL9++NEhJITyxJzU5NLUgt gsnKcHAoSfBW5QA1ChalpqdWpGXmlCCkmTg4QYbzAA2PA6nhLS5IzC3OTIfIn2K05zj0fkoP M8c5MHns8jQg+e/m/l5mIZa8/LxUKXFeV5A2AZC2jNI8uMmgdOa+zs7iFaM40KPCvDkgVTzA VAg3+xXQWiagtQYqN0DWliQipKQaGLNCm89WLZu7nmO+0Rtb7kWO0l9erT5dOL39V+7u9KJD rO2s61+f2mUyz8bxR5vCcp/J1gzxGjbnHL9p3FjH/GTRqsPHTxXpPu1z99l7S8t4sYS01u2V R/Iqtoa1bDAryvuTO2MXk6mI/1bJYLO1Br8SIlfyLp6yQ6d1s9+2Bdu05pY4Tf1Yp67EUpyR aKjFXFScCAC6IB2IQgMAAA== Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 22:43:46 -0000 --Apple-Mail=_4C6570B4-4A11-4BFF-A60B-E151D4C6FD3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Additional confirmation methods can be easily defined outside of this = draft. That said, I think those two in particular are pretty = straightforward to add (well-known algorithms that are widely available) = so it might make sense to just toss them in now? I think it=E2=80=99s = fine either way. =E2=80=94 Justin > On Apr 19, 2018, at 12:23 PM, Brian Campbell = wrote: >=20 > Okay, so I retract the idea of metadata indicating the hash alg/cnf = method (based on John pointing out that it doesn't really make sense).=20= >=20 > That still leaves the question of whether or not to define additional = confirmation methods in this document (and if so, what they would be = though x5t#S384 and x5t#S512 seem the most likely).=20 >=20 > There's some reasonable rational for both adding one or two new hash = alg confirmation methods in the doc now vs. sticking with just SHA256 = for now. I'll note again that the doc doesn't preclude using or later = defining other confirmation methods. >=20 > I'm kind of on the fence about it, to be honest. But that doesn't = really matter because the draft should reflect rough WG consensus. So = I'm looking to get a rough gauge of rough consensus. At this point = there's one comment out of WGLC asking for additional confirmation = method(s). I don't think that makes for consensus. But I'd ask others = from the WG to chime in, if appropriate, to help me better gauge = consensus.=20 >=20 > On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden = > wrote: > I=E2=80=99m not particularly wedded to SHA-512, just that it should be = possible to use something else. At the moment, the draft seems pretty = wedded to SHA-256. SHA-512 may be overkill, but it is fast (faster than = SHA-256 on many 64-bit machines) and provides a very wide security = margin against any future crypto advances (quantum or otherwise). I=E2=80=99= d also be happy with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems = pretty widely available.=20 >=20 > I don=E2=80=99t think short-lived access tokens is a help if the = likelihood is that certs will be reused for many access tokens.=20 >=20 > Public Web PKI certs tend to only use SHA-256 as it has broad support, = and I gather there were some compatibility issues with SHA-512 certs in = TLS. There are a handful of SHA-384 certs - e.g., the Comodo CA certs = for https://home.cern/ are signed with SHA-384 = (although with RSA-2048, which NSA estimates at only ~112-bit security). = SHA-512 is used on some internal networks where there is more control = over components being used, which is also where people are mostly likely = to care about security beyond 128-bit level (eg government internal = networks).=20 >=20 > By the way, I just mentioned quantum attacks as an example of = something that might weaken the hash in future. Obviously, quantum = attacks completely destroy RSA, ECDSA etc, so SHA-512 would not solve = this on its own, but it provides a considerable margin to hedge against = future quantum *or classical* advances while allowing the paranoid to = pick a stronger security level now.. We have customers that ask for = 256-bit AES already. >=20 > (I also misremembered the quantum attack - =E2=80=9CSerious = Cryptography=E2=80=9D by Aumasson tells me the best known quantum attack = against collision resistance is O(2^n/3) - so ~2^85 for SHA-256 but also = needs O(2^85) space so is impractical. I don=E2=80=99t know if that is = the last word though). =20 >=20 > As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty = broken now with practical collisions having been demonstrated. The kind = of attacks on CA certs demonstrated for MD5 [1] are probably not too far = off for SHA-1 now. As far as I am aware, we=E2=80=99re nowhere near = those kinds of attacks on SHA-256, but I=E2=80=99d prefer that there was = a backup plan in place already rather than waiting to see (and waiting = for everyone to have hard-coded SHA-256 everywhere). >=20 > Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 = :-) >=20 > [1] http://www.win.tue.nl/hashclash/rogue-ca/ = >=20 > Neil >=20 >=20 > On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley > wrote: > The WG discusses RS meta-data as part of one of Dick=E2=80=99s = proposals. I am unclear on who is going to work on it in what draft. >=20 > If the client is doing mtls to both the Token endpoint and RS the = information in the confirmation method is not relevant to the client as = long as the AS and RS are in agreement like with most tokens. >=20 > The hash on the certificate and length of the signing key are equally = or more vulnerable to any sort of attack. > At least with AT the tokens are not long lived. >=20 > Doing anything better than SHA256 only makes sense if the cert is = signed by something stronger like SHA512 with a 2048bit RSA key. That = seems sort of unlikely in the near term. =20 >=20 > I prefer to wait to see what general fix is proposed before we jump = the gun with a bandade for a small part of the overall problem. >=20 > People are typically using SHA1 fingerprints. We added SHA256 for JWT = and got push back on that as overkill.=20 > I don=E2=80=99t think this is the correct place to be deciding this. =20= >=20 > We could say that if new thumbprints are defined the AS and RS can = decide to use them as necessary. > That is sort of the situation we have now. >=20 > The correct solution may be a thousand rounds of PBKDF2 or something = like that to make finding collisions more difficult rather than longer = hashes. >=20 > John B. >=20 > > On Apr 12, 2018, at 5:20 PM, Brian Campbell = > wrote: > >=20 > > That's true about it being opaque to the client. I was thinking of = client metadata (config or registration) as a way for the AS to decide = if to bind the AT to a cert. And moving from a boolean to a conf method = as an extension of that. It would be more meaningful in RS discovery, if = there was such a thing. > >=20 > > I don=E2=80=99t know that SHA512 would be the best choice either but = it is something that is stronger and could be included now. If there's = consensus to do more than SHA256 in this doc. =20 > >=20 > >=20 > >=20 > > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley > wrote: > > Inline > >=20 > > Snip > >=20 > >>=20 > >>=20 > >> 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. > >>=20 > >> The idea behind haveing just one thumbprint hash algorithm was to = keep things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous.=20 > >>=20 > >> That was the thinking anyway. Maybe it is too short sighted though? > >>=20 > >> I do think SHA-256 should stay regardless.=20 > >>=20 > >> But the draft could also define SHA-512 (and maybe others). What do = you and WG folks think about that? > >>=20 > >> *** Yes please.=20 > >>=20 > >> It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to change from just boolean values to something to convey what = hash alg/cnf method the client expects and the list of what the server = supports. That's maybe something that should be done anyway. That'd be a = breaking change to the metadata. But there's already another potential = breaking change identified earlier in this message. So maybe it's worth = doing... > >>=20 > >> How do folks feel about making this kind of change?=20 > >>=20 > >>=20 > > The confirmation method is opaque to the client. I don=E2=80=99t = think adding hash algs to discovery will really help. > > The AS selection needs to be based on what the RS can support. > >=20 > > If anyplace it should be in RS discovery.=20 > >=20 > > As a practical matter you art going to find a client certificate = with more than a SHA256 hash anytime in the near future.=20 > > So for a short lived access token 128bits of collision resistance is = quite good. We are going to have issues with certificates long before = this becomes a problem. > >=20 > > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit = RSA keys, but again that is over the long term. =20 > > We are using short lived access tokens. People should rotate the = certificate more often than once a year if this is a real issue. > >=20 > > I am not against new hash for the fingerprint, but I also don=E2=80=99= t know that SHA512 would be the best choice if we are concerned about = quantum crypto resistance. That is a issue beyond mtls and should be = addressed by CFRG etc. > >=20 > > Regards > > John B. > >=20 > >=20 > >=20 > >=20 > > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_4C6570B4-4A11-4BFF-A60B-E151D4C6FD3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Additional confirmation methods can be easily defined outside = of this draft. That said, I think those two in particular are pretty = straightforward to add (well-known algorithms that are widely available) = so it might make sense to just toss them in now? I think it=E2=80=99s = fine either way.

 =E2=80=94 Justin

On Apr = 19, 2018, at 12:23 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Okay, so I retract the idea = of metadata indicating the hash alg/cnf method (based on John pointing out that it doesn't = really make sense). 

That still leaves the question of whether or not to define = additional confirmation methods in this document = (and if so, what they would be though x5t#S384 and x5t#S512 seem the most = likely). 

There's some reasonable rational for both adding one or two new hash alg confirmation methods in the doc = now vs. sticking with just SHA256 for now. I'll note again that the doc = doesn't preclude using or later defining other confirmation methods.

I'm kind of on the fence about it, to be honest. But that doesn't = really matter because the draft should reflect rough WG consensus. So = I'm looking to get a rough gauge of rough consensus. At this point there's one comment out of WGLC = asking for additional confirmation method(s). I don't think that makes = for consensus. But I'd ask others from the WG to chime = in, if appropriate, to help me better gauge consensus. 

On = Fri, Apr 13, 2018 at 4:49 AM, Neil Madden <neil.madden@forgerock.com> wrote:
I=E2=80=99m = not particularly wedded to SHA-512, just that it should be possible to = use something else. At the moment, the draft seems pretty wedded to = SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on = many 64-bit machines) and provides a very wide security margin against = any future crypto advances (quantum or otherwise). I=E2=80=99d also be = happy with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely = available. 

I don=E2=80=99t think short-lived access = tokens is a help if the likelihood is that certs will be reused for many = access tokens. 

Public Web PKI certs tend to only use SHA-256 = as it has broad support, and I gather there were some compatibility = issues with SHA-512 certs in TLS. There are a handful of SHA-384 certs - = e.g., the Comodo CA certs for https://home.cern/ are signed with SHA-384 = (although with RSA-2048, which NSA estimates at only ~112-bit security). = SHA-512 is used on some internal networks where there is more control = over components being used, which is also where people are mostly likely = to care about security beyond 128-bit level (eg government internal = networks). 

By the way, I just mentioned quantum attacks = as an example of something that might weaken the hash in future. = Obviously, quantum attacks completely destroy RSA, ECDSA etc, so SHA-512 = would not solve this on its own, but it provides a considerable margin = to hedge against future quantum *or classical* advances while allowing = the paranoid to pick a stronger security level now.. We have customers = that ask for 256-bit AES already.

(I also = misremembered the quantum attack - =E2=80=9CSerious Cryptography=E2=80=9D = by Aumasson tells me the best known quantum attack against collision = resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) = space so is impractical. I don=E2=80=99t know if that is the last word = though).  

As for SHA-1, doesn=E2=80=99t that prove the = point? SHA-1 is pretty broken now with practical collisions having been = demonstrated. The kind of attacks on CA certs demonstrated for MD5 [1] = are probably not too far off for SHA-1 now. As far as I am aware, = we=E2=80=99re nowhere near those kinds of attacks on SHA-256, but I=E2=80=99= d prefer that there was a backup plan in place already rather than = waiting to see (and waiting for everyone to have hard-coded SHA-256 = everywhere).

Now I have to get back to my = daughter=E2=80=99s birthday party=E2=80=A6 :-)

[1] http://www.win.tue.nl/hashclash/rogue-ca/

Neil


On Thursday, Apr 12, 2018 at 10:07 pm, John = Bradley <ve7jtb@ve7jtb.com> wrote:
The WG = discusses RS meta-data as part of one of Dick=E2=80=99s proposals.  =  I am unclear on who is going to work on it in what draft.

If the client is doing mtls to both the Token = endpoint and RS the information in the confirmation method is not = relevant to the client as long as the AS and RS are in agreement like = with most tokens.

The hash on the = certificate and length of the signing key are equally or more vulnerable = to any sort of attack.
At least with AT the tokens are not = long lived.

Doing anything better than = SHA256 only makes sense if the cert is signed by something stronger like = SHA512 with a 2048bit RSA key.   That seems sort of unlikely = in the near term.  

I prefer to wait to see what general fix is proposed before = we jump the gun with a bandade for a small part of the overall = problem.

People are typically using SHA1 = fingerprints.  We added SHA256 for JWT and got push back on that as = overkill. 
I don=E2=80=99t think this is the correct place to be = deciding this.   

We could say = that if new thumbprints are defined the AS and RS can decide to use them = as necessary.
That is sort of the situation we have = now.

The correct solution may be a thousand = rounds of PBKDF2 or something like that to make finding collisions more = difficult rather than longer hashes.

John = B.

> On Apr 12, 2018, at 5:20 PM, Brian = Campbell <bcampbell@pingidentity.com> wrote:
> 
> That's true about it being opaque to the client. I was = thinking of client metadata (config or registration) as a way for the AS = to decide if to bind the AT to a cert. And moving from a boolean to a = conf method as an extension of that. It would be more meaningful in RS = discovery, if there was such a thing.
> 
> I = don=E2=80=99t know that SHA512 would be the best choice either but it is = something that is stronger and could be included now. If there's = consensus to do more than SHA256 in this doc.  
> 
> 
> 
> On Thu, = Apr 12, 2018 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
> Inline
> 
> Snip
> 
>> 
>> 
>> 12. The use of only SHA-256 fingerprints means that = the security strength of the sender-constrained access tokens is limited = by the collision resistance of SHA-256 - roughly =E2=80=9C128-bit = security" - without a new specification for a new thumbprint algorithm. = An implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512.
>> 
>> The = idea behind haveing just one thumbprint hash algorithm was to keep = things simple. And SHA-256 seems good enough for the reasonably = foreseeable future (and space aware). Also a new little spec to register = a different hash algorithm, should the need arise, didn't seem = particularity onerous. 
>> 
>> = That was the thinking anyway. Maybe it is too short sighted though?
>> 
>> I do think SHA-256 should stay regardless. 
>> 
>> But = the draft could also define SHA-512 (and maybe others). What do you and = WG folks think about that?
>> 
>> *** = Yes please. 
>> 
>> It would probably then be useful for the metadata in = =C2=A73.3 and =C2=A73.4 to change from just boolean values to something = to convey what hash alg/cnf method the client expects and the list of = what the server supports. That's maybe something that should be done = anyway. That'd be a breaking change to the metadata. But there's already = another potential breaking change identified earlier in this message. So = maybe it's worth doing...
>> 
>> How = do folks feel about making this kind of change? 
>> 
>> 
> The = confirmation method is opaque to the client.  I don=E2=80=99t think = adding hash algs to discovery will really help.
> The = AS selection needs to be based on what the RS can support.
> 
> If anyplace it should be in RS discovery. 
> 
> As a = practical matter you art going to find a client certificate with more = than a SHA256 hash anytime in the near future. 
> So for = a short lived access token 128bits of collision resistance is quite = good.   We are going to have issues with certificates long = before this becomes a problem.
> 
> SHA256 = is appropriate for AES128 256bit elliptic curves and 3072bit RSA keys, = but again that is over the long term.  
> We are = using short lived access tokens.  People should rotate the = certificate more often than once a year if this is a real issue.
> 
> I am not against new hash for the fingerprint, but I = also don=E2=80=99t know that SHA512 would be the best choice if we are = concerned about quantum crypto resistance.   That is a issue = beyond mtls and should be addressed by CFRG etc.
> 
> = Regards
> John B.
> 
> 
> 
> 
> = CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.



CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole = use of the intended recipient(s). Any review, use, distribution or = disclosure by others is strictly prohibited..  If you have received = this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your = computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_4C6570B4-4A11-4BFF-A60B-E151D4C6FD3D-- From nobody Fri Apr 20 17:26:44 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38312D95E; Fri, 20 Apr 2018 17:26:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152427039807.20560.17372637737943100805@ietfa.amsl.com> Date: Fri, 20 Apr 2018 17:26:38 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 00:26:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-09.txt Pages : 18 Date : 2018-04-20 Abstract: This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 23 06:28:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BAB127871 for ; Mon, 23 Apr 2018 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OedZnH82D8M for ; Mon, 23 Apr 2018 06:28:20 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E433E126C89 for ; Mon, 23 Apr 2018 06:28:19 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o7-v6so16597233iob.8 for ; Mon, 23 Apr 2018 06:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T6vza/vmO1CZ5M5iTWZKZp04/OsuZRXjxJ9JxG7ixPk=; b=fBgcZHdn0iUVD8jMGTKdFAXXtaeFt9VpT1eX14lWq+8/FBT7JszCIgRn2YJjsob46f zdyx1RNs6Y7Gz1MquYLY5VVjNG3LXZ+H5ZGtYityoGBE3a2bMuQpwUam0jAZUE8gctF8 27gKQcH3WVl7r6anxjEhD+w+9vLAl2fBewvqg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T6vza/vmO1CZ5M5iTWZKZp04/OsuZRXjxJ9JxG7ixPk=; b=BOAL1RdreGba6chowKmSNrsCHID1+aGR8tgn/GUtAIL1bL2peGyyAz6yKusgf1JZfA MmWjV62ptE75ExZ1NpKqd7Ld7XYXYinqX/Cz7WpRFVnn2kh32wT48nFNJ96P1FgB3qWH RGNf6RIbFwN41RGzukc00GMW7YgWi9KxsRNtIetrs12JF5bKerCnf+SSasTykvRsat2E BmSZxJ/RTfwkHkyo+jByiZoUd8wRB0d6WdPyRB+ug5RlDloPD4mxx4YlV4NX4bmqG2Yi /JLkJRagt9E3iCELhazTsD2x6FQOxY1Cgb4KgmoDuSLG4pzTp0+XHhWA6ajv/3A4LsWz CMzQ== X-Gm-Message-State: ALQs6tAP98jMuiGMAyUXHVP23Sd8zadDc++wgic5QT564jNwt4BO7bAS BUBIzN5auefWX5e9qi86MdjWHYatCJ8/r2NGX65dTcK+W5Y18kHM3mOxqBSkVJxPnOplq/wxTBT 12HnyjXxdvoOxQg== X-Google-Smtp-Source: AB8JxZq49HOwmakFKbuWgIqSoj91y1ZlygEh7OThEovNzsAxZlmILZrtPxEh3DlbvvGoyN6EzapDYsfamNGroFJrsGg= X-Received: by 2002:a6b:8361:: with SMTP id f94-v6mr20382878iod.17.1524490098939; Mon, 23 Apr 2018 06:28:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 06:27:48 -0700 (PDT) In-Reply-To: <1C26CD81-2DF2-4D9C-B5D6-F95761B426AE@mit.edu> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <1C26CD81-2DF2-4D9C-B5D6-F95761B426AE@mit.edu> From: Brian Campbell Date: Mon, 23 Apr 2018 07:27:48 -0600 Message-ID: To: Justin Richer Cc: Neil Madden , "" Content-Type: multipart/alternative; boundary="000000000000cfbe6d056a84025f" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 13:28:24 -0000 --000000000000cfbe6d056a84025f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's pretty much in line with my on-the-fence position on it. On Fri, Apr 20, 2018 at 4:43 PM, Justin Richer wrote: > Additional confirmation methods can be easily defined outside of this > draft. That said, I think those two in particular are pretty > straightforward to add (well-known algorithms that are widely available) = so > it might make sense to just toss them in now? I think it=E2=80=99s fine e= ither way. > > =E2=80=94 Justin > > On Apr 19, 2018, at 12:23 PM, Brian Campbell > wrote: > > Okay, so I retract the idea of metadata indicating the hash alg/cnf > method (based on John pointing out that it doesn't really make sense). > > That still leaves the question of whether or not to define additional > confirmation methods in this document (and if so, what they would be > though x5t#S384 and x5t#S512 seem the most likely). > > There's some reasonable rational for both adding one or two new hash alg > confirmation methods in the doc now vs. sticking with just SHA256 for > now. I'll note again that the doc doesn't preclude using or later definin= g > other confirmation methods. > > I'm kind of on the fence about it, to be honest. But that doesn't really > matter because the draft should reflect rough WG consensus. So I'm lookin= g > to get a rough gauge of rough consensus. At this point there's one > comment out of WGLC asking for additional confirmation method(s). I don't > think that makes for consensus. But I'd ask others from the WG to chime > in, if appropriate, to help me better gauge consensus. > > On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden > wrote: > >> I=E2=80=99m not particularly wedded to SHA-512, just that it should be p= ossible >> to use something else. At the moment, the draft seems pretty wedded to >> SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on >> many 64-bit machines) and provides a very wide security margin against a= ny >> future crypto advances (quantum or otherwise). I=E2=80=99d also be happy= with >> SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely available. >> >> I don=E2=80=99t think short-lived access tokens is a help if the likelih= ood is >> that certs will be reused for many access tokens. >> >> Public Web PKI certs tend to only use SHA-256 as it has broad support, >> and I gather there were some compatibility issues with SHA-512 certs in >> TLS. There are a handful of SHA-384 certs - e.g., the Comodo CA certs fo= r >> https://home.cern/ are signed with SHA-384 (although with RSA-2048, >> which NSA estimates at only ~112-bit security). SHA-512 is used on some >> internal networks where there is more control over components being used= , >> which is also where people are mostly likely to care about security beyo= nd >> 128-bit level (eg government internal networks). >> >> By the way, I just mentioned quantum attacks as an example of something >> that might weaken the hash in future. Obviously, quantum attacks complet= ely >> destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but = it >> provides a considerable margin to hedge against future quantum *or >> classical* advances while allowing the paranoid to pick a stronger secur= ity >> level now.. We have customers that ask for 256-bit AES already. >> >> >> (I also misremembered the quantum attack - =E2=80=9CSerious Cryptography= =E2=80=9D by >> Aumasson tells me the best known quantum attack against collision >> resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) spa= ce >> so is impractical. I don=E2=80=99t know if that is the last word though)= . >> >> As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty brok= en now >> with practical collisions having been demonstrated. The kind of attacks = on >> CA certs demonstrated for MD5 [1] are probably not too far off for SHA-1 >> now. As far as I am aware, we=E2=80=99re nowhere near those kinds of att= acks on >> SHA-256, but I=E2=80=99d prefer that there was a backup plan in place al= ready >> rather than waiting to see (and waiting for everyone to have hard-coded >> SHA-256 everywhere). >> >> Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 = :-) >> >> [1] http://www.win.tue.nl/hashclash/rogue-ca/ >> >> Neil >> >> >> On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley >> wrote: >> The WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals= . I am >> unclear on who is going to work on it in what draft. >> >> If the client is doing mtls to both the Token endpoint and RS the >> information in the confirmation method is not relevant to the client as >> long as the AS and RS are in agreement like with most tokens. >> >> The hash on the certificate and length of the signing key are equally or >> more vulnerable to any sort of attack. >> At least with AT the tokens are not long lived. >> >> Doing anything better than SHA256 only makes sense if the cert is signed >> by something stronger like SHA512 with a 2048bit RSA key. That seems s= ort >> of unlikely in the near term. >> >> I prefer to wait to see what general fix is proposed before we jump the >> gun with a bandade for a small part of the overall problem. >> >> People are typically using SHA1 fingerprints. We added SHA256 for JWT >> and got push back on that as overkill. >> I don=E2=80=99t think this is the correct place to be deciding this. >> >> We could say that if new thumbprints are defined the AS and RS can decid= e >> to use them as necessary. >> That is sort of the situation we have now. >> >> The correct solution may be a thousand rounds of PBKDF2 or something lik= e >> that to make finding collisions more difficult rather than longer hashes= . >> >> John B. >> >> > On Apr 12, 2018, at 5:20 PM, Brian Campbell >> wrote: >> > >> > That's true about it being opaque to the client. I was thinking of >> client metadata (config or registration) as a way for the AS to decide i= f >> to bind the AT to a cert. And moving from a boolean to a conf method as = an >> extension of that. It would be more meaningful in RS discovery, if there >> was such a thing. >> > >> > I don=E2=80=99t know that SHA512 would be the best choice either but i= t is >> something that is stronger and could be included now. If there's consens= us >> to do more than SHA256 in this doc. >> > >> > >> > >> > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley >> wrote: >> > Inline >> > >> > Snip >> > >> >> >> >> >> >> 12. The use of only SHA-256 fingerprints means that the security >> strength of the sender-constrained access tokens is limited by the >> collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - w= ithout a >> new specification for a new thumbprint algorithm. An implication of this= is >> that is is fairly pointless for the protected resource TLS stack to ever >> negotiate cipher suites/keys with a higher level of security. In more >> crystal ball territory, if a practical quantum computer becomes a >> possibility within the lifetime of this spec, then the expected collisio= n >> resistance of SHA-256 would drop quadratically, allowing an attacker to >> find a colliding certificate in ~2^64 effort. If we are going to pick ju= st >> one thumbprint hash algorithm, I would prefer we pick SHA-512. >> >> >> >> The idea behind haveing just one thumbprint hash algorithm was to kee= p >> things simple. And SHA-256 seems good enough for the reasonably foreseea= ble >> future (and space aware). Also a new little spec to register a different >> hash algorithm, should the need arise, didn't seem particularity onerous= . >> >> >> >> >> That was the thinking anyway. Maybe it is too short sighted though? >> >> >> >> I do think SHA-256 should stay regardless. >> >> >> >> But the draft could also define SHA-512 (and maybe others). What do >> you and WG folks think about that? >> >> >> >> *** Yes please. >> >> >> >> It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to >> change from just boolean values to something to convey what hash alg/cnf >> method the client expects and the list of what the server supports. That= 's >> maybe something that should be done anyway. That'd be a breaking change = to >> the metadata. But there's already another potential breaking change >> identified earlier in this message. So maybe it's worth doing... >> >> >> >> How do folks feel about making this kind of change? >> >> >> >> >> > The confirmation method is opaque to the client. I don=E2=80=99t thin= k adding >> hash algs to discovery will really help. >> > The AS selection needs to be based on what the RS can support. >> > >> > If anyplace it should be in RS discovery. >> > >> > As a practical matter you art going to find a client certificate with >> more than a SHA256 hash anytime in the near future. >> > So for a short lived access token 128bits of collision resistance is >> quite good. We are going to have issues with certificates long before >> this becomes a problem. >> > >> > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RS= A >> keys, but again that is over the long term. >> > We are using short lived access tokens. People should rotate the >> certificate more often than once a year if this is a real issue. >> > >> > I am not against new hash for the fingerprint, but I also don=E2=80=99= t know >> that SHA512 would be the best choice if we are concerned about quantum >> crypto resistance. That is a issue beyond mtls and should be addressed= by >> CFRG etc. >> > >> > Regards >> > John B. >> > >> > >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you. >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000cfbe6d056a84025f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's pretty much in line with my on-the-fence positi= on on it.

On Fri, Apr 20, 2018 at 4:43 PM, Justin Richer <jricher@mit.edu> wrote:
Additional confirmation methods can be= easily defined outside of this draft. That said, I think those two in part= icular are pretty straightforward to add (well-known algorithms that are wi= dely available) so it might make sense to just toss them in now? I think it= =E2=80=99s fine either way.

=C2=A0=E2=80=94 Justin

On Apr 19, 2018, at = 12:23 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Okay, so I retract t= he idea of metadata indicating the=C2=A0hash alg/cn= f method (based on John pointing out that it doesn't really make sense)= .=C2=A0<= br>
That still leaves the q= uestion of whether or not to define additional=C2=A0confirmation=C2=A0methods in this document (and if so, what they= would be though x5t#S384 and=C2=A0x5t#S512=C2=A0seem the most likely).=C2=A0

There's some reasonable rational for both adding one or two=C2=A0new hash alg=C2=A0confirmation=C2=A0method<= /span>s in the doc now vs. sticking with just SHA256 for now. I'll note= again that the doc doesn't preclude using or later defining other conf= irmation methods.

I'= ;m kind of on the fence about it, to be honest. But that doesn't really= matter because the draft should reflect rough WG consensus. So I'm loo= king to get a rough gauge of rough=C2=A0consensus. At this point there's one comment out of WGLC asking for additio= nal confirmation method(s). I don't think that makes for=C2=A0consensus. But= I'd ask others from the WG to chime in, if appropriate, to help me bet= ter gauge=C2=A0cons= ensus.=C2=A0

On Fri, Apr 13, = 2018 at 4:49 AM, Neil Madden=C2=A0<neil.madden@forgerock.com><= /span>=C2=A0wrote:
I=E2=80=99m not part= icularly wedded to SHA-512, just that it should be possible to use somethin= g else. At the moment, the draft seems pretty wedded to SHA-256. SHA-512 ma= y be overkill, but it is fast (faster than SHA-256 on many 64-bit machines)= and provides a very wide security margin against any future crypto advance= s (quantum or otherwise). I=E2=80=99d also be happy with SHA-384, SHA3-512,= Blake2 etc but SHA-512 seems pretty widely available.=C2=A0

I don=E2=80=99t= think short-lived access tokens is a help if the likelihood is that certs = will be reused for many access tokens.=C2=A0

Public Web PKI certs tend to on= ly use SHA-256 as it has broad support, and I gather there were some compat= ibility issues with SHA-512 certs in TLS. There are a handful of SHA-384 ce= rts - e.g., the Comodo CA certs for=C2=A0https://home.cern/=C2=A0are signed with SHA-384 (alth= ough with RSA-2048, which NSA estimates at only ~112-bit security). SHA-512= is used on some internal networks where there is more control over compone= nts being used, which is also where people are mostly likely to care about = security beyond 128-bit level (eg government internal networks).=C2=A0

By the way, I just mentioned quantum attacks as an example of something t= hat might weaken the hash in future. Obviously, quantum attacks completely = destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it = provides a considerable margin to hedge against future quantum *or classica= l* advances while allowing the paranoid to pick a stronger security level n= ow.. We have customers that ask for 256-bit AES already.


(I also misremembered the quantum attack - =E2=80=9CSerious Cry= ptography=E2=80=9D by Aumasson tells me the best known quantum attack again= st collision resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O= (2^85) space so is impractical. I don=E2=80=99t know if that is the last wo= rd though).=C2=A0=C2=A0

As for SHA-1, doesn=E2=80=99t that prove the point? = SHA-1 is pretty broken now with practical collisions having been demonstrat= ed. The kind of attacks on CA certs demonstrated for MD5 [1] are probably n= ot too far off for SHA-1 now. As far as I am aware, we=E2=80=99re nowhere n= ear those kinds of attacks on SHA-256, but I=E2=80=99d prefer that there wa= s a backup plan in place already rather than waiting to see (and waiting fo= r everyone to have hard-coded SHA-256 everywhere).

Now I have to get= back to my daughter=E2=80=99s birthday party=E2=80=A6 :-)

[1]=C2=A0http://www.win.tue.nl/hashclash/rogue-ca/

Neil


On Thursday, Apr 12, 2018 at 10:07 pm, John Bradl= ey <ve7jtb@ve7jtb= .com> wrote:
The WG discusses RS meta-data as part of one of Dick= =E2=80=99s proposals.=C2=A0 =C2=A0I am unclear on who is going to work on i= t in what draft.

If the client is doing mtls to both the Token endpo= int and RS the information in the confirmation method is not relevant to th= e client as long as the AS and RS are in agreement like with most tokens.
The hash on the certificate and length of the signing key are equally= or more vulnerable to any sort of attack.
At least with AT the tokens a= re not long lived.

Doing anything better than SHA256 only makes sens= e if the cert is signed by something stronger like SHA512 with a 2048bit RS= A key.=C2=A0 =C2=A0That seems sort of unlikely in the near term.=C2=A0=C2=A0
I prefer to wait to see what general fix is proposed before we jump the gu= n with a bandade for a small part of the overall problem.

People are= typically using SHA1 fingerprints.=C2=A0 We added SHA256 for JWT and got p= ush back on that as overkill.=C2=A0
I don=E2=80=99t think this is the correct pl= ace to be deciding this.=C2=A0 =C2=A0

We could say that if new thumb= prints are defined the AS and RS can decide to use them as necessary.
Th= at is sort of the situation we have now.

The correct solution may be= a thousand rounds of PBKDF2 or something like that to make finding collisi= ons more difficult rather than longer hashes.

John B.

> On= Apr 12, 2018, at 5:20 PM, Brian Campbell <bcampbell@pingidentity.com> wrote= :
>=C2=A0=
> That's true about it being opaque to the client. I was = thinking of client metadata (config or registration) as a way for the AS to= decide if to bind the AT to a cert. And moving from a boolean to a conf me= thod as an extension of that. It would be more meaningful in RS discovery, = if there was such a thing.
>=C2=A0
> I don=E2=80=99t know that SHA512 w= ould be the best choice either but it is something that is stronger and cou= ld be included now. If there's consensus to do more than SHA256 in this= doc.=C2=A0=C2= =A0
>=C2=A0
>=C2=A0
>=C2=A0
> On Thu, Apr 12, 2018 at 1:52 PM, John = Bradley <ve7jtb@v= e7jtb.com> wrote:
> Inline
>=C2=A0
> Snip
>=C2=A0
>>= ;=C2=A0<= br>>>=C2= =A0
>> 12. The use of only SHA-256 fingerprints means that = the security strength of the sender-constrained access tokens is limited by= the collision resistance of SHA-256 - roughly =E2=80=9C128-bit security&qu= ot; - without a new specification for a new thumbprint algorithm. An implic= ation of this is that is is fairly pointless for the protected resource TLS= stack to ever negotiate cipher suites/keys with a higher level of security= . In more crystal ball territory, if a practical quantum computer becomes a= possibility within the lifetime of this spec, then the expected collision = resistance of SHA-256 would drop quadratically, allowing an attacker to fin= d a colliding certificate in ~2^64 effort. If we are going to pick just one= thumbprint hash algorithm, I would prefer we pick SHA-512.
>>=C2=A0
&g= t;> The idea behind haveing just one thumbprint hash algorithm was to ke= ep things simple. And SHA-256 seems good enough for the reasonably foreseea= ble future (and space aware). Also a new little spec to register a differen= t hash algorithm, should the need arise, didn't seem particularity oner= ous.=C2=A0
>>= =C2=A0
>> That was the thinking anyway. Maybe it is too sho= rt sighted though?
>>=C2=A0
>> I do think SHA-256 should stay reg= ardless.=C2=A0<= /span>
>>=C2=A0
>> But the draft could also define SHA-512 (and m= aybe others). What do you and WG folks think about that?
>>=C2=A0
>&= gt; *** Yes please.=C2=A0
>>=C2=A0
>> It would probably then be useful fo= r the metadata in =C2=A73.3 and =C2=A73.4 to change from just boolean value= s to something to convey what hash alg/cnf method the client expects and th= e list of what the server supports. That's maybe something that should = be done anyway. That'd be a breaking change to the metadata. But there&= #39;s already another potential breaking change identified earlier in this = message. So maybe it's worth doing...
>>=C2=A0
>> How do folk= s feel about making this kind of change?=C2=A0
>>=C2=A0
>>=C2=A0
> The conf= irmation method is opaque to the client.=C2=A0 I don=E2=80=99t think adding= hash algs to discovery will really help.
> The AS selection needs to= be based on what the RS can support.
>=C2=A0
> If anyplace it should b= e in RS discovery.=C2=A0
>=C2=A0
> As a practical matter you art going to find = a client certificate with more than a SHA256 hash anytime in the near futur= e.=C2=A0=
> So for a short lived access token 128bits of collision resistance = is quite good.=C2=A0 =C2=A0We are going to have issues with certificates lo= ng before this becomes a problem.
>=C2=A0
> SHA256 is appropriate for A= ES128 256bit elliptic curves and 3072bit RSA keys, but again that is over t= he long term.=C2=A0=C2=A0
> We are using short lived access tokens.=C2=A0 Peo= ple should rotate the certificate more often than once a year if this is a = real issue.
>=C2=A0
> I am not against new hash for the fingerprint, bu= t I also don=E2=80=99t know that SHA512 would be the best choice if we are = concerned about quantum crypto resistance.=C2=A0 =C2=A0That is a issue beyo= nd mtls and should be addressed by CFRG etc.
>=C2=A0
> Regards
> = John B.
>= =C2=A0
>=C2=A0
>=C2=A0
>=C2=A0
> CONFIDENTIALITY NOTICE: This email = may contain confidential and privileged material for the sole use of the in= tended recipient(s). Any review, use, distribution or disclosure by others = is strictly prohibited.=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.

=


CONFIDENTIALITY NOTICE: This= email may contain confidential and privileged material for the sole use of= the intended recipient(s). Any review, use, distribution or disclosure by = others is strictly prohibited..=C2=A0 If you have received this communicati= on in error, please notify the sender immediately by e-mail and delete the = message and any file attachments from your computer. Thank you.___________= ____________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000cfbe6d056a84025f-- From nobody Mon Apr 23 07:57:38 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C34129C51 for ; Mon, 23 Apr 2018 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbkqr_WeNMZF for ; Mon, 23 Apr 2018 07:57:33 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC851270A7 for ; Mon, 23 Apr 2018 07:57:33 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z73-v6so42183161wrb.0 for ; Mon, 23 Apr 2018 07:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ArAT6oVD1M4n5kPJxhe/+ofcioup0czcPgOdCYKgmYY=; b=ozi7ZoLk8xRzopoZtICuunO3b58w/KvCNsFKV8d9xaUeMCQXCGDCqT7qbJ2XGdHGKI OWEymPZbrbD90lTRS5fm70gZj9zeTIclWuPZcvm04nIhpX/2JkBsRi3ri7ZNwWq/ZmxT EnTCdILqdZHBF4Rjr2iWTpU5IVzN6ys8appW9oKItn6AjFxpWOyHaOvH8hsqI/Z4avtQ Me4iwA97nK6QHD0CeS728vwZz8bGfmGdpX2NvoZLWdcdp9xUejD0UASQrBWw5y1qFuNh rC/H+N6Y6eGUzpfwI714M6rLH08TRhgsO5pM/aQDb7AbdmqjEY0Pf/YxnnuMFSQwEqQ5 5m5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ArAT6oVD1M4n5kPJxhe/+ofcioup0czcPgOdCYKgmYY=; b=QG4eX4dvo52DC/F6KXSoXosvEdau5s2XLwV2+EpoB2+w85QIL1wStEpqlyszL52p8j 3dbW7yzjMeuwHipJXqvQsr//wIUmIPYfy0QtHIwNqF4gckrbm8cS4CIvi68BAx9modTr zEztLrgzgFdqnrtF3HCKs7Ebi8nBVYUKyFsnbxMThIqZsC2lr+BzYyd3MT0RGluzXdIU wJgdhq03Zp+Q7jgYNQeBjcraMpbyCrdbTMwxz6oj6A8tCQvkN6Hw0vmVibB5PKQqY/kK CGD2wGdMt3lBEzCyqixQ9B4S1peCuUcQdZvdWxbhDELvpvIW+h0oqcOMaKPhTNxuMhmh 3ZHQ== X-Gm-Message-State: ALQs6tAsSvLZuRgeuWJiPD5WQidopaVu7TENQeJJm7g5HJCBXwt0RqML FxXsKMCfNzsFMLmciUWHlXzHJkKn X-Google-Smtp-Source: AB8JxZpbm/B7/6ZZzgM+3FpTOnU6bcVlAURo0pSbC6oigKWxCmev+TvbfEz/mcsYNDDfC1KliPiqcQ== X-Received: by 2002:adf:d245:: with SMTP id o5-v6mr1061639wri.134.1524495451258; Mon, 23 Apr 2018 07:57:31 -0700 (PDT) Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id m35-v6sm8196145wrm.51.2018.04.23.07.57.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 07:57:30 -0700 (PDT) To: oauth@ietf.org References: From: Yaron Sheffer Message-ID: Date: Mon, 23 Apr 2018 17:57:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 14:57:37 -0000 Hi Neil, Thank you again for your review and the follow up. Please see my comments in-line. ‏Yaron > > Hi Mike, > > I sent this originally back in June last year, I can see some of these points have been addressed in -01, but not others, so I will include further comments in-line below. (Apologies if I missed replies - I?ve realised a few messages from this WG have ended up in my spam folder). > > As a general point, the BCP is for JWT, but some of the advice (and my points below) apply more generally to other JOSE objects (as pointed out in the introduction). Should this be reflected in the title? > > >> On 4 Jun 2017, at 15:11, Neil Madden wrote: >> >> I originally set this message just to the BCP authors. As requested by Mike Jones, I am sending it here too: >> >> Hi, >> >> I've just seen this draft best-practice guide for JWTs pop up. I have a number of suggestions for improvements. Mostly, I think the advice is good but should be spelt out a bit more clearly. Here are some suggestions: >> >> 1. Explicitly spell out the ECDH-ES public key validation routines from NIST. I have a blog post summarising them: https://neilmadden.wordpress.com/2017/05/17/so-how-do-you-validate-nist-ecdh-public-keys/ > > To be clear here, I think section 3.4 (Validate Cryptographic Inputs) should have text along the lines of the following added: > > ?ECDH-ES ephemeral public key (epk) inputs should be validated according to the recipient?s chosen elliptic curve. For NIST prime-order curves P-256, P-384 and P-521, validation MUST be performed according to Section 5.6.2.3.4 ?ECC Partial Public-Key Validation Routine? of NIST Special Publication 800-56A revision 3 [1]. Where the X25519 or X448 curves of RFC 8037 [2] are used, then the implementation MAY reject any ephemeral public key that produces an all-zero ECDH shared secret as per RFC 7748 Section 6 [3]." > > [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf > [2] https://tools.ietf.org/html/rfc8037 > [3] https://tools.ietf.org/html/rfc7748#section-6 > > I should note that the final sentence about validating X25519/X448 public keys is not without some controversy. See https://moderncrypto.org/mail-archive/curves/2017/000896.html for a rabbit-hole discussion together with associated links. > > I do not feel confident to say what the right answer is for those curves - whether to validate at all, and if so whether to blacklist bad public keys or check for an all-zero shared secret. Perhaps we should get CFRG input on this point? Or should we take RFC 7748 as being the considered CFRG opinion on this topic (and so copy the ?MAY? wording)? I think a MAY check is useless in practice, and also, the link you mention argues quite convincingly against the 25519 check. So I propose to adopt the first part of your text. > >> 2. Recommend that (despite the -ES) ECDH is safest when *both* keys are ephemeral (eg you use some initial step to retrieve a fresh authenticated ephemeral key from the other party). > > I think this comment is not necessary in hindsight. While fully-ephemeral ECDH has some advantages (as does static-static in some cases, e.g. NaCl crypto_box), it?s a more complicated discussion. For this BCP it is best to concentrate on ECDH-ES as specified and ensure that implementations perform proper validation of ephemeral public keys. > Agree. >> 3. Spell out how to authenticate ECDH ephemeral keys. For instance, include an inner signed JWT that repeats the epk and possibly the apu/apv claims too. > > This is probably a more general point that none of the public-key encryption modes in JOSE are authenticated. If sender authentication is required then nested signed-and-encrypted objects should be used. > Yes, and it's not up to the BCP to add new authenticated modes. >> 4. Recommend that the apu and apv claims as a bare minimum include a hash of both public keys and SHOULD include any other known identifiers. I'm not clear about "apu" in the general use case for JWT, where the identity of the recipient of a JWT is not known in advance to the sender. Also, RFC 7518 uses "Alice" and "Bob" in these claims, and does not include any hashes. (And see my next comment). > > Section 5.8.2 of NIST SP.800-56A rev 3 (referenced in point 1 above) gives some advice on the kinds of things that should be included here. Appendix B of the same document provides some rationale for why this should be done, as does RFC 7748 Section 7 (Security Considerations). RFC 7518 (JWA) Section 4.6.2 already normatively references NIST SP.800-56A, but only for ?applications wishing to conform to [NIST.800-56A]?. In my opinion, this should be strengthened in this BCP to a SHOULD/RECOMMENDED. > >> 5. Recommend that the receiving party recalculates the apu and apv claims from known inputs to check they match. (Or leave these out of the JWT and require the other party to recalculate them). But this would require normative language on the contents of these claims, which does not appear in existing RFCs. I would hesitate to include such language in a BCP. There must be a very good reason for a BCP to make existing implementations non-conformant. >> 6. Provide explicit key lifetime requirements. E.g., for AES GCM this should not exceed 2^32 messages for randomly-generated IVs, and not exceed 2^64 *blocks* in total (so unless you restrict JWT lengths to less than 2^32 blocks and use a message counter as IV then this also limits to 2^32 messages). For CBC it should not exceed 2^48 messages. > > I withdraw this comment, RFC 7518 Section 8.2 already addresses this point. > >> 7. Require that the "alg" and "enc" claims are ONLY used to reject unexpected algorithms, NEVER to select an algorithm (even amongst a "supported" set). Cryptographic agility should be achieved by using "kid" claims that reference one of a set of known keys and the key should specify the algorithm (either explicitly or by the key parameters/size). > > I think this is now adequately addressed by section 3.1. > >> 8. Deprecate or strongly recommend against all of the RSA encryption modes except OAEP-256. Yes. What about RSA with/without PSS? >> 9. Strongly discourage any use of compression with encrypted JWEs - it is too easy to leak sensitive information. >> 10. Recommend that if a JWE is used to encrypt a password or other value for which knowing the length may be a weakness, that such fields are explicitly padded by the application or at least use CBC mode to reduce the amount of length information leaked to a multiple of the AES block size. > > These last two points are related: encryption hides everything apart from the length of a plaintext. Compression varies the length based on the content. The combination of the two weakens the security of the encryption, but the length may already be sensitive. Applications should consider what information might be leaked in these cases and make informed decisions about whether to pad or compress content before encryption. Agree. > >> 11. Require constant-time comparisons of HMAC tags. > > This point is already covered by RFC 7518 Section 3.2. > >> 12. Recommend using deterministic ECDSA signatures as described in RFC 6979 to minimise the risk of leaking the private key. I'm not sure how this would interact with JWE. I suspect these signatures would have to be defined as a new algorithm (so out of scope for the BCP). >> 13. Recommend that if the ECDH calculation produces an all-zero shared secret that this is rejected. > > This is covered in my suggestion in point 1. > >> 14. Never produce a signed JWT containing a "sub" claim unless you are explicitly vouching for the identity of that subject. It is far too easy to accidentally produce valid OIDC id tokens from unrelated code! > > I think this is now covered by the section on explicit typing. > > Explicit typing is a welcome addition. A complementary approach would be to recommend using different cryptographic keys for different types of JWTs. One way to achieve this for symmetric algorithms or ECDH would be to use a key-derivation function to derive unique keys based on some domain separation string. > > I find the discussion in section 3.2 about the ?none? algorithm unnecessary for the BCP. I would say using ?none? should not be a recommended best practice. > > A colleague recently shared this pen-tester JWT cheat-sheet with me: https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_security_cheatsheet.pdf which hints at a few other points worth mentioning (I can draft text for these if you wish): > > - If the ?kid? header is used to perform a lookup in a database then there is a risk of SQL/LDAP injection if the value is not validated first or appropriate interfaces used (e.g. prepared statements). > - The ?jwk? header should not be directly trusted, but only ever used to match a known key. I agree about kid and jku, but I'm not familiar with all valid use cases of "jwk" so would appreciate more opinions regarding this statement. Likewise, I?d say the ?jku? header should really be matched against a known whitelist before being trusted, as it might additionally lead to SSRF attacks if the server can be tricked into loading arbitrary URLs. > > Kind regards, > > Neil > > > --- From nobody Mon Apr 23 09:37:56 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4954012D7F7 for ; Mon, 23 Apr 2018 09:37:55 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wazd7ER4n13f for ; Mon, 23 Apr 2018 09:37:53 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376CB12D7F6 for ; Mon, 23 Apr 2018 09:37:53 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id j11so9759364pff.10 for ; Mon, 23 Apr 2018 09:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JqiGJPP+1qWZHSJUYNwoHlilt+YrbBqs2mlaeqlK+NY=; b=dNY00I/7+MPzXH2b6ogkDdLGSfNqrijlZBwqaLduplpPNWGBoWCZAIL9Pu6mQI4zrm O/HVtrdOKmmskvYzs5wS9jk4ly32tWQ+weWZ7tLVedmkNl2L+4q22qJQkMsf3kpAI3Gi 2hoIRAACZKiTKCSP4XHeKTXRDrZWwNlLVarAlFNwRM1F3sHI5iNw0xyE7vZg1eWPzVuT x36xrjxvkv1B+xnfn/hbvPdpbFxOrBPPZQb/Jh6VWxub17g5NHywAtQmlOnkNWDfraIH PXhPEFsnIgv2w5VHYLn4c+bJgoIWLuQykigP9oQh0+bSNhZ4nljCm6k/aU22nSgo9NFI RzMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JqiGJPP+1qWZHSJUYNwoHlilt+YrbBqs2mlaeqlK+NY=; b=DqDmrxdYoDNMxW3TViuT0cWu+nDmpK1mvkB7MTczKCUNKhyRKwjYyaEFaLZfXyu2K9 h3SvCcVsekpSGUFr6b/2qULJrNUu0tbJ9uYw+PXj3TH37CG1ooeniIQ9gHzgFejiJlg9 AUK9t5l3CCgnFwskip9BPLordE7+EMXYvhWMvC0wZyQi/st4Ryl859Yj5tCOHwinpNGt +Dv1z1HPtY0fBjkzOuuWqQ09V3HE3uv1ikqnOWArFB309GWp5vTB2IUPG6Gx2yw1jnW1 5Gn5kjl7aDLFDkf+xW1CGyFhwEQ0ZyCrXTNi5jlLQMzfdNTZ9kL6xESenyfD5pbTskl7 l1jA== X-Gm-Message-State: ALQs6tAFBclIxb/e0KLOmW65vtLvGqDwWfX5WLDEOjaSiAbacWu+ByyQ oPkKwBQr/NgNHuixpwqeQtKH7+UN9Yhgtb0+iV0= X-Google-Smtp-Source: AIpwx49L7oohI2oL3opEMRXDAlEgJguY9zGcFO0KNhNJkWak4JuMGW0bxEOyxWMdDd+EbYCIlwlCghcKRWS0MOmEdW4= X-Received: by 2002:a17:902:bd41:: with SMTP id b1-v6mr21040770plx.302.1524501472535; Mon, 23 Apr 2018 09:37:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.226.131 with HTTP; Mon, 23 Apr 2018 09:37:32 -0700 (PDT) In-Reply-To: References: <6BBA90E7-6496-42C8-A1AB-9D896ECFF120@amazon.com> From: Dick Hardt Date: Mon, 23 Apr 2018 09:37:32 -0700 Message-ID: To: William Denniss Cc: "Richard Backman, Annabelle" , oauth Content-Type: multipart/alternative; boundary="000000000000bae91f056a86a8af" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 16:37:55 -0000 --000000000000bae91f056a86a8af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As the author, I support the adoption. Do we have consensus now? On Tue, Apr 17, 2018 at 1:18 PM, William Denniss wrote: > +1, I support the adoption of this document. > > I've encountered this problem in the wild for account linking scenarios, > and I think it would be useful to have a standardized way to do it. > > > On Tue, Apr 17, 2018 at 7:43 AM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> I support the adoption of *Reciprocal OAuth* as a WG document. >> >> -- >> Annabelle Richard Backman >> Amazon =E2=80=93 Identity Services >> >> =EF=BB=BFOn 4/16/18, 8:20 AM, "OAuth on behalf of Hannes Tschofenig" < >> oauth-bounces@ietf.org on behalf of Hannes.Tschofenig@arm.com> wrote: >> >> Hi all, >> >> we had gotten positive feedback from the group on Reciprocal OAuth a= t >> the virtual interim meeting earlier this year and also at the London IET= F >> meeting. >> >> We would therefore like to get a final confirmation on the mailing >> list for the adoption of the *Reciprocal OAuth* as a WG document >> https://tools.ietf.org/html/draft-hardt-oauth-mutual-02 >> >> Please, let us know if you support or object to the adoption of this >> document by April 25th. >> >> Ciao >> Hannes & Rifaat >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000bae91f056a86a8af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As the author, I support the adoption.=C2=A0

Do we have consensus now?

<= div class=3D"gmail_quote">On Tue, Apr 17, 2018 at 1:18 PM, William Denniss = <wdenniss@google.com> wrote:
+1, I support the adoption = of this document.

<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal= ;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex= t-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:= initial;text-decoration-color:initial">I've encountered this problem in= the wild for account linking scenarios, and I think it would be useful to = have a standardized way to do it.


On = Tue, Apr 17, 2018 at 7:43 AM, Richard Backman, Annabelle = <richanna@amazo= n.com> wrote:
I support the= adoption of *Reciprocal OAuth* as a WG document.

--
Annabelle Richard Backman
Amazon =E2=80=93 Identity Services
=C2=A0
=EF=BB=BFOn 4/16/18, 8:20 AM, "OAuth on behalf of Hannes Tschofenig&qu= ot; <oauth-b= ounces@ietf.org on behalf of Hannes.Tschofenig@arm.com> wrote:

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 we had gotten positive feedback from the group on Reciprocal = OAuth at the virtual interim meeting earlier this year and also at the Lond= on IETF meeting.

=C2=A0 =C2=A0 We would therefore like to get a final confirmation on the ma= iling list for the adoption of the *Reciprocal OAuth* as a WG document
=C2=A0 =C2=A0 https://tools.ietf.org/html/dr<= wbr>aft-hardt-oauth-mutual-02

=C2=A0 =C2=A0 Please, let us know if you support or object to the adoption = of this document by April 25th.

=C2=A0 =C2=A0 Ciao
=C2=A0 =C2=A0 Hannes & Rifaat
=C2=A0 =C2=A0 IMPORTANT NOTICE: The contents of this email and any attachme= nts are confidential and may also be privileged. If you are not the intende= d recipient, please notify the sender immediately and do not disclose the c= ontents to any other person, use it for any purpose, or store or copy the i= nformation in any medium. Thank you.

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
=C2=A0 =C2=A0 OAuth@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/oauth


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


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


--000000000000bae91f056a86a8af-- From nobody Mon Apr 23 12:14:07 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB912DA46 for ; Mon, 23 Apr 2018 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7vsDj6ntVdB for ; Mon, 23 Apr 2018 12:13:55 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BED12D947 for ; Mon, 23 Apr 2018 12:13:54 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h143-v6so12391501ita.4 for ; Mon, 23 Apr 2018 12:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JJSdnaw3SVTYYskSi9oDLcq5tGadJL9Adf0HMji5j0A=; b=nFr3USFYDnQM20U7W9ByroZ+xSTDbATPCLr8+VkOuWVjf+gw1vkDRgdsDsJmTE9hZj +hvVr8r8oFB6QyxbkeOqabGH9xOENdgkZTwYJ5wAUOP2udVCIilINfYRjgTse8toh763 iZvXT+E51EIsNuViKEUn54eKCe3sxuWdqHPls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JJSdnaw3SVTYYskSi9oDLcq5tGadJL9Adf0HMji5j0A=; b=NpcvVx8wJuDm1rsjCk7JTHElP0BWTols9tbG3TTPd7EvwuV8EDmhooWOX/bxSvCiQO SIZU4YpHrAWvmtUPCssRn4PaErpGZSxZ6pYQkCD9PqTTpEqEJDMCoi1Xg5Pq2dLxRg3b igek+Z6Ukf0sBHoCuRfwPw3ZnHVHwsXBXggZ/C2CMMrGdYhXUYN+iTpZz5F3qMf5mI1u Qcz09FGeTrpOjIE1SG10fdDQJH1M4L3xRnfcaMhYHmtxkEzD6G7tbtHeIPZ3CfvbWptw ZkSvp8hMDschTp4XVnNSS9EiCh1ycGuwyrLyXWKxrO2aHI7FE5k7jRNjWQNqZ7hABkWw IGwQ== X-Gm-Message-State: ALQs6tBdNsaILbXAljKzBIFWkCq3gRzzh1Q3I7FJUl0n6Httv15SpkPm iPcsS0wlCj8bZfDosHBEGiC+fgCZvm9Vn8Y4n0qHQ2pWtcJQbahx0NoV2/Lgmt4jGR8OvSe3RPX qLRG8TVXrOcIkrQ== X-Google-Smtp-Source: AB8JxZrciaq8pTsEFiyTGyKtz5eWS/osVEbBIUWO0XC9W7CyMX6svv9/IesOe1gGVRkPACvI+YTGPvwv9JNFnCXroDI= X-Received: by 2002:a24:2f8d:: with SMTP id j135-v6mr15421785itj.53.1524510833966; Mon, 23 Apr 2018 12:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 12:13:23 -0700 (PDT) In-Reply-To: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> References: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> From: Brian Campbell Date: Mon, 23 Apr 2018 13:13:23 -0600 Message-ID: To: Torsten Lodderstedt Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000b72faa056a88d63a" Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:14:01 -0000 --000000000000b72faa056a88d63a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I just noticed/remembered that the draft also currently defines a "cid" claim for the client identifier where Introspection's RFC 7662 already uses "client_id" for the same thing. The reason for using "cid" was similar in that I was looking to follow the semi-convention of JWT using three letter short claim names. But I think consistency with RFC 7662 is more important and meaningful here. So, barring a rough conscious of objections, I'm going to make that change too in a soon-to-be next revision of the draft. On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 - It will makes thinks much simpler. > > > Am 19.04.2018 um 00:58 schrieb Mike Jones : > > I=E2=80=99m OK with this change, given it makes the OAuth suite of specs = more > self-consistent. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Brian Campbell > *Sent:* Wednesday, April 18, 2018 8:17 AM > *To:* Torsten Lodderstedt > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 > > > > The draft-ietf-oauth-token-exchange document makes use of scope and at > some point in that work it came to light that, despite the concept of sco= pe > being used lots of places elsewhere, there was no officially registered J= WT > claim for scope. As a result, we (the WG) decided to have > draft-ietf-oauth-token-exchange define and register a JWT claim for > scope. It's kind of an awkward place for it really but that's how it came > to be there. > > When I added it to the draft, I opted for the semi-convention of JWT usin= g > three letter short claim names.. And decided to use a JSON array to conve= y > multiple values rather than space delimiting. It seemed like a good idea = at > the time - more consistent with other JWT claim names and cleaner to use > the facilities of JSON rather than a delimited string. That was the > thinking at the time anyway and, as I recall, I asked the WG about doing = it > that way at one of the meetings and there was general, if somewhat absent= , > nodding in the room. > > Looking at this again in the context of the question from Torsten and his > developers, I think using a different name and syntax for the JWT claim > vs.. the Introspection response member/parameter/claim is probably a > mistake. While RFC 7662 Introspection response parameters aren't exactly > the same as JWT claims, they are similar in many respects. So giving > consistent treatment across them to something like scope is > > Therefore I propose that the JWT claim for representing scope in > draft-ietf-oauth-token-exchange be changed to be consistent with the > treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That > effectively means changing the name from "scp" to "scope" and the value > from a JSON array to a string delimited by spaces. > > I realize it's late in the process to make this change but believe doing > so will significantly reduce confusion and issues in the long run. > > > > > > > > > > > On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a = claim > =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC 7662 u= se a claim =E2=80=9Escope=E2=80=9C > for the same purpose. As far as I understand the text, the intension is t= o > represent a list of RFC6749 scopes. Is this correct? What=E2=80=99s the r= ationale > behind? > > Different claim names for representing scope values confuse people. I > realized that when one of our developers pointed out that difference > recently. > > best regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b72faa056a88d63a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just noticed/remembered that the draft also currently de= fines a "cid" claim for the client identifier where Introspection= 's RFC 7662 already uses "client_id" for the same thing. The = reason for using "cid" was similar in that I was looking to follo= w the semi-convention of JWT using three letter short claim names. But I th= ink consistency with RFC 7662 is more important and meaningful here. So, ba= rring a rough conscious of objections, I'm going to make that change to= o in a soon-to-be next revision of the draft.


<= /div>

On Thu= , Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt <torsten@lodderstedt.= net> wrote:
+1 - It will makes thinks= much simpler.


Am 19.04.2018 um 00:58 schrieb Mike Jones <Michael.Jones@microsoft.com&g= t;:

I=E2=80=99m OK with this change, given it makes= the OAuth suite of specs more self-consistent.

=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=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=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=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 18, 2018 8:17 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exc= hange-12

=C2=A0

The draft-ietf-o= auth-token-exchange document makes use of scope and at some point in t= hat work it came to light that, despite the concept of scope being used lot= s of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to have d= raft-ietf-oauth-token-exchange define and register a JWT claim for sco= pe. It's kind of an awkward place for it really but that's how it c= ame to be there.

When I added it= to the draft, I opted for the semi-convention of JWT using three letter sh= ort claim names.. And decided to use a JSON array to convey multiple values= rather than space delimiting. It seemed like a good idea at the time - more consistent with other JWT claim names and c= leaner to use the facilities of JSON rather than a delimited string. That w= as the thinking at the time anyway and, as I recall, I asked the WG about d= oing it that way at one of the meetings and there was general, if somewhat absent, nodding in the room. =

Looking at this = again in the context of the question from Torsten and his developers, I thi= nk using a different name and syntax for the JWT claim vs.. the Introspecti= on response member/parameter/claim is probably a mistake.=C2=A0 While RFC 7662 Introspection response parameters aren'= ;t exactly the same as JWT claims, they are similar in many respects. So gi= ving consistent treatment across them to something like scope is

Therefore I prop= ose that the JWT claim for representing scope in draft-ietf-oauth-token-exchange be changed to be consistent with the treatment of scope in=C2=A0= RFC 7662 OAuth 2.0 Token Introspection. That effectively means changing the name from "scp" to "scope" and the = value from a JSON array to a string delimited by spaces.

I realize it's late in the process to make = this change but believe doing so will significantly reduce confusion and is= sues in the long run.=C2=A0


=C2=A0

=C2=A0=

=C2=A0

=C2=A0

On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodde= rstedt <tor= sten@lodderstedt.net> wrote:

Hi all,

I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines= a claim =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC= 7662 use a claim =E2=80=9Escope=E2=80=9C for the same purpose. As far as I= understand the text, the intension is to represent a list of RFC6749 scope= s. Is this correct? What=E2=80=99s the rationale behind?

Different claim names for representing scope values confuse people. I reali= zed that when one of our developers pointed out that difference recently.

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b72faa056a88d63a-- From nobody Mon Apr 23 12:17:32 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58948126B6E for ; Mon, 23 Apr 2018 12:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLxFR6b1j9Dg for ; Mon, 23 Apr 2018 12:17:27 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0108.outbound.protection.outlook.com [104.47.37.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B15112D810 for ; Mon, 23 Apr 2018 12:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=weWHFzpcS34mNU15RwTcujjx1F3Asf09XVpGZWg1dNY=; b=bKhTIHzzV0Ic8MGfoXSZKaGslRwa40v6g1L4WujQ+ZmoffoqZZ/DCJrd389a85IR6fnIbmtKfKH2IEsK4l0ZqxdrTFQLMkAsL4P45++zVePdN7BtB+ZCzLj461o+q9U8HhXwQc9BFRpBvBozbKdJYZuV/qkYXudAkZdaZXfRL3c= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0422.namprd00.prod.outlook.com (2603:10b6:4:a0::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.746.0; Mon, 23 Apr 2018 19:17:25 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0747.000; Mon, 23 Apr 2018 19:17:25 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Device Flow spec addressing Area Director comments Thread-Index: AdPbNgH4jqD+9n5fSSaHzJsDpiE4sw== Date: Mon, 23 Apr 2018 19:17:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T19:17:23.8531038Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0422; 7:PnZYulRJ9CBz4hl1AlbYjPMHuN589XK6a++OVRpBTDGdPyt9spAmbezSw/FHOnNaYHnETXdpiJHMtMgYOzcNofw/DsvYg7zMcBFfD/PMbP9AVnZlfG1RQgBKKokMVjWTiu2Ytw8XwxpFnbxFAeQ0PEyXzPFnBvLj2ArF8rOYXB1ALcRbh4Qp6QZlmoz9VZYaSvg2Cev2+gqMusau5R+1RCBRvXDjvKUyIoNXTGc80cYjl8pAWx5abfGwxGrNUbDy; 20:29PfuOHtu2BPyC4NTmZ5VOs4rbzO9hL0HjzFNJ1TqMCbLePrlRAzgvsovuInXvIwutUeFmIlPnGj3SfybQMup6ORBLdZp6QPDflFSHiBbUhZONJ9+2ZApILKVTFK5kwWybdHr38tNU9zgwjwPCV1oD0LK26Z/uzSXvDUxPwk5Z8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0422; x-ms-traffictypediagnostic: DM5PR00MB0422: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0422; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0422; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(396003)(39380400002)(209900001)(25786009)(606006)(10090500001)(2351001)(8990500004)(966005)(72206003)(3660700001)(8936002)(478600001)(8676002)(3280700002)(1730700003)(6306002)(2906002)(6916009)(33656002)(86612001)(5630700001)(790700001)(6116002)(81166006)(14454004)(10290500003)(7736002)(99286004)(5640700003)(5660300001)(9686003)(54896002)(7696005)(236005)(52396003)(476003)(53936002)(53376002)(22452003)(55016002)(21615005)(74316002)(59450400001)(6506007)(102836004)(5250100002)(316002)(2501003)(46003)(186003)(86362001)(2900100001)(6436002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0422; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:ovrnspm; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /mXPJmHXiULDBtOv8NqzkD1aic7ku6z5rTs5jy+Zi2cD5uZ/9R3Vu4ISx1DH0j9CWnhwgAsoVs+7rUlhkIDI+tJ7LsCcx0gJ+B9A11/R+5SO0b4otdSpZ6xSFOsrqQuq/2gSF+f9j92ox+s+T7gsCGeqJCFz1FbTqSMPdKcNr2SlRWnsi0E7qtMmS8IrWwAa spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296E989389D78FE7567A73FF5890DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 25de7561-932e-4365-78f6-08d5a94ed8e4 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25de7561-932e-4365-78f6-08d5a94ed8e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 19:17:25.2877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0422 Archived-At: Subject: [OAUTH-WG] OAuth Device Flow spec addressing Area Director comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:17:30 -0000 --_000_DM5PR00MB0296E989389D78FE7567A73FF5890DM5PR00MB0296namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 Device Flow for Browserless and Input Constrained Devices spe= cification has been updated to address feedback by Security Area Director E= ric Rescorla about the potential of a confused deputy attack. Thanks to Jo= hn Bradley for helping work out the response to= Eric and to William Denniss for review= ing and publishing the changes to the draft. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-device-flow-09.html -- Mike P.S. This notice was also published at http://self-issued.info/?p=3D1823 a= nd as @selfissued. --_000_DM5PR00MB0296E989389D78FE7567A73FF5890DM5PR00MB0296namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth 2.0 Device Flow for Browserless and Input = Constrained Devices specification has been updated to address feedback by S= ecurity Area Director Eric Rescorla about the potential of a confused deput= y attack.  Thanks to John Bradley for helping work ou= t the response to Eric and to William Denniss for revi= ewing and publishing the changes to the draft.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S.  This notice was also published at http://self-issued.info/?p=3D1823 and as @selfissued.

--_000_DM5PR00MB0296E989389D78FE7567A73FF5890DM5PR00MB0296namp_-- From nobody Mon Apr 23 12:18:02 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D14126B6E for ; Mon, 23 Apr 2018 12:18:01 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE2IkyQKelaa for ; Mon, 23 Apr 2018 12:17:55 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0612012D946 for ; Mon, 23 Apr 2018 12:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rHBjWh4a7gwywUpLKeNVz/wfZ77JiJI69x0s01tBVSE=; b=MqZLwGahZD5KDGbMaz5TVyu0Z6RglHFDV+YFk5s0A0FV+bQreqtqhHJPpCW8rzDMCtU2qOEXf09ZeaVXM9qXF+/y1kIrSrmvvMK84AufcJMGptsABbt5aByMHcOZwNDb8kEgkzt1nl+B4jbtc1rP688NLlmJE4H//hM8Lf0wWEk= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0422.namprd00.prod.outlook.com (2603:10b6:4:a0::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.746.0; Mon, 23 Apr 2018 19:17:49 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0747.000; Mon, 23 Apr 2018 19:17:49 +0000 From: Mike Jones To: Eric Rescorla , John Bradley , "draft-ietf-oauth-device-flow@tools.ietf.org" , "oauth@ietf.org" Thread-Topic: First look at: draft-ietf-oauth-device-flow Thread-Index: AQHTrcMK5xJMkV2cYk2pb66wzOmOVqPX4ZsAgDcxzYA= Date: Mon, 23 Apr 2018 19:17:48 +0000 Message-ID: References: <5aafe3ee.84b2df0a.59648.3412@mx.google.com> In-Reply-To: <5aafe3ee.84b2df0a.59648.3412@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T19:17:47.6620374Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0422; 7:5rNeSo3rBnKvbNvF2F5JmH49H8x9zXxYUmMt4bpI0MQredtOvScUwnzqQ++nPqdLGS9480mKnN6E/X+5Ib8vxL+NV4dI0pJwjNZsyr0bslRjhwwITLjAk5ljFAdgKcoB6jvzDA0rt0hLCRyZ3dBk1hO402FDwRMjj/hzeOjuqyzcnWFoacmtJLf12z5QG1Mm5uh0Ev/CH8ZUALj2dIWSNZatsTFEFK1kmMuhAPsEvDKXIUhV9Noq7gzQPoSSa+Bx; 20:CRRWvf0oWxvW66lu6zBgL1xoXO7NaWAFhA9901sR6HDHj40mkVFNSuXPaL69J5evO2NjkuJYWEz0EItsqFULP5h56bVd2kVNsq0P0TyjJXDu8EkA3BQd3c+HSUCzo6B8YyzCTfbR0f8VDGX3hsQfIpc1RJGD38x0To3utCQ3A2o= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0422; x-ms-traffictypediagnostic: DM5PR00MB0422: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(156600954879566)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0422; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0422; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(396003)(39380400002)(25786009)(9326002)(606006)(966005)(72206003)(3660700001)(8936002)(478600001)(8676002)(3280700002)(6306002)(2906002)(33656002)(86612001)(790700001)(6116002)(81166006)(10290500003)(7736002)(5660300001)(9686003)(53546011)(54896002)(76176011)(7696005)(236005)(52396003)(476003)(11346002)(53936002)(446003)(6246003)(22452003)(55016002)(110136005)(74316002)(59450400001)(6506007)(102836004)(5250100002)(316002)(2501003)(46003)(186003)(2201001)(86362001)(2900100001)(6436002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0422; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: RDsZverXAo0ErHTwcYV7omUwP8YA13IfWAoR4HVOaXWhUT0/UjWUER9l6oHF3SkyYFpn1of5ssAwvEgf5OJg/cpuUZzXDZ9Q9b6c4Px1gsU2YT452X2wZes6OPOg/9L2fWnHfOaxb5PTXNWZD/E07K+BscNa0J7dLrQGKHxK0zu0vejiURXvuezEgpfDPYN+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02962EBC0BA5B8D51C09E57DF5890DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1d37d701-f688-4e25-246f-08d5a94ee70a X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d37d701-f688-4e25-246f-08d5a94ee70a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 19:17:49.0277 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0422 Archived-At: Subject: Re: [OAUTH-WG] First look at: draft-ietf-oauth-device-flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:18:01 -0000 --_000_DM5PR00MB02962EBC0BA5B8D51C09E57DF5890DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1k ZXZpY2UtZmxvdy0wOSAgU2VjdGlvbnMgNS4yIGFuZCA1LjMgaGF2ZSBiZWVuIHVwZGF0ZWQgYXMg cHJvcG9zZWQgYmVsb3cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEpvaG4gQnJhZGxleSA8 dmU3anRiQHZlN2p0Yi5jb20+DQpTZW50OiBNb25kYXksIE1hcmNoIDE5LCAyMDE4IDk6MjMgQU0N ClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBkcmFmdC1pZXRmLW9hdXRoLWRldmlj ZS1mbG93QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogRmlyc3QgbG9vayBhdDogZHJhZnQt aWV0Zi1vYXV0aC1kZXZpY2UtZmxvdw0KDQpJZiBhbiBBdXRob3JpemF0aW9uIFNlcnZlciBpcyBt YWxpY2lvdXMsIHRoZW4gaXQgY291bGQgbWFuLWluLXRoZSBtaWRkbGUgdGhlIGJhY2tjaGFubmVs IGZsb3cgdG8gYW5vdGhlciBBUy4NCg0KTm90ZSB0aGF0IHRoZSBkZXZpY2UgbWFudWZhY3R1cmVy IG11c3QgZWl0aGVyIGJlIHRoZSBhdHRhY2tlciBvciBiZSB1c2luZyBhbiBhdXRob3JpemF0aW9u IHNlcnZlciB0aGF0IGlzIGNvbnRyb2xsZWQgYnkgYW4gYXR0YWNrZXIgZm9yIHRoaXMgYXR0YWNr IHRvIGJlIHBvc3NpYmxlLiAgV2UgY2FuIGFtcGxpZnkgU2VjdGlvbiA1LjIgKERldmljZSBUcnVz dHdvcnRoaW5lc3MpIHRvIG1ha2UgdGhpcyBleHBsaWNpdC4gIEluIHBhcnQsIHRoZSBwZXJzb24g cHVyY2hhc2luZyB0aGUgZGV2aWNlIGlzIGNvdW50aW5nIG9uIGl0IGFuZCBpdHMgYnVzaW5lc3Mg cGFydG5lcnMgdG8gYmUgdHJ1c3R3b3J0aHkuDQoNCkFzIGEgY29uY3JldGUgZXhhbXBsZSwgTmV0 ZmxpeCBjb3VsZCBtYW4taW4tdGhlIG1pZGRsZSBBbWF6b24gUHJpbWUgdG8gZ2V0IGFuIGFjY2Vz cyB0b2tlbiBhcyB0aGUgdXNlcuKAmXMgZGV2aWNlLiAgIEZvciB0aGF0IHRvIHdvcmssIHRoZSB1 c2VyIHdvdWxkIG5lZWQgdG8gc2VsZWN0IE5ldGZsaXggb24gdGhlIFRWIGFuZCBnZXQgYmFjayB0 aGUgVVJJIGZvciBBbWF6b24gUHJpbWUgdmlkZW8gdG8gZW50ZXIuICBUaGV5IHdvdWxkIGhvcGVm dWxseSBub3RpY2UgdGhhdCB0aGV5IGFyZSBiZWluZyBzZW50IHRvIHRoZSB3cm9uZyBzaXRlLg0K DQpXZSBjb3VsZCBleHBhbmQgU2VjdGlvbiA1LjMgKFJlbW90ZSBQaGlzaGluZykgdG8gZW5jb3Vy YWdlIHRoZSBBUyB0byBkaXNwbGF5IGluZm9ybWF0aW9uIGFib3V0IHRoZSBkZXZpY2UvY2xpZW50 IHNvIHRoYXQgdGhleSB3b3VsZCBub3RpY2UgaWYgYSBzb2Z0d2FyZSBjbGllbnQgd2FzIGltcGVy c29uYXRpbmcgYSBSb2t1LiBXZSBjdXJyZW50bHkgb25seSB0YWxrIGFib3V0IGluZm9ybWluZyB0 aGUgdXNlciB0aGF0IHRoZXkgYXJlIGF1dGhlbnRpY2F0aW5nIGEgZGV2aWNlLg0KDQpUaGlzIGlz IG5vdCB0aGUgb25seSBwbGFjZSBpbiBPQXV0aCB3aGVyZSB3ZSBoYXZlIGlzc3VlcyB3aXRoIGNs aWVudHMgYmVpbmcgYWJsZSB0byBpbXBlcnNvbmF0ZSBvdGhlciBjbGllbnRzLiAgVG8gY29tcGxl dGVseSBwcmV2ZW50IHRoaXMgYXR0YWNrLCB3ZSB3b3VsZCBuZWVkIGEgY2xpZW50IGF0dGVzdGF0 aW9uIG9yIHNvbWUgZm9ybSBvZiBjbGllbnQgY3JlZGVudGlhbCBsaWtlIGEgY2VydGlmaWNhdGUg dXNpbmcgTVRMUyBmb3IgYXV0aGVudGljYXRpb24uDQoNCkR5bmFtaWMgY2xpZW50IHJlZ2lzdHJh dGlvbiBiYXNlZCBvbiBhIHNvZnR3YXJlIHN0YXRlbWVudCBjb250YWluaW5nIHRoZSBjbGllbnRz IHB1YmxpYyBrZXkgd291bGQgd29yayBidXQgcmFpc2VzIHRoZSBkZXBsb3ltZW50IGJhciBzaWdu aWZpY2FudGx5Lg0KDQpKb2huIEIuDQoNClNlbnQgZnJvbSBNYWlsPGh0dHBzOi8vZ28ubWljcm9z b2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvciBXaW5kb3dzIDEwDQoNCkZyb206IEVy aWMgUmVzY29ybGE8bWFpbHRvOmVrckBydGZtLmNvbT4NClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFy eSAyNCwgMjAxOCAxMDo1OCBQTQ0KVG86IGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3dAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3dAdG9vbHMuaWV0 Zi5vcmc+DQpTdWJqZWN0OiBGaXJzdCBsb29rIGF0OiBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1m bG93DQoNCg0KSSBhbSBjb25jZXJuZWQgYWJvdXQgdGhlIHNlY3VyaXR5IG9mIHRoaXMgbWVjaGFu aXNtLiBJbiBTIDUuMyB5b3UNCmRlc2NyaWJlIGEgcGhpc2hpbmcgYXR0YWNrLCBidXQgaXQgc2Vl bXMgbGlrZSB0aGVyZSBpcyBhIGNvbmZ1c2VkDQpkZXB1dHkgYXR0YWNrIHdoZW4gYSB1c2VyIGhh cyBhY2NvdW50cyBvbiB0d28gc2VydmljZXMsIEEgYW5kIEIsIHdoZXJlDQpBIGdldHMgdGhlIHVz ZXIgdG8gYXV0aGVudGljYXRlIHRvIEIgZm9yIHRoZW06DQoNCg0KQ2xpZW50ICAgICAgICAgICAg ICAgICAgIEEgICAgICAgICAgICAgICAgICAgICAgICAgIEINCg0KQ2xpZW50IElkZW50aWZpZXIg KEEpIC0tLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIENsaWVudCBpZGVudGlmaWVyIChC KSAtLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICA8LSBWZXJpZmljYXRpb24gVVJJICsg Q29kZQ0KPC0gVmVyaWZpY2F0aW9uIFVSSSArIENvZGUNClVzZXIgYXV0aG9yaXphdGlvbiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICBQb2xsIC0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg PC0tLS0tLS0tLS0tLSBBY2Nlc3MgVG9rZW4NCg0KVGhlIGlkZWEgaGVyZSBpcyB0aGF0IEEgY29u bmVjdHMgdG8gQiBjbGFpbWluZyB0byBiZSBDbGllbnQNCmFuZCB0aGVuIGdldHMgdGhlIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBDbGllbnQtPkINCmludGVyYWN0aW9uLCB3aGlj aCBpdCBjb252aW5jZXMgQ2xpZW50IHRvIHN1cHBseSB0byBCIGFsb25nDQp3aXRoIGl0cyBhbWJp ZW50IGF1dGhvcml0eS4NCg0KSXMgdGhpcyBhIHJlYWwgYXR0YWNrPyBJZiBub3QsIHdoYXQgYW0g SSBtaXNzaW5nPw0KDQotRWtyDQoNCg0K --_000_DM5PR00MB02962EBC0BA5B8D51C09E57DF5890DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPkhpIEVrciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRldmlj ZS1mbG93LTA5Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1k ZXZpY2UtZmxvdy0wOTwvYT4gJm5ic3A7U2VjdGlvbnMgNS4yIGFuZCA1LjMgaGF2ZSBiZWVuIHVw ZGF0ZWQgYXMgcHJvcG9zZWQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEpvaG4gQnJh ZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IE1hcmNoIDE5LCAyMDE4IDk6MjMgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0 O2VrckBydGZtLmNvbSZndDs7IGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3dAdG9vbHMuaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEZpcnN0IGxvb2sgYXQ6IGRyYWZ0LWlldGYt b2F1dGgtZGV2aWNlLWZsb3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIGFuIEF1dGhvcml6YXRpb24gU2VydmVyIGlzIG1hbGljaW91cywgdGhlbiBpdCBjb3VsZCBt YW4taW4tdGhlIG1pZGRsZSB0aGUgYmFja2NoYW5uZWwgZmxvdyB0byBhbm90aGVyIEFTLiZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGUgZGV2aWNlIG1hbnVmYWN0 dXJlciBtdXN0IGVpdGhlciBiZSB0aGUgYXR0YWNrZXIgb3IgYmUgdXNpbmcgYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdGhhdCBpcyBjb250cm9sbGVkIGJ5IGFuJm5ic3A7YXR0YWNrZXIgZm9yIHRo aXMgYXR0YWNrIHRvIGJlIHBvc3NpYmxlLiZuYnNwOyBXZSBjYW4gYW1wbGlmeSBTZWN0aW9uIDUu MiAoRGV2aWNlIFRydXN0d29ydGhpbmVzcykgdG8gbWFrZSB0aGlzIGV4cGxpY2l0LiZuYnNwOw0K IEluIHBhcnQsIHRoZSBwZXJzb24gcHVyY2hhc2luZyB0aGUgZGV2aWNlIGlzIGNvdW50aW5nIG9u IGl0IGFuZCBpdHMgYnVzaW5lc3MgcGFydG5lcnMgdG8gYmUgdHJ1c3R3b3J0aHkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIGEgY29uY3JldGUgZXhhbXBsZSwgTmV0ZmxpeCBjb3VsZCBtYW4t aW4tdGhlIG1pZGRsZSBBbWF6b24gUHJpbWUgdG8gZ2V0IGFuIGFjY2VzcyB0b2tlbiBhcyB0aGUg dXNlcuKAmXMgZGV2aWNlLiZuYnNwOyZuYnNwOyBGb3IgdGhhdCB0byB3b3JrLCB0aGUgdXNlciB3 b3VsZCBuZWVkIHRvIHNlbGVjdCBOZXRmbGl4IG9uIHRoZSBUViBhbmQgZ2V0IGJhY2sgdGhlIFVS SSBmb3IgQW1hem9uIFByaW1lIHZpZGVvIHRvIGVudGVyLiZuYnNwOw0KIFRoZXkgd291bGQgaG9w ZWZ1bGx5IG5vdGljZSB0aGF0IHRoZXkgYXJlIGJlaW5nIHNlbnQgdG8gdGhlIHdyb25nIHNpdGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNvdWxkIGV4cGFuZCBTZWN0aW9uIDUuMyAoUmVt b3RlIFBoaXNoaW5nKSB0byBlbmNvdXJhZ2UgdGhlIEFTIHRvIGRpc3BsYXkgaW5mb3JtYXRpb24g YWJvdXQgdGhlIGRldmljZS9jbGllbnQgc28gdGhhdCB0aGV5IHdvdWxkIG5vdGljZSBpZiBhIHNv ZnR3YXJlIGNsaWVudCB3YXMgaW1wZXJzb25hdGluZyBhIFJva3UuIFdlIGN1cnJlbnRseSBvbmx5 IHRhbGsgYWJvdXQgaW5mb3JtaW5nIHRoZSB1c2VyIHRoYXQNCiB0aGV5IGFyZSBhdXRoZW50aWNh dGluZyBhIGRldmljZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3QgdGhlIG9u bHkgcGxhY2UgaW4gT0F1dGggd2hlcmUgd2UgaGF2ZSBpc3N1ZXMgd2l0aCBjbGllbnRzIGJlaW5n IGFibGUgdG8gaW1wZXJzb25hdGUgb3RoZXIgY2xpZW50cy4mbmJzcDsgVG8gY29tcGxldGVseSBw cmV2ZW50IHRoaXMgYXR0YWNrLCB3ZSB3b3VsZCBuZWVkIGEgY2xpZW50IGF0dGVzdGF0aW9uIG9y IHNvbWUgZm9ybSBvZiBjbGllbnQgY3JlZGVudGlhbCBsaWtlIGEgY2VydGlmaWNhdGUgdXNpbmcN CiBNVExTIGZvciBhdXRoZW50aWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uIGJhc2VkIG9uIGEgc29mdHdhcmUgc3RhdGVtZW50IGNvbnRh aW5pbmcgdGhlIGNsaWVudHMgcHVibGljIGtleSB3b3VsZCB3b3JrIGJ1dCByYWlzZXMgdGhlIGRl cGxveW1lbnQgYmFyIHNpZ25pZmljYW50bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4g Qi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIDxhIGhyZWY9Imh0dHBzOi8vZ28u bWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODYiPg0KTWFpbDwvYT4gZm9yIFdpbmRv d3MgMTA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPkVyaWMgUmVzY29ybGE8 L2E+PGJyPg0KPGI+U2VudDogPC9iPlNhdHVyZGF5LCBGZWJydWFyeSAyNCwgMjAxOCAxMDo1OCBQ TTxicj4NCjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb2F1dGgtZGV2aWNl LWZsb3dAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3dAdG9vbHMu aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDogPC9iPkZpcnN0IGxvb2sgYXQ6IGRyYWZ0LWll dGYtb2F1dGgtZGV2aWNlLWZsb3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBhbSBjb25jZXJuZWQgYWJvdXQgdGhlIHNlY3VyaXR5IG9mIHRoaXMgbWVj aGFuaXNtLiBJbiBTIDUuMyB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmRlc2NyaWJlIGEgcGhpc2hpbmcgYXR0YWNrLCBidXQgaXQgc2VlbXMg bGlrZSB0aGVyZSBpcyBhIGNvbmZ1c2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXB1dHkgYXR0YWNrIHdoZW4gYSB1c2VyIGhhcyBhY2NvdW50 cyBvbiB0d28gc2VydmljZXMsIEEgYW5kIEIsIHdoZXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGdldHMgdGhlIHVzZXIgdG8gYXV0aGVudGlj YXRlIHRvIEIgZm9yIHRoZW06PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNsaWVudCBJZGVudGlmaWVyIChBKSAtLS0mZ3Q7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2xpZW50IGlkZW50aWZpZXIgKEIpIC0tLSZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7LSBWZXJpZmljYXRpb24gVVJJICYjNDM7 IENvZGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZsdDstIFZlcmlmaWNhdGlvbiBVUkkgJiM0MzsgQ29kZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNlciBhdXRo b3JpemF0aW9uIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQb2xsIC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDstLS0tLS0tLS0tLS0gQWNjZXNz IFRva2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBpZGVhIGhlcmUgaXMgdGhhdCBBIGNvbm5lY3RzIHRvIEIgY2xhaW1pbmcgdG8gYmUg Q2xpZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hbmQgdGhlbiBnZXRzIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGZvciB0aGUgQ2xp ZW50LSZndDtCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5pbnRlcmFjdGlvbiwgd2hpY2ggaXQgY29udmluY2VzIENsaWVudCB0byBzdXBwbHkgdG8g QiBhbG9uZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d2l0aCBpdHMgYW1iaWVudCBhdXRob3JpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoaXMgYSByZWFsIGF0dGFjaz8gSWYgbm90 LCB3aGF0IGFtIEkgbWlzc2luZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR00MB02962EBC0BA5B8D51C09E57DF5890DM5PR00MB0296namp_-- From nobody Mon Apr 23 12:20:35 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4A126B6E for ; Mon, 23 Apr 2018 12:20:29 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tocj3e7CDji8 for ; Mon, 23 Apr 2018 12:20:22 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7631912D93F for ; Mon, 23 Apr 2018 12:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qfi7mW8WdR4fP4IeW3kmpSYzi7SHJed9NwlOYQtYwZg=; b=SrI2kfkxcga6+4o4tzCIKzFv5dM6Xr7QmXfrAqhwJ+CUdzBzTdOMS6ROvtkAdCCVvNLOZv24F7hOd4FbQ5eGHY8ElBEEBW9d0CPSdn8x2wggXTcIHQXNOIIBugjykFM9lt6wSZem0wM0FIRuMUbFfROsAtKL1i7/Kgn8lzUyNkE= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.747.0; Mon, 23 Apr 2018 19:20:09 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0747.000; Mon, 23 Apr 2018 19:20:09 +0000 From: Mike Jones To: Eric Rescorla CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 Thread-Index: AQHT04wCwx4Q8pxqD0CRb2HM3g16k6P/coIwgAAZcACADzzMwA== Date: Mon, 23 Apr 2018 19:20:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T19:20:08.3269252Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0296; 7:XQB1n2zmsnh4rMXEjihkWrh1CSGzp1S+6EiB/OKxlmR7VS5nBkeeU5pOEM4t0bTXs+U15VNH8nYcSWAUMQp/9FXOCW9i44fBi3OenrzivGM32vcLTdjoqxDHxeL2qJ8etmYpdS7z2QBfmTduY8eL2zDlLnexe5tTjcHyDp9sxG7BsTS0JYME1VhPIdkJc+apZPH4VrtjeSSS6oNuMkWlBFqkReyD82BIXNvtO70/Hkzc8paM9e3eBzJHScUkr6r0; 20:CRBDA80RoBhJniF7gz+SqAD3H0A3myIHl8GuMSlqICSPwtuOmfXrJIBq7a6x2BihprO9gMCagAdAm0rah6nbOKoPBLKzd419UIr47MegsVHSED2hPDDRD5etTq6Bsx/1c9rECyjDhBLgDfASfjxIHXI+4hqmGTlvfi31DfFByHY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0296; x-ms-traffictypediagnostic: DM5PR00MB0296: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0296; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0296; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(396003)(346002)(39860400002)(366004)(51914003)(25786009)(19609705001)(606006)(966005)(72206003)(3660700001)(3280700002)(478600001)(8676002)(2906002)(6916009)(8936002)(86612001)(33656002)(6116002)(790700001)(10290500003)(7736002)(81166006)(55016002)(6306002)(6506007)(9686003)(7696005)(54896002)(76176011)(236005)(52396003)(5660300001)(476003)(4326008)(11346002)(446003)(53936002)(22452003)(316002)(6246003)(74316002)(53546011)(102836004)(5250100002)(46003)(186003)(6436002)(86362001)(2900100001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0296; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: AI6HUSCths8S93sT7+qKcmt1hajGnBMiRyYmNChZbout36du7hBcZapFNkNFZVs9uRxRx9VZwz9B9rg/tvCZ/W2HJhwRdGA3+Law3tI/zaPis6Vu0ExzFC1R//CzqWXVtkpUO/Z4UhKmiMD6wqdb0ULOfHAZLSs8JMMRUbHmZQnoQ8eCTpkcnNcFG59JbBQD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296F09166551B8D649225AEF5890DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f04ad6e0-6556-45ed-f56c-08d5a94f3af2 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f04ad6e0-6556-45ed-f56c-08d5a94f3af2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 19:20:09.8174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0296 Archived-At: Subject: Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:20:29 -0000 --_000_DM5PR00MB0296F09166551B8D649225AEF5890DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ct MDkgIFNlY3Rpb25zIDUuMiBhbmQgNS4zIGNvbnRhaW4gdGhlIGNvbmZ1c2VkIGRlcHV0eSBhdHRh Y2sgdXBkYXRlcyBkZXNjcmliZWQgaW4gSm9obuKAmXMgcmVzcG9uc2UgZHVyaW5nIExvbmRvbi4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0K U2VudDogRnJpZGF5LCBBcHJpbCAxMywgMjAxOCA3OjM3IFBNDQpUbzogTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBGb2xsb3cgdXAgb24gZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0w OA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayBmb2xsb3d1cC4gSSB3aWxsIHRha2UgYSBsb29rIGF0 IHRoZSBuZXh0IHZlcnNpb24NCg0KLUVrcg0KDQoNCk9uIEZyaSwgQXByIDEzLCAyMDE4IGF0IDY6 MDYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpXZSBzdGlsbCBuZWVkIHRvIGFkZCB0 aGUgdGV4dCBhZGRyZXNzaW5nIHRoZSBwb2ludHMgZGVzY3JpYmVkIGluIEpvaG4gQnJhZGxleeKA mXMgcmVwbHkgdG8geW91IHNlbnQgd2hpbGUgaW4gTG9uZG9uLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBP QXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Zz4+IE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAy MDE4IDY6MDAgUE0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbT0FVVEgtV0ddIEZvbGxvdyB1cCBvbiBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1m bG93LTA4DQoNCkhpIGZvbGtzLA0KDQpJIGp1c3QgbG9va2VkIGF0IHRoZSAtMDggZGlmZnMgYW5k IEkgc2VlIGEgbmV3IHNlY3Rpb24gb24gYnJ1dGUgZm9yY2luZyB0aGUgdG9rZW4NCmJ1dCBub3Qg ZGVzY3JpYmluZyB0aGUgY29uZnVzZWQgZGVwdXR5IGF0dGFjay4gRGlkIEkgbWlzcyBzb21ldGhp bmcsIG9yIHdlcmUgeW91DQpzdGlsbCBwbGFubmluZyB0byBhZGQgbW9yZSB0ZXh0Pw0KDQpUaGFu a3MNCi1Fa3INCg0KDQoNCg== --_000_DM5PR00MB0296F09166551B8D649225AEF5890DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA5PC9hPiAmbmJzcDtTZWN0aW9u cyA1LjIgYW5kIDUuMyBjb250YWluIHRoZSBjb25mdXNlZCBkZXB1dHkgYXR0YWNrIHVwZGF0ZXMg ZGVzY3JpYmVkDQogaW4gSm9obuKAmXMgcmVzcG9uc2UgZHVyaW5nIExvbmRvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFcmljIFJlc2NvcmxhICZsdDtl a3JAcnRmbS5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4 IDc6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEZvbGxvdyB1cCBvbiBkcmFmdC1pZXRmLW9hdXRoLWRl dmljZS1mbG93LTA4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IGZvciB0aGUgcXVpY2sgZm9sbG93dXAuIEkgd2lsbCB0YWtlIGEgbG9vayBhdCB0aGUgbmV4dCB2 ZXJzaW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIEFwciAxMywgMjAxOCBhdCA2OjA2IFBNLCBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XZSBzdGlsbCBuZWVkIHRvIGFkZCB0aGUgdGV4dCBh ZGRyZXNzaW5nIHRoZSBwb2ludHMgZGVzY3JpYmVkIGluIEpvaG4gQnJhZGxleeKAmXMgcmVwbHkg dG8geW91IHNlbnQgd2hpbGUgaW4gTG9uZG9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAxMywgMjAxOCA2OjAwIFBNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBGb2xsb3cgdXAgb24gZHJh ZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wODxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBqdXN0IGxvb2tlZCBhdCB0 aGUgLTA4IGRpZmZzIGFuZCBJIHNlZSBhIG5ldyBzZWN0aW9uIG9uIGJydXRlIGZvcmNpbmcgdGhl IHRva2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPmJ1dCBub3QgZGVzY3JpYmluZyB0aGUgY29uZnVzZWQgZGVwdXR5IGF0dGFjay4gRGlkIEkg bWlzcyBzb21ldGhpbmcsIG9yIHdlcmUgeW91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnN0aWxsIHBsYW5uaW5nIHRvIGFkZCBtb3JlIHRleHQ/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DM5PR00MB0296F09166551B8D649225AEF5890DM5PR00MB0296namp_-- From nobody Mon Apr 23 12:23:47 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F236D12D810 for ; Mon, 23 Apr 2018 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPeu2kCMlU48 for ; Mon, 23 Apr 2018 12:23:43 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BFF126B6E for ; Mon, 23 Apr 2018 12:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EXr/ggEUPSyhDE3x7Fc2QaZXF5LAID/5AB2lVFsRH/A=; b=JYUsF4yBEZJS1ogEVubZYloUrxGGWeuExm2W+b+nqxj0Y+TwT5vuaXvSTPZ/3Ma43WvolTdHnHwy4Y6CCrRuQuVApei3gDCKsxhZoQu9X9aD+pvIiBNqUMlZ2XfLe74FuV99iUxDKLwj8f3jwfcLR6UPdfVDrm5dGL6yeJY5AOU= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0294.namprd00.prod.outlook.com (2603:10b6:4:9e::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.744.0; Mon, 23 Apr 2018 19:23:40 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0747.000; Mon, 23 Apr 2018 19:23:40 +0000 From: Mike Jones To: Brian Campbell , Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 Thread-Index: AQHT1NjgJy8mHwoFFk6XUY9K9SCN+aQGpvqAgACAzaCAAPXeAIAGpvWAgAAC18A= Date: Mon, 23 Apr 2018 19:23:40 +0000 Message-ID: References: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T19:23:39.1561280Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0294; 7:KV3v9++lAPrZNC1QNnHkL47uvrpDRPC92DB7TQip4+VrsDapenKsA4fbrDsMRtdzlx6AMe8wU7elohmn+y3ppWU3QTbCQu9zgx4vKrk8ja7ztxxqX7NQDC5bNzPY072IRCxk2EVkhlK7oDgjWOy6jShqJK+KtxPG7GXssgv3kij3tHB5Lsiz0UjkwG7pjG0RG4YEzscKslJrtKZAj90T6byrv1yhoEuHB/bIH5BsSRMWcov5kYMUr8Q3+jjkBXac; 20:2a7RZs2NBlzd/T8k/4IVQXOAP8IQgyR0Ruv7vQ/M8wkrRFlXFfeG6d+kwu/ehR18lQVipRWNTtHBS0RLzyh3WcIY9hgbld4GgKDhPzWdQaQ1OxYYVYozaT4yP5YUz35cSWu/k9rVrnrn3RZAYT2/xASX9Vwgn9g89uKiWLkw0cU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0294; x-ms-traffictypediagnostic: DM5PR00MB0294: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231232)(944501410)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR00MB0294; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0294; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(346002)(376002)(366004)(53754006)(76176011)(6116002)(790700001)(19609705001)(55016002)(186003)(53936002)(5890100001)(6436002)(2900100001)(5250100002)(46003)(11346002)(476003)(606006)(236005)(5660300001)(54896002)(6306002)(74316002)(2906002)(3280700002)(9686003)(446003)(25786009)(478600001)(72206003)(86362001)(4326008)(3660700001)(8936002)(8676002)(966005)(7696005)(81166006)(52396003)(10290500003)(102836004)(53546011)(110136005)(7736002)(6506007)(59450400001)(22452003)(86612001)(6246003)(316002)(33656002)(229853002)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0294; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: c+5Sks+C3F6stV/R3FXhiCEdjvgn6TRgr9+dvAVtb+zyYeS6usaeZWovFvhg3kv7Bu9Rb1pTmPNNmeKAKA+jokvh8gWxYnH1wouujpydCa+cbtgTIMdpfun223uWcDxp1zcIpf1H5GaXVXrpSJt8deO4yKUK+bpl2srHl7F5R75Di8+yTyYy9JVeHaEwvUU9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296E9493BA61BEDAA24B73BF5890DM5PR00MB0296namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b6379281-a3c9-4b59-1ebe-08d5a94fb86e X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6379281-a3c9-4b59-1ebe-08d5a94fb86e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 19:23:40.3037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0294 Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:23:46 -0000 --_000_DM5PR00MB0296E9493BA61BEDAA24B73BF5890DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0K U2VudDogTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAxMjoxMyBQTQ0KVG86IFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIHNjcCBjbGFpbSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl LTEyDQoNCkkganVzdCBub3RpY2VkL3JlbWVtYmVyZWQgdGhhdCB0aGUgZHJhZnQgYWxzbyBjdXJy ZW50bHkgZGVmaW5lcyBhICJjaWQiIGNsYWltIGZvciB0aGUgY2xpZW50IGlkZW50aWZpZXIgd2hl cmUgSW50cm9zcGVjdGlvbidzIFJGQyA3NjYyIGFscmVhZHkgdXNlcyAiY2xpZW50X2lkIiBmb3Ig dGhlIHNhbWUgdGhpbmcuIFRoZSByZWFzb24gZm9yIHVzaW5nICJjaWQiIHdhcyBzaW1pbGFyIGlu IHRoYXQgSSB3YXMgbG9va2luZyB0byBmb2xsb3cgdGhlIHNlbWktY29udmVudGlvbiBvZiBKV1Qg dXNpbmcgdGhyZWUgbGV0dGVyIHNob3J0IGNsYWltIG5hbWVzLiBCdXQgSSB0aGluayBjb25zaXN0 ZW5jeSB3aXRoIFJGQyA3NjYyIGlzIG1vcmUgaW1wb3J0YW50IGFuZCBtZWFuaW5nZnVsIGhlcmUu IFNvLCBiYXJyaW5nIGEgcm91Z2ggY29uc2Npb3VzIG9mIG9iamVjdGlvbnMsIEknbSBnb2luZyB0 byBtYWtlIHRoYXQgY2hhbmdlIHRvbyBpbiBhIHNvb24tdG8tYmUgbmV4dCByZXZpc2lvbiBvZiB0 aGUgZHJhZnQuDQoNCg0KT24gVGh1LCBBcHIgMTksIDIwMTggYXQgNzozOCBBTSwgVG9yc3RlbiBM b2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Pj4gd3JvdGU6DQorMSAtIEl0IHdpbGwgbWFrZXMgdGhpbmtzIG11Y2ggc2ltcGxl ci4NCg0KDQoNCkFtIDE5LjA0LjIwMTggdW0gMDA6NTggc2NocmllYiBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+Og0KDQpJ4oCZbSBPSyB3aXRoIHRoaXMgY2hhbmdlLCBnaXZlbiBpdCBtYWtlcyB0aGUgT0F1 dGggc3VpdGUgb2Ygc3BlY3MgbW9yZSBzZWxmLWNvbnNpc3RlbnQuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnPj4gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDE4LCAyMDE4IDg6MTcgQU0NClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KQ2M6IG9hdXRoIDxv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gc2NwIGNsYWltIGluIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTINCg0K VGhlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgZG9jdW1lbnQgbWFrZXMgdXNlIG9m IHNjb3BlIGFuZCBhdCBzb21lIHBvaW50IGluIHRoYXQgd29yayBpdCBjYW1lIHRvIGxpZ2h0IHRo YXQsIGRlc3BpdGUgdGhlIGNvbmNlcHQgb2Ygc2NvcGUgYmVpbmcgdXNlZCBsb3RzIG9mIHBsYWNl cyBlbHNld2hlcmUsIHRoZXJlIHdhcyBubyBvZmZpY2lhbGx5IHJlZ2lzdGVyZWQgSldUIGNsYWlt IGZvciBzY29wZS4gQXMgYSByZXN1bHQsIHdlICh0aGUgV0cpIGRlY2lkZWQgdG8gaGF2ZSBkcmFm dC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRlZmluZSBhbmQgcmVnaXN0ZXIgYSBKV1QgY2xh aW0gZm9yIHNjb3BlLiBJdCdzIGtpbmQgb2YgYW4gYXdrd2FyZCBwbGFjZSBmb3IgaXQgcmVhbGx5 IGJ1dCB0aGF0J3MgaG93IGl0IGNhbWUgdG8gYmUgdGhlcmUuDQpXaGVuIEkgYWRkZWQgaXQgdG8g dGhlIGRyYWZ0LCBJIG9wdGVkIGZvciB0aGUgc2VtaS1jb252ZW50aW9uIG9mIEpXVCB1c2luZyB0 aHJlZSBsZXR0ZXIgc2hvcnQgY2xhaW0gbmFtZXMuLiBBbmQgZGVjaWRlZCB0byB1c2UgYSBKU09O IGFycmF5IHRvIGNvbnZleSBtdWx0aXBsZSB2YWx1ZXMgcmF0aGVyIHRoYW4gc3BhY2UgZGVsaW1p dGluZy4gSXQgc2VlbWVkIGxpa2UgYSBnb29kIGlkZWEgYXQgdGhlIHRpbWUgLSBtb3JlIGNvbnNp c3RlbnQgd2l0aCBvdGhlciBKV1QgY2xhaW0gbmFtZXMgYW5kIGNsZWFuZXIgdG8gdXNlIHRoZSBm YWNpbGl0aWVzIG9mIEpTT04gcmF0aGVyIHRoYW4gYSBkZWxpbWl0ZWQgc3RyaW5nLiBUaGF0IHdh cyB0aGUgdGhpbmtpbmcgYXQgdGhlIHRpbWUgYW55d2F5IGFuZCwgYXMgSSByZWNhbGwsIEkgYXNr ZWQgdGhlIFdHIGFib3V0IGRvaW5nIGl0IHRoYXQgd2F5IGF0IG9uZSBvZiB0aGUgbWVldGluZ3Mg YW5kIHRoZXJlIHdhcyBnZW5lcmFsLCBpZiBzb21ld2hhdCBhYnNlbnQsIG5vZGRpbmcgaW4gdGhl IHJvb20uDQpMb29raW5nIGF0IHRoaXMgYWdhaW4gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHF1ZXN0 aW9uIGZyb20gVG9yc3RlbiBhbmQgaGlzIGRldmVsb3BlcnMsIEkgdGhpbmsgdXNpbmcgYSBkaWZm ZXJlbnQgbmFtZSBhbmQgc3ludGF4IGZvciB0aGUgSldUIGNsYWltIHZzLi4gdGhlIEludHJvc3Bl Y3Rpb24gcmVzcG9uc2UgbWVtYmVyL3BhcmFtZXRlci9jbGFpbSBpcyBwcm9iYWJseSBhIG1pc3Rh a2UuICBXaGlsZSBSRkMgNzY2MiBJbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHBhcmFtZXRlcnMgYXJl bid0IGV4YWN0bHkgdGhlIHNhbWUgYXMgSldUIGNsYWltcywgdGhleSBhcmUgc2ltaWxhciBpbiBt YW55IHJlc3BlY3RzLiBTbyBnaXZpbmcgY29uc2lzdGVudCB0cmVhdG1lbnQgYWNyb3NzIHRoZW0g dG8gc29tZXRoaW5nIGxpa2Ugc2NvcGUgaXMNClRoZXJlZm9yZSBJIHByb3Bvc2UgdGhhdCB0aGUg SldUIGNsYWltIGZvciByZXByZXNlbnRpbmcgc2NvcGUgaW4gZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZSBiZSBjaGFuZ2VkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgdHJlYXRtZW50 IG9mIHNjb3BlIGluIFJGQyA3NjYyIE9BdXRoIDIuMCBUb2tlbiBJbnRyb3NwZWN0aW9uLiBUaGF0 IGVmZmVjdGl2ZWx5IG1lYW5zIGNoYW5naW5nIHRoZSBuYW1lIGZyb20gInNjcCIgdG8gInNjb3Bl IiBhbmQgdGhlIHZhbHVlIGZyb20gYSBKU09OIGFycmF5IHRvIGEgc3RyaW5nIGRlbGltaXRlZCBi eSBzcGFjZXMuDQpJIHJlYWxpemUgaXQncyBsYXRlIGluIHRoZSBwcm9jZXNzIHRvIG1ha2UgdGhp cyBjaGFuZ2UgYnV0IGJlbGlldmUgZG9pbmcgc28gd2lsbCBzaWduaWZpY2FudGx5IHJlZHVjZSBj b25mdXNpb24gYW5kIGlzc3VlcyBpbiB0aGUgbG9uZyBydW4uDQoNCg0KDQoNCg0KT24gU3VuLCBB cHIgMTUsIDIwMTggYXQgMTA6NDMgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KSGkg YWxsLA0KDQpJIEnigJltIHdvbmRlcmluZyB3aHkgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZS0xMiBkZWZpbmVzIGEgY2xhaW0g4oCec2Nw4oCcIHRvIGNhcnJ5IHNjb3BlIHZhbHVlcyB3 aGlsZSBSRkMgNzU5MSBhbmQgUkZDIDc2NjIgdXNlIGEgY2xhaW0g4oCec2NvcGXigJwgZm9yIHRo ZSBzYW1lIHB1cnBvc2UuIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIHRleHQsIHRoZSBpbnRl bnNpb24gaXMgdG8gcmVwcmVzZW50IGEgbGlzdCBvZiBSRkM2NzQ5IHNjb3Blcy4gSXMgdGhpcyBj b3JyZWN0PyBXaGF04oCZcyB0aGUgcmF0aW9uYWxlIGJlaGluZD8NCg0KRGlmZmVyZW50IGNsYWlt IG5hbWVzIGZvciByZXByZXNlbnRpbmcgc2NvcGUgdmFsdWVzIGNvbmZ1c2UgcGVvcGxlLiBJIHJl YWxpemVkIHRoYXQgd2hlbiBvbmUgb2Ygb3VyIGRldmVsb3BlcnMgcG9pbnRlZCBvdXQgdGhhdCBk aWZmZXJlbmNlIHJlY2VudGx5Lg0KDQpiZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6 IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVy aWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJl dmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwg YW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcs IHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuDQo= --_000_DM5PR00MB0296E9493BA61BEDAA24B73BF5890DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiYjNDM7MTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAxMjoxMyBQTTxi cj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20mZ3Q7OyBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHNjcCBjbGFpbSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRv a2VuLWV4Y2hhbmdlLTEyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgbm90 aWNlZC9yZW1lbWJlcmVkIHRoYXQgdGhlIGRyYWZ0IGFsc28gY3VycmVudGx5IGRlZmluZXMgYSAm cXVvdDtjaWQmcXVvdDsgY2xhaW0gZm9yIHRoZSBjbGllbnQgaWRlbnRpZmllciB3aGVyZSBJbnRy b3NwZWN0aW9uJ3MgUkZDIDc2NjIgYWxyZWFkeSB1c2VzICZxdW90O2NsaWVudF9pZCZxdW90OyBm b3IgdGhlIHNhbWUgdGhpbmcuIFRoZSByZWFzb24gZm9yIHVzaW5nICZxdW90O2NpZCZxdW90OyB3 YXMgc2ltaWxhciBpbiB0aGF0IEkgd2FzIGxvb2tpbmcNCiB0byBmb2xsb3cgdGhlIHNlbWktY29u dmVudGlvbiBvZiBKV1QgdXNpbmcgdGhyZWUgbGV0dGVyIHNob3J0IGNsYWltIG5hbWVzLiBCdXQg SSB0aGluayBjb25zaXN0ZW5jeSB3aXRoIFJGQyA3NjYyIGlzIG1vcmUgaW1wb3J0YW50IGFuZCBt ZWFuaW5nZnVsIGhlcmUuIFNvLCBiYXJyaW5nIGEgcm91Z2ggY29uc2Npb3VzIG9mIG9iamVjdGlv bnMsIEknbSBnb2luZyB0byBtYWtlIHRoYXQgY2hhbmdlIHRvbyBpbiBhIHNvb24tdG8tYmUgbmV4 dCByZXZpc2lvbg0KIG9mIHRoZSBkcmFmdC4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBBcHIgMTksIDIwMTggYXQgNzozOCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVk dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9i bGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIC0gSXQg d2lsbCBtYWtlcyB0aGlua3MgbXVjaCBzaW1wbGVyLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFtIDE5LjA0LjIwMTggdW0gMDA6NTggc2NocmllYiBNaWtl IEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmW0gT0sgd2l0aCB0aGlzIGNoYW5nZSwgZ2l2ZW4gaXQg bWFrZXMgdGhlIE9BdXRoIHN1aXRlIG9mIHNwZWNzIG1vcmUgc2VsZi1jb25zaXN0ZW50Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gT0F1 dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTgsIDIw MTggODoxNyBBTTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gc2NwIGNsYWltIGlu IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl IGRvY3VtZW50IG1ha2VzIHVzZSBvZiBzY29wZSBhbmQgYXQgc29tZSBwb2ludCBpbiB0aGF0IHdv cmsgaXQgY2FtZSB0byBsaWdodCB0aGF0LCBkZXNwaXRlIHRoZSBjb25jZXB0IG9mIHNjb3BlIGJl aW5nIHVzZWQgbG90cyBvZiBwbGFjZXMgZWxzZXdoZXJlLA0KIHRoZXJlIHdhcyBubyBvZmZpY2lh bGx5IHJlZ2lzdGVyZWQgSldUIGNsYWltIGZvciBzY29wZS4gQXMgYSByZXN1bHQsIHdlICh0aGUg V0cpIGRlY2lkZWQgdG8gaGF2ZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRlZmlu ZSBhbmQgcmVnaXN0ZXIgYSBKV1QgY2xhaW0gZm9yIHNjb3BlLiBJdCdzIGtpbmQgb2YgYW4gYXdr d2FyZCBwbGFjZSBmb3IgaXQgcmVhbGx5IGJ1dCB0aGF0J3MgaG93IGl0IGNhbWUgdG8gYmUgdGhl cmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5XaGVuIEkgYWRk ZWQgaXQgdG8gdGhlIGRyYWZ0LCBJIG9wdGVkIGZvciB0aGUgc2VtaS1jb252ZW50aW9uIG9mIEpX VCB1c2luZyB0aHJlZSBsZXR0ZXIgc2hvcnQgY2xhaW0gbmFtZXMuLiBBbmQgZGVjaWRlZCB0byB1 c2UgYSBKU09OIGFycmF5IHRvIGNvbnZleSBtdWx0aXBsZSB2YWx1ZXMgcmF0aGVyIHRoYW4gc3Bh Y2UNCiBkZWxpbWl0aW5nLiBJdCBzZWVtZWQgbGlrZSBhIGdvb2QgaWRlYSBhdCB0aGUgdGltZSAt IG1vcmUgY29uc2lzdGVudCB3aXRoIG90aGVyIEpXVCBjbGFpbSBuYW1lcyBhbmQgY2xlYW5lciB0 byB1c2UgdGhlIGZhY2lsaXRpZXMgb2YgSlNPTiByYXRoZXIgdGhhbiBhIGRlbGltaXRlZCBzdHJp bmcuIFRoYXQgd2FzIHRoZSB0aGlua2luZyBhdCB0aGUgdGltZSBhbnl3YXkgYW5kLCBhcyBJIHJl Y2FsbCwgSSBhc2tlZCB0aGUgV0cgYWJvdXQgZG9pbmcNCiBpdCB0aGF0IHdheSBhdCBvbmUgb2Yg dGhlIG1lZXRpbmdzIGFuZCB0aGVyZSB3YXMgZ2VuZXJhbCwgaWYgc29tZXdoYXQgYWJzZW50LCBu b2RkaW5nIGluIHRoZSByb29tLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPkxvb2tpbmcgYXQgdGhpcyBhZ2FpbiBpbiB0aGUgY29udGV4dCBvZiB0aGUg cXVlc3Rpb24gZnJvbSBUb3JzdGVuIGFuZCBoaXMgZGV2ZWxvcGVycywgSSB0aGluayB1c2luZyBh IGRpZmZlcmVudCBuYW1lIGFuZCBzeW50YXggZm9yIHRoZSBKV1QgY2xhaW0gdnMuLiB0aGUgSW50 cm9zcGVjdGlvbiByZXNwb25zZSBtZW1iZXIvcGFyYW1ldGVyL2NsYWltDQogaXMgcHJvYmFibHkg YSBtaXN0YWtlLiZuYnNwOyBXaGlsZSBSRkMgNzY2MiBJbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHBh cmFtZXRlcnMgYXJlbid0IGV4YWN0bHkgdGhlIHNhbWUgYXMgSldUIGNsYWltcywgdGhleSBhcmUg c2ltaWxhciBpbiBtYW55IHJlc3BlY3RzLiBTbyBnaXZpbmcgY29uc2lzdGVudCB0cmVhdG1lbnQg YWNyb3NzIHRoZW0gdG8gc29tZXRoaW5nIGxpa2Ugc2NvcGUgaXMNCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZWZvcmUgSSBwcm9wb3NlIHRoYXQg dGhlIEpXVCBjbGFpbSBmb3IgcmVwcmVzZW50aW5nIHNjb3BlIGluIGRyYWZ0LWlldGYtb2F1dGgt dG9rZW4tZXhjaGFuZ2UgYmUgY2hhbmdlZCB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHRyZWF0 bWVudCBvZiBzY29wZSBpbiZuYnNwO1JGQyA3NjYyIE9BdXRoIDIuMCBUb2tlbiBJbnRyb3NwZWN0 aW9uLg0KIFRoYXQgZWZmZWN0aXZlbHkgbWVhbnMgY2hhbmdpbmcgdGhlIG5hbWUgZnJvbSAmcXVv dDtzY3AmcXVvdDsgdG8gJnF1b3Q7c2NvcGUmcXVvdDsgYW5kIHRoZSB2YWx1ZSBmcm9tIGEgSlNP TiBhcnJheSB0byBhIHN0cmluZyBkZWxpbWl0ZWQgYnkgc3BhY2VzLg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVhbGl6ZSBpdCdzIGxh dGUgaW4gdGhlIHByb2Nlc3MgdG8gbWFrZSB0aGlzIGNoYW5nZSBidXQgYmVsaWV2ZSBkb2luZyBz byB3aWxsIHNpZ25pZmljYW50bHkgcmVkdWNlIGNvbmZ1c2lvbiBhbmQgaXNzdWVzIGluIHRoZSBs b25nIHJ1bi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBB cHIgMTUsIDIwMTggYXQgMTA6NDMgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9 Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ SGkgYWxsLDxicj4NCjxicj4NCkkgSeKAmW0gd29uZGVyaW5nIHdoeSBkcmFmdC1pZXRmLW9hdXRo LXRva2VuLWV4Y2hhbmdlLTEyIGRlZmluZXMgYSBjbGFpbSDigJ5zY3DigJwgdG8gY2Fycnkgc2Nv cGUgdmFsdWVzIHdoaWxlIFJGQyA3NTkxIGFuZCBSRkMgNzY2MiB1c2UgYSBjbGFpbSDigJ5zY29w ZeKAnCBmb3IgdGhlIHNhbWUgcHVycG9zZS4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGUgdGV4 dCwgdGhlIGludGVuc2lvbiBpcyB0byByZXByZXNlbnQgYSBsaXN0IG9mIFJGQzY3NDkgc2NvcGVz Lg0KIElzIHRoaXMgY29ycmVjdD8gV2hhdOKAmXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQ/PGJyPg0K PGJyPg0KRGlmZmVyZW50IGNsYWltIG5hbWVzIGZvciByZXByZXNlbnRpbmcgc2NvcGUgdmFsdWVz IGNvbmZ1c2UgcGVvcGxlLiBJIHJlYWxpemVkIHRoYXQgd2hlbiBvbmUgb2Ygb3VyIGRldmVsb3Bl cnMgcG9pbnRlZCBvdXQgdGhhdCBkaWZmZXJlbmNlIHJlY2VudGx5Lg0KPGJyPg0KPGJyPg0KYmVz dCByZWdhcmRzLDxicj4NClRvcnN0ZW4uPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7 Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZ IE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVn ZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMp Lg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJz IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNo bWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM5PR00MB0296E9493BA61BEDAA24B73BF5890DM5PR00MB0296namp_-- From nobody Mon Apr 23 13:15:52 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735A9126D45 for ; Mon, 23 Apr 2018 13:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brd4n1Jz9IrJ for ; Mon, 23 Apr 2018 13:15:47 -0700 (PDT) Received: from omr-m014e.mx.aol.com (omr-m014e.mx.aol.com [204.29.186.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A81126B6E for ; Mon, 23 Apr 2018 13:15:47 -0700 (PDT) Received: from mtaout-aag01.mx.aol.com (mtaout-aag01.mx.aol.com [172.26.126.77]) by omr-m014e.mx.aol.com (Outbound Mail Relay) with ESMTP id EBFD2380005D; Mon, 23 Apr 2018 16:15:45 -0400 (EDT) Received: from [172.135.141.251] (0x5b3137322e3133352e3134312e3235315d [98.139.248.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mtaout-aag01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 754AD38000091; Mon, 23 Apr 2018 16:15:45 -0400 (EDT) To: Brian Campbell , Torsten Lodderstedt Cc: oauth References: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> From: George Fletcher Organization: AOL LLC Message-ID: <9f16d60a-73dc-eb3f-85e8-5869472181b8@aol.com> Date: Mon, 23 Apr 2018 16:15:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E52D34E19B964A949C38DEB3" Content-Language: en-US x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1524514545; bh=ue0qBNch8gEGG0KnsjZ4XaXCmqG+tzmcHA8v7CxkBJU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Sv2HETFDGrTah9tfR7rcsiu4dY4zu/QnGJkBfrabcH4/NBKDYc+6ENpHb7RzhF8/d XUCQn2o/9If5ZYg5dAVG+TMMRecuWLRHdqcKHisCR+IWY56cRE4rdYDOzkWOnUiq1o 1shEmv6ZuOLn/HRcRdYfWGRUEc8nB1zTTpRA2U6E= x-aol-sid: 3039ac1a7e4d5ade3ef1423e X-AOL-IP: 98.139.248.67 Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:15:51 -0000 This is a multi-part message in MIME format. --------------E52D34E19B964A949C38DEB3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 On 4/23/18 3:13 PM, Brian Campbell wrote: > I just noticed/remembered that the draft also currently defines a > "cid" claim for the client identifier where Introspection's RFC 7662 > already uses "client_id" for the same thing. The reason for using > "cid" was similar in that I was looking to follow the semi-convention > of JWT using three letter short claim names. But I think consistency > with RFC 7662 is more important and meaningful here. So, barring a > rough conscious of objections, I'm going to make that change too in a > soon-to-be next revision of the draft. > > > > On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt > > wrote: > > +1 - It will makes thinks much simpler. > > >> Am 19.04.2018 um 00:58 schrieb Mike Jones >> >: >> >> I’m OK with this change, given it makes the OAuth suite of specs >> more self-consistent. >> >> -- Mike >> >> *From:* OAuth > > *On Behalf Of * Brian Campbell >> *Sent:* Wednesday, April 18, 2018 8:17 AM >> *To:* Torsten Lodderstedt > > >> *Cc:* oauth > >> *Subject:* Re: [OAUTH-WG] scp claim in >> draft-ietf-oauth-token-exchange-12 >> >> The draft-ietf-oauth-token-exchange document makes use of scope >> and at some point in that work it came to light that, despite the >> concept of scope being used lots of places elsewhere, there was >> no officially registered JWT claim for scope. As a result, we >> (the WG) decided to have draft-ietf-oauth-token-exchange define >> and register a JWT claim for scope. It's kind of an awkward place >> for it really but that's how it came to be there. >> >> When I added it to the draft, I opted for the semi-convention of >> JWT using three letter short claim names.. And decided to use a >> JSON array to convey multiple values rather than space >> delimiting. It seemed like a good idea at the time - more >> consistent with other JWT claim names and cleaner to use the >> facilities of JSON rather than a delimited string. That was the >> thinking at the time anyway and, as I recall, I asked the WG >> about doing it that way at one of the meetings and there was >> general, if somewhat absent, nodding in the room. >> >> Looking at this again in the context of the question from Torsten >> and his developers, I think using a different name and syntax for >> the JWT claim vs.. the Introspection response >> member/parameter/claim is probably a mistake.  While RFC 7662 >> Introspection response parameters aren't exactly the same as JWT >> claims, they are similar in many respects. So giving consistent >> treatment across them to something like scope is >> >> Therefore I propose that the JWT claim for representing scope in >> draft-ietf-oauth-token-exchange be changed to be consistent with >> the treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. >> That effectively means changing the name from "scp" to "scope" >> and the value from a JSON array to a string delimited by spaces. >> >> I realize it's late in the process to make this change but >> believe doing so will significantly reduce confusion and issues >> in the long run. >> >> >> On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt >> > wrote: >> >> Hi all, >> >> I I’m wondering why draft-ietf-oauth-token-exchange-12 >> defines a claim „scp“ to carry scope values while RFC 7591 >> and RFC 7662 use a claim „scope“ for the same purpose. As far >> as I understand the text, the intension is to represent a >> list of RFC6749 scopes. Is this correct? What’s the rationale >> behind? >> >> Different claim names for representing scope values confuse >> people. I realized that when one of our developers pointed >> out that difference recently. >> >> best regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> */CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended >> recipient(s). Any review, use, distribution or disclosure by >> others is strictly prohibited..  If you have received this >> communication in error, please notify the sender immediately by >> e-mail and delete the message and any file attachments from your >> computer. Thank you./* >> > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Distinguished Engineer Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------E52D34E19B964A949C38DEB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

On 4/23/18 3:13 PM, Brian Campbell wrote:
I just noticed/remembered that the draft also currently defines a "cid" claim for the client identifier where Introspection's RFC 7662 already uses "client_id" for the same thing. The reason for using "cid" was similar in that I was looking to follow the semi-convention of JWT using three letter short claim names. But I think consistency with RFC 7662 is more important and meaningful here. So, barring a rough conscious of objections, I'm going to make that change too in a soon-to-be next revision of the draft.



On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
+1 - It will makes thinks much simpler.


Am 19.04.2018 um 00:58 schrieb Mike Jones <Michael.Jones@microsoft.com>:

I’m OK with this change, given it makes the OAuth suite of specs more self-consistent.

 

                                                       -- Mike

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 18, 2018 8:17 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

 

The draft-ietf-oauth-token-exchange document makes use of scope and at some point in that work it came to light that, despite the concept of scope being used lots of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to have draft-ietf-oauth-token-exchange define and register a JWT claim for scope. It's kind of an awkward place for it really but that's how it came to be there.

When I added it to the draft, I opted for the semi-convention of JWT using three letter short claim names.. And decided to use a JSON array to convey multiple values rather than space delimiting. It seemed like a good idea at the time - more consistent with other JWT claim names and cleaner to use the facilities of JSON rather than a delimited string. That was the thinking at the time anyway and, as I recall, I asked the WG about doing it that way at one of the meetings and there was general, if somewhat absent, nodding in the room.

Looking at this again in the context of the question from Torsten and his developers, I think using a different name and syntax for the JWT claim vs.. the Introspection response member/parameter/claim is probably a mistake.  While RFC 7662 Introspection response parameters aren't exactly the same as JWT claims, they are similar in many respects. So giving consistent treatment across them to something like scope is

Therefore I propose that the JWT claim for representing scope in draft-ietf-oauth-token-exchange be changed to be consistent with the treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That effectively means changing the name from "scp" to "scope" and the value from a JSON array to a string delimited by spaces.

I realize it's late in the process to make this change but believe doing so will significantly reduce confusion and issues in the long run. 


 

 

 

 

On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ to carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the same purpose. As far as I understand the text, the intension is to represent a list of RFC6749 scopes. Is this correct? What’s the rationale behind?

Different claim names for representing scope values confuse people. I realized that when one of our developers pointed out that difference recently.

best regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.




CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

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


-- 
Distinguished Engineer                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------E52D34E19B964A949C38DEB3-- From nobody Mon Apr 23 13:41:24 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 681C7124207; Mon, 23 Apr 2018 13:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152451607738.21805.4086899301059406797@ietfa.amsl.com> Date: Mon, 23 Apr 2018 13:41:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:41:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-13.txt Pages : 33 Date : 2018-04-23 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 23 13:46:01 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FA512D95A for ; Mon, 23 Apr 2018 13:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKjNRERdxrP9 for ; Mon, 23 Apr 2018 13:45:57 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022A212D957 for ; Mon, 23 Apr 2018 13:45:57 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 71-v6so12427609ith.2 for ; Mon, 23 Apr 2018 13:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EOzwcfNSNLJ60PVk3GS/gOuCBh79jZLi8p3iqM5XDpQ=; b=FqL1KD3+7yNnN1kQVnmW53hzOQFDAeYmCZa3ySyOijOoEYFOFv//rEHR+NxCmVqs+m jwwUH1NkHMEHLoZmYqmT+Zsr2gCDZWZ+fAohV3ro+MfxvwjS/xS3rua2mr8yfjfD8e+l RLi9uZoAz89D6OqSg9jXS6LXGwJgbITLVPWxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EOzwcfNSNLJ60PVk3GS/gOuCBh79jZLi8p3iqM5XDpQ=; b=JIxZy+9KT1YPPZMrIRjTfCFLGtkZIKgyc4xCox26oYt8+29fWm+nbcyM4A0pqILPoF SGBV46B8OUMYVh1+A8ifYGRnPeaQppclsP6/r8PyXwVITSrldXOPncZ6gNswVL60pYCm Gf2Ge1kZXmTurWF25k/YYYP7Wz3GllQaCBpsa4piD3eh2b0A6UAb9WCl0b7thTTW9LB1 KmlZ67MBwUn9dH1kUYNd6Cr84DGSW1CXrLcYF/10IiuLgu3RcdLvcpNqAO1RfyIRPE2g oEXz+OArdn+Gx6lpd+duDeuXARqKpMt8C0eSh045UGrQVhe49XkAhXTRZbkf7UG5jwXF Ts6g== X-Gm-Message-State: ALQs6tDX/bRNsWVVhAj5bUUFAGe4goJxR50xx5bB+lZ6f5E7O0lkbfzG MfSGRoL1X+Z7VQjryFuL3B89eJMYDKSvMHbdiqGk+551XM55prHj2tVGqDARnyaqOHrR2L7gUs4 bZAtBy6WhDjcoEA== X-Google-Smtp-Source: AIpwx48nDb+LEVGZ7HVxl8kt7S9j2icTC/Jk23r7beQCD+AfG1cY8udyZxSXw/gjdHXYEw+JmisqGuSufH7F2smHBAk= X-Received: by 2002:a24:2551:: with SMTP id g78-v6mr6777830itg.76.1524516356166; Mon, 23 Apr 2018 13:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 13:45:25 -0700 (PDT) In-Reply-To: <9f16d60a-73dc-eb3f-85e8-5869472181b8@aol.com> References: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> <9f16d60a-73dc-eb3f-85e8-5869472181b8@aol.com> From: Brian Campbell Date: Mon, 23 Apr 2018 14:45:25 -0600 Message-ID: To: George Fletcher Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000dd37e5056a8a1f15" Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:46:00 -0000 --000000000000dd37e5056a8a1f15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable draft -13 was just published with these changes On Mon, Apr 23, 2018 at 2:15 PM, George Fletcher wrote: > +1 > > > On 4/23/18 3:13 PM, Brian Campbell wrote: > > I just noticed/remembered that the draft also currently defines a "cid" > claim for the client identifier where Introspection's RFC 7662 already us= es > "client_id" for the same thing. The reason for using "cid" was similar in > that I was looking to follow the semi-convention of JWT using three lette= r > short claim names. But I think consistency with RFC 7662 is more importan= t > and meaningful here. So, barring a rough conscious of objections, I'm goi= ng > to make that change too in a soon-to-be next revision of the draft. > > > > On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> +1 - It will makes thinks much simpler. >> >> >> Am 19.04.2018 um 00:58 schrieb Mike Jones : >> >> I=E2=80=99m OK with this change, given it makes the OAuth suite of specs= more >> self-consistent. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * Brian Campbell >> *Sent:* Wednesday, April 18, 2018 8:17 AM >> *To:* Torsten Lodderstedt >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-1= 2 >> >> >> >> The draft-ietf-oauth-token-exchange document makes use of scope and at >> some point in that work it came to light that, despite the concept of sc= ope >> being used lots of places elsewhere, there was no officially registered = JWT >> claim for scope. As a result, we (the WG) decided to have >> draft-ietf-oauth-token-exchange define and register a JWT claim for >> scope. It's kind of an awkward place for it really but that's how it cam= e >> to be there. >> >> When I added it to the draft, I opted for the semi-convention of JWT >> using three letter short claim names.. And decided to use a JSON array t= o >> convey multiple values rather than space delimiting. It seemed like a go= od >> idea at the time - more consistent with other JWT claim names and cleane= r >> to use the facilities of JSON rather than a delimited string. That was t= he >> thinking at the time anyway and, as I recall, I asked the WG about doing= it >> that way at one of the meetings and there was general, if somewhat absen= t, >> nodding in the room. >> >> Looking at this again in the context of the question from Torsten and hi= s >> developers, I think using a different name and syntax for the JWT claim >> vs.. the Introspection response member/parameter/claim is probably a >> mistake. While RFC 7662 Introspection response parameters aren't exactl= y >> the same as JWT claims, they are similar in many respects. So giving >> consistent treatment across them to something like scope is >> >> Therefore I propose that the JWT claim for representing scope in >> draft-ietf-oauth-token-exchange be changed to be consistent with the >> treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That >> effectively means changing the name from "scp" to "scope" and the value >> from a JSON array to a string delimited by spaces. >> >> I realize it's late in the process to make this change but believe doing >> so will significantly reduce confusion and issues in the long run. >> >> >> >> >> >> >> >> >> >> >> On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> Hi all, >> >> I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a= claim >> =E2=80=9Escp=E2=80=9C to carry scope values while RFC 7591 and RFC 7662 = use a claim =E2=80=9Escope=E2=80=9C >> for the same purpose. As far as I understand the text, the intension is = to >> represent a list of RFC6749 scopes. Is this correct? What=E2=80=99s the = rationale >> behind? >> >> Different claim names for representing scope values confuse people. I >> realized that when one of our developers pointed out that difference >> recently. >> >> best regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Distinguished Engineer > Identity Services Engineering Work: george.fletcher@teamaol.com > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photograp= hy > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000dd37e5056a8a1f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
draft -13 was just published with these changes
=

On Mon, Apr 23, 2= 018 at 2:15 PM, George Fletcher <gffletch@aol.com> wrote:
=
=20 =20 =20
+1


On 4/23/18 3:13 PM,= Brian Campbell wrote:
I just noticed/remembered that the draft also currently defines a "cid" claim for the client identifier= where Introspection's RFC 7662 already uses "client_id" for= the same thing. The reason for using "cid" was similar in that I w= as looking to follow the semi-convention of JWT using three letter short claim names. But I think consistency with RFC 7662 is more important and meaningful here. So, barring a rough conscious of objections, I'm going to make that change too in a soon-to-be next revision of the draft.



On Thu, Apr 19, 2018 at 7:38 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
+1 - It will makes thinks much simpler.


Am 19.04.2018 um 00:58 schrieb Mike Jones <Michael.Jones@microsoft.com>:

I=E2=80=99m OK with this change, given it makes the OAuth suite of specs more self-consistent.

=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=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=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=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth <<= a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ie= tf.org> On Behalf Of Brian Campbell
Sent: Wednesday, April 18, 2018 8:17 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net<= /a>>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

=C2=A0

The draft-ietf-oauth-token-exchange document makes use of scope and at some point in that work it came to light that, despite the concept of scope being used lots of places elsewhere, there was no officially registered JWT claim for scope. As a result, we (the WG) decided to have draft-ietf-oauth-token-exchange define and register a JWT claim for scope. It's kind of an awkward plac= e for it really but that's how it cam= e to be there.

When I added it to the draft, I opted for the semi-convention of JWT using three letter short claim names.. And decided to use a JSON array to convey multiple values rather than space delimiting. It seemed like a good idea at the time - more consistent with other JWT claim names and cleaner to use the facilities of JSON rather than a delimited string. That was the thinking at the time anyway and, as I recall, I asked the WG about doing it that way at one of the meetings and there was general, if somewhat absent, nodding in the room.

Looking at this again in the context of the question from Torsten and his developers, I think using a different name and syntax for the JWT claim vs.. the Introspection response member/parameter/claim is probably a mistake.=C2=A0 While RFC 7662 Introspecti= on response parameters aren't exactly th= e same as JWT claims, they are similar in many respects. So giving consistent treatment across them to something like scope is

Therefore I propose that the JWT claim for representing scope in draft-ietf-oauth-token-exchange be changed to be consistent with the treatment of scope in=C2=A0RFC 7662 OAuth 2.0 Token Introspection. That effectively means changing the name from "scp" to "scope"= and the value from a JSON array to a string delimited by spaces.

I realize it's l= ate in the process to make this change but believe doing so will significantly reduce confusion and issues in the long run.=C2=A0


=C2=A0

=C2=A0

=C2=A0=

=C2=A0

On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

I I=E2=80=99m wondering why draft-ietf-oauth-token-exchange-12 defines a claim =E2=80=9Escp=E2=80=9C t= o carry scope values while RFC 7591 and RFC 7662 use a claim =E2=80=9Escope=E2=80=9C for= the same purpose. As far as I understand the text, the intension is to represent a list of RFC6749 scopes. Is this correct? What=E2=80=99s the rationale behind?

Different claim names for representing scope values confuse people. I realized that when one of our developers pointed out that difference recently.

best regards,
Torsten.
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.




CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth


--=20
Distinguished Engineer                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000dd37e5056a8a1f15-- From nobody Mon Apr 23 20:33:39 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553BD124B0A for ; Mon, 23 Apr 2018 20:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-jF4wbol_27 for ; Mon, 23 Apr 2018 20:33:35 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B7212704A for ; Mon, 23 Apr 2018 20:33:34 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id d1-v6so46488748wrj.13 for ; Mon, 23 Apr 2018 20:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jStsI1odsuC2DjodpyMNmrWFOW35hzNIHcFWlxsUFVc=; b=LVLD9yE1Efq2XWov9qb9JwsmRW7/vdQoA7nVRZO4afhygZ4hrpaPbIWk5R4JI545+Z r7HfZQnxFOW+RK0E+3+T0jhvcbYcqb8x8Y1/z5hqWPSbz6mCNDHpjP1HotNM65+FRSXc 7A1ARloM3N0ckYQbf8ezYaoEJFXE+s99eJkcoziego0QELjw3S7Ga2hE5RYuUwwcxqa5 +MXNTSHw3VI2qC+LyeUA4Cx3iIKCS0nQbZiNuWYoplLILkyuoVcummbakYre10J2iYMq 8wXhjwYWTzLQCQXiTMzaFKi7Fy1gIBOjmb7MeqHFid9asACh+2wOURKI0aYxVa5wZzRz exlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jStsI1odsuC2DjodpyMNmrWFOW35hzNIHcFWlxsUFVc=; b=camz2L/kSy0xuJ8fe5M5e37ePomEH9phQtmUpvxpocfGE1SHpPSdAXsnqyD0WFjgPR jKCbL7jENUTyt/XA9eLjjH1WOK6IZRbafTMItSikpYeXhuVTX/xNCzBaorTy1S7w8bW2 wlvmnKBtsM/naChi+qeD5Tkxf3TsevuRuNfcrB48iV3aoV1fQeLx5ZjY538V/nAnaB4l NrYeCTVSXUWLO59CsS2IQqaw9oXE7S77HRLOHs4UCR2pS3EVslgHjwWK8f1RaQr/LGKv 0IINIxNYP/b5TPwwC/7n7ed7nhQaiWsgtnoicnUQSduF2U/mdF0+Blfp8l2j+yXBG86M uBXg== X-Gm-Message-State: ALQs6tBkjfB1rTW6nW6fwWTQ0x/f3i020rQ0+91cto8CJCq+iJfdAdaY +sP9RJSwdGVQTrT1AeDeizEbKXWKwcwUZhfs7No= X-Google-Smtp-Source: AIpwx4/nXRH3N0M7i/MWVfZ8IOf7XmyfVEE35f/Bjp+290gcRs9xpKohGs+FudTI57TvKJKXt0atAKsJmA1OP9kS1S4= X-Received: by 2002:adf:c4c4:: with SMTP id o4-v6mr19497003wrf.173.1524540813461; Mon, 23 Apr 2018 20:33:33 -0700 (PDT) MIME-Version: 1.0 References: <88C79981-4D1B-402F-A284-A636153DE082@amazon.com> In-Reply-To: <88C79981-4D1B-402F-A284-A636153DE082@amazon.com> From: Nat Sakimura Date: Tue, 24 Apr 2018 03:33:22 +0000 Message-ID: To: "Richard Backman, Annabelle" Cc: Brian Campbell , Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000a1cba9056a8fd1c3" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 03:33:37 -0000 --000000000000a1cba9056a8fd1c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle < richanna@amazon.com> wrote: > I support adoption of OAuth 2.0 Incremental Authorization as a WG documen= t. > > > > -- > > Annabelle Richard Backman > > Amazon =E2=80=93 Identity Services > > > > *From: *OAuth on behalf of Brian Campbell < > bcampbell@pingidentity.com> > *Date: *Wednesday, April 18, 2018 at 8:23 AM > *To: *Rifaat Shekh-Yusef > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental > Authorization > > > > I support adoption of OAuth 2.0 Incremental Authorization as a WG documen= t. > > > > On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-Yusef > wrote: > > All, > > > > We would like to get a confirmation on the mailing list for the adoption = of > the *OAuth 2.0 Incremental Authorization* as a WG document > > https://datatracker.ietf.org/doc/draft-wdenniss-oauth-incremental-auth/ > > > > Please, let us know if you support or object to the adoption of this > document. > > > > Regards, > > Rifaat & Hannes > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --000000000000a1cba9056a8fd1c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle <richanna@amazon.com> wrote:

I support adoption of OAuth 2.0 Incremental Authoriz= ation as a WG document.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Amazon =E2=80=93 Identity Services=

=C2=A0

From= : OAuth <oaut= h-bounces@ietf.org> on behalf of Brian Campbell <bcampbell@pin= gidentity.com>
Date: Wednesday, April 18, 2018 at 8:23 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Aut= horization

=C2=A0

=C2=A0

On Mon, Apr 16, 2018 at 8:47 AM, Rifaat Shekh-= Yusef <rifaat.ietf@gmail.com> wrote:

All,

= =C2=A0

We would like to get a confirmation on the mailing list for th= e=C2=A0adoption=C2=A0of the=C2=A0OAuth 2.0 Incremental Authorization=C2=A0as a WG document<= /span>

=C2=A0

Please,= let us know if you support or object to the=C2=A0adoption=C2=A0of this document.

= =C2=A0

Regards= ,

=C2=A0R= ifaat & Hannes

=C2=A0


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

=C2=A0


CONF= IDENTIALITY NOTICE: This email may contain confidential and privileged mate= rial for the sole use of the intended recipient(s). Any review, use, distributi= on or disclosure by others is strictly prohibited..=C2=A0 If you have recei= ved this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--000000000000a1cba9056a8fd1c3-- From nobody Tue Apr 24 07:33:21 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5BE12D7F6 for ; Tue, 24 Apr 2018 07:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 317RvTZTzWa6 for ; Tue, 24 Apr 2018 07:33:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6106712DFDB for ; Tue, 24 Apr 2018 07:32:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 90DABB82844; Tue, 24 Apr 2018 07:32:38 -0700 (PDT) To: dick.hardt@gmail.com, kaduk@mit.edu, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: donald.coffin@reminetworks.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180424143238.90DABB82844@rfc-editor.org> Date: Tue, 24 Apr 2018 07:32:38 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5332) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:33:20 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5332 -------------------------------------- Type: Technical Reported by: Donald F Coffin Section: 4.1 Original Text ------------- (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request. Corrected Text -------------- (B) The authorization server validates the request to ensure that all required parameters are present and valid. If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner via the user-agent or by use of other established approval means). Notes ----- "Section 4.1 Authorization Code Grant (B)" conflicts with "Section 4.1.1 Authorization Request". The current verbiage implies the resource owner should be authenticated prior to "The authorization server validates the request to ensure that all required parameters are present and valid". Such implementations lead to overly complex user experiences when the Authorization Server determines the request is invalid. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 24 15:53:49 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC312DA02 for ; Tue, 24 Apr 2018 15:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsF1QzlqkmIZ for ; Tue, 24 Apr 2018 15:53:41 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0095.outbound.protection.outlook.com [104.47.33.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E1512D87E for ; Tue, 24 Apr 2018 15:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=InfUtvaFKwXKbSTsw2XU6L3KraLkIstDpNNn3/AgXIk=; b=bM7nKkP8hVzYDslDvbvg8Toh/eLeBvzgkJrquhU5lU0+A5BSl7ibAabjOJ2EPM/bIA46Fkc4su2P2OwS3JBXSr1KHYVwUM1YQ7we5/lO7FWB5waaNQLf2a0cZOpIim182TMc6jTPxr3KW/nJh/36z9S6VjGiUmecbCQ7xZgdVH4= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0291.namprd00.prod.outlook.com (2603:10b6:207:1e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.749.0; Tue, 24 Apr 2018 22:53:36 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::f9bf:2cdb:bda8:6be]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::f9bf:2cdb:bda8:6be%5]) with mapi id 15.20.0749.000; Tue, 24 Apr 2018 22:53:36 +0000 From: Mike Jones To: Brian Campbell , George Fletcher CC: oauth Thread-Topic: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 Thread-Index: AQHT1NjgJy8mHwoFFk6XUY9K9SCN+aQGpvqAgACAzaCAAPXeAIAGpvWAgAARawCAAAhLgIABp+vA Date: Tue, 24 Apr 2018 22:53:36 +0000 Message-ID: References: <99725E0A-45F8-4E5C-8AAF-6F6C38110F2A@lodderstedt.net> <9f16d60a-73dc-eb3f-85e8-5869472181b8@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-24T22:53:34.9022112Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:9::50e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0291; 7:yYFU429W1DjHf1hvf5PppagED32U0wVTo80j6bwvuJeuiI2wywgokTNnyII2LrSLRYCI4NZ+FTrIzu6fP0N/tSSJ+2CHY7ulPx9d7mV3FJ11/wcXqFXBe80qjDxJVnHALZtRxpvBmP9oURYlIshzhcqPlY9m8Gjkyjto4NDp4FEEAX1gnq++k3Xmtaag4QT9PIRtTU/MbkXzMre2akgpxagee8ZIGyfjWDMiSACMpoEf4OdOUhhqTuhevacbDjb4; 20:+Hae5Ow97ral20RiQr9IhtikIzDjSGYAlLv3kLf1iKGL7eAme82qYuwJcyQZPIevQTInD1d3piFSxoVtudZHy3GZJXc70i78HTzJ5CkpOBpkeHczuZKBPDmoOyuoVeUYMwzI+DchSyWbovtd88AemfYgesq8CGCG60kWDusne3s= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0291; x-ms-traffictypediagnostic: BL0PR00MB0291: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(148322886591682)(149059832740258)(89211679590171)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(3231232)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:BL0PR00MB0291; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0291; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39380400002)(376002)(39860400002)(396003)(209900001)(69234005)(199004)(189003)(53754006)(7736002)(76176011)(5660300001)(14454004)(5890100001)(606006)(99286004)(7696005)(5250100002)(52396003)(55016002)(4326008)(33656002)(39060400002)(10090500001)(8990500004)(105586002)(102836004)(236005)(186003)(97736004)(2906002)(6306002)(9686003)(54896002)(74316002)(53936002)(106356001)(3660700001)(6506007)(59450400001)(53376002)(53546011)(6246003)(68736007)(3280700002)(46003)(446003)(86362001)(478600001)(10290500003)(2900100001)(1600100001)(790700001)(6116002)(11346002)(25786009)(486006)(316002)(22452003)(966005)(6436002)(110136005)(93886005)(8936002)(81156014)(229853002)(476003)(19609705001)(86612001)(72206003)(81166006)(8676002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0291; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oDdO6aZZMXDqKrWnjRfPJzB1zwtgbK7ArJTitLEQrQqWnjGd5DmFaIMadRyPJh6IwXapnhBLAwVL9eaUd65Tsi88eUO/qcG1NF+HRHd4HEkewIB4fsQDcq0sSAGSmHJkrnwvD4XDsLUVP44MbZJTn8CFixPLqaWtQmAXLdRU0NTT7tomtME9Ku+6rbICOnu+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292E3A7FA7A2217CDC4324CF5880BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 868be8fc-c7c0-44ef-a6d7-08d5aa3636b7 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 868be8fc-c7c0-44ef-a6d7-08d5aa3636b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 22:53:36.3813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0291 Archived-At: Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 22:53:46 -0000 --_000_BL0PR00MB0292E3A7FA7A2217CDC4324CF5880BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCBJIGJsb2dnZWQgYWJvdXQgdGhlc2UgY2hhbmdlcyBpbiBteSBwb3N0IOKAnExhdGUtYnJl YWtpbmcgY2hhbmdlcyB0byBPQXV0aCBUb2tlbiBFeGNoYW5nZSBzeW50YXjigJ0gYXQgaHR0cDov L3NlbGYtaXNzdWVkLmluZm8vP3A9MTgyNSBhbmQgYXQgQHNlbGZpc3N1ZWQ8aHR0cHM6Ly90d2l0 dGVyLmNvbS9zZWxmaXNzdWVkPi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDog TW9uZGF5LCBBcHJpbCAyMywgMjAxOCAxOjQ1IFBNDQpUbzogR2VvcmdlIEZsZXRjaGVyIDxnZmZs ZXRjaEBhb2wuY29tPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIHNjcCBjbGFpbSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEy DQoNCmRyYWZ0IC0xMyB3YXMganVzdCBwdWJsaXNoZWQgd2l0aCB0aGVzZSBjaGFuZ2VzDQoNCk9u IE1vbiwgQXByIDIzLCAyMDE4IGF0IDI6MTUgUE0sIEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hA YW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+IHdyb3RlOg0KKzENCg0KT24gNC8yMy8x OCAzOjEzIFBNLCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCkkganVzdCBub3RpY2VkL3JlbWVtYmVy ZWQgdGhhdCB0aGUgZHJhZnQgYWxzbyBjdXJyZW50bHkgZGVmaW5lcyBhICJjaWQiIGNsYWltIGZv ciB0aGUgY2xpZW50IGlkZW50aWZpZXIgd2hlcmUgSW50cm9zcGVjdGlvbidzIFJGQyA3NjYyIGFs cmVhZHkgdXNlcyAiY2xpZW50X2lkIiBmb3IgdGhlIHNhbWUgdGhpbmcuIFRoZSByZWFzb24gZm9y IHVzaW5nICJjaWQiIHdhcyBzaW1pbGFyIGluIHRoYXQgSSB3YXMgbG9va2luZyB0byBmb2xsb3cg dGhlIHNlbWktY29udmVudGlvbiBvZiBKV1QgdXNpbmcgdGhyZWUgbGV0dGVyIHNob3J0IGNsYWlt IG5hbWVzLiBCdXQgSSB0aGluayBjb25zaXN0ZW5jeSB3aXRoIFJGQyA3NjYyIGlzIG1vcmUgaW1w b3J0YW50IGFuZCBtZWFuaW5nZnVsIGhlcmUuIFNvLCBiYXJyaW5nIGEgcm91Z2ggY29uc2Npb3Vz IG9mIG9iamVjdGlvbnMsIEknbSBnb2luZyB0byBtYWtlIHRoYXQgY2hhbmdlIHRvbyBpbiBhIHNv b24tdG8tYmUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCg0KT24gVGh1LCBBcHIgMTks IDIwMTggYXQgNzozOCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQorMSAtIEl0IHdp bGwgbWFrZXMgdGhpbmtzIG11Y2ggc2ltcGxlci4NCg0KDQoNCkFtIDE5LjA0LjIwMTggdW0gMDA6 NTggc2NocmllYiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+Og0KDQpJ4oCZbSBPSyB3aXRoIHRoaXMgY2hh bmdlLCBnaXZlbiBpdCBtYWtlcyB0aGUgT0F1dGggc3VpdGUgb2Ygc3BlY3MgbW9yZSBzZWxmLWNv bnNpc3RlbnQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBi ZWxsDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE4LCAyMDE4IDg6MTcgQU0NClRvOiBUb3JzdGVu IExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gc2NwIGNsYWltIGluIGRyYWZ0LWlldGYt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTINCg0KVGhlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhj aGFuZ2UgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHNjb3BlIGFuZCBhdCBzb21lIHBvaW50IGluIHRo YXQgd29yayBpdCBjYW1lIHRvIGxpZ2h0IHRoYXQsIGRlc3BpdGUgdGhlIGNvbmNlcHQgb2Ygc2Nv cGUgYmVpbmcgdXNlZCBsb3RzIG9mIHBsYWNlcyBlbHNld2hlcmUsIHRoZXJlIHdhcyBubyBvZmZp Y2lhbGx5IHJlZ2lzdGVyZWQgSldUIGNsYWltIGZvciBzY29wZS4gQXMgYSByZXN1bHQsIHdlICh0 aGUgV0cpIGRlY2lkZWQgdG8gaGF2ZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRl ZmluZSBhbmQgcmVnaXN0ZXIgYSBKV1QgY2xhaW0gZm9yIHNjb3BlLiBJdCdzIGtpbmQgb2YgYW4g YXdrd2FyZCBwbGFjZSBmb3IgaXQgcmVhbGx5IGJ1dCB0aGF0J3MgaG93IGl0IGNhbWUgdG8gYmUg dGhlcmUuDQpXaGVuIEkgYWRkZWQgaXQgdG8gdGhlIGRyYWZ0LCBJIG9wdGVkIGZvciB0aGUgc2Vt aS1jb252ZW50aW9uIG9mIEpXVCB1c2luZyB0aHJlZSBsZXR0ZXIgc2hvcnQgY2xhaW0gbmFtZXMu LiBBbmQgZGVjaWRlZCB0byB1c2UgYSBKU09OIGFycmF5IHRvIGNvbnZleSBtdWx0aXBsZSB2YWx1 ZXMgcmF0aGVyIHRoYW4gc3BhY2UgZGVsaW1pdGluZy4gSXQgc2VlbWVkIGxpa2UgYSBnb29kIGlk ZWEgYXQgdGhlIHRpbWUgLSBtb3JlIGNvbnNpc3RlbnQgd2l0aCBvdGhlciBKV1QgY2xhaW0gbmFt ZXMgYW5kIGNsZWFuZXIgdG8gdXNlIHRoZSBmYWNpbGl0aWVzIG9mIEpTT04gcmF0aGVyIHRoYW4g YSBkZWxpbWl0ZWQgc3RyaW5nLiBUaGF0IHdhcyB0aGUgdGhpbmtpbmcgYXQgdGhlIHRpbWUgYW55 d2F5IGFuZCwgYXMgSSByZWNhbGwsIEkgYXNrZWQgdGhlIFdHIGFib3V0IGRvaW5nIGl0IHRoYXQg d2F5IGF0IG9uZSBvZiB0aGUgbWVldGluZ3MgYW5kIHRoZXJlIHdhcyBnZW5lcmFsLCBpZiBzb21l d2hhdCBhYnNlbnQsIG5vZGRpbmcgaW4gdGhlIHJvb20uDQpMb29raW5nIGF0IHRoaXMgYWdhaW4g aW4gdGhlIGNvbnRleHQgb2YgdGhlIHF1ZXN0aW9uIGZyb20gVG9yc3RlbiBhbmQgaGlzIGRldmVs b3BlcnMsIEkgdGhpbmsgdXNpbmcgYSBkaWZmZXJlbnQgbmFtZSBhbmQgc3ludGF4IGZvciB0aGUg SldUIGNsYWltIHZzLi4gdGhlIEludHJvc3BlY3Rpb24gcmVzcG9uc2UgbWVtYmVyL3BhcmFtZXRl ci9jbGFpbSBpcyBwcm9iYWJseSBhIG1pc3Rha2UuICBXaGlsZSBSRkMgNzY2MiBJbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIHBhcmFtZXRlcnMgYXJlbid0IGV4YWN0bHkgdGhlIHNhbWUgYXMgSldUIGNs YWltcywgdGhleSBhcmUgc2ltaWxhciBpbiBtYW55IHJlc3BlY3RzLiBTbyBnaXZpbmcgY29uc2lz dGVudCB0cmVhdG1lbnQgYWNyb3NzIHRoZW0gdG8gc29tZXRoaW5nIGxpa2Ugc2NvcGUgaXMNClRo ZXJlZm9yZSBJIHByb3Bvc2UgdGhhdCB0aGUgSldUIGNsYWltIGZvciByZXByZXNlbnRpbmcgc2Nv cGUgaW4gZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBiZSBjaGFuZ2VkIHRvIGJlIGNv bnNpc3RlbnQgd2l0aCB0aGUgdHJlYXRtZW50IG9mIHNjb3BlIGluIFJGQyA3NjYyIE9BdXRoIDIu MCBUb2tlbiBJbnRyb3NwZWN0aW9uLiBUaGF0IGVmZmVjdGl2ZWx5IG1lYW5zIGNoYW5naW5nIHRo ZSBuYW1lIGZyb20gInNjcCIgdG8gInNjb3BlIiBhbmQgdGhlIHZhbHVlIGZyb20gYSBKU09OIGFy cmF5IHRvIGEgc3RyaW5nIGRlbGltaXRlZCBieSBzcGFjZXMuDQpJIHJlYWxpemUgaXQncyBsYXRl IGluIHRoZSBwcm9jZXNzIHRvIG1ha2UgdGhpcyBjaGFuZ2UgYnV0IGJlbGlldmUgZG9pbmcgc28g d2lsbCBzaWduaWZpY2FudGx5IHJlZHVjZSBjb25mdXNpb24gYW5kIGlzc3VlcyBpbiB0aGUgbG9u ZyBydW4uDQoNCg0KDQoNCg0KT24gU3VuLCBBcHIgMTUsIDIwMTggYXQgMTA6NDMgQU0sIFRvcnN0 ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxv ZGRlcnN0ZWR0Li5uZXQ+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBJ4oCZbSB3b25kZXJpbmcgd2h5 IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTIgZGVmaW5lcyBhIGNsYWltIOKAnnNj cOKAnCB0byBjYXJyeSBzY29wZSB2YWx1ZXMgd2hpbGUgUkZDIDc1OTEgYW5kIFJGQyA3NjYyIHVz ZSBhIGNsYWltIOKAnnNjb3Bl4oCcIGZvciB0aGUgc2FtZSBwdXJwb3NlLiBBcyBmYXIgYXMgSSB1 bmRlcnN0YW5kIHRoZSB0ZXh0LCB0aGUgaW50ZW5zaW9uIGlzIHRvIHJlcHJlc2VudCBhIGxpc3Qg b2YgUkZDNjc0OSBzY29wZXMuIElzIHRoaXMgY29ycmVjdD8gV2hhdOKAmXMgdGhlIHJhdGlvbmFs ZSBiZWhpbmQ/DQoNCkRpZmZlcmVudCBjbGFpbSBuYW1lcyBmb3IgcmVwcmVzZW50aW5nIHNjb3Bl IHZhbHVlcyBjb25mdXNlIHBlb3BsZS4gSSByZWFsaXplZCB0aGF0IHdoZW4gb25lIG9mIG91ciBk ZXZlbG9wZXJzIHBvaW50ZWQgb3V0IHRoYXQgZGlmZmVyZW5jZSByZWNlbnRseS4NCg0KYmVzdCBy ZWdhcmRzLA0KVG9yc3Rlbi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRp c2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFu eSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQoNCg0K Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9z dXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBs aXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy4uaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aD4NCg0KDQotLQ0KDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVy DQoNCklkZW50aXR5IFNlcnZpY2VzIEVuZ2luZWVyaW5nICAgICBXb3JrOiBnZW9yZ2UuZmxldGNo ZXJAdGVhbWFvbC5jb208bWFpbHRvOmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbT4NCg0KQU9M IEluYy4gICAgICAgICAgICAgICAgICAgICAgICAgIEFJTTogIGdmZmxldGNoDQoNCk1vYmlsZTog KzEtNzAzLTQ2Mi0zNDk0ICAgICAgICAgICBUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vZ2Zm bGV0Y2gNCg0KT2ZmaWNlOiArMS03MDMtMjY1LTI1NDQgICAgICAgICAgIFBob3RvczogaHR0cDov L2dlb3JnZWZsZXRjaGVyLnBob3RvZ3JhcGh5DQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJp YWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_BL0PR00MB0292E3A7FA7A2217CDC4324CF5880BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5GWUksIEkgYmxvZ2dlZCBhYm91dCB0aGVz ZSBjaGFuZ2VzIGluIG15IHBvc3Qg4oCcTGF0ZS1icmVha2luZyBjaGFuZ2VzIHRvIE9BdXRoIFRv a2VuIEV4Y2hhbmdlIHN5bnRheOKAnSBhdA0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmlu Zm8vP3A9MTgyNSI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTgyNTwvYT4gYW5kIGF0DQo8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIj5Ac2VsZmlzc3Vl ZDwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3Jn Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBBcHJpbCAyMywgMjAxOCAxOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBHZW9yZ2Ug RmxldGNoZXIgJmx0O2dmZmxldGNoQGFvbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAm bHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IHNjcCBjbGFpbSBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTEyPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdCAtMTMgd2FzIGp1c3QgcHVibGlzaGVkIHdpdGgg dGhlc2UgY2hhbmdlcyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgQXByIDIzLCAyMDE4IGF0IDI6MTUgUE0sIEdlb3JnZSBGbGV0Y2hlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nZmZsZXRj aEBhb2wuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDQvMjMvMTggMzoxMyBQTSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkganVzdCBub3RpY2VkL3Jl bWVtYmVyZWQgdGhhdCB0aGUgZHJhZnQgYWxzbyBjdXJyZW50bHkgZGVmaW5lcyBhICZxdW90O2Np ZCZxdW90OyBjbGFpbSBmb3IgdGhlIGNsaWVudCBpZGVudGlmaWVyIHdoZXJlIEludHJvc3BlY3Rp b24ncyBSRkMgNzY2MiBhbHJlYWR5IHVzZXMgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IGZvciB0aGUg c2FtZSB0aGluZy4gVGhlIHJlYXNvbiBmb3IgdXNpbmcgJnF1b3Q7Y2lkJnF1b3Q7IHdhcyBzaW1p bGFyIGluIHRoYXQgSSB3YXMgbG9va2luZw0KIHRvIGZvbGxvdyB0aGUgc2VtaS1jb252ZW50aW9u IG9mIEpXVCB1c2luZyB0aHJlZSBsZXR0ZXIgc2hvcnQgY2xhaW0gbmFtZXMuIEJ1dCBJIHRoaW5r IGNvbnNpc3RlbmN5IHdpdGggUkZDIDc2NjIgaXMgbW9yZSBpbXBvcnRhbnQgYW5kIG1lYW5pbmdm dWwgaGVyZS4gU28sIGJhcnJpbmcgYSByb3VnaCBjb25zY2lvdXMgb2Ygb2JqZWN0aW9ucywgSSdt IGdvaW5nIHRvIG1ha2UgdGhhdCBjaGFuZ2UgdG9vIGluIGEgc29vbi10by1iZSBuZXh0IHJldmlz aW9uDQogb2YgdGhlIGRyYWZ0LiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIEFwciAxOSwgMjAxOCBhdCA3OjM4IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8 YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgLSBJdCB3aWxsIG1h a2VzIHRoaW5rcyBtdWNoIHNpbXBsZXIuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFtIDE5LjA0LjIwMTggdW0gMDA6NTggc2NocmllYiBNaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+SeKAmW0gT0sgd2l0aCB0aGlzIGNoYW5nZSwgZ2l2ZW4gaXQgbWFrZXMg dGhlIE9BdXRoIHN1aXRlIG9mIHNwZWNzIG1vcmUgc2VsZi1jb25zaXN0ZW50Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0 OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFu IENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTggODox NyBBTTxicj4NCjxiPlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gc2NwIGNsYWltIGluIGRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPlRoZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRvY3Vt ZW50IG1ha2VzIHVzZSBvZiBzY29wZSBhbmQgYXQgc29tZSBwb2ludCBpbiB0aGF0IHdvcmsgaXQg Y2FtZSB0byBsaWdodCB0aGF0LCBkZXNwaXRlIHRoZSBjb25jZXB0IG9mIHNjb3BlIGJlaW5nIHVz ZWQgbG90cyBvZiBwbGFjZXMgZWxzZXdoZXJlLA0KIHRoZXJlIHdhcyBubyBvZmZpY2lhbGx5IHJl Z2lzdGVyZWQgSldUIGNsYWltIGZvciBzY29wZS4gQXMgYSByZXN1bHQsIHdlICh0aGUgV0cpIGRl Y2lkZWQgdG8gaGF2ZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRlZmluZSBhbmQg cmVnaXN0ZXIgYSBKV1QgY2xhaW0gZm9yIHNjb3BlLiBJdCdzIGtpbmQgb2YgYW4gYXdrd2FyZCBw bGFjZSBmb3IgaXQgcmVhbGx5IGJ1dCB0aGF0J3MgaG93IGl0IGNhbWUgdG8gYmUgdGhlcmUuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5XaGVuIEkgYWRkZWQgaXQg dG8gdGhlIGRyYWZ0LCBJIG9wdGVkIGZvciB0aGUgc2VtaS1jb252ZW50aW9uIG9mIEpXVCB1c2lu ZyB0aHJlZSBsZXR0ZXIgc2hvcnQgY2xhaW0gbmFtZXMuLiBBbmQgZGVjaWRlZCB0byB1c2UgYSBK U09OIGFycmF5IHRvIGNvbnZleSBtdWx0aXBsZSB2YWx1ZXMgcmF0aGVyIHRoYW4gc3BhY2UNCiBk ZWxpbWl0aW5nLiBJdCBzZWVtZWQgbGlrZSBhIGdvb2QgaWRlYSBhdCB0aGUgdGltZSAtIG1vcmUg Y29uc2lzdGVudCB3aXRoIG90aGVyIEpXVCBjbGFpbSBuYW1lcyBhbmQgY2xlYW5lciB0byB1c2Ug dGhlIGZhY2lsaXRpZXMgb2YgSlNPTiByYXRoZXIgdGhhbiBhIGRlbGltaXRlZCBzdHJpbmcuIFRo YXQgd2FzIHRoZSB0aGlua2luZyBhdCB0aGUgdGltZSBhbnl3YXkgYW5kLCBhcyBJIHJlY2FsbCwg SSBhc2tlZCB0aGUgV0cgYWJvdXQgZG9pbmcNCiBpdCB0aGF0IHdheSBhdCBvbmUgb2YgdGhlIG1l ZXRpbmdzIGFuZCB0aGVyZSB3YXMgZ2VuZXJhbCwgaWYgc29tZXdoYXQgYWJzZW50LCBub2RkaW5n IGluIHRoZSByb29tLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPkxvb2tpbmcgYXQgdGhpcyBhZ2FpbiBpbiB0aGUgY29udGV4dCBvZiB0aGUgcXVlc3Rp b24gZnJvbSBUb3JzdGVuIGFuZCBoaXMgZGV2ZWxvcGVycywgSSB0aGluayB1c2luZyBhIGRpZmZl cmVudCBuYW1lIGFuZCBzeW50YXggZm9yIHRoZSBKV1QgY2xhaW0gdnMuLiB0aGUgSW50cm9zcGVj dGlvbiByZXNwb25zZSBtZW1iZXIvcGFyYW1ldGVyL2NsYWltDQogaXMgcHJvYmFibHkgYSBtaXN0 YWtlLiZuYnNwOyBXaGlsZSBSRkMgNzY2MiBJbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHBhcmFtZXRl cnMgYXJlbid0IGV4YWN0bHkgdGhlIHNhbWUgYXMgSldUIGNsYWltcywgdGhleSBhcmUgc2ltaWxh ciBpbiBtYW55IHJlc3BlY3RzLiBTbyBnaXZpbmcgY29uc2lzdGVudCB0cmVhdG1lbnQgYWNyb3Nz IHRoZW0gdG8gc29tZXRoaW5nIGxpa2Ugc2NvcGUgaXMNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZWZvcmUgSSBwcm9wb3NlIHRoYXQgdGhlIEpX VCBjbGFpbSBmb3IgcmVwcmVzZW50aW5nIHNjb3BlIGluIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UgYmUgY2hhbmdlZCB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHRyZWF0bWVudCBv ZiBzY29wZSBpbiZuYnNwO1JGQyA3NjYyIE9BdXRoIDIuMCBUb2tlbiBJbnRyb3NwZWN0aW9uLg0K IFRoYXQgZWZmZWN0aXZlbHkgbWVhbnMgY2hhbmdpbmcgdGhlIG5hbWUgZnJvbSAmcXVvdDtzY3Am cXVvdDsgdG8gJnF1b3Q7c2NvcGUmcXVvdDsgYW5kIHRoZSB2YWx1ZSBmcm9tIGEgSlNPTiBhcnJh eSB0byBhIHN0cmluZyBkZWxpbWl0ZWQgYnkgc3BhY2VzLg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVhbGl6ZSBpdCdzIGxhdGUgaW4g dGhlIHByb2Nlc3MgdG8gbWFrZSB0aGlzIGNoYW5nZSBidXQgYmVsaWV2ZSBkb2luZyBzbyB3aWxs IHNpZ25pZmljYW50bHkgcmVkdWNlIGNvbmZ1c2lvbiBhbmQgaXNzdWVzIGluIHRoZSBsb25nIHJ1 bi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBBcHIgMTUs IDIwMTggYXQgMTA6NDMgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0 bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Li5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIGFs bCw8YnI+DQo8YnI+DQpJIEnigJltIHdvbmRlcmluZyB3aHkgZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS0xMiBkZWZpbmVzIGEgY2xhaW0g4oCec2Nw4oCcIHRvIGNhcnJ5IHNjb3BlIHZh bHVlcyB3aGlsZSBSRkMgNzU5MSBhbmQgUkZDIDc2NjIgdXNlIGEgY2xhaW0g4oCec2NvcGXigJwg Zm9yIHRoZSBzYW1lIHB1cnBvc2UuIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIHRleHQsIHRo ZSBpbnRlbnNpb24gaXMgdG8gcmVwcmVzZW50IGEgbGlzdCBvZiBSRkM2NzQ5IHNjb3Blcy4NCiBJ cyB0aGlzIGNvcnJlY3Q/IFdoYXTigJlzIHRoZSByYXRpb25hbGUgYmVoaW5kPzxicj4NCjxicj4N CkRpZmZlcmVudCBjbGFpbSBuYW1lcyBmb3IgcmVwcmVzZW50aW5nIHNjb3BlIHZhbHVlcyBjb25m dXNlIHBlb3BsZS4gSSByZWFsaXplZCB0aGF0IHdoZW4gb25lIG9mIG91ciBkZXZlbG9wZXJzIHBv aW50ZWQgb3V0IHRoYXQgZGlmZmVyZW5jZSByZWNlbnRseS4NCjxicj4NCjxicj4NCmJlc3QgcmVn YXJkcyw8YnI+DQpUb3JzdGVuLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KPGI+PGk+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uDQogaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1 dGVyLiBUaGFuayB5b3UuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5DT05GSURFTlRJQUxJVFkgTk9USUNF OiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZQ0KIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5 IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBm cm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPg0KPG86cD48L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4t LSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPkRpc3Rpbmd1aXNoZWQgRW5naW5lZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5JZGVudGl0eSBTZXJ2aWNlcyBFbmdpbmVlcmluZyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBXb3JrOiA8YSBocmVmPSJtYWlsdG86Z2VvcmdlLmZsZXRjaGVy QHRlYW1hb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2VvcmdlLmZsZXRjaGVyQHRlYW1hb2wuY29t PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+QU9MIEluYy4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUlNOiZu YnNwOyBnZmZsZXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+TW9iaWxlOiAmIzQzOzEtNzAzLTQ2Mi0zNDk0Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFR3aXR0ZXI6IDxh IGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly90d2l0dGVyLmNvbS9nZmZsZXRjaDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPk9mZmljZTogJiM0MzsxLTcwMy0yNjUtMjU0NCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBQaG90b3M6IDxhIGhyZWY9Imh0dHA6Ly9nZW9yZ2VmbGV0Y2hlci5waG90b2dyYXBoeSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9nZW9yZ2VmbGV0Y2hlci5waG90b2dyYXBoeTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJ Q0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1h dGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBB bnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLi4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR00MB0292E3A7FA7A2217CDC4324CF5880BL0PR00MB0292namp_-- From nobody Wed Apr 25 09:57:17 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B7128C0A for ; Wed, 25 Apr 2018 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOmUCUj3nYCA for ; Wed, 25 Apr 2018 09:57:12 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607961200C5 for ; Wed, 25 Apr 2018 09:57:12 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id j5so8059344wme.5 for ; Wed, 25 Apr 2018 09:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kEPiuWR0wNcvpbmA39pONSI4JgXaLL4X5Ti/J6DS9mk=; b=CB1Ig0622dClkAMWDXbhXcxewlPOrcY1Zqvhh67Ao4CsTnRG9vWSdfC1T35Mlww30B EeDrM6fwgep1Y5kMLTWgmtRLOqjTarLCoSUnO0ooBUdjWZUM3KDKi5FXW3Kqs5dfXWqI JFAMlVVYolr3R9sigebQi7my2ZQ+nnwyR4tm0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kEPiuWR0wNcvpbmA39pONSI4JgXaLL4X5Ti/J6DS9mk=; b=JyvYbyOsXNd9BHRk+8gdW7d6ZUxWTltzFY1h9t3kQy4v7i8SQhVbPM/6PfDs0PACZn S7yGHXKafWy1qdbc0YiCSbSg5hkXhbkuZN3a3ckmlqCaNuScvd9bh19LsX9ROgQl+SxK sX6VzmuLYhy3zdlo2t4Z4FRvbs7jdCDdIh18wvxbVkVqp7PBT+LC25U2zrj2LTvqFuyG YGpmF46I9rWyy330uZXRVDwRcr8/jt2QD1ogeA1LVJ6KrCbc1SjfiC+0XWDoFSzRk/Gd piDQ3gQd9UrzDtpYjK1GPUMVA/SIKSArM/9+LUjBrHqaqhFd1Q9mRsZrCPZfvsdzb/zx 71zw== X-Gm-Message-State: ALQs6tAy0ApktVrpg3b/Vs4Vl6NhbaYTaVGakqXtRvAPupq8R2cyQXYg m5Yjl1GXIpsAG/GwkZJ4YgmwJw== X-Google-Smtp-Source: AB8JxZp2X/PucZYNvWvKJPOMZ9esWKo0miCvyuVHTQGYTpd4v6Av/vYPER2wWF/5qTgngzjro0iaHQ== X-Received: by 10.28.6.14 with SMTP id 14mr15203956wmg.42.1524675430519; Wed, 25 Apr 2018 09:57:10 -0700 (PDT) Received: from guest2s-mbp.home (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id q81sm16766381wmg.8.2018.04.25.09.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 09:57:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Neil Madden In-Reply-To: Date: Wed, 25 Apr 2018 17:57:08 +0100 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <792EE9B9-1955-4C4F-95D4-46AD4927B757@forgerock.com> References: To: Yaron Sheffer X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 16:57:15 -0000 Thanks Yaron, Some responses in-line. > On 23 Apr 2018, at 15:57, Yaron Sheffer wrote: >=20 > Hi Neil, >=20 > Thank you again for your review and the follow up. Please see my = comments in-line. >=20 > =E2=80=8FYaron >=20 >> Hi Mike, >> I sent this originally back in June last year, I can see some of = these points have been addressed in -01, but not others, so I will = include further comments in-line below. (Apologies if I missed replies - = I?ve realised a few messages from this WG have ended up in my spam = folder). >> As a general point, the BCP is for JWT, but some of the advice (and = my points below) apply more generally to other JOSE objects (as pointed = out in the introduction). Should this be reflected in the title? >>> On 4 Jun 2017, at 15:11, Neil Madden = wrote: >>>=20 >>> I originally set this message just to the BCP authors. As requested = by Mike Jones, I am sending it here too: >>>=20 >>> Hi, >>>=20 >>> I've just seen this draft best-practice guide for JWTs pop up. I = have a number of suggestions for improvements. Mostly, I think the = advice is good but should be spelt out a bit more clearly. Here are some = suggestions: >>>=20 >>> 1. Explicitly spell out the ECDH-ES public key validation routines = from NIST. I have a blog post summarising them: = https://neilmadden.wordpress.com/2017/05/17/so-how-do-you-validate-nist-ec= dh-public-keys/ >> To be clear here, I think section 3.4 (Validate Cryptographic Inputs) = should have text along the lines of the following added: >> ?ECDH-ES ephemeral public key (epk) inputs should be validated = according to the recipient?s chosen elliptic curve. For NIST prime-order = curves P-256, P-384 and P-521, validation MUST be performed according to = Section 5.6.2.3.4 ?ECC Partial Public-Key Validation Routine? of NIST = Special Publication 800-56A revision 3 [1]. Where the X25519 or X448 = curves of RFC 8037 [2] are used, then the implementation MAY reject any = ephemeral public key that produces an all-zero ECDH shared secret as per = RFC 7748 Section 6 [3]." >> [1] = https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd= f >> [2] https://tools.ietf.org/html/rfc8037 >> [3] https://tools.ietf.org/html/rfc7748#section-6 >> I should note that the final sentence about validating X25519/X448 = public keys is not without some controversy. See = https://moderncrypto.org/mail-archive/curves/2017/000896.html for a = rabbit-hole discussion together with associated links. >> I do not feel confident to say what the right answer is for those = curves - whether to validate at all, and if so whether to blacklist bad = public keys or check for an all-zero shared secret. Perhaps we should = get CFRG input on this point? Or should we take RFC 7748 as being the = considered CFRG opinion on this topic (and so copy the ?MAY? wording)? >=20 > I think a MAY check is useless in practice, and also, the link you = mention argues quite convincingly against the 25519 check. So I propose = to adopt the first part of your text. OK, I am happy with that. My understanding is that this check should = never be required for ECDH-ES as specified in JOSE. >=20 >>> 2. Recommend that (despite the -ES) ECDH is safest when *both* keys = are ephemeral (eg you use some initial step to retrieve a fresh = authenticated ephemeral key from the other party). >> I think this comment is not necessary in hindsight. While = fully-ephemeral ECDH has some advantages (as does static-static in some = cases, e.g. NaCl crypto_box), it?s a more complicated discussion. For = this BCP it is best to concentrate on ECDH-ES as specified and ensure = that implementations perform proper validation of ephemeral public keys. >=20 > Agree. >=20 >>> 3. Spell out how to authenticate ECDH ephemeral keys. For instance, = include an inner signed JWT that repeats the epk and possibly the = apu/apv claims too. >> This is probably a more general point that none of the public-key = encryption modes in JOSE are authenticated. If sender authentication is = required then nested signed-and-encrypted objects should be used. >=20 > Yes, and it's not up to the BCP to add new authenticated modes. >=20 >>> 4. Recommend that the apu and apv claims as a bare minimum include a = hash of both public keys and SHOULD include any other known identifiers. >=20 > I'm not clear about "apu" in the general use case for JWT, where the = identity of the recipient of a JWT is not known in advance to the = sender. >=20 > Also, RFC 7518 uses "Alice" and "Bob" in these claims, and does not = include any hashes. (And see my next comment). >=20 >> Section 5.8.2 of NIST SP.800-56A rev 3 (referenced in point 1 above) = gives some advice on the kinds of things that should be included here. = Appendix B of the same document provides some rationale for why this = should be done, as does RFC 7748 Section 7 (Security Considerations). = RFC 7518 (JWA) Section 4.6.2 already normatively references NIST = SP.800-56A, but only for ?applications wishing to conform to = [NIST.800-56A]?. In my opinion, this should be strengthened in this BCP = to a SHOULD/RECOMMENDED. >>> 5. Recommend that the receiving party recalculates the apu and apv = claims from known inputs to check they match. (Or leave these out of the = JWT and require the other party to recalculate them). >=20 > But this would require normative language on the contents of these = claims, which does not appear in existing RFCs. I would hesitate to = include such language in a BCP. There must be a very good reason for a = BCP to make existing implementations non-conformant. I don=E2=80=99t think the BCP has to mandate a particular format, just = recommend that the recipient checks that the apu and apv claims are what = it expected. One good way to do this is to recreate them from scratch. >=20 >>> 6. Provide explicit key lifetime requirements. E.g., for AES GCM = this should not exceed 2^32 messages for randomly-generated IVs, and not = exceed 2^64 *blocks* in total (so unless you restrict JWT lengths to = less than 2^32 blocks and use a message counter as IV then this also = limits to 2^32 messages). For CBC it should not exceed 2^48 messages. >> I withdraw this comment, RFC 7518 Section 8.2 already addresses this = point. >>> 7. Require that the "alg" and "enc" claims are ONLY used to reject = unexpected algorithms, NEVER to select an algorithm (even amongst a = "supported" set). Cryptographic agility should be achieved by using = "kid" claims that reference one of a set of known keys and the key = should specify the algorithm (either explicitly or by the key = parameters/size). >> I think this is now adequately addressed by section 3.1. >>> 8. Deprecate or strongly recommend against all of the RSA encryption = modes except OAEP-256. >=20 > Yes. What about RSA with/without PSS? I was only thinking about encryption. RSA-PSS signatures are pretty = solid - although I tend to avoid them in JWT usage as the signatures = themselves are quite bulky, but that=E2=80=99s irrelevant to the BCP. >=20 >>> 9. Strongly discourage any use of compression with encrypted JWEs - = it is too easy to leak sensitive information. >>> 10. Recommend that if a JWE is used to encrypt a password or other = value for which knowing the length may be a weakness, that such fields = are explicitly padded by the application or at least use CBC mode to = reduce the amount of length information leaked to a multiple of the AES = block size. >> These last two points are related: encryption hides everything apart = from the length of a plaintext. Compression varies the length based on = the content. The combination of the two weakens the security of the = encryption, but the length may already be sensitive. Applications should = consider what information might be leaked in these cases and make = informed decisions about whether to pad or compress content before = encryption. >=20 > Agree. >=20 >>> 11. Require constant-time comparisons of HMAC tags. >> This point is already covered by RFC 7518 Section 3.2. >>> 12. Recommend using deterministic ECDSA signatures as described in = RFC 6979 to minimise the risk of leaking the private key. >=20 > I'm not sure how this would interact with JWE. I suspect these = signatures would have to be defined as a new algorithm (so out of scope = for the BCP). RFC 6979 signatures are completely compatible with (and = indistinguishable from) normal ECDSA signatures. Where ECDSA requires a = fresh random nonce for each signature (and fails catastrophically if you = reuse a nonce even once [*]), RFC 6979 instead generates those nonces = pseudorandomly as a hash over the private key and the message itself. = That makes them deterministic and much more robust against accidental = nonce reuse. Basically the same thing is done in EdDSA signatures (RFC = 8037). The BCP can just point out that RFC 6979 exists and recommend it = is used. [*] Actually, it is even worse for ECDSA. Papers like [1] have shown = that the ECDSA private key can be recovered mathematically if even just = a few *bits* of the nonces are constant or guessable. [1] https://link.springer.com/article/10.1023%2FA%3A1025436905711 >=20 >>> 13. Recommend that if the ECDH calculation produces an all-zero = shared secret that this is rejected. >> This is covered in my suggestion in point 1. >>> 14. Never produce a signed JWT containing a "sub" claim unless you = are explicitly vouching for the identity of that subject. It is far too = easy to accidentally produce valid OIDC id tokens from unrelated code! >> I think this is now covered by the section on explicit typing. >> Explicit typing is a welcome addition. A complementary approach would = be to recommend using different cryptographic keys for different types = of JWTs. One way to achieve this for symmetric algorithms or ECDH would = be to use a key-derivation function to derive unique keys based on some = domain separation string. >> I find the discussion in section 3.2 about the ?none? algorithm = unnecessary for the BCP. I would say using ?none? should not be a = recommended best practice. >> A colleague recently shared this pen-tester JWT cheat-sheet with me: = https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_security_cheat= sheet.pdf which hints at a few other points worth mentioning (I can = draft text for these if you wish): >> - If the ?kid? header is used to perform a lookup in a database then = there is a risk of SQL/LDAP injection if the value is not validated = first or appropriate interfaces used (e.g. prepared statements). >> - The ?jwk? header should not be directly trusted, but only ever used = to match a known key. >=20 > I agree about kid and jku, but I'm not familiar with all valid use = cases of "jwk" so would appreciate more opinions regarding this = statement. >=20 > Likewise, I?d say the ?jku? header should really be matched against a = known whitelist before being trusted, as it might additionally lead to = SSRF attacks if the server can be tricked into loading arbitrary URLs. >> Kind regards, >> Neil >> --- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Apr 25 22:00:17 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B18126CE8 for ; Wed, 25 Apr 2018 22:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM3BkL8_Kag0 for ; Wed, 25 Apr 2018 22:00:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E98120725 for ; Wed, 25 Apr 2018 22:00:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC619B83D1F; Wed, 25 Apr 2018 21:59:55 -0700 (PDT) To: mbj@microsoft.com, dick.hardt@gmail.com, kaduk@mit.edu, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: KavinduDodanduwa@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180426045955.CC619B83D1F@rfc-editor.org> Date: Wed, 25 Apr 2018 21:59:55 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Technical Errata Reported] RFC6750 (5335) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 05:00:16 -0000 The following errata report has been submitted for RFC6750, "The OAuth 2.0 Authorization Framework: Bearer Token Usage". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5335 -------------------------------------- Type: Technical Reported by: Kavindu Dodanduwa Section: 2.1 Original Text ------------- b64token Corrected Text -------------- token68 Notes ----- Usage of b64token is confusing. Definition is self explanatory but could be easily confused with Base64. RFC7235 defines token68. Following some old RFC draft discussions (http://w3-org.9356.n7.nabble.com/p7-rename-b64token-to-token68-to-avoid-misunderstandings-td108256.html) I found that b64token was renamed to token68. I believe it's appropriate to use naming of token68 (instead of b64token) in RFC6750. So that it is less confusing as well as refers to an existing standard. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6750 (draft-ietf-oauth-v2-bearer-23) -------------------------------------- Title : The OAuth 2.0 Authorization Framework: Bearer Token Usage Publication Date : October 2012 Author(s) : M. Jones, D. Hardt Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Apr 30 07:07:36 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9CD12DA4F for ; Mon, 30 Apr 2018 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o86TE9NqneQu for ; Mon, 30 Apr 2018 07:07:30 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EF4124BFA for ; Mon, 30 Apr 2018 07:07:30 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id v60-v6so8166478wrc.7 for ; Mon, 30 Apr 2018 07:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KNiLBkUclydHsm779OyjfQ/gNUSrTGitCML5c5iKFnw=; b=kSXU7IuHBx3Zb4wAb0CryCUxezGP5ImwlRy6tai88jsyrdO1+RVJL17eDsXPrcixHQ CT0/t5DMETpeCN1uLpbE6TuQ5ILWhriJKIrnOWK1JF7z4pAVaW2+hyR2S4xr7Ur4OVBF 5D6WAI6l6JxiTlgyEtKvC5r+TjIO0yYUULPMItWCwERitLweOwW3cIvxVcZDYR9wxCXE LMTZXf6InrJQozsUNcThwIfaZrIpVeETdbtCFjJ2CrNH4kB4xPMj1irRCRmipXyLDDIG 0/v9PGIC0cx3jMWl9G7IncWHTOzFEhD+w97/OI1UbzRGkEu6MKy0w4d5KHRErTj3QBvh JBoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KNiLBkUclydHsm779OyjfQ/gNUSrTGitCML5c5iKFnw=; b=scFTLhK8grRIck1LZZa14SfmwLXJXGrRCjz4AsgpDlGpchFSZsMRRvBHFMX/AIfy2m ZlhjM9oq/JDXLoZemE7PGyzSyTj0EQQHHG4G+mn0clb1IMvCpmGdyQ2N5gI1me1tRF2c FDxr/+0usECMHHAWn+0iCjmTtoFDCjmtwN9lsTp1YUTZX9PjlP15F4WoMT5RKiKtAXM0 hHH9M5J+0mdHWd0Twschurugj8HBzXtw+fqs22rcv/WOsUmW4L3tmip9y33Dm9U9A1UD HJRySy2b/ziHqtW+7csFgH7RZyjQH7iZ+m2e1rlK1cA9fJlm4gaUDX3w/N+u4fTR4lxp Zwqw== X-Gm-Message-State: ALQs6tDRv9Isz4V4LtaD1+YSGPTtWbKmPV0R4cxvHe5Mlklj4cSFtXlo fAgmuHhA0nXlDhamkxoPUpvRAucNO7JO1HG/9xnMGA== X-Google-Smtp-Source: AB8JxZo7/947QYLc4zM24/OkDO1OwO5qn6QNbOSsIrofnySQbY7CNW8TEWBe2L6X9/cGzSMpyN63Eyzh0l9TAPNO1oM= X-Received: by 2002:adf:ea01:: with SMTP id q1-v6mr9613631wrm.50.1525097248010; Mon, 30 Apr 2018 07:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.191.1 with HTTP; Mon, 30 Apr 2018 07:07:27 -0700 (PDT) In-Reply-To: References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> From: John Bradley Date: Mon, 30 Apr 2018 11:07:27 -0300 Message-ID: To: Brian Campbell Cc: Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000b765df056b115f86" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:07:35 -0000 --000000000000b765df056b115f86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I lean towards letting new certificate thumbprints be defined someplace else. With SHA256, it is really second preimage resistance that we care about for a certificate thumbprint, rather than simple collision resistance. MD5 failed quite badly with chosen prefix collision attacks against certificates (Thanks to some X.509 extensions). SHA1 has also been shown to be vulnerable to a PDF chosen prefix attack ( http://shattered.io) The reason NIST pushed for development of SHA3 was concern that a preimage attack might eventually be found agains the SHA2 family of hash algorithms. While SHA512 may have double the number of bytes it may not help much against a SHA2 preimage attack,. (Some papers suggest that the double word size of SHA512 it may be more vulnerable than SHA256 to some attacks) It is currently believed that SHA256 has 256 bits of second preimage strength. That could always turn out to be wrong as SHA2 has some similarities to SHA1, and yes post quantum that is reduced to 128bits. To have a safe future option we would probably want to go with SHA3-512. However I don=E2=80=99t see that getting much traction in the near term. Practical things people should do run more along the lines of: 1: Put at least 64 bits of entropy into the certificate serial number if using self signed or a local CA. Commercial CA need to do that now. 2: Rotate certificates on a regular basis, using a registered JWKS URI My concern is that people will see a bigger number and decide it is better if we define it in the spec. We may be getting people to do additional work and increasing token size without a good reason by putting it in the spec directly. I have yet to see any real discussion on using bigger hashes for signing certificates, or creating thumbprints in other places. John B. On Thu, Apr 19, 2018 at 1:23 PM, Brian Campbell wrote: > Okay, so I retract the idea of metadata indicating the hash alg/cnf > method (based on John pointing out that it doesn't really make sense). > > That still leaves the question of whether or not to define additional > confirmation methods in this document (and if so, what they would be > though x5t#S384 and x5t#S512 seem the most likely). > > There's some reasonable rational for both adding one or two new hash alg > confirmation methods in the doc now vs. sticking with just SHA256 for > now. I'll note again that the doc doesn't preclude using or later definin= g > other confirmation methods. > > I'm kind of on the fence about it, to be honest. But that doesn't really > matter because the draft should reflect rough WG consensus. So I'm lookin= g > to get a rough gauge of rough consensus. At this point there's one > comment out of WGLC asking for additional confirmation method(s). I don't > think that makes for consensus. But I'd ask others from the WG to chime > in, if appropriate, to help me better gauge consensus. > > On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden > wrote: > >> I=E2=80=99m not particularly wedded to SHA-512, just that it should be p= ossible >> to use something else. At the moment, the draft seems pretty wedded to >> SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on >> many 64-bit machines) and provides a very wide security margin against a= ny >> future crypto advances (quantum or otherwise). I=E2=80=99d also be happy= with >> SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely available. >> >> I don=E2=80=99t think short-lived access tokens is a help if the likelih= ood is >> that certs will be reused for many access tokens. >> >> Public Web PKI certs tend to only use SHA-256 as it has broad support, >> and I gather there were some compatibility issues with SHA-512 certs in >> TLS. There are a handful of SHA-384 certs - e.g., the Comodo CA certs fo= r >> https://home.cern/ are signed with SHA-384 (although with RSA-2048, >> which NSA estimates at only ~112-bit security). SHA-512 is used on some >> internal networks where there is more control over components being used= , >> which is also where people are mostly likely to care about security beyo= nd >> 128-bit level (eg government internal networks). >> >> By the way, I just mentioned quantum attacks as an example of something >> that might weaken the hash in future. Obviously, quantum attacks complet= ely >> destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but = it >> provides a considerable margin to hedge against future quantum *or >> classical* advances while allowing the paranoid to pick a stronger secur= ity >> level now. We have customers that ask for 256-bit AES already. >> >> (I also misremembered the quantum attack - =E2=80=9CSerious Cryptography= =E2=80=9D by >> Aumasson tells me the best known quantum attack against collision >> resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) spa= ce >> so is impractical. I don=E2=80=99t know if that is the last word though)= . >> >> As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty brok= en now >> with practical collisions having been demonstrated. The kind of attacks = on >> CA certs demonstrated for MD5 [1] are probably not too far off for SHA-1 >> now. As far as I am aware, we=E2=80=99re nowhere near those kinds of att= acks on >> SHA-256, but I=E2=80=99d prefer that there was a backup plan in place al= ready >> rather than waiting to see (and waiting for everyone to have hard-coded >> SHA-256 everywhere). >> >> Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 = :-) >> >> [1] http://www.win.tue.nl/hashclash/rogue-ca/ >> >> Neil >> >> >> On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley >> wrote: >> The WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals= . I am >> unclear on who is going to work on it in what draft. >> >> If the client is doing mtls to both the Token endpoint and RS the >> information in the confirmation method is not relevant to the client as >> long as the AS and RS are in agreement like with most tokens. >> >> The hash on the certificate and length of the signing key are equally or >> more vulnerable to any sort of attack. >> At least with AT the tokens are not long lived. >> >> Doing anything better than SHA256 only makes sense if the cert is signed >> by something stronger like SHA512 with a 2048bit RSA key. That seems s= ort >> of unlikely in the near term. >> >> I prefer to wait to see what general fix is proposed before we jump the >> gun with a bandade for a small part of the overall problem. >> >> People are typically using SHA1 fingerprints. We added SHA256 for JWT >> and got push back on that as overkill. >> I don=E2=80=99t think this is the correct place to be deciding this. >> >> We could say that if new thumbprints are defined the AS and RS can decid= e >> to use them as necessary. >> That is sort of the situation we have now. >> >> The correct solution may be a thousand rounds of PBKDF2 or something lik= e >> that to make finding collisions more difficult rather than longer hashes= . >> >> John B. >> >> > On Apr 12, 2018, at 5:20 PM, Brian Campbell >> wrote: >> > >> > That's true about it being opaque to the client. I was thinking of >> client metadata (config or registration) as a way for the AS to decide i= f >> to bind the AT to a cert. And moving from a boolean to a conf method as = an >> extension of that. It would be more meaningful in RS discovery, if there >> was such a thing. >> > >> > I don=E2=80=99t know that SHA512 would be the best choice either but i= t is >> something that is stronger and could be included now. If there's consens= us >> to do more than SHA256 in this doc. >> > >> > >> > >> > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley >> wrote: >> > Inline >> > >> > Snip >> > >> >> >> >> >> >> 12. The use of only SHA-256 fingerprints means that the security >> strength of the sender-constrained access tokens is limited by the >> collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - w= ithout a >> new specification for a new thumbprint algorithm. An implication of this= is >> that is is fairly pointless for the protected resource TLS stack to ever >> negotiate cipher suites/keys with a higher level of security. In more >> crystal ball territory, if a practical quantum computer becomes a >> possibility within the lifetime of this spec, then the expected collisio= n >> resistance of SHA-256 would drop quadratically, allowing an attacker to >> find a colliding certificate in ~2^64 effort. If we are going to pick ju= st >> one thumbprint hash algorithm, I would prefer we pick SHA-512. >> >> >> >> The idea behind haveing just one thumbprint hash algorithm was to kee= p >> things simple. And SHA-256 seems good enough for the reasonably foreseea= ble >> future (and space aware). Also a new little spec to register a different >> hash algorithm, should the need arise, didn't seem particularity onerous= . >> >> >> >> That was the thinking anyway. Maybe it is too short sighted though? >> >> >> >> I do think SHA-256 should stay regardless. >> >> >> >> But the draft could also define SHA-512 (and maybe others). What do >> you and WG folks think about that? >> >> >> >> *** Yes please. >> >> >> >> It would probably then be useful for the metadata in =C2=A73.3 and = =C2=A73.4 to >> change from just boolean values to something to convey what hash alg/cnf >> method the client expects and the list of what the server supports. That= 's >> maybe something that should be done anyway. That'd be a breaking change = to >> the metadata. But there's already another potential breaking change >> identified earlier in this message. So maybe it's worth doing... >> >> >> >> How do folks feel about making this kind of change? >> >> >> >> >> > The confirmation method is opaque to the client. I don=E2=80=99t thin= k adding >> hash algs to discovery will really help. >> > The AS selection needs to be based on what the RS can support. >> > >> > If anyplace it should be in RS discovery. >> > >> > As a practical matter you art going to find a client certificate with >> more than a SHA256 hash anytime in the near future. >> > So for a short lived access token 128bits of collision resistance is >> quite good. We are going to have issues with certificates long before >> this becomes a problem. >> > >> > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RS= A >> keys, but again that is over the long term. >> > We are using short lived access tokens. People should rotate the >> certificate more often than once a year if this is a real issue. >> > >> > I am not against new hash for the fingerprint, but I also don=E2=80=99= t know >> that SHA512 would be the best choice if we are concerned about quantum >> crypto resistance. That is a issue beyond mtls and should be addressed= by >> CFRG etc. >> > >> > Regards >> > John B. >> > >> > >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you. >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --000000000000b765df056b115f86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I lean towards letting new certificate thumbprints be defi= ned someplace else.

Wit= h SHA256, it is really second preimage resistance that we care about for a = certificate thumbprint, rather than simple collision resistance. =C2=A0

MD5 failed quite badly with chosen prefix collision attacks ag= ainst certificates (Thanks to some X.509 extensions).
SHA1 has also been shown to be vulnerable to a PDF ch= osen prefix attack (http://shattered.io= )

The reason NIST pushed for development of SHA3 was concer= n that a preimage attack might eventually be found agains the SHA2 family o= f hash algorithms.=C2=A0

While SHA512 may have double the n= umber of bytes it may not help much against a SHA2 preimage attack,. (Some = papers =C2=A0suggest that the double word size of SHA512 it may be more vul= nerable than SHA256 to some attacks)

It is currently believ= ed that SHA256 has 256 bits of second preimage strength. =C2=A0 That could = always turn out to be wrong as SHA2 has some similarities to SHA1, and yes = post quantum that is reduced to 128bits.=C2=A0

To have a sa= fe future option we would probably want to go with SHA3-512. =C2=A0 However= I don=E2=80=99t see that getting much traction in the near term. =C2=A0

Practical things people should do run more along the lines of= :
1: Put at least 64 bits of ent= ropy into the certificate serial number if using self signed or a local CA.= =C2=A0 Commercial CA need to do that now.
2: Rotate certificates on a regular basis, =C2=A0using a register= ed JWKS URI

My concern is that people will see a bigger num= ber and decide it is better if we define it in the spec.=C2=A0=C2=A0
<= div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-sty= le:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal= ;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= rd-spacing:0px;text-decoration:none">We may be getting people to do additio= nal work and increasing token size without a good reason by putting it in t= he spec directly.

I have yet to see any real discussion on = using bigger hashes for signing certificates, or creating thumbprints in ot= her places.

John B.



=
On Thu, Apr 19, 2018 at 1:23 PM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Okay, so I retract t= he idea of metadata indicating the hash alg= /cnf method (based on John pointing out that it doesn't really make sen= se).

That still leaves= the question of whether or not to define additional confirmation methods in this document (and if so, wh= at they would be though x5t#S384 and = x5t#S512 seem the most likely).

There's some reasonable rational for both adding one o= r two new hash alg conf= irmation methods in the doc now vs. sticking with just SHA256= for now. I'll note again that the doc doesn't preclude using or la= ter defining other confirmation methods.

I'm kind of on the fence about it, to be honest. But = that doesn't really matter because the draft should reflect rough WG co= nsensus. So I'm looking to get a rough gauge of rough consensus. At this point there's one comment out = of WGLC asking for additional confirmation method(s). I don't think tha= t makes for consensus. But I'd ask others from the WG to chime in, i= f appropriate, to help me better gauge consensus.

On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden <ne= il.madden@forgerock.com> wrote:
I=E2=80=99m not particularly wedded to SHA-512, just that it should be= possible to use something else. At the moment, the draft seems pretty wedd= ed to SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256= on many 64-bit machines) and provides a very wide security margin against = any future crypto advances (quantum or otherwise). I=E2=80=99d also be happ= y with SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely availa= ble.

I don=E2=80=99t think short-lived access tokens is a help if the likelihood= is that certs will be reused for many access tokens.

Public Web PKI certs tend to only use SHA-256 as it has broad support, and = I gather there were some compatibility issues with SHA-512 certs in TLS. Th= ere are a handful of SHA-384 certs - e.g., the Comodo CA certs for https://home.c= ern/ are signed with SHA-384 (although with RSA-2048, which NSA estimat= es at only ~112-bit security). SHA-512 is used on some internal networks wh= ere there is more control over components being used, which is also where p= eople are mostly likely to care about security beyond 128-bit level (eg gov= ernment internal networks).

By the way, I just mentioned quantum attacks as an example of something tha= t might weaken the hash in future. Obviously, quantum attacks completely de= stroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it pr= ovides a considerable margin to hedge against future quantum *or classical*= advances while allowing the paranoid to pick a stronger security level now= . We have customers that ask for 256-bit AES already.

(I also misremembered the quantum attack - =E2=80=9CSerious Cryptography=E2= =80=9D by Aumasson tells me the best known quantum attack against collision= resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) space= so is impractical. I don=E2=80=99t know if that is the last word though).= =C2=A0

As for SHA-1, doesn=E2=80=99t that prove the point? SHA-1 is pretty broken = now with practical collisions having been demonstrated. The kind of attacks= on CA certs demonstrated for MD5 [1] are probably not too far off for SHA-= 1 now. As far as I am aware, we=E2=80=99re nowhere near those kinds of atta= cks on SHA-256, but I=E2=80=99d prefer that there was a backup plan in plac= e already rather than waiting to see (and waiting for everyone to have hard= -coded SHA-256 everywhere).

Now I have to get back to my daughter=E2=80=99s birthday party=E2=80=A6 :-)=

[1] http://www.win.tue.nl/hashclash/rogue-ca/

Neil


On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:
The WG discusses RS meta-data as part of one of Dick=E2=80=99s proposals.= =C2=A0 =C2=A0I am unclear on who is going to work on it in what draft.

If the client is doing mtls to both the Token endpoint and RS the informati= on in the confirmation method is not relevant to the client as long as the = AS and RS are in agreement like with most tokens.

The hash on the certificate and length of the signing key are equally or mo= re vulnerable to any sort of attack.
At least with AT the tokens are not long lived.

Doing anything better than SHA256 only makes sense if the cert is signed by= something stronger like SHA512 with a 2048bit RSA key.=C2=A0 =C2=A0That se= ems sort of unlikely in the near term.=C2=A0

I prefer to wait to see what general fix is proposed before we jump the gun= with a bandade for a small part of the overall problem.

People are typically using SHA1 fingerprints.=C2=A0 We added SHA256 for JWT= and got push back on that as overkill.
I don=E2=80=99t think this is the correct place to be deciding this.=C2=A0 = =C2=A0

We could say that if new thumbprints are defined the AS and RS can decide t= o use them as necessary.
That is sort of the situation we have now.

The correct solution may be a thousand rounds of PBKDF2 or something like t= hat to make finding collisions more difficult rather than longer hashes.
John B.

> On Apr 12, 2018, at 5:20 PM, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
>
> That's true about it being opaque to the client. I was thinking of= client metadata (config or registration) as a way for the AS to decide if = to bind the AT to a cert. And moving from a boolean to a conf method as an = extension of that. It would be more meaningful in RS discovery, if there wa= s such a thing.
>
> I don=E2=80=99t know that SHA512 would be the best choice either but i= t is something that is stronger and could be included now. If there's c= onsensus to do more than SHA256 in this doc.=C2=A0
>
>
>
> On Thu, Apr 12, 2018 at 1:52 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Inline
>
> Snip
>
>>
>>
>> 12. The use of only SHA-256 fingerprints means that the security s= trength of the sender-constrained access tokens is limited by the collision= resistance of SHA-256 - roughly =E2=80=9C128-bit security" - without = a new specification for a new thumbprint algorithm. An implication of this = is that is is fairly pointless for the protected resource TLS stack to ever= negotiate cipher suites/keys with a higher level of security. In more crys= tal ball territory, if a practical quantum computer becomes a possibility w= ithin the lifetime of this spec, then the expected collision resistance of = SHA-256 would drop quadratically, allowing an attacker to find a colliding = certificate in ~2^64 effort. If we are going to pick just one thumbprint ha= sh algorithm, I would prefer we pick SHA-512.
>>
>> The idea behind haveing just one thumbprint hash algorithm was to = keep things simple. And SHA-256 seems good enough for the reasonably forese= eable future (and space aware). Also a new little spec to register a differ= ent hash algorithm, should the need arise, didn't seem particularity on= erous.
>>
>> That was the thinking anyway. Maybe it is too short sighted though= ?
>>
>> I do think SHA-256 should stay regardless.
>>
>> But the draft could also define SHA-512 (and maybe others). What d= o you and WG folks think about that?
>>
>> *** Yes please.
>>
>> It would probably then be useful for the metadata in =C2=A73.3 and= =C2=A73.4 to change from just boolean values to something to convey what h= ash alg/cnf method the client expects and the list of what the server suppo= rts. That's maybe something that should be done anyway. That'd be a= breaking change to the metadata. But there's already another potential= breaking change identified earlier in this message. So maybe it's wort= h doing...
>>
>> How do folks feel about making this kind of change?
>>
>>
> The confirmation method is opaque to the client.=C2=A0 I don=E2=80=99t= think adding hash algs to discovery will really help.
> The AS selection needs to be based on what the RS can support.
>
> If anyplace it should be in RS discovery.
>
> As a practical matter you art going to find a client certificate with = more than a SHA256 hash anytime in the near future.
> So for a short lived access token 128bits of collision resistance is q= uite good.=C2=A0 =C2=A0We are going to have issues with certificates long b= efore this becomes a problem.
>
> SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RS= A keys, but again that is over the long term.=C2=A0
> We are using short lived access tokens.=C2=A0 People should rotate the= certificate more often than once a year if this is a real issue.
>
> I am not against new hash for the fingerprint, but I also don=E2=80=99= t know that SHA512 would be the best choice if we are concerned about quant= um crypto resistance.=C2=A0 =C2=A0That is a issue beyond mtls and should be= addressed by CFRG etc.
>
> Regards
> John B.
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

--000000000000b765df056b115f86-- From nobody Mon Apr 30 08:51:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD61241F5 for ; Mon, 30 Apr 2018 08:51:03 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7IbFLaLDJr4 for ; Mon, 30 Apr 2018 08:50:59 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0122.outbound.protection.outlook.com [104.47.33.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81017124C27 for ; Mon, 30 Apr 2018 08:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AvOwdhIUJsw+53wyr+QF8XA5SzIwvcHQgOZ+nApQ2uQ=; b=Fq5FgzYP6urjKmiTW+EvOfxhKB8iCPRaixUcHY36jmPb8dzGsiZai2Xp/pUUxZQ2D/EaU1nvcbwzv3r2jtsab8I+4EqHbIAxKDlBWCW5OWr3fuC9Qye/hy9wOHUnj92x+zy41CfVXbvZpB0f1Ux4qZGW/Q+HyJFCTsJsPrhqVHY= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (2603:10b6:302:8::29) by MW2PR00MB0379.namprd00.prod.outlook.com (2603:10b6:302:9::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.764.0; Mon, 30 Apr 2018 15:50:55 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::95a5:3531:866a:36e6]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::95a5:3531:866a:36e6%8]) with mapi id 15.20.0766.000; Mon, 30 Apr 2018 15:50:55 +0000 From: Mike Jones To: John Bradley , Brian Campbell CC: oauth Thread-Topic: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 Thread-Index: AQHTv9KElW7vEFcDB0qmdNJz6W5e2KPnYuCAgBTJ+QCAAM2rgIAAtVYAgAAH7oCAAA0NAIAA5ZUAgAnLhwCAESONgIAAHLDg Date: Mon, 30 Apr 2018 15:50:55 +0000 Message-ID: References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0379; 7:B6ikfP+meivBewKD6JPLv/BUHq6yDer8ydo3yNUBOzVr3DsKdvy83YyNsBgxmFbR06YEws83zvnenm07zgh8+RWOF0L+cF77YUGniOMPFPg5L8lAQiTkJFOe7TgeYhUuPrizwx9gSqYkuOKlpOtVU708UeY9zkHX9ggL/D9JBxsCSkUcX7qjguuUG/3zMQ08kdIQMeEmFBJ8dk85NPlxAAJKDxrbfLclvCgExvXSa0Z1fQ68Um3+FTMfx+/7WqXe; 20:S5Ex1V63bsoEHtKRRJUoAMmj93h5L1MQhMrU3STcXQRD4EAP7849PHwlnR+Rs8N3LVb239jWYEOzOm7yg1FoJMh4Z5QHjD3pP7Fm5woUjZwv2uv79M7ZKHlK2ROeNh+Ap80ACn9eQs+TB6dk3zllF14jPaCi0IGGJ6fG11RUiyw= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MW2PR00MB0379; x-ms-traffictypediagnostic: MW2PR00MB0379: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(244540007438412)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MW2PR00MB0379; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0379; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(396003)(376002)(346002)(189003)(199004)(40224003)(74316002)(55016002)(6506007)(93886005)(53546011)(4326008)(68736007)(186003)(81156014)(8676002)(6306002)(54896002)(19609705001)(59450400001)(236005)(53386004)(6246003)(9686003)(53936002)(5250100002)(316002)(14454004)(7736002)(26005)(22452003)(86362001)(86612001)(110136005)(5890100001)(102836004)(3280700002)(2906002)(3660700001)(606006)(6116002)(486006)(81166006)(790700001)(97736004)(25786009)(52396003)(105586002)(10290500003)(229853002)(11346002)(5660300001)(476003)(106356001)(2900100001)(3846002)(8936002)(99286004)(966005)(446003)(6436002)(76176011)(7696005)(478600001)(10090500001)(66066001)(8990500004)(33656002)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0379; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: iDXFiBYFrJVUy04n2hsPEVv1O4gvU7k0v9ee9rMZwZsjsJFNM+X0fwX6yvWlMMmD8F9+R0fneSEVJUnYZ1cMeOJoTX8M9oeYVYwHxngef8S8D3tGFr28i8a32CfFbhkBPdqPgZc4KN47N04zndw4T56JHBkTe/iRxhJWUNhSKp+9n/HAwQi5PxVMIvmg4zMf spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0298114EFC7165151F5514A9F5820MW2PR00MB0298namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 41cccbe9-4b55-4a6d-a689-08d5aeb228fe X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41cccbe9-4b55-4a6d-a689-08d5aeb228fe X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 15:50:55.6411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0379 Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:51:03 -0000 --_000_MW2PR00MB0298114EFC7165151F5514A9F5820MW2PR00MB0298namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBzaG91bGQgbm90IGRlZmluZSBuZXcgY2Vy dGlmaWNhdGUgdGh1bWJwcmludCBtZXRob2RzLiAgVGhleSBjYW4gYWx3YXlzIGJlIHJlZ2lzdGVy ZWQgYnkgb3RoZXIgc3BlY2lmaWNhdGlvbnMgaWYgbmVlZGVkIGluIHRoZSBmdXR1cmUuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg Sm9obiBCcmFkbGV5DQpTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDE4IDc6MDcgQU0NClRvOiBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+DQpDYzogb2F1dGggPG9h dXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV0dMQyBvbiBkcmFmdC1pZXRm LW9hdXRoLW10bHMtMDcNCg0KSSBsZWFuIHRvd2FyZHMgbGV0dGluZyBuZXcgY2VydGlmaWNhdGUg dGh1bWJwcmludHMgYmUgZGVmaW5lZCBzb21lcGxhY2UgZWxzZS4NCg0KV2l0aCBTSEEyNTYsIGl0 IGlzIHJlYWxseSBzZWNvbmQgcHJlaW1hZ2UgcmVzaXN0YW5jZSB0aGF0IHdlIGNhcmUgYWJvdXQg Zm9yIGEgY2VydGlmaWNhdGUgdGh1bWJwcmludCwgcmF0aGVyIHRoYW4gc2ltcGxlIGNvbGxpc2lv biByZXNpc3RhbmNlLg0KDQpNRDUgZmFpbGVkIHF1aXRlIGJhZGx5IHdpdGggY2hvc2VuIHByZWZp eCBjb2xsaXNpb24gYXR0YWNrcyBhZ2FpbnN0IGNlcnRpZmljYXRlcyAoVGhhbmtzIHRvIHNvbWUg WC41MDkgZXh0ZW5zaW9ucykuDQpTSEExIGhhcyBhbHNvIGJlZW4gc2hvd24gdG8gYmUgdnVsbmVy YWJsZSB0byBhIFBERiBjaG9zZW4gcHJlZml4IGF0dGFjayAoaHR0cDovL3NoYXR0ZXJlZC5pbykN Cg0KVGhlIHJlYXNvbiBOSVNUIHB1c2hlZCBmb3IgZGV2ZWxvcG1lbnQgb2YgU0hBMyB3YXMgY29u Y2VybiB0aGF0IGEgcHJlaW1hZ2UgYXR0YWNrIG1pZ2h0IGV2ZW50dWFsbHkgYmUgZm91bmQgYWdh aW5zIHRoZSBTSEEyIGZhbWlseSBvZiBoYXNoIGFsZ29yaXRobXMuDQoNCldoaWxlIFNIQTUxMiBt YXkgaGF2ZSBkb3VibGUgdGhlIG51bWJlciBvZiBieXRlcyBpdCBtYXkgbm90IGhlbHAgbXVjaCBh Z2FpbnN0IGEgU0hBMiBwcmVpbWFnZSBhdHRhY2ssLiAoU29tZSBwYXBlcnMgIHN1Z2dlc3QgdGhh dCB0aGUgZG91YmxlIHdvcmQgc2l6ZSBvZiBTSEE1MTIgaXQgbWF5IGJlIG1vcmUgdnVsbmVyYWJs ZSB0aGFuIFNIQTI1NiB0byBzb21lIGF0dGFja3MpDQoNCkl0IGlzIGN1cnJlbnRseSBiZWxpZXZl ZCB0aGF0IFNIQTI1NiBoYXMgMjU2IGJpdHMgb2Ygc2Vjb25kIHByZWltYWdlIHN0cmVuZ3RoLiAg IFRoYXQgY291bGQgYWx3YXlzIHR1cm4gb3V0IHRvIGJlIHdyb25nIGFzIFNIQTIgaGFzIHNvbWUg c2ltaWxhcml0aWVzIHRvIFNIQTEsIGFuZCB5ZXMgcG9zdCBxdWFudHVtIHRoYXQgaXMgcmVkdWNl ZCB0byAxMjhiaXRzLg0KDQpUbyBoYXZlIGEgc2FmZSBmdXR1cmUgb3B0aW9uIHdlIHdvdWxkIHBy b2JhYmx5IHdhbnQgdG8gZ28gd2l0aCBTSEEzLTUxMi4gICBIb3dldmVyIEkgZG9u4oCZdCBzZWUg dGhhdCBnZXR0aW5nIG11Y2ggdHJhY3Rpb24gaW4gdGhlIG5lYXIgdGVybS4NCg0KUHJhY3RpY2Fs IHRoaW5ncyBwZW9wbGUgc2hvdWxkIGRvIHJ1biBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZjoNCjE6 IFB1dCBhdCBsZWFzdCA2NCBiaXRzIG9mIGVudHJvcHkgaW50byB0aGUgY2VydGlmaWNhdGUgc2Vy aWFsIG51bWJlciBpZiB1c2luZyBzZWxmIHNpZ25lZCBvciBhIGxvY2FsIENBLiAgQ29tbWVyY2lh bCBDQSBuZWVkIHRvIGRvIHRoYXQgbm93Lg0KMjogUm90YXRlIGNlcnRpZmljYXRlcyBvbiBhIHJl Z3VsYXIgYmFzaXMsICB1c2luZyBhIHJlZ2lzdGVyZWQgSldLUyBVUkkNCg0KTXkgY29uY2VybiBp cyB0aGF0IHBlb3BsZSB3aWxsIHNlZSBhIGJpZ2dlciBudW1iZXIgYW5kIGRlY2lkZSBpdCBpcyBi ZXR0ZXIgaWYgd2UgZGVmaW5lIGl0IGluIHRoZSBzcGVjLg0KV2UgbWF5IGJlIGdldHRpbmcgcGVv cGxlIHRvIGRvIGFkZGl0aW9uYWwgd29yayBhbmQgaW5jcmVhc2luZyB0b2tlbiBzaXplIHdpdGhv dXQgYSBnb29kIHJlYXNvbiBieSBwdXR0aW5nIGl0IGluIHRoZSBzcGVjIGRpcmVjdGx5Lg0KDQpJ IGhhdmUgeWV0IHRvIHNlZSBhbnkgcmVhbCBkaXNjdXNzaW9uIG9uIHVzaW5nIGJpZ2dlciBoYXNo ZXMgZm9yIHNpZ25pbmcgY2VydGlmaWNhdGVzLCBvciBjcmVhdGluZyB0aHVtYnByaW50cyBpbiBv dGhlciBwbGFjZXMuDQoNCkpvaG4gQi4NCg0KDQoNCg0KT24gVGh1LCBBcHIgMTksIDIwMTggYXQg MToyMyBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0 bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KT2theSwgc28gSSByZXRyYWN0 IHRoZSBpZGVhIG9mIG1ldGFkYXRhIGluZGljYXRpbmcgdGhlIGhhc2ggYWxnL2NuZiBtZXRob2Qg KGJhc2VkIG9uIEpvaG4gcG9pbnRpbmcgb3V0IHRoYXQgaXQgZG9lc24ndCByZWFsbHkgbWFrZSBz ZW5zZSkuDQpUaGF0IHN0aWxsIGxlYXZlcyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBvciBub3Qg dG8gZGVmaW5lIGFkZGl0aW9uYWwgY29uZmlybWF0aW9uIG1ldGhvZHMgaW4gdGhpcyBkb2N1bWVu dCAoYW5kIGlmIHNvLCB3aGF0IHRoZXkgd291bGQgYmUgdGhvdWdoIHg1dCNTMzg0IGFuZCB4NXQj UzUxMiBzZWVtIHRoZSBtb3N0IGxpa2VseSkuDQpUaGVyZSdzIHNvbWUgcmVhc29uYWJsZSByYXRp b25hbCBmb3IgYm90aCBhZGRpbmcgb25lIG9yIHR3byBuZXcgaGFzaCBhbGcgY29uZmlybWF0aW9u IG1ldGhvZHMgaW4gdGhlIGRvYyBub3cgdnMuIHN0aWNraW5nIHdpdGgganVzdCBTSEEyNTYgZm9y IG5vdy4gSSdsbCBub3RlIGFnYWluIHRoYXQgdGhlIGRvYyBkb2Vzbid0IHByZWNsdWRlIHVzaW5n IG9yIGxhdGVyIGRlZmluaW5nIG90aGVyIGNvbmZpcm1hdGlvbiBtZXRob2RzLg0KSSdtIGtpbmQg b2Ygb24gdGhlIGZlbmNlIGFib3V0IGl0LCB0byBiZSBob25lc3QuIEJ1dCB0aGF0IGRvZXNuJ3Qg cmVhbGx5IG1hdHRlciBiZWNhdXNlIHRoZSBkcmFmdCBzaG91bGQgcmVmbGVjdCByb3VnaCBXRyBj b25zZW5zdXMuIFNvIEknbSBsb29raW5nIHRvIGdldCBhIHJvdWdoIGdhdWdlIG9mIHJvdWdoIGNv bnNlbnN1cy4gQXQgdGhpcyBwb2ludCB0aGVyZSdzIG9uZSBjb21tZW50IG91dCBvZiBXR0xDIGFz a2luZyBmb3IgYWRkaXRpb25hbCBjb25maXJtYXRpb24gbWV0aG9kKHMpLiBJIGRvbid0IHRoaW5r IHRoYXQgbWFrZXMgZm9yIGNvbnNlbnN1cy4gQnV0IEknZCBhc2sgb3RoZXJzIGZyb20gdGhlIFdH IHRvIGNoaW1lIGluLCBpZiBhcHByb3ByaWF0ZSwgdG8gaGVscCBtZSBiZXR0ZXIgZ2F1Z2UgY29u c2Vuc3VzLg0KDQpPbiBGcmksIEFwciAxMywgMjAxOCBhdCA0OjQ5IEFNLCBOZWlsIE1hZGRlbiA8 bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTxtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNv bT4+IHdyb3RlOg0KSeKAmW0gbm90IHBhcnRpY3VsYXJseSB3ZWRkZWQgdG8gU0hBLTUxMiwganVz dCB0aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2Ugc29tZXRoaW5nIGVsc2UuIEF0IHRo ZSBtb21lbnQsIHRoZSBkcmFmdCBzZWVtcyBwcmV0dHkgd2VkZGVkIHRvIFNIQS0yNTYuIFNIQS01 MTIgbWF5IGJlIG92ZXJraWxsLCBidXQgaXQgaXMgZmFzdCAoZmFzdGVyIHRoYW4gU0hBLTI1NiBv biBtYW55IDY0LWJpdCBtYWNoaW5lcykgYW5kIHByb3ZpZGVzIGEgdmVyeSB3aWRlIHNlY3VyaXR5 IG1hcmdpbiBhZ2FpbnN0IGFueSBmdXR1cmUgY3J5cHRvIGFkdmFuY2VzIChxdWFudHVtIG9yIG90 aGVyd2lzZSkuIEnigJlkIGFsc28gYmUgaGFwcHkgd2l0aCBTSEEtMzg0LCBTSEEzLTUxMiwgQmxh a2UyIGV0YyBidXQgU0hBLTUxMiBzZWVtcyBwcmV0dHkgd2lkZWx5IGF2YWlsYWJsZS4NCg0KSSBk b27igJl0IHRoaW5rIHNob3J0LWxpdmVkIGFjY2VzcyB0b2tlbnMgaXMgYSBoZWxwIGlmIHRoZSBs aWtlbGlob29kIGlzIHRoYXQgY2VydHMgd2lsbCBiZSByZXVzZWQgZm9yIG1hbnkgYWNjZXNzIHRv a2Vucy4NCg0KUHVibGljIFdlYiBQS0kgY2VydHMgdGVuZCB0byBvbmx5IHVzZSBTSEEtMjU2IGFz IGl0IGhhcyBicm9hZCBzdXBwb3J0LCBhbmQgSSBnYXRoZXIgdGhlcmUgd2VyZSBzb21lIGNvbXBh dGliaWxpdHkgaXNzdWVzIHdpdGggU0hBLTUxMiBjZXJ0cyBpbiBUTFMuIFRoZXJlIGFyZSBhIGhh bmRmdWwgb2YgU0hBLTM4NCBjZXJ0cyAtIGUuZy4sIHRoZSBDb21vZG8gQ0EgY2VydHMgZm9yIGh0 dHBzOi8vaG9tZS5jZXJuLyBhcmUgc2lnbmVkIHdpdGggU0hBLTM4NCAoYWx0aG91Z2ggd2l0aCBS U0EtMjA0OCwgd2hpY2ggTlNBIGVzdGltYXRlcyBhdCBvbmx5IH4xMTItYml0IHNlY3VyaXR5KS4g U0hBLTUxMiBpcyB1c2VkIG9uIHNvbWUgaW50ZXJuYWwgbmV0d29ya3Mgd2hlcmUgdGhlcmUgaXMg bW9yZSBjb250cm9sIG92ZXIgY29tcG9uZW50cyBiZWluZyB1c2VkLCB3aGljaCBpcyBhbHNvIHdo ZXJlIHBlb3BsZSBhcmUgbW9zdGx5IGxpa2VseSB0byBjYXJlIGFib3V0IHNlY3VyaXR5IGJleW9u ZCAxMjgtYml0IGxldmVsIChlZyBnb3Zlcm5tZW50IGludGVybmFsIG5ldHdvcmtzKS4NCg0KQnkg dGhlIHdheSwgSSBqdXN0IG1lbnRpb25lZCBxdWFudHVtIGF0dGFja3MgYXMgYW4gZXhhbXBsZSBv ZiBzb21ldGhpbmcgdGhhdCBtaWdodCB3ZWFrZW4gdGhlIGhhc2ggaW4gZnV0dXJlLiBPYnZpb3Vz bHksIHF1YW50dW0gYXR0YWNrcyBjb21wbGV0ZWx5IGRlc3Ryb3kgUlNBLCBFQ0RTQSBldGMsIHNv IFNIQS01MTIgd291bGQgbm90IHNvbHZlIHRoaXMgb24gaXRzIG93biwgYnV0IGl0IHByb3ZpZGVz IGEgY29uc2lkZXJhYmxlIG1hcmdpbiB0byBoZWRnZSBhZ2FpbnN0IGZ1dHVyZSBxdWFudHVtICpv ciBjbGFzc2ljYWwqIGFkdmFuY2VzIHdoaWxlIGFsbG93aW5nIHRoZSBwYXJhbm9pZCB0byBwaWNr IGEgc3Ryb25nZXIgc2VjdXJpdHkgbGV2ZWwgbm93Li4gV2UgaGF2ZSBjdXN0b21lcnMgdGhhdCBh c2sgZm9yIDI1Ni1iaXQgQUVTIGFscmVhZHkuDQoNCihJIGFsc28gbWlzcmVtZW1iZXJlZCB0aGUg cXVhbnR1bSBhdHRhY2sgLSDigJxTZXJpb3VzIENyeXB0b2dyYXBoeeKAnSBieSBBdW1hc3NvbiB0 ZWxscyBtZSB0aGUgYmVzdCBrbm93biBxdWFudHVtIGF0dGFjayBhZ2FpbnN0IGNvbGxpc2lvbiBy ZXNpc3RhbmNlIGlzIE8oMl5uLzMpIC0gc28gfjJeODUgZm9yIFNIQS0yNTYgYnV0IGFsc28gbmVl ZHMgTygyXjg1KSBzcGFjZSBzbyBpcyBpbXByYWN0aWNhbC4gSSBkb27igJl0IGtub3cgaWYgdGhh dCBpcyB0aGUgbGFzdCB3b3JkIHRob3VnaCkuDQoNCkFzIGZvciBTSEEtMSwgZG9lc27igJl0IHRo YXQgcHJvdmUgdGhlIHBvaW50PyBTSEEtMSBpcyBwcmV0dHkgYnJva2VuIG5vdyB3aXRoIHByYWN0 aWNhbCBjb2xsaXNpb25zIGhhdmluZyBiZWVuIGRlbW9uc3RyYXRlZC4gVGhlIGtpbmQgb2YgYXR0 YWNrcyBvbiBDQSBjZXJ0cyBkZW1vbnN0cmF0ZWQgZm9yIE1ENSBbMV0gYXJlIHByb2JhYmx5IG5v dCB0b28gZmFyIG9mZiBmb3IgU0hBLTEgbm93LiBBcyBmYXIgYXMgSSBhbSBhd2FyZSwgd2XigJly ZSBub3doZXJlIG5lYXIgdGhvc2Uga2luZHMgb2YgYXR0YWNrcyBvbiBTSEEtMjU2LCBidXQgSeKA mWQgcHJlZmVyIHRoYXQgdGhlcmUgd2FzIGEgYmFja3VwIHBsYW4gaW4gcGxhY2UgYWxyZWFkeSBy YXRoZXIgdGhhbiB3YWl0aW5nIHRvIHNlZSAoYW5kIHdhaXRpbmcgZm9yIGV2ZXJ5b25lIHRvIGhh dmUgaGFyZC1jb2RlZCBTSEEtMjU2IGV2ZXJ5d2hlcmUpLg0KDQpOb3cgSSBoYXZlIHRvIGdldCBi YWNrIHRvIG15IGRhdWdodGVy4oCZcyBiaXJ0aGRheSBwYXJ0eeKApiA6LSkNCg0KWzFdIGh0dHA6 Ly93d3cud2luLnR1ZS5ubC9oYXNoY2xhc2gvcm9ndWUtY2EvDQoNCk5laWwNCg0KDQpPbiBUaHVy c2RheSwgQXByIDEyLCAyMDE4IGF0IDEwOjA3IHBtLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdq dGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KVGhlIFdHIGRpc2N1c3Nl cyBSUyBtZXRhLWRhdGEgYXMgcGFydCBvZiBvbmUgb2YgRGlja+KAmXMgcHJvcG9zYWxzLiAgIEkg YW0gdW5jbGVhciBvbiB3aG8gaXMgZ29pbmcgdG8gd29yayBvbiBpdCBpbiB3aGF0IGRyYWZ0Lg0K DQpJZiB0aGUgY2xpZW50IGlzIGRvaW5nIG10bHMgdG8gYm90aCB0aGUgVG9rZW4gZW5kcG9pbnQg YW5kIFJTIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgY29uZmlybWF0aW9uIG1ldGhvZCBpcyBub3Qg cmVsZXZhbnQgdG8gdGhlIGNsaWVudCBhcyBsb25nIGFzIHRoZSBBUyBhbmQgUlMgYXJlIGluIGFn cmVlbWVudCBsaWtlIHdpdGggbW9zdCB0b2tlbnMuDQoNClRoZSBoYXNoIG9uIHRoZSBjZXJ0aWZp Y2F0ZSBhbmQgbGVuZ3RoIG9mIHRoZSBzaWduaW5nIGtleSBhcmUgZXF1YWxseSBvciBtb3JlIHZ1 bG5lcmFibGUgdG8gYW55IHNvcnQgb2YgYXR0YWNrLg0KQXQgbGVhc3Qgd2l0aCBBVCB0aGUgdG9r ZW5zIGFyZSBub3QgbG9uZyBsaXZlZC4NCg0KRG9pbmcgYW55dGhpbmcgYmV0dGVyIHRoYW4gU0hB MjU2IG9ubHkgbWFrZXMgc2Vuc2UgaWYgdGhlIGNlcnQgaXMgc2lnbmVkIGJ5IHNvbWV0aGluZyBz dHJvbmdlciBsaWtlIFNIQTUxMiB3aXRoIGEgMjA0OGJpdCBSU0Ega2V5LiAgIFRoYXQgc2VlbXMg c29ydCBvZiB1bmxpa2VseSBpbiB0aGUgbmVhciB0ZXJtLg0KDQpJIHByZWZlciB0byB3YWl0IHRv IHNlZSB3aGF0IGdlbmVyYWwgZml4IGlzIHByb3Bvc2VkIGJlZm9yZSB3ZSBqdW1wIHRoZSBndW4g d2l0aCBhIGJhbmRhZGUgZm9yIGEgc21hbGwgcGFydCBvZiB0aGUgb3ZlcmFsbCBwcm9ibGVtLg0K DQpQZW9wbGUgYXJlIHR5cGljYWxseSB1c2luZyBTSEExIGZpbmdlcnByaW50cy4gIFdlIGFkZGVk IFNIQTI1NiBmb3IgSldUIGFuZCBnb3QgcHVzaCBiYWNrIG9uIHRoYXQgYXMgb3ZlcmtpbGwuDQpJ IGRvbuKAmXQgdGhpbmsgdGhpcyBpcyB0aGUgY29ycmVjdCBwbGFjZSB0byBiZSBkZWNpZGluZyB0 aGlzLg0KDQpXZSBjb3VsZCBzYXkgdGhhdCBpZiBuZXcgdGh1bWJwcmludHMgYXJlIGRlZmluZWQg dGhlIEFTIGFuZCBSUyBjYW4gZGVjaWRlIHRvIHVzZSB0aGVtIGFzIG5lY2Vzc2FyeS4NClRoYXQg aXMgc29ydCBvZiB0aGUgc2l0dWF0aW9uIHdlIGhhdmUgbm93Lg0KDQpUaGUgY29ycmVjdCBzb2x1 dGlvbiBtYXkgYmUgYSB0aG91c2FuZCByb3VuZHMgb2YgUEJLREYyIG9yIHNvbWV0aGluZyBsaWtl IHRoYXQgdG8gbWFrZSBmaW5kaW5nIGNvbGxpc2lvbnMgbW9yZSBkaWZmaWN1bHQgcmF0aGVyIHRo YW4gbG9uZ2VyIGhhc2hlcy4NCg0KSm9obiBCLg0KDQo+IE9uIEFwciAxMiwgMjAxOCwgYXQgNToy MCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KPg0KPiBUaGF0J3MgdHJ1ZSBhYm91 dCBpdCBiZWluZyBvcGFxdWUgdG8gdGhlIGNsaWVudC4gSSB3YXMgdGhpbmtpbmcgb2YgY2xpZW50 IG1ldGFkYXRhIChjb25maWcgb3IgcmVnaXN0cmF0aW9uKSBhcyBhIHdheSBmb3IgdGhlIEFTIHRv IGRlY2lkZSBpZiB0byBiaW5kIHRoZSBBVCB0byBhIGNlcnQuIEFuZCBtb3ZpbmcgZnJvbSBhIGJv b2xlYW4gdG8gYSBjb25mIG1ldGhvZCBhcyBhbiBleHRlbnNpb24gb2YgdGhhdC4gSXQgd291bGQg YmUgbW9yZSBtZWFuaW5nZnVsIGluIFJTIGRpc2NvdmVyeSwgaWYgdGhlcmUgd2FzIHN1Y2ggYSB0 aGluZy4NCj4NCj4gSSBkb27igJl0IGtub3cgdGhhdCBTSEE1MTIgd291bGQgYmUgdGhlIGJlc3Qg Y2hvaWNlIGVpdGhlciBidXQgaXQgaXMgc29tZXRoaW5nIHRoYXQgaXMgc3Ryb25nZXIgYW5kIGNv dWxkIGJlIGluY2x1ZGVkIG5vdy4gSWYgdGhlcmUncyBjb25zZW5zdXMgdG8gZG8gbW9yZSB0aGFu IFNIQTI1NiBpbiB0aGlzIGRvYy4NCj4NCj4NCj4NCj4gT24gVGh1LCBBcHIgMTIsIDIwMTggYXQg MTo1MiBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl N2p0Yi5jb20+PiB3cm90ZToNCj4gSW5saW5lDQo+DQo+IFNuaXANCj4NCj4+DQo+Pg0KPj4gMTIu IFRoZSB1c2Ugb2Ygb25seSBTSEEtMjU2IGZpbmdlcnByaW50cyBtZWFucyB0aGF0IHRoZSBzZWN1 cml0eSBzdHJlbmd0aCBvZiB0aGUgc2VuZGVyLWNvbnN0cmFpbmVkIGFjY2VzcyB0b2tlbnMgaXMg bGltaXRlZCBieSB0aGUgY29sbGlzaW9uIHJlc2lzdGFuY2Ugb2YgU0hBLTI1NiAtIHJvdWdobHkg 4oCcMTI4LWJpdCBzZWN1cml0eSIgLSB3aXRob3V0IGEgbmV3IHNwZWNpZmljYXRpb24gZm9yIGEg bmV3IHRodW1icHJpbnQgYWxnb3JpdGhtLiBBbiBpbXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRoYXQg aXMgaXMgZmFpcmx5IHBvaW50bGVzcyBmb3IgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBUTFMgc3Rh Y2sgdG8gZXZlciBuZWdvdGlhdGUgY2lwaGVyIHN1aXRlcy9rZXlzIHdpdGggYSBoaWdoZXIgbGV2 ZWwgb2Ygc2VjdXJpdHkuIEluIG1vcmUgY3J5c3RhbCBiYWxsIHRlcnJpdG9yeSwgaWYgYSBwcmFj dGljYWwgcXVhbnR1bSBjb21wdXRlciBiZWNvbWVzIGEgcG9zc2liaWxpdHkgd2l0aGluIHRoZSBs aWZldGltZSBvZiB0aGlzIHNwZWMsIHRoZW4gdGhlIGV4cGVjdGVkIGNvbGxpc2lvbiByZXNpc3Rh bmNlIG9mIFNIQS0yNTYgd291bGQgZHJvcCBxdWFkcmF0aWNhbGx5LCBhbGxvd2luZyBhbiBhdHRh Y2tlciB0byBmaW5kIGEgY29sbGlkaW5nIGNlcnRpZmljYXRlIGluIH4yXjY0IGVmZm9ydC4gSWYg d2UgYXJlIGdvaW5nIHRvIHBpY2sganVzdCBvbmUgdGh1bWJwcmludCBoYXNoIGFsZ29yaXRobSwg SSB3b3VsZCBwcmVmZXIgd2UgcGljayBTSEEtNTEyLg0KPj4NCj4+IFRoZSBpZGVhIGJlaGluZCBo YXZlaW5nIGp1c3Qgb25lIHRodW1icHJpbnQgaGFzaCBhbGdvcml0aG0gd2FzIHRvIGtlZXAgdGhp bmdzIHNpbXBsZS4gQW5kIFNIQS0yNTYgc2VlbXMgZ29vZCBlbm91Z2ggZm9yIHRoZSByZWFzb25h Ymx5IGZvcmVzZWVhYmxlIGZ1dHVyZSAoYW5kIHNwYWNlIGF3YXJlKS4gQWxzbyBhIG5ldyBsaXR0 bGUgc3BlYyB0byByZWdpc3RlciBhIGRpZmZlcmVudCBoYXNoIGFsZ29yaXRobSwgc2hvdWxkIHRo ZSBuZWVkIGFyaXNlLCBkaWRuJ3Qgc2VlbSBwYXJ0aWN1bGFyaXR5IG9uZXJvdXMuDQo+Pg0KPj4g VGhhdCB3YXMgdGhlIHRoaW5raW5nIGFueXdheS4gTWF5YmUgaXQgaXMgdG9vIHNob3J0IHNpZ2h0 ZWQgdGhvdWdoPw0KPj4NCj4+IEkgZG8gdGhpbmsgU0hBLTI1NiBzaG91bGQgc3RheSByZWdhcmRs ZXNzLg0KPj4NCj4+IEJ1dCB0aGUgZHJhZnQgY291bGQgYWxzbyBkZWZpbmUgU0hBLTUxMiAoYW5k IG1heWJlIG90aGVycykuIFdoYXQgZG8geW91IGFuZCBXRyBmb2xrcyB0aGluayBhYm91dCB0aGF0 Pw0KPj4NCj4+ICoqKiBZZXMgcGxlYXNlLg0KPj4NCj4+IEl0IHdvdWxkIHByb2JhYmx5IHRoZW4g YmUgdXNlZnVsIGZvciB0aGUgbWV0YWRhdGEgaW4gwqczLjMgYW5kIMKnMy40IHRvIGNoYW5nZSBm cm9tIGp1c3QgYm9vbGVhbiB2YWx1ZXMgdG8gc29tZXRoaW5nIHRvIGNvbnZleSB3aGF0IGhhc2gg YWxnL2NuZiBtZXRob2QgdGhlIGNsaWVudCBleHBlY3RzIGFuZCB0aGUgbGlzdCBvZiB3aGF0IHRo ZSBzZXJ2ZXIgc3VwcG9ydHMuIFRoYXQncyBtYXliZSBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUg ZG9uZSBhbnl3YXkuIFRoYXQnZCBiZSBhIGJyZWFraW5nIGNoYW5nZSB0byB0aGUgbWV0YWRhdGEu IEJ1dCB0aGVyZSdzIGFscmVhZHkgYW5vdGhlciBwb3RlbnRpYWwgYnJlYWtpbmcgY2hhbmdlIGlk ZW50aWZpZWQgZWFybGllciBpbiB0aGlzIG1lc3NhZ2UuIFNvIG1heWJlIGl0J3Mgd29ydGggZG9p bmcuLi4NCj4+DQo+PiBIb3cgZG8gZm9sa3MgZmVlbCBhYm91dCBtYWtpbmcgdGhpcyBraW5kIG9m IGNoYW5nZT8NCj4+DQo+Pg0KPiBUaGUgY29uZmlybWF0aW9uIG1ldGhvZCBpcyBvcGFxdWUgdG8g dGhlIGNsaWVudC4gIEkgZG9u4oCZdCB0aGluayBhZGRpbmcgaGFzaCBhbGdzIHRvIGRpc2NvdmVy eSB3aWxsIHJlYWxseSBoZWxwLg0KPiBUaGUgQVMgc2VsZWN0aW9uIG5lZWRzIHRvIGJlIGJhc2Vk IG9uIHdoYXQgdGhlIFJTIGNhbiBzdXBwb3J0Lg0KPg0KPiBJZiBhbnlwbGFjZSBpdCBzaG91bGQg YmUgaW4gUlMgZGlzY292ZXJ5Lg0KPg0KPiBBcyBhIHByYWN0aWNhbCBtYXR0ZXIgeW91IGFydCBn b2luZyB0byBmaW5kIGEgY2xpZW50IGNlcnRpZmljYXRlIHdpdGggbW9yZSB0aGFuIGEgU0hBMjU2 IGhhc2ggYW55dGltZSBpbiB0aGUgbmVhciBmdXR1cmUuDQo+IFNvIGZvciBhIHNob3J0IGxpdmVk IGFjY2VzcyB0b2tlbiAxMjhiaXRzIG9mIGNvbGxpc2lvbiByZXNpc3RhbmNlIGlzIHF1aXRlIGdv b2QuICAgV2UgYXJlIGdvaW5nIHRvIGhhdmUgaXNzdWVzIHdpdGggY2VydGlmaWNhdGVzIGxvbmcg YmVmb3JlIHRoaXMgYmVjb21lcyBhIHByb2JsZW0uDQo+DQo+IFNIQTI1NiBpcyBhcHByb3ByaWF0 ZSBmb3IgQUVTMTI4IDI1NmJpdCBlbGxpcHRpYyBjdXJ2ZXMgYW5kIDMwNzJiaXQgUlNBIGtleXMs IGJ1dCBhZ2FpbiB0aGF0IGlzIG92ZXIgdGhlIGxvbmcgdGVybS4NCj4gV2UgYXJlIHVzaW5nIHNo b3J0IGxpdmVkIGFjY2VzcyB0b2tlbnMuICBQZW9wbGUgc2hvdWxkIHJvdGF0ZSB0aGUgY2VydGlm aWNhdGUgbW9yZSBvZnRlbiB0aGFuIG9uY2UgYSB5ZWFyIGlmIHRoaXMgaXMgYSByZWFsIGlzc3Vl Lg0KPg0KPiBJIGFtIG5vdCBhZ2FpbnN0IG5ldyBoYXNoIGZvciB0aGUgZmluZ2VycHJpbnQsIGJ1 dCBJIGFsc28gZG9u4oCZdCBrbm93IHRoYXQgU0hBNTEyIHdvdWxkIGJlIHRoZSBiZXN0IGNob2lj ZSBpZiB3ZSBhcmUgY29uY2VybmVkIGFib3V0IHF1YW50dW0gY3J5cHRvIHJlc2lzdGFuY2UuICAg VGhhdCBpcyBhIGlzc3VlIGJleW9uZCBtdGxzIGFuZCBzaG91bGQgYmUgYWRkcmVzc2VkIGJ5IENG UkcgZXRjLg0KPg0KPiBSZWdhcmRzDQo+IEpvaG4gQi4NCj4NCj4NCj4NCj4NCj4gQ09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1l bnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQoNCkNPTkZJREVOVElBTElUWSBO T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g QW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoNCg== --_000_MW2PR00MB0298114EFC7165151F5514A9F5820MW2PR00MB0298namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLm0tNTQzOTY5OTIzMjEzMDE2MTQ3NGdtYWlsLW01MDc0OTYzODYzNDA3Mzc5 ODYxbS00NjgwOTk1OTg2NTUyNTEzNDA3bTgzMjgxNzM2MzUyMzcxMDY2NzJtNjE2NDMzMDgwODg3 MzkyMjc0MW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0tNDEzOTU3NzU1NjQ0NDYzNzAyOGdtYWlsLWlt DQoJe21zby1zdHlsZS1uYW1lOm1fLTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tXzUwNzQ5NjM4 NjM0MDczNzk4NjFtXy00NjgwOTk1OTg2NTUyNTEzNDA3bV84MzI4MTczNjM1MjM3MTA2NjcybV82 MTY0MzMwODA4ODczOTIyNzQxbV8tNDAyNzg4OTAzNDI4NDIwNTYyOW1fLTQxMzk1Nzc1NTY0NDQ2 MzcwMjhnbWFpbC1pbTt9DQpzcGFuLm0tNTQzOTY5OTIzMjEzMDE2MTQ3NGdtYWlsLW01MDc0OTYz ODYzNDA3Mzc5ODYxbS00NjgwOTk1OTg2NTUyNTEzNDA3bTgzMjgxNzM2MzUyMzcxMDY2NzJtNjE2 NDMzMDgwODg3MzkyMjc0MWdtYWlsLW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0tNDEzOTU3NzU1NjQ0 NDYzNzAyOGdtYWlsLWltDQoJe21zby1zdHlsZS1uYW1lOm1fLTU0Mzk2OTkyMzIxMzAxNjE0NzRn bWFpbC1tXzUwNzQ5NjM4NjM0MDczNzk4NjFtXy00NjgwOTk1OTg2NTUyNTEzNDA3bV84MzI4MTcz NjM1MjM3MTA2NjcybV82MTY0MzMwODA4ODczOTIyNzQxZ21haWwtbV8tNDAyNzg4OTAzNDI4NDIw NTYyOW1fLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFpbC1pbTt9DQpzcGFuLm0tNTQzOTY5OTIzMjEz MDE2MTQ3NGdtYWlsLW01MDc0OTYzODYzNDA3Mzc5ODYxZ21haWwtbS00NjgwOTk1OTg2NTUyNTEz NDA3bTgzMjgxNzM2MzUyMzcxMDY2NzJtNjE2NDMzMDgwODg3MzkyMjc0MW0tNDAyNzg4OTAzNDI4 NDIwNTYyOW0tNDEzOTU3NzU1NjQ0NDYzNzAyOGdtYWlsLWltDQoJe21zby1zdHlsZS1uYW1lOm1f LTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tXzUwNzQ5NjM4NjM0MDczNzk4NjFnbWFpbC1tXy00 NjgwOTk1OTg2NTUyNTEzNDA3bV84MzI4MTczNjM1MjM3MTA2NjcybV82MTY0MzMwODA4ODczOTIy NzQxbV8tNDAyNzg4OTAzNDI4NDIwNTYyOW1fLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFpbC1pbTt9 DQpzcGFuLm0tNTQzOTY5OTIzMjEzMDE2MTQ3NGdtYWlsLW01MDc0OTYzODYzNDA3Mzc5ODYxbS00 NjgwOTk1OTg2NTUyNTEzNDA3Z21haWwtbTgzMjgxNzM2MzUyMzcxMDY2NzJtNjE2NDMzMDgwODg3 MzkyMjc0MW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0tNDEzOTU3NzU1NjQ0NDYzNzAyOGdtYWlsLWlt DQoJe21zby1zdHlsZS1uYW1lOm1fLTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tXzUwNzQ5NjM4 NjM0MDczNzk4NjFtXy00NjgwOTk1OTg2NTUyNTEzNDA3Z21haWwtbV84MzI4MTczNjM1MjM3MTA2 NjcybV82MTY0MzMwODA4ODczOTIyNzQxbV8tNDAyNzg4OTAzNDI4NDIwNTYyOW1fLTQxMzk1Nzc1 NTY0NDQ2MzcwMjhnbWFpbC1pbTt9DQpzcGFuLm0tNTQzOTY5OTIzMjEzMDE2MTQ3NGdtYWlsLW01 MDc0OTYzODYzNDA3Mzc5ODYxbS00NjgwOTk1OTg2NTUyNTEzNDA3Z21haWwtbTgzMjgxNzM2MzUy MzcxMDY2NzJtNjE2NDMzMDgwODg3MzkyMjc0MWdtYWlsLW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0t NDEzOTU3NzU1NjQ0NDYzNzAyOGdtYWlsLWltDQoJe21zby1zdHlsZS1uYW1lOm1fLTU0Mzk2OTky MzIxMzAxNjE0NzRnbWFpbC1tXzUwNzQ5NjM4NjM0MDczNzk4NjFtXy00NjgwOTk1OTg2NTUyNTEz NDA3Z21haWwtbV84MzI4MTczNjM1MjM3MTA2NjcybV82MTY0MzMwODA4ODczOTIyNzQxZ21haWwt bV8tNDAyNzg4OTAzNDI4NDIwNTYyOW1fLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFpbC1pbTt9DQpz cGFuLm0tNTQzOTY5OTIzMjEzMDE2MTQ3NGhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy01NDM5 Njk5MjMyMTMwMTYxNDc0aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBzaG91bGQgbm90 IGRlZmluZSBuZXcgY2VydGlmaWNhdGUgdGh1bWJwcmludCBtZXRob2RzLiZuYnNwOyBUaGV5IGNh biBhbHdheXMgYmUgcmVnaXN0ZXJlZCBieSBvdGhlciBzcGVjaWZpY2F0aW9ucyBpZiBuZWVkZWQg aW4gdGhlIGZ1dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxm IE9mIDwvYj4NCkpvaG4gQnJhZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDMw LCAyMDE4IDc6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gV0dMQyBvbiBk cmFmdC1pZXRmLW9hdXRoLW10bHMtMDc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg bGVhbiB0b3dhcmRzIGxldHRpbmcgbmV3IGNlcnRpZmljYXRlIHRodW1icHJpbnRzIGJlIGRlZmlu ZWQgc29tZXBsYWNlIGVsc2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XaXRoIFNIQTI1NiwgaXQgaXMg cmVhbGx5IHNlY29uZCBwcmVpbWFnZSByZXNpc3RhbmNlIHRoYXQgd2UgY2FyZSBhYm91dCBmb3Ig YSBjZXJ0aWZpY2F0ZSB0aHVtYnByaW50LCByYXRoZXIgdGhhbiBzaW1wbGUgY29sbGlzaW9uIHJl c2lzdGFuY2UuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1ENSBmYWlsZWQgcXVpdGUgYmFkbHkgd2l0 aCBjaG9zZW4gcHJlZml4IGNvbGxpc2lvbiBhdHRhY2tzIGFnYWluc3QgY2VydGlmaWNhdGVzIChU aGFua3MgdG8gc29tZSBYLjUwOSBleHRlbnNpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5TSEExIGhhcyBhbHNvIGJlZW4gc2hvd24gdG8gYmUgdnVsbmVyYWJsZSB0byBhIFBE RiBjaG9zZW4gcHJlZml4IGF0dGFjayAoPGEgaHJlZj0iaHR0cDovL3NoYXR0ZXJlZC5pbyI+aHR0 cDovL3NoYXR0ZXJlZC5pbzwvYT4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHJlYXNvbiBOSVNUIHB1c2hl ZCBmb3IgZGV2ZWxvcG1lbnQgb2YgU0hBMyB3YXMgY29uY2VybiB0aGF0IGEgcHJlaW1hZ2UgYXR0 YWNrIG1pZ2h0IGV2ZW50dWFsbHkgYmUgZm91bmQgYWdhaW5zIHRoZSBTSEEyIGZhbWlseSBvZiBo YXNoIGFsZ29yaXRobXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2hpbGUgU0hBNTEyIG1heSBoYXZl IGRvdWJsZSB0aGUgbnVtYmVyIG9mIGJ5dGVzIGl0IG1heSBub3QgaGVscCBtdWNoIGFnYWluc3Qg YSBTSEEyIHByZWltYWdlIGF0dGFjaywuIChTb21lIHBhcGVycyAmbmJzcDtzdWdnZXN0IHRoYXQg dGhlIGRvdWJsZSB3b3JkIHNpemUgb2YgU0hBNTEyDQogaXQgbWF5IGJlIG1vcmUgdnVsbmVyYWJs ZSB0aGFuIFNIQTI1NiB0byBzb21lIGF0dGFja3MpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SXQgaXMgY3VycmVu dGx5IGJlbGlldmVkIHRoYXQgU0hBMjU2IGhhcyAyNTYgYml0cyBvZiBzZWNvbmQgcHJlaW1hZ2Ug c3RyZW5ndGguICZuYnNwOyBUaGF0IGNvdWxkIGFsd2F5cyB0dXJuIG91dCB0byBiZSB3cm9uZyBh cyBTSEEyIGhhcyBzb21lIHNpbWlsYXJpdGllcyB0byBTSEExLA0KIGFuZCB5ZXMgcG9zdCBxdWFu dHVtIHRoYXQgaXMgcmVkdWNlZCB0byAxMjhiaXRzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRvIGhh dmUgYSBzYWZlIGZ1dHVyZSBvcHRpb24gd2Ugd291bGQgcHJvYmFibHkgd2FudCB0byBnbyB3aXRo IFNIQTMtNTEyLiAmbmJzcDsgSG93ZXZlciBJIGRvbuKAmXQgc2VlIHRoYXQgZ2V0dGluZyBtdWNo IHRyYWN0aW9uIGluIHRoZSBuZWFyIHRlcm0uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlByYWN0aWNh bCB0aGluZ3MgcGVvcGxlIHNob3VsZCBkbyBydW4gbW9yZSBhbG9uZyB0aGUgbGluZXMgb2Y6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTogUHV0IGF0IGxlYXN0IDY0IGJpdHMgb2Yg ZW50cm9weSBpbnRvIHRoZSBjZXJ0aWZpY2F0ZSBzZXJpYWwgbnVtYmVyIGlmIHVzaW5nIHNlbGYg c2lnbmVkIG9yIGEgbG9jYWwgQ0EuJm5ic3A7IENvbW1lcmNpYWwgQ0EgbmVlZCB0byBkbyB0aGF0 IG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yOiBSb3RhdGUgY2VydGlmaWNh dGVzIG9uIGEgcmVndWxhciBiYXNpcywgJm5ic3A7dXNpbmcgYSByZWdpc3RlcmVkIEpXS1MgVVJJ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TXkgY29uY2VybiBpcyB0aGF0IHBlb3BsZSB3aWxsIHNlZSBhIGJpZ2dl ciBudW1iZXIgYW5kIGRlY2lkZSBpdCBpcyBiZXR0ZXIgaWYgd2UgZGVmaW5lIGl0IGluIHRoZSBz cGVjLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldlIG1heSBi ZSBnZXR0aW5nIHBlb3BsZSB0byBkbyBhZGRpdGlvbmFsIHdvcmsgYW5kIGluY3JlYXNpbmcgdG9r ZW4gc2l6ZSB3aXRob3V0IGEgZ29vZCByZWFzb24gYnkgcHV0dGluZyBpdCBpbiB0aGUgc3BlYyBk aXJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgeWV0IHRvIHNlZSBhbnkgcmVhbCBkaXNjdXNz aW9uIG9uIHVzaW5nIGJpZ2dlciBoYXNoZXMgZm9yIHNpZ25pbmcgY2VydGlmaWNhdGVzLCBvciBj cmVhdGluZyB0aHVtYnByaW50cyBpbiBvdGhlciBwbGFjZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sm9obiBC LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCBBcHIgMTksIDIwMTggYXQgMToyMyBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9 Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T2theSwgc28gSSByZXRyYWN0IHRoZSBpZGVh IG9mIG1ldGFkYXRhIGluZGljYXRpbmcgdGhlDQo8c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMyMTMw MTYxNDc0Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4NjFtLTQ2ODA5OTU5ODY1NTI1MTM0MDdtODMy ODE3MzYzNTIzNzEwNjY3Mm02MTY0MzMwODA4ODczOTIyNzQxbS00MDI3ODg5MDM0Mjg0MjA1NjI5 bS00MTM5NTc3NTU2NDQ0NjM3MDI4Z21haWwtaW0iPg0KaGFzaCBhbGcvY25mIG1ldGhvZCAoYmFz ZWQgb24gSm9obiBwb2ludGluZyBvdXQgdGhhdCBpdCBkb2Vzbid0IHJlYWxseSBtYWtlIHNlbnNl KS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMyMTMw MTYxNDc0Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4NjFtLTQ2ODA5OTU5ODY1NTI1MTM0MDdtODMy ODE3MzYzNTIzNzEwNjY3Mm02MTY0MzMwODA4ODczOTIyNzQxbS00MDI3ODg5MDM0Mjg0MjA1NjI5 bS00MTM5NTc3NTU2NDQ0NjM3MDI4Z21haWwtaW0iPlRoYXQgc3RpbGwgbGVhdmVzIHRoZSBxdWVz dGlvbiBvZg0KIHdoZXRoZXIgb3Igbm90IHRvIGRlZmluZSBhZGRpdGlvbmFsIDwvc3Bhbj48c3Bh biBjbGFzcz0ibS01NDM5Njk5MjMyMTMwMTYxNDc0Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4NjFt LTQ2ODA5OTU5ODY1NTI1MTM0MDdtODMyODE3MzYzNTIzNzEwNjY3Mm02MTY0MzMwODA4ODczOTIy NzQxZ21haWwtbS00MDI3ODg5MDM0Mjg0MjA1NjI5bS00MTM5NTc3NTU2NDQ0NjM3MDI4Z21haWwt aW0iPmNvbmZpcm1hdGlvbjwvc3Bhbj48c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMyMTMwMTYxNDc0 Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4NjFtLTQ2ODA5OTU5ODY1NTI1MTM0MDdtODMyODE3MzYz NTIzNzEwNjY3Mm02MTY0MzMwODA4ODczOTIyNzQxbS00MDI3ODg5MDM0Mjg0MjA1NjI5bS00MTM5 NTc3NTU2NDQ0NjM3MDI4Z21haWwtaW0iPg0KIG1ldGhvZHMgaW4gdGhpcyBkb2N1bWVudCAoYW5k IGlmIHNvLCB3aGF0IHRoZXkgd291bGQgYmUgdGhvdWdoIHg1dCNTMzg0IGFuZCA8L3NwYW4+DQo8 c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMyMTMwMTYxNDc0Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4 NjFtLTQ2ODA5OTU5ODY1NTI1MTM0MDdtODMyODE3MzYzNTIzNzEwNjY3Mm02MTY0MzMwODA4ODcz OTIyNzQxZ21haWwtbS00MDI3ODg5MDM0Mjg0MjA1NjI5bS00MTM5NTc3NTU2NDQ0NjM3MDI4Z21h aWwtaW0iPng1dCNTNTEyDQo8L3NwYW4+PHNwYW4gY2xhc3M9Im0tNTQzOTY5OTIzMjEzMDE2MTQ3 NGdtYWlsLW01MDc0OTYzODYzNDA3Mzc5ODYxbS00NjgwOTk1OTg2NTUyNTEzNDA3bTgzMjgxNzM2 MzUyMzcxMDY2NzJtNjE2NDMzMDgwODg3MzkyMjc0MW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0tNDEz OTU3NzU1NjQ0NDYzNzAyOGdtYWlsLWltIj5zZWVtIHRoZSBtb3N0IGxpa2VseSkuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gY2xhc3M9Im0tNTQzOTY5OTIzMjEzMDE2MTQ3NGdtYWls LW01MDc0OTYzODYzNDA3Mzc5ODYxbS00NjgwOTk1OTg2NTUyNTEzNDA3bTgzMjgxNzM2MzUyMzcx MDY2NzJtNjE2NDMzMDgwODg3MzkyMjc0MW0tNDAyNzg4OTAzNDI4NDIwNTYyOW0tNDEzOTU3NzU1 NjQ0NDYzNzAyOGdtYWlsLWltIj5UaGVyZSdzIHNvbWUgcmVhc29uYWJsZSByYXRpb25hbCBmb3IN CiBib3RoIGFkZGluZyBvbmUgb3IgdHdvIDwvc3Bhbj48c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMy MTMwMTYxNDc0Z21haWwtbTUwNzQ5NjM4NjM0MDczNzk4NjFnbWFpbC1tLTQ2ODA5OTU5ODY1NTI1 MTM0MDdtODMyODE3MzYzNTIzNzEwNjY3Mm02MTY0MzMwODA4ODczOTIyNzQxbS00MDI3ODg5MDM0 Mjg0MjA1NjI5bS00MTM5NTc3NTU2NDQ0NjM3MDI4Z21haWwtaW0iPm5ldyBoYXNoIGFsZw0KPC9z cGFuPjxzcGFuIGNsYXNzPSJtLTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tNTA3NDk2Mzg2MzQw NzM3OTg2MW0tNDY4MDk5NTk4NjU1MjUxMzQwN2dtYWlsLW04MzI4MTczNjM1MjM3MTA2NjcybTYx NjQzMzA4MDg4NzM5MjI3NDFnbWFpbC1tLTQwMjc4ODkwMzQyODQyMDU2MjltLTQxMzk1Nzc1NTY0 NDQ2MzcwMjhnbWFpbC1pbSI+Y29uZmlybWF0aW9uPC9zcGFuPjxzcGFuIGNsYXNzPSJtLTU0Mzk2 OTkyMzIxMzAxNjE0NzRnbWFpbC1tNTA3NDk2Mzg2MzQwNzM3OTg2MW0tNDY4MDk5NTk4NjU1MjUx MzQwN2dtYWlsLW04MzI4MTczNjM1MjM3MTA2NjcybTYxNjQzMzA4MDg4NzM5MjI3NDFtLTQwMjc4 ODkwMzQyODQyMDU2MjltLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFpbC1pbSI+DQogbWV0aG9kPC9z cGFuPjxzcGFuIGNsYXNzPSJtLTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tNTA3NDk2Mzg2MzQw NzM3OTg2MW0tNDY4MDk5NTk4NjU1MjUxMzQwN204MzI4MTczNjM1MjM3MTA2NjcybTYxNjQzMzA4 MDg4NzM5MjI3NDFtLTQwMjc4ODkwMzQyODQyMDU2MjltLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFp bC1pbSI+cyBpbiB0aGUgZG9jIG5vdyB2cy4gc3RpY2tpbmcgd2l0aCBqdXN0IFNIQTI1NiBmb3Ig bm93LiBJJ2xsIG5vdGUgYWdhaW4NCiB0aGF0IHRoZSBkb2MgZG9lc24ndCBwcmVjbHVkZSB1c2lu ZyBvciBsYXRlciBkZWZpbmluZyBvdGhlciBjb25maXJtYXRpb24gbWV0aG9kcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJt LTU0Mzk2OTkyMzIxMzAxNjE0NzRnbWFpbC1tNTA3NDk2Mzg2MzQwNzM3OTg2MW0tNDY4MDk5NTk4 NjU1MjUxMzQwN204MzI4MTczNjM1MjM3MTA2NjcybTYxNjQzMzA4MDg4NzM5MjI3NDFtLTQwMjc4 ODkwMzQyODQyMDU2MjltLTQxMzk1Nzc1NTY0NDQ2MzcwMjhnbWFpbC1pbSI+SSdtIGtpbmQgb2Yg b24gdGhlIGZlbmNlIGFib3V0IGl0LCB0byBiZSBob25lc3QuIEJ1dCB0aGF0IGRvZXNuJ3QNCiBy ZWFsbHkgbWF0dGVyIGJlY2F1c2UgdGhlIGRyYWZ0IHNob3VsZCByZWZsZWN0IHJvdWdoIFdHIGNv bnNlbnN1cy4gU28gSSdtIGxvb2tpbmcgdG8gZ2V0IGEgcm91Z2ggZ2F1Z2Ugb2Ygcm91Z2ggY29u c2Vuc3VzLiBBdCB0aGlzIHBvaW50IHRoZXJlJ3Mgb25lIGNvbW1lbnQgb3V0IG9mIFdHTEMgYXNr aW5nIGZvciBhZGRpdGlvbmFsIGNvbmZpcm1hdGlvbiBtZXRob2QocykuIEkgZG9uJ3QgdGhpbmsg dGhhdCBtYWtlcyBmb3IgY29uc2Vuc3VzLiBCdXQNCiBJJ2QgYXNrIG90aGVycyBmcm9tIHRoZSBX RyB0byBjaGltZSBpbiwgaWYgYXBwcm9wcmlhdGUsIHRvIGhlbHAgbWUgYmV0dGVyIGdhdWdlIGNv bnNlbnN1cy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMTMsIDIwMTggYXQgNDo0OSBBTSwgTmVp bCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIiB0 YXJnZXQ9Il9ibGFuayI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5v dCBwYXJ0aWN1bGFybHkgd2VkZGVkIHRvIFNIQS01MTIsIGp1c3QgdGhhdCBpdCBzaG91bGQgYmUg cG9zc2libGUgdG8gdXNlIHNvbWV0aGluZyBlbHNlLiBBdCB0aGUgbW9tZW50LCB0aGUgZHJhZnQg c2VlbXMgcHJldHR5IHdlZGRlZCB0byBTSEEtMjU2LiBTSEEtNTEyIG1heSBiZSBvdmVya2lsbCwg YnV0IGl0IGlzIGZhc3QgKGZhc3RlciB0aGFuIFNIQS0yNTYgb24gbWFueSA2NC1iaXQgbWFjaGlu ZXMpDQogYW5kIHByb3ZpZGVzIGEgdmVyeSB3aWRlIHNlY3VyaXR5IG1hcmdpbiBhZ2FpbnN0IGFu eSBmdXR1cmUgY3J5cHRvIGFkdmFuY2VzIChxdWFudHVtIG9yIG90aGVyd2lzZSkuIEnigJlkIGFs c28gYmUgaGFwcHkgd2l0aCBTSEEtMzg0LCBTSEEzLTUxMiwgQmxha2UyIGV0YyBidXQgU0hBLTUx MiBzZWVtcyBwcmV0dHkgd2lkZWx5IGF2YWlsYWJsZS4NCjxicj4NCjxicj4NCkkgZG9u4oCZdCB0 aGluayBzaG9ydC1saXZlZCBhY2Nlc3MgdG9rZW5zIGlzIGEgaGVscCBpZiB0aGUgbGlrZWxpaG9v ZCBpcyB0aGF0IGNlcnRzIHdpbGwgYmUgcmV1c2VkIGZvciBtYW55IGFjY2VzcyB0b2tlbnMuDQo8 YnI+DQo8YnI+DQpQdWJsaWMgV2ViIFBLSSBjZXJ0cyB0ZW5kIHRvIG9ubHkgdXNlIFNIQS0yNTYg YXMgaXQgaGFzIGJyb2FkIHN1cHBvcnQsIGFuZCBJIGdhdGhlciB0aGVyZSB3ZXJlIHNvbWUgY29t cGF0aWJpbGl0eSBpc3N1ZXMgd2l0aCBTSEEtNTEyIGNlcnRzIGluIFRMUy4gVGhlcmUgYXJlIGEg aGFuZGZ1bCBvZiBTSEEtMzg0IGNlcnRzIC0gZS5nLiwgdGhlIENvbW9kbyBDQSBjZXJ0cyBmb3IN CjxhIGhyZWY9Imh0dHBzOi8vaG9tZS5jZXJuLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaG9t ZS5jZXJuLzwvYT4gYXJlIHNpZ25lZCB3aXRoIFNIQS0zODQgKGFsdGhvdWdoIHdpdGggUlNBLTIw NDgsIHdoaWNoIE5TQSBlc3RpbWF0ZXMgYXQgb25seSB+MTEyLWJpdCBzZWN1cml0eSkuIFNIQS01 MTIgaXMgdXNlZCBvbiBzb21lIGludGVybmFsIG5ldHdvcmtzIHdoZXJlIHRoZXJlIGlzIG1vcmUg Y29udHJvbCBvdmVyIGNvbXBvbmVudHMgYmVpbmcNCiB1c2VkLCB3aGljaCBpcyBhbHNvIHdoZXJl IHBlb3BsZSBhcmUgbW9zdGx5IGxpa2VseSB0byBjYXJlIGFib3V0IHNlY3VyaXR5IGJleW9uZCAx MjgtYml0IGxldmVsIChlZyBnb3Zlcm5tZW50IGludGVybmFsIG5ldHdvcmtzKS4NCjxicj4NCjxi cj4NCkJ5IHRoZSB3YXksIEkganVzdCBtZW50aW9uZWQgcXVhbnR1bSBhdHRhY2tzIGFzIGFuIGV4 YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgbWlnaHQgd2Vha2VuIHRoZSBoYXNoIGluIGZ1dHVyZS4g T2J2aW91c2x5LCBxdWFudHVtIGF0dGFja3MgY29tcGxldGVseSBkZXN0cm95IFJTQSwgRUNEU0Eg ZXRjLCBzbyBTSEEtNTEyIHdvdWxkIG5vdCBzb2x2ZSB0aGlzIG9uIGl0cyBvd24sIGJ1dCBpdCBw cm92aWRlcyBhIGNvbnNpZGVyYWJsZSBtYXJnaW4gdG8NCiBoZWRnZSBhZ2FpbnN0IGZ1dHVyZSBx dWFudHVtICpvciBjbGFzc2ljYWwqIGFkdmFuY2VzIHdoaWxlIGFsbG93aW5nIHRoZSBwYXJhbm9p ZCB0byBwaWNrIGEgc3Ryb25nZXIgc2VjdXJpdHkgbGV2ZWwgbm93Li4gV2UgaGF2ZSBjdXN0b21l cnMgdGhhdCBhc2sgZm9yIDI1Ni1iaXQgQUVTIGFscmVhZHkuPGJyPg0KPGJyPg0KKEkgYWxzbyBt aXNyZW1lbWJlcmVkIHRoZSBxdWFudHVtIGF0dGFjayAtIOKAnFNlcmlvdXMgQ3J5cHRvZ3JhcGh5 4oCdIGJ5IEF1bWFzc29uIHRlbGxzIG1lIHRoZSBiZXN0IGtub3duIHF1YW50dW0gYXR0YWNrIGFn YWluc3QgY29sbGlzaW9uIHJlc2lzdGFuY2UgaXMgTygyXm4vMykgLSBzbyB+Ml44NSBmb3IgU0hB LTI1NiBidXQgYWxzbyBuZWVkcyBPKDJeODUpIHNwYWNlIHNvIGlzIGltcHJhY3RpY2FsLiBJIGRv buKAmXQga25vdyBpZiB0aGF0IGlzIHRoZQ0KIGxhc3Qgd29yZCB0aG91Z2gpLiZuYnNwOyA8YnI+ DQo8YnI+DQpBcyBmb3IgU0hBLTEsIGRvZXNu4oCZdCB0aGF0IHByb3ZlIHRoZSBwb2ludD8gU0hB LTEgaXMgcHJldHR5IGJyb2tlbiBub3cgd2l0aCBwcmFjdGljYWwgY29sbGlzaW9ucyBoYXZpbmcg YmVlbiBkZW1vbnN0cmF0ZWQuIFRoZSBraW5kIG9mIGF0dGFja3Mgb24gQ0EgY2VydHMgZGVtb25z dHJhdGVkIGZvciBNRDUgWzFdIGFyZSBwcm9iYWJseSBub3QgdG9vIGZhciBvZmYgZm9yIFNIQS0x IG5vdy4gQXMgZmFyIGFzIEkgYW0gYXdhcmUsIHdl4oCZcmUgbm93aGVyZQ0KIG5lYXIgdGhvc2Ug a2luZHMgb2YgYXR0YWNrcyBvbiBTSEEtMjU2LCBidXQgSeKAmWQgcHJlZmVyIHRoYXQgdGhlcmUg d2FzIGEgYmFja3VwIHBsYW4gaW4gcGxhY2UgYWxyZWFkeSByYXRoZXIgdGhhbiB3YWl0aW5nIHRv IHNlZSAoYW5kIHdhaXRpbmcgZm9yIGV2ZXJ5b25lIHRvIGhhdmUgaGFyZC1jb2RlZCBTSEEtMjU2 IGV2ZXJ5d2hlcmUpLjxicj4NCjxicj4NCk5vdyBJIGhhdmUgdG8gZ2V0IGJhY2sgdG8gbXkgZGF1 Z2h0ZXLigJlzIGJpcnRoZGF5IHBhcnR54oCmIDotKTxicj4NCjxicj4NClsxXSA8YSBocmVmPSJo dHRwOi8vd3d3Lndpbi50dWUubmwvaGFzaGNsYXNoL3JvZ3VlLWNhLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cud2luLnR1ZS5ubC9oYXNoY2xhc2gvcm9ndWUtY2EvPC9hPjxicj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS01NDM5Njk5MjMyMTMw MTYxNDc0aG9lbnpiIj5OZWlsPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQo8YnI+DQpPbiBUaHVyc2RheSwgQXByIDEyLCAyMDE4IGF0IDEwOjA3IHBtLCBKb2huIEJy YWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KVGhlIFdHIGRpc2N1c3Nl cyBSUyBtZXRhLWRhdGEgYXMgcGFydCBvZiBvbmUgb2YgRGlja+KAmXMgcHJvcG9zYWxzLiZuYnNw OyAmbmJzcDtJIGFtIHVuY2xlYXIgb24gd2hvIGlzIGdvaW5nIHRvIHdvcmsgb24gaXQgaW4gd2hh dCBkcmFmdC48YnI+DQo8YnI+DQpJZiB0aGUgY2xpZW50IGlzIGRvaW5nIG10bHMgdG8gYm90aCB0 aGUgVG9rZW4gZW5kcG9pbnQgYW5kIFJTIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgY29uZmlybWF0 aW9uIG1ldGhvZCBpcyBub3QgcmVsZXZhbnQgdG8gdGhlIGNsaWVudCBhcyBsb25nIGFzIHRoZSBB UyBhbmQgUlMgYXJlIGluIGFncmVlbWVudCBsaWtlIHdpdGggbW9zdCB0b2tlbnMuPGJyPg0KPGJy Pg0KVGhlIGhhc2ggb24gdGhlIGNlcnRpZmljYXRlIGFuZCBsZW5ndGggb2YgdGhlIHNpZ25pbmcg a2V5IGFyZSBlcXVhbGx5IG9yIG1vcmUgdnVsbmVyYWJsZSB0byBhbnkgc29ydCBvZiBhdHRhY2su PGJyPg0KQXQgbGVhc3Qgd2l0aCBBVCB0aGUgdG9rZW5zIGFyZSBub3QgbG9uZyBsaXZlZC48YnI+ DQo8YnI+DQpEb2luZyBhbnl0aGluZyBiZXR0ZXIgdGhhbiBTSEEyNTYgb25seSBtYWtlcyBzZW5z ZSBpZiB0aGUgY2VydCBpcyBzaWduZWQgYnkgc29tZXRoaW5nIHN0cm9uZ2VyIGxpa2UgU0hBNTEy IHdpdGggYSAyMDQ4Yml0IFJTQSBrZXkuJm5ic3A7ICZuYnNwO1RoYXQgc2VlbXMgc29ydCBvZiB1 bmxpa2VseSBpbiB0aGUgbmVhciB0ZXJtLiZuYnNwOw0KPGJyPg0KPGJyPg0KSSBwcmVmZXIgdG8g d2FpdCB0byBzZWUgd2hhdCBnZW5lcmFsIGZpeCBpcyBwcm9wb3NlZCBiZWZvcmUgd2UganVtcCB0 aGUgZ3VuIHdpdGggYSBiYW5kYWRlIGZvciBhIHNtYWxsIHBhcnQgb2YgdGhlIG92ZXJhbGwgcHJv YmxlbS48YnI+DQo8YnI+DQpQZW9wbGUgYXJlIHR5cGljYWxseSB1c2luZyBTSEExIGZpbmdlcnBy aW50cy4mbmJzcDsgV2UgYWRkZWQgU0hBMjU2IGZvciBKV1QgYW5kIGdvdCBwdXNoIGJhY2sgb24g dGhhdCBhcyBvdmVya2lsbC4NCjxicj4NCkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHRoZSBjb3Jy ZWN0IHBsYWNlIHRvIGJlIGRlY2lkaW5nIHRoaXMuJm5ic3A7ICZuYnNwOzxicj4NCjxicj4NCldl IGNvdWxkIHNheSB0aGF0IGlmIG5ldyB0aHVtYnByaW50cyBhcmUgZGVmaW5lZCB0aGUgQVMgYW5k IFJTIGNhbiBkZWNpZGUgdG8gdXNlIHRoZW0gYXMgbmVjZXNzYXJ5Ljxicj4NClRoYXQgaXMgc29y dCBvZiB0aGUgc2l0dWF0aW9uIHdlIGhhdmUgbm93Ljxicj4NCjxicj4NClRoZSBjb3JyZWN0IHNv bHV0aW9uIG1heSBiZSBhIHRob3VzYW5kIHJvdW5kcyBvZiBQQktERjIgb3Igc29tZXRoaW5nIGxp a2UgdGhhdCB0byBtYWtlIGZpbmRpbmcgY29sbGlzaW9ucyBtb3JlIGRpZmZpY3VsdCByYXRoZXIg dGhhbiBsb25nZXIgaGFzaGVzLjxicj4NCjxicj4NCkpvaG4gQi48YnI+DQo8YnI+DQomZ3Q7IE9u IEFwciAxMiwgMjAxOCwgYXQgNToyMCBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo YXQncyB0cnVlIGFib3V0IGl0IGJlaW5nIG9wYXF1ZSB0byB0aGUgY2xpZW50LiBJIHdhcyB0aGlu a2luZyBvZiBjbGllbnQgbWV0YWRhdGEgKGNvbmZpZyBvciByZWdpc3RyYXRpb24pIGFzIGEgd2F5 IGZvciB0aGUgQVMgdG8gZGVjaWRlIGlmIHRvIGJpbmQgdGhlIEFUIHRvIGEgY2VydC4gQW5kIG1v dmluZyBmcm9tIGEgYm9vbGVhbiB0byBhIGNvbmYgbWV0aG9kIGFzIGFuIGV4dGVuc2lvbiBvZiB0 aGF0LiBJdCB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwNCiBpbiBSUyBkaXNjb3ZlcnksIGlmIHRo ZXJlIHdhcyBzdWNoIGEgdGhpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9u4oCZdCBrbm93 IHRoYXQgU0hBNTEyIHdvdWxkIGJlIHRoZSBiZXN0IGNob2ljZSBlaXRoZXIgYnV0IGl0IGlzIHNv bWV0aGluZyB0aGF0IGlzIHN0cm9uZ2VyIGFuZCBjb3VsZCBiZSBpbmNsdWRlZCBub3cuIElmIHRo ZXJlJ3MgY29uc2Vuc3VzIHRvIGRvIG1vcmUgdGhhbiBTSEEyNTYgaW4gdGhpcyBkb2MuJm5ic3A7 DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFRodSwgQXBy IDEyLCAyMDE4IGF0IDE6NTIgUE0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IElubGluZTxicj4NCiZndDsgPGJyPg0KJmd0OyBTbmlwPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAxMi4gVGhl IHVzZSBvZiBvbmx5IFNIQS0yNTYgZmluZ2VycHJpbnRzIG1lYW5zIHRoYXQgdGhlIHNlY3VyaXR5 IHN0cmVuZ3RoIG9mIHRoZSBzZW5kZXItY29uc3RyYWluZWQgYWNjZXNzIHRva2VucyBpcyBsaW1p dGVkIGJ5IHRoZSBjb2xsaXNpb24gcmVzaXN0YW5jZSBvZiBTSEEtMjU2IC0gcm91Z2hseSDigJwx MjgtYml0IHNlY3VyaXR5JnF1b3Q7IC0gd2l0aG91dCBhIG5ldyBzcGVjaWZpY2F0aW9uIGZvciBh IG5ldyB0aHVtYnByaW50IGFsZ29yaXRobS4NCiBBbiBpbXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRo YXQgaXMgaXMgZmFpcmx5IHBvaW50bGVzcyBmb3IgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBUTFMg c3RhY2sgdG8gZXZlciBuZWdvdGlhdGUgY2lwaGVyIHN1aXRlcy9rZXlzIHdpdGggYSBoaWdoZXIg bGV2ZWwgb2Ygc2VjdXJpdHkuIEluIG1vcmUgY3J5c3RhbCBiYWxsIHRlcnJpdG9yeSwgaWYgYSBw cmFjdGljYWwgcXVhbnR1bSBjb21wdXRlciBiZWNvbWVzIGEgcG9zc2liaWxpdHkgd2l0aGluIHRo ZQ0KIGxpZmV0aW1lIG9mIHRoaXMgc3BlYywgdGhlbiB0aGUgZXhwZWN0ZWQgY29sbGlzaW9uIHJl c2lzdGFuY2Ugb2YgU0hBLTI1NiB3b3VsZCBkcm9wIHF1YWRyYXRpY2FsbHksIGFsbG93aW5nIGFu IGF0dGFja2VyIHRvIGZpbmQgYSBjb2xsaWRpbmcgY2VydGlmaWNhdGUgaW4gfjJeNjQgZWZmb3J0 LiBJZiB3ZSBhcmUgZ29pbmcgdG8gcGljayBqdXN0IG9uZSB0aHVtYnByaW50IGhhc2ggYWxnb3Jp dGhtLCBJIHdvdWxkIHByZWZlciB3ZSBwaWNrIFNIQS01MTIuPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgVGhlIGlkZWEgYmVoaW5kIGhhdmVpbmcganVzdCBvbmUgdGh1bWJwcmludCBoYXNo IGFsZ29yaXRobSB3YXMgdG8ga2VlcCB0aGluZ3Mgc2ltcGxlLiBBbmQgU0hBLTI1NiBzZWVtcyBn b29kIGVub3VnaCBmb3IgdGhlIHJlYXNvbmFibHkgZm9yZXNlZWFibGUgZnV0dXJlIChhbmQgc3Bh Y2UgYXdhcmUpLiBBbHNvIGEgbmV3IGxpdHRsZSBzcGVjIHRvIHJlZ2lzdGVyIGEgZGlmZmVyZW50 IGhhc2ggYWxnb3JpdGhtLCBzaG91bGQgdGhlIG5lZWQgYXJpc2UsDQogZGlkbid0IHNlZW0gcGFy dGljdWxhcml0eSBvbmVyb3VzLiA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGF0IHdh cyB0aGUgdGhpbmtpbmcgYW55d2F5LiBNYXliZSBpdCBpcyB0b28gc2hvcnQgc2lnaHRlZCB0aG91 Z2g/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBkbyB0aGluayBTSEEtMjU2IHNob3Vs ZCBzdGF5IHJlZ2FyZGxlc3MuIDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEJ1dCB0aGUg ZHJhZnQgY291bGQgYWxzbyBkZWZpbmUgU0hBLTUxMiAoYW5kIG1heWJlIG90aGVycykuIFdoYXQg ZG8geW91IGFuZCBXRyBmb2xrcyB0aGluayBhYm91dCB0aGF0Pzxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7ICoqKiBZZXMgcGxlYXNlLiA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJ dCB3b3VsZCBwcm9iYWJseSB0aGVuIGJlIHVzZWZ1bCBmb3IgdGhlIG1ldGFkYXRhIGluIMKnMy4z IGFuZCDCpzMuNCB0byBjaGFuZ2UgZnJvbSBqdXN0IGJvb2xlYW4gdmFsdWVzIHRvIHNvbWV0aGlu ZyB0byBjb252ZXkgd2hhdCBoYXNoIGFsZy9jbmYgbWV0aG9kIHRoZSBjbGllbnQgZXhwZWN0cyBh bmQgdGhlIGxpc3Qgb2Ygd2hhdCB0aGUgc2VydmVyIHN1cHBvcnRzLiBUaGF0J3MgbWF5YmUgc29t ZXRoaW5nIHRoYXQgc2hvdWxkIGJlIGRvbmUNCiBhbnl3YXkuIFRoYXQnZCBiZSBhIGJyZWFraW5n IGNoYW5nZSB0byB0aGUgbWV0YWRhdGEuIEJ1dCB0aGVyZSdzIGFscmVhZHkgYW5vdGhlciBwb3Rl bnRpYWwgYnJlYWtpbmcgY2hhbmdlIGlkZW50aWZpZWQgZWFybGllciBpbiB0aGlzIG1lc3NhZ2Uu IFNvIG1heWJlIGl0J3Mgd29ydGggZG9pbmcuLi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyBIb3cgZG8gZm9sa3MgZmVlbCBhYm91dCBtYWtpbmcgdGhpcyBraW5kIG9mIGNoYW5nZT8gPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyBUaGUgY29uZmlybWF0aW9uIG1l dGhvZCBpcyBvcGFxdWUgdG8gdGhlIGNsaWVudC4mbmJzcDsgSSBkb27igJl0IHRoaW5rIGFkZGlu ZyBoYXNoIGFsZ3MgdG8gZGlzY292ZXJ5IHdpbGwgcmVhbGx5IGhlbHAuPGJyPg0KJmd0OyBUaGUg QVMgc2VsZWN0aW9uIG5lZWRzIHRvIGJlIGJhc2VkIG9uIHdoYXQgdGhlIFJTIGNhbiBzdXBwb3J0 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBhbnlwbGFjZSBpdCBzaG91bGQgYmUgaW4gUlMgZGlz Y292ZXJ5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgYSBwcmFjdGljYWwgbWF0dGVyIHlvdSBh cnQgZ29pbmcgdG8gZmluZCBhIGNsaWVudCBjZXJ0aWZpY2F0ZSB3aXRoIG1vcmUgdGhhbiBhIFNI QTI1NiBoYXNoIGFueXRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLg0KPGJyPg0KJmd0OyBTbyBmb3Ig YSBzaG9ydCBsaXZlZCBhY2Nlc3MgdG9rZW4gMTI4Yml0cyBvZiBjb2xsaXNpb24gcmVzaXN0YW5j ZSBpcyBxdWl0ZSBnb29kLiZuYnNwOyAmbmJzcDtXZSBhcmUgZ29pbmcgdG8gaGF2ZSBpc3N1ZXMg d2l0aCBjZXJ0aWZpY2F0ZXMgbG9uZyBiZWZvcmUgdGhpcyBiZWNvbWVzIGEgcHJvYmxlbS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgU0hBMjU2IGlzIGFwcHJvcHJpYXRlIGZvciBBRVMxMjggMjU2Yml0 IGVsbGlwdGljIGN1cnZlcyBhbmQgMzA3MmJpdCBSU0Ega2V5cywgYnV0IGFnYWluIHRoYXQgaXMg b3ZlciB0aGUgbG9uZyB0ZXJtLiZuYnNwOw0KPGJyPg0KJmd0OyBXZSBhcmUgdXNpbmcgc2hvcnQg bGl2ZWQgYWNjZXNzIHRva2Vucy4mbmJzcDsgUGVvcGxlIHNob3VsZCByb3RhdGUgdGhlIGNlcnRp ZmljYXRlIG1vcmUgb2Z0ZW4gdGhhbiBvbmNlIGEgeWVhciBpZiB0aGlzIGlzIGEgcmVhbCBpc3N1 ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhbSBub3QgYWdhaW5zdCBuZXcgaGFzaCBmb3IgdGhl IGZpbmdlcnByaW50LCBidXQgSSBhbHNvIGRvbuKAmXQga25vdyB0aGF0IFNIQTUxMiB3b3VsZCBi ZSB0aGUgYmVzdCBjaG9pY2UgaWYgd2UgYXJlIGNvbmNlcm5lZCBhYm91dCBxdWFudHVtIGNyeXB0 byByZXNpc3RhbmNlLiZuYnNwOyAmbmJzcDtUaGF0IGlzIGEgaXNzdWUgYmV5b25kIG10bHMgYW5k IHNob3VsZCBiZSBhZGRyZXNzZWQgYnkgQ0ZSRyBldGMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJl Z2FyZHM8YnI+DQomZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Is DQogcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+ Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Ns b3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW2PR00MB0298114EFC7165151F5514A9F5820MW2PR00MB0298namp_-- From nobody Mon Apr 30 08:57:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6E31241F5 for ; Mon, 30 Apr 2018 08:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv--qWky8T14 for ; Mon, 30 Apr 2018 08:57:49 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8163812DB6C for ; Mon, 30 Apr 2018 08:57:49 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t11so14044546wmt.0 for ; Mon, 30 Apr 2018 08:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUaFTREPTvCFficYbzpQlnFNgpZou9w828VUHrcl2DY=; b=G4X792VZLTAOx/6/Z1UcSAglGQF2HjjTYive0AoSy/iF7I/UobU1eoBZwovGgUHoqY vlFUmvC1kNdsmM08XdVHb9Hn69wnT4YTI+FP976/Pfi2tbFko7bt5Kx2bDKxOQCEUx8v 5UsXJGzU0BX43l8afUguomcGfBWL3QR/g9NMI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUaFTREPTvCFficYbzpQlnFNgpZou9w828VUHrcl2DY=; b=KzVeDCrrJQ6x5XWpbGfTNgB2/3tE7qE5d0GtqJNX/3nFIltyMIru9npXShTyoaWSum J+IkxREYqt6OfAAGo8+gcpLxWp4GJhoyLJ69KN5bPeqyKKmpR+lReb2Qrh1ANqEDRCoi a9YFv8xGhq0vjI3Mhr3vx7Py1F6P0qGjT9NLndN1IwqARG8KJM5NovDhn/NCQOOg8/T+ VmqYjv93lhXW/3dzOScCe1Hs5q1fLpFBi4uvGO+PjyIBxEIIrzS0WzD4UkPUWch9uOZr AwkTf/8A1aRHlrj6dvSQuIQiB2JyeaDoB1+T5E+Bd1awDMgFAY1jCpjLg9wFQfD8Vf5A cClQ== X-Gm-Message-State: ALQs6tCz0EAwv1KhL2HghOaV09ZAPVV4kq9IqqRiuQKIAz7ZOwY8QKTL CQ3DZ7xG37k4vcOJEbSoJlvjaw== X-Google-Smtp-Source: AB8JxZqfJR8hCOEplv/x+H6zLO+RWWQwsbPG0n1oci5015IWRsL60LnX3LIlmcRt4ocgjRodeHX8Jw== X-Received: by 10.28.147.83 with SMTP id v80mr7723974wmd.91.1525103867934; Mon, 30 Apr 2018 08:57:47 -0700 (PDT) Received: from guest2s-mbp.home (72.142.200.146.dyn.plus.net. [146.200.142.72]) by smtp.gmail.com with ESMTPSA id 135sm8420592wmx.21.2018.04.30.08.57.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 08:57:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Neil Madden In-Reply-To: Date: Mon, 30 Apr 2018 16:57:45 +0100 Cc: Brian Campbell , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> To: John Bradley X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:57:53 -0000 Hi John, > On 30 Apr 2018, at 15:07, John Bradley wrote: >=20 > I lean towards letting new certificate thumbprints be defined = someplace else. >=20 > With SHA256, it is really second preimage resistance that we care = about for a certificate thumbprint, rather than simple collision = resistance. =20 That=E2=80=99s not true if you consider a malicious client. If I can = find any pair of certificates c1 and c2 such that SHA256(c1) =3D=3D = SHA256(c2) then I can present c1 to the AS when I request an access = token and later present c2 to the protected resource when I use it. I = don=E2=80=99t know if there is an actual practical attack based on this, = but a successful attack would violate the security goal implied by the = draft: that that requests made to the protected resource "MUST be made = [=E2=80=A6] using the same certificate that was used for mutual TLS at = the token endpoint.=E2=80=9D NB: this is obviously easier if the client gets to choose its own = client_id, as it can find the colliding certificates and then sign up = with whatever subject ended up in c1. >=20 > MD5 failed quite badly with chosen prefix collision attacks against = certificates (Thanks to some X.509 extensions). > SHA1 has also been shown to be vulnerable to a PDF chosen prefix = attack (http://shattered.io) >=20 > The reason NIST pushed for development of SHA3 was concern that a = preimage attack might eventually be found agains the SHA2 family of hash = algorithms.=20 >=20 > While SHA512 may have double the number of bytes it may not help much = against a SHA2 preimage attack,. (Some papers suggest that the double = word size of SHA512 it may be more vulnerable than SHA256 to some = attacks) This is really something where the input of a cryptographer would be = welcome. As far as I am aware, the collision resistance of SHA-256 is = still considered at around the 128-bit level, while it is considered at = around the 256-bit level for SHA-512. Absent a total break of SHA2, it = is likely that SHA-512 will remain at a higher security level than = SHA-256 even if both are weakened by cryptanalytic advances. They are = based on the same algorithm, with different parameters and word/block = sizes. >=20 > It is currently believed that SHA256 has 256 bits of second preimage = strength. That could always turn out to be wrong as SHA2 has some = similarities to SHA1, and yes post quantum that is reduced to 128bits.=20= >=20 > To have a safe future option we would probably want to go with = SHA3-512. However I don=E2=80=99t see that getting much traction in = the near term. =20 SHA3 is also slower than SHA2 in software. >=20 > Practical things people should do run more along the lines of: > 1: Put at least 64 bits of entropy into the certificate serial number = if using self signed or a local CA. Commercial CA need to do that now. > 2: Rotate certificates on a regular basis, using a registered JWKS = URI >=20 > My concern is that people will see a bigger number and decide it is = better if we define it in the spec. =20 > We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly. I=E2=80=99m not sure why this is a concern. As previously pointed out, = SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99= t seem worth worrying about. [snip] =E2=80=94 Neil= From nobody Mon Apr 30 11:44:31 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E2127010 for ; Mon, 30 Apr 2018 11:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_vkEatgMLJG for ; Mon, 30 Apr 2018 11:44:28 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7310812708C for ; Mon, 30 Apr 2018 11:44:27 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id B7F706AEB7 for ; Mon, 30 Apr 2018 12:44:23 -0600 (MDT) Received: from box514.bluehost.com ([74.220.219.114]) by cmsmtp with ESMTP id DDmPfdpPUBTwVDDmPfg1rU; Mon, 30 Apr 2018 12:44:05 -0600 X-Authority-Reason: nr=8 X-Authority-Reason: s=1 Received: from [173.224.162.69] (port=31828 helo=[10.225.93.17]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1fDDmh-002ndW-IF for oauth@ietf.org; Mon, 30 Apr 2018 12:44:23 -0600 References: <84282a24-dd5d-bb86-e5a2-c96327a1f626@KingsMountain.com> To: IETF OAuth WG From: =JeffH X-Forwarded-Message-Id: <84282a24-dd5d-bb86-e5a2-c96327a1f626@KingsMountain.com> Message-ID: <0c2d1ad2-1239-26e0-87c1-9be2bd1e79c4@KingsMountain.com> Date: Mon, 30 Apr 2018 11:44:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <84282a24-dd5d-bb86-e5a2-c96327a1f626@KingsMountain.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1fDDmh-002ndW-IF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.93.17]) [173.224.162.69]:31828 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: no Archived-At: Subject: [OAUTH-WG] reference for invalid point attack [-jwt-bcp] ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 18:44:30 -0000 In search of CurveSwap: Measuring elliptic curve implementations in the wild Luke Valenta, Nick Sullivan, Antonio Sanso, Nadia Heninger https://eprint.iacr.org/2018/298.pdf (see section 7.1) ..is perhaps a suitable reference for section 3.4 of -jwt-bcp ? https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01#section-3.4 HTH, =JeffH From nobody Mon Apr 30 11:44:41 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442A412E046 for ; Mon, 30 Apr 2018 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n9lLgmOCeJl for ; Mon, 30 Apr 2018 11:44:30 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF78127735 for ; Mon, 30 Apr 2018 11:44:28 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id f1-v6so12109419qtj.6 for ; Mon, 30 Apr 2018 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=06nVvJ31WvbPxHmOeeFfP0i5qCzamlM58tRt2+tPBRE=; b=ECSsColxbJVg8C0ynUiQNj3vXUNgFF6FVU9niDEYGzLSq1OlCi4eKkSkF0LSucWItV 2MccQkMB7drESFOmUQbDUz2hnQucfmnaqlWXyeNJq5rJLyxPVADY7vfVbBJG+U7hvR2p JHmNeIJJOEhjQ8M9RLtsovY3HKKsZ8rbmaVkqDbYeIifMgAL+BwQA1gruvpjN8R/6LBg E+dbYLUlFkqlfF192EgTfELj2aJnITVeii5WzNqZXR1J2IVdkx9hBcdTqZWGBYrT89sc OurcPncOLP78jTkglP3gPyY04454RhgY8zSGU4kkZbmWc9VRN8+7B2yfdWXh1i+WmPUN c9WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=06nVvJ31WvbPxHmOeeFfP0i5qCzamlM58tRt2+tPBRE=; b=Ci22+YFrOmH85EgN/5SnG+8L5JcpoD3XPJPaMI4Ql3cQTlJQBSo2dqRvYqNlpFkYqK bJt7Wifnh892UYVjiBf4THqD0sb1N6zP8VZZ/l/mdqqPxbLgLqNZG/FD2Gbjkun2Lk0i Jxsk8/vIl+6XapU0dKEJrFea7VJ6L0YyF3iULZt/uKTitqKS880nPpWg5YpqBaIqL8BF pwSrTm/YnwUis/xLdwPG8/DQce7w07AUm1IHra/cvENzoSHSOBdM/C7f/Sa20tK7Glxj zAfyItXpxDcnz/1ZvaT4xLEnmlUoNlERPCtFzmEvidfWyPDFIgBOch+DTuBxks2WJb+m tULA== X-Gm-Message-State: ALQs6tBmfj1vU568dZLdNy8YOl+X2oqyHiWY6+8k6WbTQPaov0FXgHI6 a1p4MFisJvBV3G9DqYyAEaP7yw== X-Google-Smtp-Source: AB8JxZpJ+VQDpwywFPbnyXDtMIVpLLIJ2X3Pdb5rWDjpUUrNIeIGXG2v5/b9pD813ApF6wtFYHbtgw== X-Received: by 2002:ac8:324b:: with SMTP id y11-v6mr11483387qta.141.1525113866846; Mon, 30 Apr 2018 11:44:26 -0700 (PDT) Received: from johns-mbp-3.lan (ip-6-237-219-201.nextelmovil.cl. [201.219.237.6]) by smtp.gmail.com with ESMTPSA id h29-v6sm6808581qtk.92.2018.04.30.11.44.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 11:44:25 -0700 (PDT) From: John Bradley Message-Id: <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B312903D-0979-406F-8473-21B6B57775BC" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 30 Apr 2018 15:43:05 -0300 In-Reply-To: <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> Cc: Brian Campbell , oauth To: Neil Madden References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 18:44:37 -0000 --Apple-Mail=_B312903D-0979-406F-8473-21B6B57775BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline. > On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: >=20 > Hi John, >=20 >> On 30 Apr 2018, at 15:07, John Bradley > wrote: >>=20 >> I lean towards letting new certificate thumbprints be defined = someplace else. >>=20 >> With SHA256, it is really second preimage resistance that we care = about for a certificate thumbprint, rather than simple collision = resistance. =20 >=20 > That=E2=80=99s not true if you consider a malicious client. If I can = find any pair of certificates c1 and c2 such that SHA256(c1) =3D=3D = SHA256(c2) then I can present c1 to the AS when I request an access = token and later present c2 to the protected resource when I use it. I = don=E2=80=99t know if there is an actual practical attack based on this, = but a successful attack would violate the security goal implied by the = draft: that that requests made to the protected resource "MUST be made = [=E2=80=A6] using the same certificate that was used for mutual TLS at = the token endpoint.=E2=80=9D >=20 > NB: this is obviously easier if the client gets to choose its own = client_id, as it can find the colliding certificates and then sign up = with whatever subject ended up in c1. >=20 Both C1 and C2 need to be valid certificates, so not just any collision = will do. =20 If the client produces C1 and C2 and has the private keys for them, I = have a hard time seeing what advantage it could get by having colliding = certificate hashes. If the AS is trusting a CA, the attacker producing a certificate that = matches the hash of another certificate so that it seems like the fake = certificate was issued by the CA, is an attack that worked on MD5 given = some predictability. That is why we now have entropy requirements for = certificate serial numbers, that reduce known prefix attacks. Second-preimage Resistance is being computationaly infusible to find a = second preimage that has the same output as the first preimage. The = second preimage strength for SHA256 is 201-256bits and collision = resistance strength is 128 bits. See Appendix A of = https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r= 1.pdf = if you want to understand the relationship between message = length and second Preimage resistance. RFC 4270 is old but still has some relevant info. = https://tools.ietf.org/html/rfc4270 = Think of the confirmation method as the out of band integrity check for = the certificate that is presented in the TLS session. >>=20 >> MD5 failed quite badly with chosen prefix collision attacks against = certificates (Thanks to some X.509 extensions). >> SHA1 has also been shown to be vulnerable to a PDF chosen prefix = attack (http://shattered.io ) >>=20 >> The reason NIST pushed for development of SHA3 was concern that a = preimage attack might eventually be found agains the SHA2 family of hash = algorithms.=20 >>=20 >> While SHA512 may have double the number of bytes it may not help much = against a SHA2 preimage attack,. (Some papers suggest that the double = word size of SHA512 it may be more vulnerable than SHA256 to some = attacks) >=20 > This is really something where the input of a cryptographer would be = welcome. As far as I am aware, the collision resistance of SHA-256 is = still considered at around the 128-bit level, while it is considered at = around the 256-bit level for SHA-512. Absent a total break of SHA2, it = is likely that SHA-512 will remain at a higher security level than = SHA-256 even if both are weakened by cryptanalytic advances. They are = based on the same algorithm, with different parameters and word/block = sizes. >=20 SHA512 uses double words and more rounds, true. It also has more rounds = broken by known attacks than SHA256 https://en.wikipedia.org/wiki/SHA-2 = .. So it is slightly more complex = than doubling the output size doubles the strength. >>=20 >> It is currently believed that SHA256 has 256 bits of second preimage = strength. That could always turn out to be wrong as SHA2 has some = similarities to SHA1, and yes post quantum that is reduced to 128bits.=20= >>=20 >> To have a safe future option we would probably want to go with = SHA3-512. However I don=E2=80=99t see that getting much traction in = the near term. =20 >=20 > SHA3 is also slower than SHA2 in software. Yes roughly half the speed in software but generally faster in hardware. = =20 I am not necessarily arguing for SHA3, rather I think this issue is = larger than this spec and selecting alternate hashing algorithms for = security should be separate from this spec. I am for agility, but I don=E2=80=99t want to accidentally have people = doing something that is just theatre. Rotating certificates, and having the lifetime of a certificates = validity is as useful as doubling the hash size.=20 I don=E2=80=99t think the confirmation hash length is the weakest link. John B. >=20 >>=20 >> Practical things people should do run more along the lines of: >> 1: Put at least 64 bits of entropy into the certificate serial number = if using self signed or a local CA. Commercial CA need to do that now. >> 2: Rotate certificates on a regular basis, using a registered JWKS = URI >>=20 >> My concern is that people will see a bigger number and decide it is = better if we define it in the spec. =20 >> We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly. >=20 > I=E2=80=99m not sure why this is a concern. As previously pointed out, = SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99= t seem worth worrying about. >=20 > [snip] >=20 > =E2=80=94 Neil --Apple-Mail=_B312903D-0979-406F-8473-21B6B57775BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Inline.


On Apr 30, 2018, at 12:57 PM, = Neil Madden <neil.madden@forgerock.com> wrote:

Hi = John,

On= 30 Apr 2018, at 15:07, John Bradley <ve7jtb@ve7jtb.com> = wrote:

I lean towards letting new = certificate thumbprints be defined someplace else.

With SHA256, it is really second preimage resistance that we = care about for a certificate thumbprint, rather than simple collision = resistance.  

That=E2=80=99= s not true if you consider a malicious client. If I can find any pair of = certificates c1 and c2 such that SHA256(c1) =3D=3D SHA256(c2) then I can = present c1 to the AS when I request an access token and later present c2 = to the protected resource when I use it. I don=E2=80=99t know if there = is an actual practical attack based on this, but a successful attack = would violate the security goal implied by the draft: that that requests = made to the protected resource "MUST be made [=E2=80=A6] using the same = certificate that was used for mutual TLS at the token endpoint.=E2=80=9D
NB: this is obviously easier if the client = gets to choose its own client_id, as it can find the colliding = certificates and then sign up with whatever subject ended up in c1.


Both C1 and C2 need to be valid certificates, so not = just any collision will do.  
If the client = produces C1 and C2 and has the private keys for them, I have a hard time = seeing what advantage it could get by having colliding certificate = hashes.

If the = AS is trusting a CA, the attacker producing a certificate that matches = the hash of another certificate so that it seems like the fake = certificate was issued by the CA, is an attack that worked on MD5 given = some predictability.  That is why we now have entropy requirements = for certificate serial numbers, that reduce known prefix = attacks.

Second-preimage Resistance is being computationaly infusible = to find a second preimage that has the same output as the first = preimage.   The second preimage strength for SHA256 is 201-256bits = and collision resistance strength is 128 bits.  See Appendix A = of https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicat= ion800-107r1.pdf if you want to understand the relationship = between message length and second Preimage resistance.

RFC 4270 is old but = still has some relevant info. https://tools.ietf.org/html/rfc4270

Think of the = confirmation method as the out of band integrity check for the = certificate that is presented in the TLS session.



MD5 failed quite badly with chosen prefix = collision attacks against certificates (Thanks to some X.509 = extensions).
SHA1 has also been shown to be vulnerable to = a PDF chosen prefix attack (http://shattered.io)

The = reason NIST pushed for development of SHA3 was concern that a preimage = attack might eventually be found agains the SHA2 family of hash = algorithms.

While SHA512 may have double = the number of bytes it may not help much against a SHA2 preimage = attack,. (Some papers  suggest that the double word size of SHA512 = it may be more vulnerable than SHA256 to some attacks)

This is really something where = the input of a cryptographer would be welcome. As far as I am aware, the = collision resistance of SHA-256 is still considered at around the = 128-bit level, while it is considered at around the 256-bit level for = SHA-512. Absent a total break of SHA2, it is likely that SHA-512 will = remain at a higher security level than SHA-256 even if both are weakened = by cryptanalytic advances. They are based on the same algorithm, with = different parameters and word/block sizes.

SHA512 uses double = words and more rounds, true.  It also has more rounds broken by = known attacks than SHA256 https://en.wikipedia.org/wiki/SHA-2.. So it is slightly = more complex than doubling the output size doubles the = strength.


It is currently believed that SHA256 has 256 bits of second = preimage strength.   That could always turn out to be wrong as = SHA2 has some similarities to SHA1, and yes post quantum that is reduced = to 128bits.

To have a safe future option = we would probably want to go with SHA3-512.   However I = don=E2=80=99t see that getting much traction in the near term.  

SHA3 is also slower than SHA2 in = software.
Yes roughly half the = speed in software but generally faster in hardware.  

I am not necessarily = arguing for SHA3, rather I think this issue is larger than this spec and = selecting alternate hashing algorithms for security should be separate = from this spec.

I am for agility, but I don=E2=80=99t want to accidentally = have people doing something that is just theatre.
Rotating certificates, and having the = lifetime of a certificates validity is as useful as doubling the hash = size. 

I = don=E2=80=99t think the confirmation hash length is the weakest = link.

John = B.



Practical things people should = do run more along the lines of:
1: Put at least 64 bits of = entropy into the certificate serial number if using self signed or a = local CA.  Commercial CA need to do that now.
2: = Rotate certificates on a regular basis,  using a registered JWKS = URI

My concern is that people will see a = bigger number and decide it is better if we define it in the spec. =  
We may be getting people to do additional work and = increasing token size without a good reason by putting it in the spec = directly.

I=E2=80=99m not sure = why this is a concern. As previously pointed out, SHA-512 is often = *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99t seem worth = worrying about.

[snip]

=E2=80=94 Neil

= --Apple-Mail=_B312903D-0979-406F-8473-21B6B57775BC-- From nobody Mon Apr 30 14:20:32 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF7D12D874 for ; Mon, 30 Apr 2018 14:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WxQhmfMkbED for ; Mon, 30 Apr 2018 14:20:29 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D24127275 for ; Mon, 30 Apr 2018 14:20:29 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id r9-v6so11799555iod.6 for ; Mon, 30 Apr 2018 14:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nLM132QxT2We8YL96rwVYkaH9JKdblRzZYqvwZcI+T0=; b=jmAvQDDch3boxK6zBDhKqMt8pjC4Cry8iK2oevgRvdcTZ7Tzvgr/DWHvzxCfd8iF47 8NbWrLh/8z9ccXChQuP1uJb5z1qcZRmlQJ7jkp1qh0aaBg+tAWo+tLAjxMAIT5IBq8Dl lYsSTYjLXEUp2bRXH6EG+f0Laie4XHPWnRw3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nLM132QxT2We8YL96rwVYkaH9JKdblRzZYqvwZcI+T0=; b=Iyyx4KFwDyQ6JVYwDh1+knBvOaEOM8/mRyJsyXknDuRBjitWGlfuJ1fW74DWdkoQ3V J2N7xdkjd/tST+KpyTwUDoR02lLpLmBi0IFKqT+m4Lj5TW+MWxvR5Rhzl2C9ddduggwd 6QPYWHxOHBG0FVCRJhzS9g6RFXw7wPtYbbJsoKXSuKDmA8vrjsGKUXhNor3erptIaN// +SFR9Mz6N8o03aPNhur4h4xOCHIE8hGyg4Hx+PxfRWDogXfq6TU1VWvPz38bb7jQ6GKM Un26MJ0KPAHQtnBjmyfXEr76Fma+Yqw7k8n6ZhJl1UoeebjGnMUg72Qb2jvu4sY8CipY OISg== X-Gm-Message-State: ALQs6tA4i4D+ck2j7dBLxXdpOTbv5KYG4+C0+Paujk1T0I62a4ONREkh InsXnKAJM5hLMzl9sbFpByLQ8eLekFcP07DngFd+nFvETHHcJHXUd9h+bq5fEbut6euW7e2nG+p yyUEr7lHcvPL96Q== X-Google-Smtp-Source: AB8JxZq68QTshSLOM94y8Idz4K+B0yC9Tzln8OyOOufieaRnhDIRpR+1SCGi1/1WTIXoxPOS/7aXLduBQIEqGnKXpX0= X-Received: by 2002:a6b:591:: with SMTP id 139-v6mr12831321iof.282.1525123228920; Mon, 30 Apr 2018 14:20:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 14:19:58 -0700 (PDT) In-Reply-To: <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> From: Brian Campbell Date: Mon, 30 Apr 2018 15:19:58 -0600 Message-ID: To: Neil Madden Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="0000000000004c8d08056b176cfa" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 21:20:32 -0000 --0000000000004c8d08056b176cfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden wrote: > > > On 30 Apr 2018, at 15:07, John Bradley wrote: > > > My concern is that people will see a bigger number and decide it is > better if we define it in the spec. > > We may be getting people to do additional work and increasing token siz= e > without a good reason by putting it in the spec directly. > > I=E2=80=99m not sure why this is a concern. As previously pointed out, SH= A-512 is > often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99t seem w= orth > worrying about. > Seems like maybe it's worth noting that with JWT, where size can be a legitimate constraint, those extra bytes end up being base64 encoded twice. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004c8d08056b176cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden <neil.madden@forg= erock.com> wrote:

> On 30 Apr 2018, at 15:07, John Bradley <ve7jtb@ve7jtb.com> wrote:

> My concern is that people will see a bigger number and decide it is be= tter if we define it in the spec.=C2=A0
> We may be getting people to do additional work and increasing token si= ze without a good reason by putting it in the spec directly.

I=E2=80=99m not sure why this is a concern. As previously pointed ou= t, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn=E2= =80=99t seem worth worrying about.

Seems like mayb= e it's worth noting that with JWT, where size can be a legitimate const= raint, those=C2=A0extra bytes end up being base64 encoded twice.=C2=A0
=


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004c8d08056b176cfa-- From nobody Mon Apr 30 15:11:18 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344FF127201 for ; Mon, 30 Apr 2018 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJzRB4dyMPP5 for ; Mon, 30 Apr 2018 15:11:13 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A5A126DED for ; Mon, 30 Apr 2018 15:11:13 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id j42-v6so12766155qtj.12 for ; Mon, 30 Apr 2018 15:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j3Ry+r/1yfo6OZVAUViXSSHeeRv8AnpL2GXQiMhBUDI=; b=WvkFbrh2y7QVZMQFzGADiCFxSi4UsbL/U4k5tUuT+afk6AHkOs8+mUAjbhABIDSkRi Wqk3WE7D9tf29iAukzwp9rV0/7ISCO5DP/6uVeLR13xnvDdweTwnh44ZbgiqXOpyFYzX BAlIYClFl8DvZ3bKyJM7y3Xj4a6BGVXTNDIl1Q1tI1UQqXXWjtcc0s8JOzfYovassuNg D3porVZj26pF6/HI77wXW9/ORE9UdBPAXPzHtZpDrgPs1hnkv+FKhEbMlTFAhlagZKG5 hzyx7zyG9OvZoD4arjY0yiU6OSnTadvp9AFO2gLbCbe0WIxx2pVSt/0OCF8xyZob1FCV lglA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j3Ry+r/1yfo6OZVAUViXSSHeeRv8AnpL2GXQiMhBUDI=; b=PqpY/yeWUfZNM5Go1hryoSv2hzp+mluexXP8TVlLQH0//Dl8TfVij3OMHsY6TALIom OnyO4s31xFQ1Azg99F6gsOFwkOy/NT8UxW7bazkY1jKuAxdxesLo3NzZq5GzNwazcAkr ePy3/w+xkhQK+gvL7bP/Jv0s9ePQcGqvfhrk/JZEd19c9pGyLaULHK+Y2YbUJnhkGPMh EAkPghljKS0aNPGmKhULSTgKnfSoCG5JTA+UfXqecd8h34tywsr8vFakMXBCjNIoPmTt 30IEvf52drblOjcnNAQsdqRjYpHB+nnoma073lo/F3BWficEDOYrua2u4d2Bb8ZDHolr /uQA== X-Gm-Message-State: ALQs6tAqGktwHBkMBKNyozigQxah5tbthBcAvDRCM0mQW7r44tS6dl1k 43rlQqLvzwni8raaKgrVpiFdkQ== X-Google-Smtp-Source: AB8JxZrw4PRTK97spv6rE/lgW/hEneMfofTRA/TfCWFqRJ+TxeZVElBx6ctmW2N3sKd/7l3QeB1zQQ== X-Received: by 2002:ac8:2d6e:: with SMTP id o43-v6mr11579295qta.316.1525126272136; Mon, 30 Apr 2018 15:11:12 -0700 (PDT) Received: from [192.168.8.102] ([181.203.105.125]) by smtp.gmail.com with ESMTPSA id z50-v6sm7278732qtj.74.2018.04.30.15.11.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 15:11:11 -0700 (PDT) From: John Bradley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED8A37F-1CEE-4327-A136-9D602FC40D36" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 30 Apr 2018 19:11:05 -0300 In-Reply-To: Cc: Neil Madden , oauth To: Brian Campbell References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 22:11:16 -0000 --Apple-Mail=_7ED8A37F-1CEE-4327-A136-9D602FC40D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes that is an issue. =20 I think one of the things that kicked this off was a question of will = this make it pointless for people to use algs such as AES GCM256 when it = is perceived that our choice of hash somehow limits overall security to = 128bits. Let me take another run at this. Things like block cyphers need to have long term secrecy. An attacker = may still get value from decrypting something years down the road. =20 Things like signatures typically need to have some non repudiation = property that lasts the useful lifetime of the document. That can be = years or minutes depending on the document.=20 In our case we are providing out of band integrity protection for the = cert. We could include the cert directly but it is allready being sent = as part of TLS. =20 In general the lifetime of the key pair used for access tokens will be = less than the lifetime of the certificate, so it is hard to argue that = we need stronger security than the cert itself. We have a way to rotate keys/certs daily if desired with JWKS and it can = support self signed certificates. The security of this is still limited = by the security of the TLS cert for the JWKS endpoint, but that is = relatively easy to update if there is a need, and alternate certificate = chains become available with security better than SHA256.=20 However currently most if not all CAB forum roots are using SHA256 = hashes with RSA2048 keys (some like RSA still have roots using RSA = 1028bit keys)=20 I am normally the paranoid one in the crowd, but I would rather pick off = some of the other issues that are more likely to go wrong first. =20 We can point out extensibility for future use, but I am not buying us = defining a new thumbprint when the one we have is as strong or stronger = than the other parts of the trust chain. I can see people choosing to use SHA512 having larger messages more = processing as a way to avoid certificate rollover and that would be a = bad tradeoff. John B. > On Apr 30, 2018, at 6:19 PM, Brian Campbell = wrote: >=20 >=20 >=20 > On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden = > wrote: >=20 > > On 30 Apr 2018, at 15:07, John Bradley > wrote: >=20 > > My concern is that people will see a bigger number and decide it is = better if we define it in the spec. =20 > > We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly. >=20 > I=E2=80=99m not sure why this is a concern. As previously pointed out, = SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99= t seem worth worrying about. >=20 > Seems like maybe it's worth noting that with JWT, where size can be a = legitimate constraint, those extra bytes end up being base64 encoded = twice. =20 >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_7ED8A37F-1CEE-4327-A136-9D602FC40D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes = that is an issue.  

I think one of the things that kicked this off was a question = of will this make it pointless for people to use algs such as AES GCM256 = when it is perceived that our choice of hash somehow limits overall = security to 128bits.

Let me take another run at this.

Things like block cyphers need to have = long term secrecy.  An attacker may still get value from decrypting = something years down the road.   

Things like signatures typically need = to have some non repudiation property that lasts the useful lifetime of = the document. That can be years or minutes depending on the = document. 

In our case we are providing out of band integrity protection = for the cert.  We could include the cert directly but it is = allready being sent as part of TLS.  

In general the lifetime of the key pair = used for access tokens will be less than the lifetime of the = certificate, so it is hard to argue that we need stronger security than = the cert itself.

We have a way to rotate keys/certs daily if desired with JWKS = and it can support self signed certificates.  The security of this = is still limited by the security of the TLS cert for the JWKS endpoint, = but that is relatively easy to update if there is a need, and alternate = certificate chains become available with security better than = SHA256. 

However currently most if not all CAB forum roots are using = SHA256 hashes with RSA2048 keys  (some like RSA still have roots = using RSA 1028bit keys) 

I am normally the paranoid one in the = crowd, but I would rather pick off some of the other issues that are = more likely to go wrong first.  

We can point out extensibility for = future use, but I am not buying us defining a new thumbprint when the = one we have is as strong or stronger than the other parts of the trust = chain.

I can = see people choosing to use SHA512 having larger messages more processing = as a way to avoid certificate rollover and that would be a bad = tradeoff.

John = B.



On Apr 30, 2018, at 6:19 PM, = Brian Campbell <bcampbell@pingidentity.com> wrote:



On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden <neil.madden@forgerock.com> = wrote:

> On 30 Apr 2018, at 15:07, John Bradley <ve7jtb@ve7jtb.com> = wrote:

> My concern is that people will see a bigger number and decide it is = better if we define it in the spec. 
> We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly.

I=E2=80=99m not sure why this is a concern. As previously pointed = out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes = doesn=E2=80=99t seem worth worrying about.

Seems like maybe it's worth noting that with = JWT, where size can be a legitimate constraint, those extra bytes = end up being base64 encoded twice. 


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_7ED8A37F-1CEE-4327-A136-9D602FC40D36-- From nobody Mon Apr 30 15:24:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741CC12D965 for ; Mon, 30 Apr 2018 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNct3op_rVb2 for ; Mon, 30 Apr 2018 15:23:59 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AD8127342 for ; Mon, 30 Apr 2018 15:23:59 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id q17-v6so3084393ywg.2 for ; Mon, 30 Apr 2018 15:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YtVu/qYjHqPAXQuHfKDpM1JPg64MEgCML46s3i1ViLY=; b=QegQI6+p4FetNVORl76OI5Et3fwlXHzYO88TL+syr2TlFa82m6KLIqIASF8MS2M2JG QIuit9ZlLIyfprnU+pNZQj3gozGft7bkR4JR4d7DWXZs51AJiZEs116J3/Psx5IFWv/8 C6ZqmUJzQ8hQ7SQ5flAzsRI+aKVpEmE8DA2G0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YtVu/qYjHqPAXQuHfKDpM1JPg64MEgCML46s3i1ViLY=; b=Uf5otqPcOSMn3uxN1QUHIcVz/otAAglM0d4M9tlKQs9RCcfT+yhGx9OQqPEJv7iDP9 NwlGIDpZOM5SwFz1BI8PFjtpTfBbm3IrwK/C0uMRmP40ahb1dDRqT/yxbwkcVYxFX6YG e8pHzzu4x/Psr/kY2ebCAjwJZ6tHmK6UzW102SJ9f862CYUu6EUslJp1fc2uIcoimDbW 2D+1nbsEzXn7ZoUOsSTNJXqaPwJerk06eVFAnoiKn+IvYMfJ3tz8yIMW0WDfQuOG/825 c/H/uJJ74enntde3t1R5pgFf7Q7/jewWSEtA42VGv/8xrih8OVofzEXg4EZ/tgS1NtPD K2PQ== X-Gm-Message-State: ALQs6tDsNI02TlGyN5QvrGJPyqP/I6r54+HShA91+e+Pf9CVn63HmzSD J/4PS2/WnrGgFBr1US0Lzm/RAG4mkIefWJo0oakk/g== X-Google-Smtp-Source: AB8JxZoJUeinihD6la1+T5pgP7UU6ripulg34ARGu7QF9CTBiaMJEbMiC6hoGY+yF/12y8rbIL6HCVTNtM+QEBZKlVI= X-Received: by 2002:a81:7c02:: with SMTP id x2-v6mr7391426ywc.81.1525127038601; Mon, 30 Apr 2018 15:23:58 -0700 (PDT) MIME-Version: 1.0 References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> In-Reply-To: <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> From: Neil Madden Date: Mon, 30 Apr 2018 22:23:48 +0000 Message-ID: To: John Bradley Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000005fa851056b184f61" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 22:24:03 -0000 --0000000000005fa851056b184f61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Responses inline again. On Mon, 30 Apr 2018 at 19:44, John Bradley wrote: > Inline. > > > On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: > > Hi John, > > On 30 Apr 2018, at 15:07, John Bradley wrote: > > I lean towards letting new certificate thumbprints be defined someplace > else. > > With SHA256, it is really second preimage resistance that we care about > for a certificate thumbprint, rather than simple collision resistance. > > > That=E2=80=99s not true if you consider a malicious client. If I can find= any pair > of certificates c1 and c2 such that SHA256(c1) =3D=3D SHA256(c2) then I c= an > present c1 to the AS when I request an access token and later present c2 = to > the protected resource when I use it. I don=E2=80=99t know if there is an= actual > practical attack based on this, but a successful attack would violate the > security goal implied by the draft: that that requests made to the > protected resource "MUST be made [=E2=80=A6] using the same certificate t= hat was > used for mutual TLS at the token endpoint.=E2=80=9D > > NB: this is obviously easier if the client gets to choose its own > client_id, as it can find the colliding certificates and then sign up wit= h > whatever subject ended up in c1. > > > Both C1 and C2 need to be valid certificates, so not just any collision > will do. > That doesn=E2=80=99t help much. There=E2=80=99s still enough you can vary i= n a certificate to generate collisions. If the client produces C1 and C2 and has the private keys for them, I have > a hard time seeing what advantage it could get by having colliding > certificate hashes. > Me too. But if the security goal is proof of possession, then this attack (assuming practical collisions) would break that goal. > If the AS is trusting a CA, the attacker producing a certificate that > matches the hash of another certificate so that it seems like the fake > certificate was issued by the CA, is an attack that worked on MD5 given > some predictability. That is why we now have entropy requirements for > certificate serial numbers, that reduce known prefix attacks. > The draft allows for self-signed certificates. Second-preimage Resistance is being computationaly infusible to find a > second preimage that has the same output as the first preimage. The > second preimage strength for SHA256 is 201-256bits and collision resistan= ce > strength is 128 bits. See Appendix A of > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107= r1.pdf if > you want to understand the relationship between message length and second > Preimage resistance. > > RFC 4270 is old but still has some relevant info. > https://tools.ietf.org/html/rfc4270 > > Think of the confirmation method as the out of band integrity check for > the certificate that is presented in the TLS session. > This is all largely irrelevant. MD5 failed quite badly with chosen prefix collision attacks against > certificates (Thanks to some X.509 extensions). > SHA1 has also been shown to be vulnerable to a PDF chosen prefix attack ( > http://shattered.io) > > The reason NIST pushed for development of SHA3 was concern that a preimag= e > attack might eventually be found agains the SHA2 family of hash algorithm= s. > > While SHA512 may have double the number of bytes it may not help much > against a SHA2 preimage attack,. (Some papers suggest that the double wo= rd > size of SHA512 it may be more vulnerable than SHA256 to some attacks) > > > This is really something where the input of a cryptographer would be > welcome. As far as I am aware, the collision resistance of SHA-256 is sti= ll > considered at around the 128-bit level, while it is considered at around > the 256-bit level for SHA-512. Absent a total break of SHA2, it is likely > that SHA-512 will remain at a higher security level than SHA-256 even if > both are weakened by cryptanalytic advances. They are based on the same > algorithm, with different parameters and word/block sizes. > > SHA512 uses double words and more rounds, true. It also has more rounds > broken by known attacks than SHA256 https://en.wikipedia.org/wiki/SHA-2.. > So it is slightly more complex than doubling the output size doubles the > strength. > SHA-512 also has more rounds (80) than SHA-256 (64), so still has more rounds left to go... > > It is currently believed that SHA256 has 256 bits of second preimage > strength. That could always turn out to be wrong as SHA2 has some > similarities to SHA1, and yes post quantum that is reduced to 128bits. > > To have a safe future option we would probably want to go with SHA3-512. > However I don=E2=80=99t see that getting much traction in the near term= . > > > SHA3 is also slower than SHA2 in software. > > Yes roughly half the speed in software but generally faster in hardware. > > I am not necessarily arguing for SHA3, rather I think this issue is large= r > than this spec and selecting alternate hashing algorithms for security > should be separate from this spec. > > I am for agility, but I don=E2=80=99t want to accidentally have people do= ing > something that is just theatre. > > Rotating certificates, and having the lifetime of a certificates validity > is as useful as doubling the hash size. > Why not allow both? > I don=E2=80=99t think the confirmation hash length is the weakest link. > Shouldn=E2=80=99t we allow all the parts to be as strong as possible? > John B. > > > > Practical things people should do run more along the lines of: > 1: Put at least 64 bits of entropy into the certificate serial number if > using self signed or a local CA. Commercial CA need to do that now. > 2: Rotate certificates on a regular basis, using a registered JWKS URI > > My concern is that people will see a bigger number and decide it is bette= r > if we define it in the spec. > We may be getting people to do additional work and increasing token size > without a good reason by putting it in the spec directly. > > > I=E2=80=99m not sure why this is a concern. As previously pointed out, SH= A-512 is > often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99t seem w= orth > worrying about. > > [snip] > > =E2=80=94 Neil > > =E2=80=94 Neil > --0000000000005fa851056b184f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses inline again.=C2=A0

<= div dir=3D"auto">On Mon, 30 Apr 2018 at 19:44, John Bradley <ve7jtb@ve7jtb.com> wrote= :
Inline.


On Apr 30, 2018, at 12:57 PM, Neil Madden <neil.madden@forgerock.co= m> wrote:

Hi John,

On 30 Apr 2018, at 15:07, John Bradley <ve7jtb@ve7jtb.com> wrote:

I lea= n towards letting new certificate thumbprints be defined someplace else.
With SHA256, it is really second preimage resistance that we care abou= t for a certificate thumbprint, rather than simple collision resistance. = =C2=A0

That=E2=80=99s not true if you consider a malici= ous client. If I can find any pair of certificates c1 and c2 such that SHA2= 56(c1) =3D=3D SHA256(c2) then I can present c1 to the AS when I request an = access token and later present c2 to the protected resource when I use it. = I don=E2=80=99t know if there is an actual practical attack based on this, = but a successful attack would violate the security goal implied by the draf= t: that that requests made to the protected resource "MUST be made [= =E2=80=A6] using the same certificate that was used for mutual TLS at the t= oken endpoint.=E2=80=9D

NB: this is obviously easier if the client g= ets to choose its own client_id, as it can find the colliding certificates = and then sign up with whatever subject ended up in c1.

<= /blockquote>

Both C1 and C2 need to be valid ce= rtificates, so not just any collision will do. =C2=A0

That doesn=E2=80=99t help much. Th= ere=E2=80=99s still enough you can vary in a certificate to generate collis= ions.=C2=A0

If the client prod= uces C1 and C2 and has the private keys for them, I have a hard time seeing= what advantage it could get by having colliding certificate hashes.
<= /div>

Me too. But if the = security goal is proof of possession, then this attack (assuming practical = collisions) would break that goal.=C2=A0


If the AS is trusting a CA, the attacker producing a c= ertificate that matches the hash of another certificate so that it seems li= ke the fake certificate was issued by the CA, is an attack that worked on M= D5 given some predictability.=C2=A0 That is why we now have entropy require= ments for certificate serial numbers, that reduce known prefix attacks.

The draft allows for self-signed certificates.=C2=A0

Second-preimage Resistance is being com= putationaly infusible to find a second preimage that has the same output as= the first preimage. =C2=A0 The second preimage strength for SHA256 is 201-= 256bits and collision resistance strength is 128 bits.=C2=A0 See Appendix A= of=C2=A0https://nvlpubs.nist.gov/nistpu= bs/Legacy/SP/nistspecialpublication800-107r1.pdf=C2=A0if you want to un= derstand the relationship between message length and second Preimage resist= ance.

RFC 4270 is old but still has some relevant = info.=C2=A0https://tools.ietf.org/html/rfc4270

Think of= the confirmation method as the out of band integrity check for the certifi= cate that is presented in the TLS session.

This is all largely irrel= evant.=C2=A0

MD5 failed quite badl= y with chosen prefix collision attacks against certificates (Thanks to some= X.509 extensions).
SHA1 has also been shown to be vulnerable to a PDF c= hosen prefix attack (htt= p://shattered.io)

The reason NIST pushed for development of SHA3= was concern that a preimage attack might eventually be found agains the SH= A2 family of hash algorithms.

While SHA512 may have double the numb= er of bytes it may not help much against a SHA2 preimage attack,. (Some pap= ers =C2=A0suggest that the double word size of SHA512 it may be more vulner= able than SHA256 to some attacks)

This is really someth= ing where the input of a cryptographer would be welcome. As far as I am awa= re, the collision resistance of SHA-256 is still considered at around the 1= 28-bit level, while it is considered at around the 256-bit level for SHA-51= 2. Absent a total break of SHA2, it is likely that SHA-512 will remain at a= higher security level than SHA-256 even if both are weakened by cryptanaly= tic advances. They are based on the same algorithm, with different paramete= rs and word/block sizes.

=
SHA512 uses double words and more rounds, true.=C2=A0 It also has more rou= nds broken by known attacks than SHA256=C2=A0https://en.wikipedia.org/wiki/SHA-2= .. So it is slightly more complex than doubling the output size doubles the= strength.

=
SHA-512 also has more rounds (80) than SHA-256 (64)= , so still has more rounds left to go...

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=

It is currently believed that SHA25= 6 has 256 bits of second preimage strength. =C2=A0=C2=A0That could always t= urn out to be wrong as SHA2 has some similarities to SHA1, and yes post qua= ntum that is reduced to 128bits.

To have a safe future option we wo= uld probably want to go with SHA3-512. =C2=A0=C2=A0However I don=E2=80=99t = see that getting much traction in the near term. =C2=A0
SHA3 is also slower than SHA2 in software.
Yes roughly half the speed in software but generally faster in h= ardware. =C2=A0

I am not necessarily arguing for S= HA3, rather I think this issue is larger than this spec and selecting alter= nate hashing algorithms for security should be separate from this spec.

I am for agility, but I don=E2=80=99t want to acciden= tally have people doing something that is just theatre.

Rotating certificates, and having the lifetime of a certificates vali= dity is as useful as doubling the hash size.=C2=A0
<= /blockquote>

Why not allow bot= h?=C2=A0


I don=E2=80=99t think the confirmation hash length is the w= eakest link.

Shouldn=E2=80=99t we allow all the parts to be as stron= g as possible?

=

John B.



Practical things people should do run mo= re along the lines of:
1: Put at least 64 bits of entropy into the certi= ficate serial number if using self signed or a local CA.=C2=A0 Commercial C= A need to do that now.
2: Rotate certificates on a regular basis, =C2=A0= using a registered JWKS URI

My concern is that people will see a big= ger number and decide it is better if we define it in the spec. =C2=A0
W= e may be getting people to do additional work and increasing token size wit= hout a good reason by putting it in the spec directly.

= I=E2=80=99m not sure why this is a concern. As previously pointed out, SHA-= 512 is often *faster* than SHA-256, and an extra 32 bytes doesn=E2=80=99t s= eem worth worrying about.

[snip]

=E2=80=94 Neil
=E2=80=94 Neil
--0000000000005fa851056b184f61-- From nobody Mon Apr 30 15:58:54 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B171E1275AB for ; Mon, 30 Apr 2018 15:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSJg4KyRcbwp for ; Mon, 30 Apr 2018 15:58:49 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC1D1274D2 for ; Mon, 30 Apr 2018 15:58:48 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id h2-v6so12904814qtp.7 for ; Mon, 30 Apr 2018 15:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ksBXmRexTtFo9PRG4+fOmw/wap6jdpxcLfuwcEkcnvA=; b=lACGt9Ge0hr7MK/VpbF1o9WUiqvGiBYxoUZOam9JcH1KYmarAbMbjShyM7tsTHiERP 3x6cHBL9c/3Osv0LZLdmq2iXoQSmR+T/2I7iZ7ncfZxm0VlsjOWqhezPThVJhwMpgUn9 UrbblmQbIjB9GYuxTR9/viVYZ/nkZaUo1fHPi6kNrVwONWglxtNGWAjoLncUUtHnH/Fi btzh87iVS6ZSA2ARx6K1ODs0Pg9Ko71oPVOaxiBaGHB2ekY5czEogtDzH8AKHW7kQxPD RhTUAjbTf+/oJoLvTg4ECV0IjFFA3Ood8vaXs9dcHedylUbsisGBdkuX5artFP6WBbxA fzqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ksBXmRexTtFo9PRG4+fOmw/wap6jdpxcLfuwcEkcnvA=; b=cXoXh4dxFUREeU11sen5Cj7o37/ybZHcK7XOBDeOnu1t99+g19VI03sRvYpJst9+XJ vXnMyTleOsb+6xJhzo7G9KY0mseEvbZMo5+fddkwWXXM+ncwyS9mIVEcuI7+GpsyR/ht GMbqFzjPE7Hv/c9bvUOoZ5x270fdMPhdy6h7G5gL4KVz8dzU5exONWVMnjKHdnrbX2Gq dUqIk7ufXRfbcmSgyOYImEb5K95IPyIdHXsyq2yBZD7CIA/bjrcn8E5YDMSH28tsqVhT NiFgTPvdSu258W0cwYFHDcuxn/LlN1/mvCqpYJXjU4FvrF1PojLvCwa6ITZ5CoW8q17s QKAQ== X-Gm-Message-State: ALQs6tCedK+ZfpMSO/IB3jdluYQYTTDhjzERLruuiczJakrmY37AHBhB pjNR0B7/RiGUQuWAlwXCyHdgXw== X-Google-Smtp-Source: AB8JxZqe6/Xlm+Pq79pUjhsmwFJGWqaX9vc1mws1UVOyHri+/nkRgOvkdmGYSRZgP/J+j54UBTFwzw== X-Received: by 2002:a0c:d88f:: with SMTP id q15-v6mr11770944qvj.83.1525129127431; Mon, 30 Apr 2018 15:58:47 -0700 (PDT) Received: from [192.168.8.102] ([181.203.105.125]) by smtp.gmail.com with ESMTPSA id f189sm6366144qkj.31.2018.04.30.15.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 15:58:46 -0700 (PDT) From: John Bradley Message-Id: <2B100423-8427-4E02-BFBE-82FAEF873666@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EC645AAD-66EF-49E1-8501-462946674F8A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 30 Apr 2018 19:58:39 -0300 In-Reply-To: Cc: Brian Campbell , oauth To: Neil Madden References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <5758ae34-1d2d-4946-9190-7a2e2bc184d2@Canary> <9A56706A-5369-4F79-A8BB-74B15C37DFB9@ve7jtb.com> <29445085-003F-45D4-A9E2-E23EFEE5A885@ve7jtb.com> <327DA0FA-96E4-4ECF-A7FF-AF6384B4D164@forgerock.com> <67CFD0C0-B5D9-4C85-BC53-87C582E93448@forgerock.com> <22823827-5743-4458-8C30-F5F386839630@ve7jtb.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 22:58:53 -0000 --Apple-Mail=_EC645AAD-66EF-49E1-8501-462946674F8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We allow for new thumbprint algorithms to be defined and used with this = spec. I think that we all agree that is a good thing. The question is if we should define them here or as part of JWT/CWT = based on broader demand. Including them in this document may be a distraction in my opinion. = There is no attack against SHA256 with a short duration token/key (days) = that is better solved by using a long duration token/key (years) with a = longer hash. That said it woiulden't like me. I just think it will distract people = in the wrong direction. John B. > On Apr 30, 2018, at 7:23 PM, Neil Madden = wrote: >=20 > Responses inline again.=20 >=20 > On Mon, 30 Apr 2018 at 19:44, John Bradley > wrote: > Inline. >=20 >=20 >> On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: >>=20 >> Hi John, >>=20 >>> On 30 Apr 2018, at 15:07, John Bradley > wrote: >>>=20 >>> I lean towards letting new certificate thumbprints be defined = someplace else. >>>=20 >>> With SHA256, it is really second preimage resistance that we care = about for a certificate thumbprint, rather than simple collision = resistance. =20 >>=20 >> That=E2=80=99s not true if you consider a malicious client. If I can = find any pair of certificates c1 and c2 such that SHA256(c1) =3D=3D = SHA256(c2) then I can present c1 to the AS when I request an access = token and later present c2 to the protected resource when I use it. I = don=E2=80=99t know if there is an actual practical attack based on this, = but a successful attack would violate the security goal implied by the = draft: that that requests made to the protected resource "MUST be made = [=E2=80=A6] using the same certificate that was used for mutual TLS at = the token endpoint.=E2=80=9D >>=20 >> NB: this is obviously easier if the client gets to choose its own = client_id, as it can find the colliding certificates and then sign up = with whatever subject ended up in c1. >>=20 >=20 > Both C1 and C2 need to be valid certificates, so not just any = collision will do. =20 >=20 > That doesn=E2=80=99t help much. There=E2=80=99s still enough you can = vary in a certificate to generate collisions.=20 >=20 > If the client produces C1 and C2 and has the private keys for them, I = have a hard time seeing what advantage it could get by having colliding = certificate hashes. >=20 > Me too. But if the security goal is proof of possession, then this = attack (assuming practical collisions) would break that goal.=20 >=20 >=20 > If the AS is trusting a CA, the attacker producing a certificate that = matches the hash of another certificate so that it seems like the fake = certificate was issued by the CA, is an attack that worked on MD5 given = some predictability. That is why we now have entropy requirements for = certificate serial numbers, that reduce known prefix attacks. >=20 > The draft allows for self-signed certificates.=20 >=20 > Second-preimage Resistance is being computationaly infusible to find a = second preimage that has the same output as the first preimage. The = second preimage strength for SHA256 is 201-256bits and collision = resistance strength is 128 bits. See Appendix A of = https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r= 1.pdf = if you want to understand the relationship between message = length and second Preimage resistance. >=20 > RFC 4270 is old but still has some relevant info. = https://tools.ietf.org/html/rfc4270 = >=20 > Think of the confirmation method as the out of band integrity check = for the certificate that is presented in the TLS session. >=20 > This is all largely irrelevant.=20 >=20 >>> MD5 failed quite badly with chosen prefix collision attacks against = certificates (Thanks to some X.509 extensions). >>> SHA1 has also been shown to be vulnerable to a PDF chosen prefix = attack (http://shattered.io ) >>>=20 >>> The reason NIST pushed for development of SHA3 was concern that a = preimage attack might eventually be found agains the SHA2 family of hash = algorithms.=20 >>>=20 >>> While SHA512 may have double the number of bytes it may not help = much against a SHA2 preimage attack,. (Some papers suggest that the = double word size of SHA512 it may be more vulnerable than SHA256 to some = attacks) >>=20 >> This is really something where the input of a cryptographer would be = welcome. As far as I am aware, the collision resistance of SHA-256 is = still considered at around the 128-bit level, while it is considered at = around the 256-bit level for SHA-512. Absent a total break of SHA2, it = is likely that SHA-512 will remain at a higher security level than = SHA-256 even if both are weakened by cryptanalytic advances. They are = based on the same algorithm, with different parameters and word/block = sizes. >>=20 >=20 > SHA512 uses double words and more rounds, true. It also has more = rounds broken by known attacks than SHA256 = https://en.wikipedia.org/wiki/SHA-2 = .. So it is slightly more complex = than doubling the output size doubles the strength. >=20 > SHA-512 also has more rounds (80) than SHA-256 (64), so still has more = rounds left to go... >=20 >=20 >>>=20 >>> It is currently believed that SHA256 has 256 bits of second preimage = strength. That could always turn out to be wrong as SHA2 has some = similarities to SHA1, and yes post quantum that is reduced to 128bits.=20= >>>=20 >>> To have a safe future option we would probably want to go with = SHA3-512. However I don=E2=80=99t see that getting much traction in = the near term. =20 >>=20 >> SHA3 is also slower than SHA2 in software. >=20 > Yes roughly half the speed in software but generally faster in = hardware. =20 >=20 > I am not necessarily arguing for SHA3, rather I think this issue is = larger than this spec and selecting alternate hashing algorithms for = security should be separate from this spec. >=20 > I am for agility, but I don=E2=80=99t want to accidentally have people = doing something that is just theatre. >=20 > Rotating certificates, and having the lifetime of a certificates = validity is as useful as doubling the hash size.=20 >=20 > Why not allow both?=20 >=20 >=20 > I don=E2=80=99t think the confirmation hash length is the weakest = link. >=20 > Shouldn=E2=80=99t we allow all the parts to be as strong as possible? >=20 >=20 > John B. >=20 >>=20 >>>=20 >>> Practical things people should do run more along the lines of: >>> 1: Put at least 64 bits of entropy into the certificate serial = number if using self signed or a local CA. Commercial CA need to do = that now. >>> 2: Rotate certificates on a regular basis, using a registered JWKS = URI >>>=20 >>> My concern is that people will see a bigger number and decide it is = better if we define it in the spec. =20 >>> We may be getting people to do additional work and increasing token = size without a good reason by putting it in the spec directly. >>=20 >> I=E2=80=99m not sure why this is a concern. As previously pointed = out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes = doesn=E2=80=99t seem worth worrying about. >>=20 >> [snip] >>=20 >> =E2=80=94 Neil > =E2=80=94 Neil --Apple-Mail=_EC645AAD-66EF-49E1-8501-462946674F8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = allow for new thumbprint algorithms to be defined and used with this = spec.
I think that we all agree that is a good = thing.

The = question is if we should define them here or as part of JWT/CWT based on = broader demand.

Including them in this document may be a distraction in my = opinion.   There is no attack against SHA256 with a short duration = token/key (days) that is better solved by using a long duration = token/key (years) with a longer hash.

That said it woiulden't like me. =  I just think it will distract people in the wrong = direction.

John = B.

On Apr 30, 2018, at 7:23 PM, = Neil Madden <neil.madden@forgerock.com> wrote:

Responses inline = again. 

On Mon, 30 Apr 2018 = at 19:44, John Bradley <ve7jtb@ve7jtb.com> wrote:
Inline.


On Apr 30, 2018, at 12:57 PM, Neil Madden = <neil.madden@forgerock.com> wrote:

Hi John,

On 30 Apr 2018, at = 15:07, John Bradley <ve7jtb@ve7jtb.com> wrote:

I lean towards letting new certificate = thumbprints be defined someplace else.

With = SHA256, it is really second preimage resistance that we care about for a = certificate thumbprint, rather than simple collision resistance. =  

That=E2=80=99s not true = if you consider a malicious client. If I can find any pair of = certificates c1 and c2 such that SHA256(c1) =3D=3D SHA256(c2) then I can = present c1 to the AS when I request an access token and later present c2 = to the protected resource when I use it. I don=E2=80=99t know if there = is an actual practical attack based on this, but a successful attack = would violate the security goal implied by the draft: that that requests = made to the protected resource "MUST be made [=E2=80=A6] using the same = certificate that was used for mutual TLS at the token endpoint.=E2=80=9D
NB: this is obviously easier if the client = gets to choose its own client_id, as it can find the colliding = certificates and then sign up with whatever subject ended up in c1.


Both C1 and C2 need to be = valid certificates, so not just any collision will do. =  

That = doesn=E2=80=99t help much. There=E2=80=99s still enough you can vary in = a certificate to generate collisions. 

If the client produces C1 and C2 and has the private keys for = them, I have a hard time seeing what advantage it could get by having = colliding certificate hashes.

Me = too. But if the security goal is proof of possession, then this attack = (assuming practical collisions) would break that = goal. 


If the AS is trusting a CA, the = attacker producing a certificate that matches the hash of another = certificate so that it seems like the fake certificate was issued by the = CA, is an attack that worked on MD5 given some predictability.  = That is why we now have entropy requirements for certificate serial = numbers, that reduce known prefix = attacks.

The draft = allows for self-signed certificates. 

Second-preimage Resistance is being computationaly infusible = to find a second preimage that has the same output as the first = preimage.   The second preimage strength for SHA256 is 201-256bits = and collision resistance strength is 128 bits.  See Appendix A = of https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicat= ion800-107r1.pdf if you want to understand the relationship = between message length and second Preimage resistance.

RFC 4270 is old but = still has some relevant info. https://tools.ietf.org/html/rfc4270

Think of the = confirmation method as the out of band integrity check for the = certificate that is presented in the TLS = session.

This is all = largely irrelevant. 

MD5 failed quite badly with chosen prefix = collision attacks against certificates (Thanks to some X.509 = extensions).
SHA1 has also been shown to be vulnerable to = a PDF chosen prefix attack (http://shattered.io)

The reason NIST pushed for development of SHA3 was concern = that a preimage attack might eventually be found agains the SHA2 family = of hash algorithms. 

While SHA512 may have double the number of = bytes it may not help much against a SHA2 preimage attack,. (Some papers =  suggest that the double word size of SHA512 it may be more = vulnerable than SHA256 to some attacks)

This is really something where the input of a cryptographer = would be welcome. As far as I am aware, the collision resistance of = SHA-256 is still considered at around the 128-bit level, while it is = considered at around the 256-bit level for SHA-512. Absent a total break = of SHA2, it is likely that SHA-512 will remain at a higher security = level than SHA-256 even if both are weakened by cryptanalytic advances. = They are based on the same algorithm, with different parameters and = word/block sizes.

SHA512 uses double words and more rounds, true.  It also = has more rounds broken by known attacks than SHA256 https://en.wikipedia.org/wiki/SHA-2.. So it is slightly = more complex than doubling the output size doubles the = strength.

SHA-512 = also has more rounds (80) than SHA-256 (64), so still has more rounds = left to go...



It is currently believed that = SHA256 has 256 bits of second preimage strength.   That could = always turn out to be wrong as SHA2 has some similarities to SHA1, and = yes post quantum that is reduced to 128bits. 

To have a safe future option we would probably want to go = with SHA3-512.   However I don=E2=80=99t see that getting much = traction in the near term.  

SHA3 is also slower than SHA2 in software.
Yes = roughly half the speed in software but generally faster in hardware. =  

I am = not necessarily arguing for SHA3, rather I think this issue is larger = than this spec and selecting alternate hashing algorithms for security = should be separate from this spec.

I am for agility, but I don=E2=80=99t = want to accidentally have people doing something that is just = theatre.

Rotating certificates, and having the lifetime of a = certificates validity is as useful as doubling the hash = size. 

Why not = allow both? 


I don=E2=80=99t think = the confirmation hash length is the weakest = link.
Shouldn=E2=80=99t we = allow all the parts to be as strong as possible?


John= B.


Practical things people should do run more along the lines = of:
1: Put at least 64 bits of entropy into the = certificate serial number if using self signed or a local CA.  = Commercial CA need to do that now.
2: Rotate certificates = on a regular basis,  using a registered JWKS URI

My concern is that people will see a bigger number and decide = it is better if we define it in the spec.  
We may be = getting people to do additional work and increasing token size without a = good reason by putting it in the spec directly.

I=E2=80=99m not sure why this is = a concern. As previously pointed out, SHA-512 is often *faster* than = SHA-256, and an extra 32 bytes doesn=E2=80=99t seem worth worrying = about.

[snip]

=E2=80=94 Neil
=E2=80=94 = Neil

= --Apple-Mail=_EC645AAD-66EF-49E1-8501-462946674F8A--
All,

We= would like to get a confirmation on the mailing list for the=C2=A0adoption=C2=A0of the=C2=A0<= b>OAuth 2.0 Incremental Authorization=C2=A0as a WG document
<= /div>

Please, let us know if you support or object to the=C2=A0<= /span>adoption= =C2=A0of this document.

Regards,
=C2=A0Rifaat &a= mp; Hannes

--f403045f8a3c47aa960569f84d76-- From nobody Mon Apr 16 08:19:18 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A26C127863 for ; Mon, 16 Apr 2018 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VaB9a-ViG8S for ; Mon, 16 Apr 2018 08:19:13 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0074.outbound.protection.outlook.com [104.47.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939D91242F5 for ; Mon, 16 Apr 2018 08:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Cl4xWwIYZEuKnKK96HV7E7/84ozLDTwk6G2NDfz//Y=; b=qf+Z5kubChQSiocyG5NMW5s9SlNIsU8zwWJ6rCn9pFNSVOATNH9HXXkCKqdOksoh4rw/VE+zFuMQzwalxa5v8cwvV09Xn5W2sPF51+E5f8qSEsKpuHBkYakZbYOkemFbFW8XQnlG7EgwkRPiCDJ8i2xVfxy7G75hzHPH2TLXFhI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1789.eurprd08.prod.outlook.com (10.168.67.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.10; Mon, 16 Apr 2018 15:19:10 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Mon, 16 Apr 2018 15:19:10 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Call for Adoption: Reciprocal OAuth Thread-Index: AdPVliIpUkS52HyWSzy33HhEMmhw2w== Date: Mon, 16 Apr 2018 15:19:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.122.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1789; 7:Ieh9ffviEYUUxC9QIDHl9GeFfdaGUHWyKWrl/Pg++Y7aUkxTZb9m2MjrRoHJ5GIcT1QjWS+62QabNEDAyW6gL5+Ebu6QhJdVEzNuoP5isjd4WPOu5gH4iupqd3xb4MKuTx3EknsBFgoNTQyVYHVvUXM4OOlB6wYk6ToVWtkJwQ8jpl/sq+H8te3NDA1CYVxVwJrnyP5kD+30BlVt7kA69iEOOl5hbg1sNE0S1g7fTY3ylh9HdC12Q2R/fCz0pS5d x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1789; x-ms-traffictypediagnostic: VI1PR0801MB1789: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231232)(944501327)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1789; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1789; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(346002)(39380400002)(53754006)(189003)(199004)(40434004)(102836004)(26005)(2900100001)(7696005)(6506007)(5250100002)(106356001)(2906002)(476003)(478600001)(68736007)(186003)(25786009)(3660700001)(105586002)(3280700002)(3846002)(6116002)(486006)(86362001)(97736004)(316002)(9686003)(33656002)(966005)(6306002)(6436002)(66066001)(72206003)(53936002)(6916009)(74316002)(55016002)(81156014)(81166006)(8676002)(59450400001)(5890100001)(8936002)(5660300001)(305945005)(14454004)(7736002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1789; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IQ3xEG/8UYv+ATO6GR1POhOnPzFEIqfP2KFY4ZVKx44cpNKczDcT2RtP3f2dw0aw5qy273qjI3WBbQ1a4F8HvOzcpxK5d+S7cqoxRlrod/i18V6uMVS9tTfsM5G3r1l8Qy+v483i4mzo8RUOyN3LZD1uZyaeuCuzTPksGqs+jHjk6yhFMe3Iy1ujAo8u3Bec spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f59d35c6-12b8-4c1d-6644-08d5a3ad67b1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f59d35c6-12b8-4c1d-6644-08d5a3ad67b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 15:19:10.6360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1789 Archived-At: Subject: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 15:19:16 -0000 Hi all, we had gotten positive feedback from the group on Reciprocal OAuth at the v= irtual interim meeting earlier this year and also at the London IETF meetin= g. We would therefore like to get a final confirmation on the mailing list for= the adoption of the *Reciprocal OAuth* as a WG document https://tools.ietf.org/html/draft-hardt-oauth-mutual-02 Please, let us know if you support or object to the adoption of this docume= nt by April 25th. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Apr 16 08:29:13 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF05F126B7E for ; Mon, 16 Apr 2018 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2x1TQujYmhJ for ; Mon, 16 Apr 2018 08:29:09 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20059.outbound.protection.outlook.com [40.107.2.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837501200F1 for ; Mon, 16 Apr 2018 08:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z8lkY2Vy5nY8f3YP4TpGkYN084wG0I7A6Mp8ddc0To8=; b=Z5FslCOY04BGdQp7OgAIGka5Vhtqo7FWn/9rwaSiWeKcE+I8frjQf3CeduT8C66waZdu1jZILKNpMb/6hRc5RDBl78bJson5JixBlWZ+xDnC6j6Zb0m8H4wfB2lwSrfenYC0WoM4/scqiOrcwVVKm74rNKlGb8FknqIFhV1CdDM= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1902.eurprd08.prod.outlook.com (10.173.73.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Mon, 16 Apr 2018 15:29:07 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Mon, 16 Apr 2018 15:29:06 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Virtual Office Hours Thread-Index: AdPVlsucOQv81oWSR0mo7aVbojYPcQ== Date: Mon, 16 Apr 2018 15:29:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1902; 7:kyrqxxYV01akSPeExFARe8bSvQWKtE2Oq7N9SKOJeKNtX9Vh8JF8EXi+5CgwOn5H6mIWiY9dZuWF3nI3P3426F3wJSTLp21cw/PdiGoUXi68avFk1ZReIC83fwDFEHkpGCtjttRP0OuYPzDdbaDndGGPFtLosf5ye9az33LFJiVltodWyobnyMvfgVvBfBB2XUUXO2DEp0SEtYpozqHKe/2wZiqBeVNFrp0BzYjszH7MBPpeD36JxolMDpx3mJCE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1902; x-ms-traffictypediagnostic: VI1PR0801MB1902: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB1902; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1902; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(376002)(39380400002)(40434004)(53754006)(199004)(189003)(106356001)(476003)(186003)(53936002)(7696005)(5250100002)(5890100001)(3280700002)(102836004)(6506007)(14454004)(68736007)(6916009)(486006)(97736004)(26005)(105586002)(316002)(305945005)(9686003)(59450400001)(25786009)(3846002)(74316002)(72206003)(5660300001)(7116003)(6436002)(478600001)(2906002)(99286004)(2900100001)(3660700001)(66066001)(8676002)(55016002)(7736002)(86362001)(6116002)(8936002)(81156014)(81166006)(3480700004)(33656002)(14444003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1902; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: wh2Zty+V2Ye6laNqCCtTJlJU21s5+p66QCn80CqALAJjyhSdSCuLS9p0pdfqE/uYsh7lbtH8SspEiXy+zI3z4lYTPgv65KaehEMgThSaI3XDFdQZywFURjZDhBDzFbu3tNUqBzu5mO87HAxZlx7DrPFbVDNcb/fZGiXG9oPxfHLsAE9XlVCFv7kmrRFKHPFu spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 97c3bc97-ea80-4c53-4ad7-08d5a3aecb14 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97c3bc97-ea80-4c53-4ad7-08d5a3aecb14 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 15:29:06.8909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1902 Archived-At: Subject: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 15:29:12 -0000 Hi all, Rifaat and I had the idea to offer folks the possibility to discuss current= issues with us on a regular basis. Starting with Monday, May 7th we will d= ial into a conference bridge at 8:30 PDT and stay on the bridge for 1 hour.= Everyone who has something to discuss with us can join and we will help as= much as we can. We will do this twice per month. There is obviously no obligation for anyone to join. If nobody joins then R= ifaat and I will use the time to sync-up among ourselves. Conference bridge= details will follow. We hope you find this useful. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Apr 16 10:49:34 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771CC12D878 for ; Mon, 16 Apr 2018 10:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo638_3ax2jY for ; Mon, 16 Apr 2018 10:49:30 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on062a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F388127909 for ; Mon, 16 Apr 2018 10:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J1pcLq0afEVWqPxTA0mpbH6zeVhdvVz2B+HrfRu8Rg8=; b=LkBk/Sjepx2OPLkWUoUIY3diJjxgb6RgK9roiegAo71MFerQq0fan0YqawgK6cIqBbWMSKhPa+xUEl0mxUjkHgUdiLC9DLhhn24IA1lR7+zhWIcbblbekmjDBLmhRX5zDZbjgyV0CCqtEusXKS4OB5upsFXhM2J3xS84gTDkkH8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1743.eurprd08.prod.outlook.com (10.168.67.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.11; Mon, 16 Apr 2018 17:49:25 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0675.015; Mon, 16 Apr 2018 17:49:25 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Working Group Last Call: JSON Web Token Best Current Practices Thread-Index: AdPVqurCFfBabyqeSkmiBPeLsGrqow== Date: Mon, 16 Apr 2018 17:49:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1743; 7:O1FHCw2vbwbe4Iz0U7d/9YEW7Way0Rsakp00Rl95EP+S7ELJcKdfTqrWQVeqHRqhfft3HYqV7wxaoA1Uvwz9c9iqcbAzjlVx7cdTCwmI1xL3ZRYhpTP1cdGfZUBwy9aui68ffEldPhmDdgltgbuP9ljCbNdR+ZbEidZt6kt+rYVmJF4aCWhIBO+NMwp0rSpyAm+hkKNc9cmlMk9zBZ0iso4CPak/reQtrj77/pshSzHBc8m1y5OZum/7lWl3zsaU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1743; x-ms-traffictypediagnostic: VI1PR0801MB1743: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1743; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1743; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(396003)(346002)(366004)(376002)(40434004)(189003)(199004)(53754006)(7736002)(106356001)(99286004)(8936002)(81166006)(81156014)(66066001)(316002)(68736007)(8676002)(476003)(33656002)(3660700001)(55016002)(486006)(14454004)(6306002)(186003)(2906002)(6436002)(72206003)(9686003)(3280700002)(53936002)(7696005)(6116002)(3846002)(105586002)(25786009)(6916009)(305945005)(102836004)(97736004)(6506007)(2900100001)(966005)(86362001)(26005)(5660300001)(478600001)(59450400001)(74316002)(5250100002)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1743; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pcs6KXVZPw77TYfv6L4D8z1xg6ISW1mYcO3wwRRga4uLd8u/1mmv0HOCH4F3goUgmD0naCrHW2FZEggOxXDYfdGsoeOjbfFM4mTOYCgmDqf0hBnfKTlNvspz9UpvI5ZQiaQpqtOcAeuRo0TClUDuevpNn3KoBRcvpcJy49ZDEEaPOe5MINmGHroowxEfUV1n spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ac127747-0991-4ab8-aae0-08d5a3c2652b X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac127747-0991-4ab8-aae0-08d5a3c2652b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 17:49:25.7730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1743 Archived-At: Subject: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 17:49:32 -0000 Hi all, this is a last call for comments on https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01 Please have your comments in no later than April 30th. Do remember to send a note in if you have read the document and have no oth= er comments other than "its ready to go" - we need those as much as we need= "I found a problem". Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Apr 16 11:51:11 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54BC126CF6 for ; Mon, 16 Apr 2018 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgMLxGG7ozPA for ; Mon, 16 Apr 2018 11:51:08 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F00126CC4 for ; Mon, 16 Apr 2018 11:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oNhZ81CMBkZ2gBnoONi/maEc8WsF9QNYQmBAmobnLC0=; b=Vracevn0/6ZkQxBH4tqWKH0US76+JaF8jPsk3PvZfqNoy2iAOi+dG1W8ISsmKvukLpoHssWeGEJ++avjNxmh9d9jHEq7HItB0qTmqp6XnA+f7AntmSyIPaErIyBsBup/WlxEIAG7yf/l+apa7UWdsyaEoXNXpPJJFiWXsOXmv74= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (2603:10b6:4:9e::34) by DM5PR00MB0358.namprd00.prod.outlook.com (2603:10b6:4:9f::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.726.0; Mon, 16 Apr 2018 18:51:06 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::ed7b:97ba:3e6f:29fd]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::ed7b:97ba:3e6f:29fd%4]) with mapi id 15.20.0727.000; Mon, 16 Apr 2018 18:51:06 +0000 From: Mike Jones To: Hannes Tschofenig , oauth Thread-Topic: Virtual Office Hours Thread-Index: AdPVlsucOQv81oWSR0mo7aVbojYPcQAHQKiw Date: Mon, 16 Apr 2018 18:51:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.204.119.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0358; 7:KYH8u3E9plJlcvM7jrFe7umCnhMwlymewqmPWqqYlul1hCZNlFymHyZ/gLQmBkyFNRFbfeKQH4NMNOyff0GWGslknJFOGgb6dosr/dxnLups+8iHedGJBA9pCHh7ZMZkIc3XK7BHlLnJxELkpg60a+Y9u/vOc64dbBuk0Z8qZIiaiwrMwd3ZL4HbHUskcEVnv3+xxeZZSb+9jieMjwSmwdu7aNJNU2gS5zrxVbt4c8D4GPVmfxGlpq+HPNM6hkcr; 20:WezIZ7Hf0J8NJm3MHCIs2eYjt/17LBZhY3AeqjkfcYlMki4PC2isTizWEenfNbp0XCvtKvN3hDLS8WboTnFvLjj51nPNTHJOIGoT1HxlKqUVTZ/3r+hc6ug8nfH/9aFT0lp3uf4VzeDfXWpI2e23ulu6Kdf5HhBmupEHZOAow3Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0358; x-ms-traffictypediagnostic: DM5PR00MB0358: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231232)(944501347)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR00MB0358; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0358; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(39860400002)(346002)(396003)(366004)(13464003)(53754006)(199004)(189003)(38314003)(40434004)(6246003)(66066001)(25786009)(5890100001)(2906002)(8990500004)(5250100002)(10090500001)(8936002)(10290500003)(478600001)(966005)(8676002)(72206003)(53936002)(3660700001)(3280700002)(6306002)(99286004)(55016002)(3480700004)(76176011)(7736002)(9686003)(7696005)(52396003)(97736004)(81166006)(68736007)(14454004)(81156014)(86362001)(2900100001)(486006)(6436002)(59450400001)(476003)(74316002)(26005)(229853002)(6506007)(106356001)(186003)(53546011)(86612001)(105586002)(7116003)(305945005)(11346002)(33656002)(5660300001)(446003)(3846002)(110136005)(22452003)(316002)(102836004)(6116002)(14444003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0358; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: D5bWsHScqsAzDqbDyCsvlQodyTyRhqPFQ+GVtmHkldPe8Ebck4qL0PuU5Pk9DI0xvccA34MSbv/YUYFNcEyiL+12AQxptLC5Qq7rkWdRIvHB4HTCpsRLbdrLxs+5aqMvNEzA/RgqNsy9Xx2voVZhemOHdZPNROfMY5lqXhYsV2j+tMvXE+qXYU0iKF3KVYvw spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 89ade725-b4ea-4281-0eb1-08d5a3cb02d3 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89ade725-b4ea-4281-0eb1-08d5a3cb02d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 18:51:06.2627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0358 Archived-At: Subject: Re: [OAUTH-WG] Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:51:11 -0000 Thanks for doing this. Please send a recurring calendar invitation with th= e call-in info. -- Mike -----Original Message----- From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, April 16, 2018 8:29 AM To: oauth Subject: [OAUTH-WG] Virtual Office Hours Hi all, Rifaat and I had the idea to offer folks the possibility to discuss current= issues with us on a regular basis. Starting with Monday, May 7th we will d= ial into a conference bridge at 8:30 PDT and stay on the bridge for 1 hour.= Everyone who has something to discuss with us can join and we will help as= much as we can. We will do this twice per month. There is obviously no obligation for anyone to join. If nobody joins then R= ifaat and I will use the time to sync-up among ourselves. Conference bridge= details will follow. We hope you find this useful. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Apr 16 11:52:10 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF112EA97 for ; Mon, 16 Apr 2018 11:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKe2SswcJD06 for ; Mon, 16 Apr 2018 11:52:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C8B126CC4 for ; Mon, 16 Apr 2018 11:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tbg1uJndrrzuYUs2J7VNmh76rlDPFMkRPDz7IFLQlT4=; b=PlgvkNl7e+Eo0RtTxWvsQSfTT0q0nAkLZzlBhtmTQq8pAa+BBTcWRw/Q84i0cj5kPF3zFdAQ+tZaMI8XjgMxQjp32HueRrwQCKSx55UkUpYhgZGG2ATFw9uAd8RoVFwrSEfDTHiMwgmmp6Oaf4qSd2+4qzW8ZmJRVF2rAMe9Xh8= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (2603:10b6:4:9e::34) by DM5PR00MB0358.namprd00.prod.outlook.com (2603:10b6:4:9f::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.726.0; Mon, 16 Apr 2018 18:52:06 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::ed7b:97ba:3e6f:29fd]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::ed7b:97ba:3e6f:29fd%4]) with mapi id 15.20.0727.000; Mon, 16 Apr 2018 18:52:06 +0000 From: Mike Jones To: Hannes Tschofenig , oauth Thread-Topic: Working Group Last Call: JSON Web Token Best Current Practices Thread-Index: AdPVqurCFfBabyqeSkmiBPeLsGrqowACQ8Ag Date: Mon, 16 Apr 2018 18:52:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.204.119.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0358; 7:JUjWAly+Lfxfr9t+myufb571irayzK+bful9HfVR5ZWc88xe2FroJ0vVzWRkYrduCND7bcA/V/+oQz+KLT28OkvCIe7//Z+urDPzzzrPEnx2lKeAnRNK7zXc3eLafIAqmtG5mgUaUq+MGXTu4T1ThxpQNlmutlUMguu/Q858nbghIsWfhHeydUIubrTMYEFC7+wB7WayZp+XKOXX/rgPtMB7wxtsqPm/6RTCHpwrYMqOOvDMie86S+0FaojFBysf; 20:KCVu8JtMSGn+J2nJejv5u0ASM751JrSz9wQBqnQXq2ZFLjQB3oEnRcc5YVAYLXjkiXwdG2yukWobdzB4VMXipd8mb1cj99/z4burzr7Y0oApipN4cXM8bfc9MzCN7SPD4XaSaoqcMhLhP47fWOuEl+J7ViWRoC4zsultK9XRu7E= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0358; x-ms-traffictypediagnostic: DM5PR00MB0358: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231232)(944501347)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR00MB0358; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0358; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(39860400002)(346002)(396003)(366004)(13464003)(53754006)(199004)(189003)(40434004)(6246003)(66066001)(25786009)(5890100001)(2906002)(8990500004)(5250100002)(10090500001)(8936002)(10290500003)(478600001)(966005)(8676002)(72206003)(53936002)(3660700001)(3280700002)(6306002)(99286004)(55016002)(76176011)(7736002)(9686003)(7696005)(52396003)(97736004)(81166006)(68736007)(14454004)(81156014)(86362001)(2900100001)(486006)(6436002)(59450400001)(476003)(74316002)(26005)(229853002)(6506007)(106356001)(186003)(53546011)(86612001)(105586002)(305945005)(11346002)(33656002)(5660300001)(446003)(3846002)(110136005)(22452003)(316002)(102836004)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0358; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ksf06kXPpuHwy6EY51gpe0IDIPPZQF5ntbiJkyQEivQwSOySQw18GVKVtWu+TZwD1tuCMaDjZqS53tBjGINdahScu/pkMqY6lOR+UfrSNTzKgIYI59HgRQQ1lQsX8SUDUx3ybMZA4nLV/LtCAOMOcD4Vmo1DWhEsmi90taXIWvJeg0i58lcrtes4E1gsxrq3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6b524cd7-92de-45d1-cf79-08d5a3cb2678 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b524cd7-92de-45d1-cf79-08d5a3cb2678 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 18:52:06.0742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0358 Archived-At: Subject: Re: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:52:09 -0000 The JWT BCP spec is ready to publish. -- Mike -----Original Message----- From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, April 16, 2018 10:49 AM To: oauth Subject: [OAUTH-WG] Working Group Last Call: JSON Web Token Best Current Pr= actices Hi all, this is a last call for comments on https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01 Please have your comments in no later than April 30th. Do remember to send a note in if you have read the document and have no oth= er comments other than "its ready to go" - we need those as much as we need= "I found a problem". Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Apr 16 22:11:25 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3D212EA54 for ; Mon, 16 Apr 2018 22:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxAVLzJgHwAD for ; Mon, 16 Apr 2018 22:11:22 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BF7126B6D for ; Mon, 16 Apr 2018 22:11:21 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id t12so4874057pgp.13 for ; Mon, 16 Apr 2018 22:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ht9uNYU8GMQwnshm4HkH8WklURDZDe6QHiHMN/s8TFw=; b=W1ppYIsH3LkbjqJS8vSLMhLESVQ88ezgLNn7or5h0tw9U6qeiO1k268dB26mmISciW xBIr0i6VV5U0zebr1Kfl/WZuz7UYtyqJIyiCIsLjO4cIC7f7IqAE0QZb1EzB9GK6Cgrd +WHVjSegB52VkPvYYZyp9QpJ+iOnvg1JkVnyL7iGcBBJ0sl7eQjqp/5kBBPu0qc4/Ndd oCnMgxOXAQITEyBcM1qk2r/RC/Q2eiVVQJYnQAb0seFEgi1pdoW3RlmSEoFXjT1qAejw 2VAINFkgZ4NuoU1dCynvFfmsNEzfGjM5piZEwPM509kH9cqaNR/RqHwf3k8Q8YuO6kT/ ilRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ht9uNYU8GMQwnshm4HkH8WklURDZDe6QHiHMN/s8TFw=; b=Sp79s9kHiF4IKiQMTrZQXp4rdMOlXx/i+TqqI4lKhD+DIeSS+1s/53nd1qWyIs6NfK 8CN8JooveevQXFNChUUWs4W3rJCFvjfOwaDpMAWkRBGe2H2vWWnHajCH1SX+ZvNlcibg hUaZofvXV+EmDGXyIMlXhRKx8Hn5Z+ZW+otaqsBpMpFFheJlkZQF7tlc1eCxUQiW2UHC RvbyVnQm/ZopyiK6FWlICFND8mNZxhNRlKkgGb5cMmuTCHE7hVEdCI5GrEAMsKfRsEuL PpZgNyhvqreiarnVYaKEvB+5+3wU6GNEj7ZxenjVyFlJSkR7d6HFYRSiQzgiwKgYgaPx jaHQ== X-Gm-Message-State: ALQs6tBUHTC5L6+lrCkW3qrRn6INe/U87PSdKiPPRalWOoYUtr0HdMrr chIA43ANQa6EnJIz7APbyVqNaEBguwpv9scM5gik7w== X-Google-Smtp-Source: AIpwx48PXMBz3vyrgBj/WIv+12eWathQ4QzjKSJIQxpBI9F0bvUICFk5dsDHKwslm6LRAKm1tW9TzRILLEfblCOhxtk= X-Received: by 10.98.155.12 with SMTP id r12mr663228pfd.15.1523941880988; Mon, 16 Apr 2018 22:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.221.20 with HTTP; Mon, 16 Apr 2018 22:11:20 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Tue, 17 Apr 2018 07:11:20 +0200 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c115eae799747056a045ebf" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 05:11:24 -0000 --94eb2c115eae799747056a045ebf Content-Type: text/plain; charset="UTF-8" I support the adoption of *Reciprocal OAuth* as a WG document On Mon, Apr 16, 2018 at 5:19 PM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > we had gotten positive feedback from the group on Reciprocal OAuth at the > virtual interim meeting earlier this year and also at the London IETF > meeting. > > We would therefore like to get a final confirmation on the mailing list > for the adoption of the *Reciprocal OAuth* as a WG document > https://tools.ietf.org/html/draft-hardt-oauth-mutual-02 > > Please, let us know if you support or object to the adoption of this > document by April 25th. > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c115eae799747056a045ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of *Reciprocal OAuth* as a WG docum= ent

On M= on, Apr 16, 2018 at 5:19 PM, Hannes Tschofenig <Hannes.Tschofenig@= arm.com> wrote:
Hi all,

we had gotten positive feedback from the group on Reciprocal OAuth at the v= irtual interim meeting earlier this year and also at the London IETF meetin= g.

We would therefore like to get a final confirmation on the mailing list for= the adoption of the *Reciprocal OAuth* as a WG document
https://tools.ietf.org/html/draft-hardt-= oauth-mutual-02

Please, let us know if you support or object to the adoption of this docume= nt by April 25th.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.

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

--94eb2c115eae799747056a045ebf-- From dave.tonge@moneyhub.com Mon Apr 16 22:33:45 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A012422F for ; Mon, 16 Apr 2018 22:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR0G6XAyr3SK for ; Mon, 16 Apr 2018 22:33:42 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DFC124D6C for ; Mon, 16 Apr 2018 22:33:42 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id m202-v6so8164329lfe.8 for ; Mon, 16 Apr 2018 22:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aof7lwgVOQ67AtEG+f+Fl2HtTa75zOm2dQKT2PDrsuc=; b=Hx0Ve5MFKxK5TXs18YENRlBwLRaNGPpQS+jYhT9CZQ/be5AmuWX4rUZxpfC09l6kSz fqfR2pa+jFENX13P89brqIZUsfnJZXLG1hVSCLWFe9mCb039w0SKl+O6/znslCOIUcNg vu8hKBMYUj0guJinrEL6muD/1N2l+NMC4LbjA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aof7lwgVOQ67AtEG+f+Fl2HtTa75zOm2dQKT2PDrsuc=; b=TNFZ/duuxVPwm6OSGuQbLuy5OyEZlbupj4kKyQYjX/+qPgwDIefZ0rVDPUn329fQIE 8oRNMFdTxGSq/xk4ZWF7sva9d/8usIGIWsRFaNPqDNOVxfLSsu8c8NKTTZVfV//Jg6Q7 L/kU8Dg6MWk6+exfswMRPxAQp4KTUyncFw2Xpx30HT46KnpIIDBOPjbk+FZ/p6ECkXbj 1BU5bUO6l1pvk73Ny9FK24j5dsKCI6W/TU3ye0EuhbBjfDMxflttCgMS5UwEzV6fTAqb xGMdA+CGUHY70zc6RS/nmwhWjI5T8CO01qfxtpHJym3h6Pmro+iQDXm67Y8inIFvaHyV 8jwA== X-Gm-Message-State: ALQs6tCaIDnfzmXdge/LLMKbN0P/bpSpb4H+5B8O28zyCjn01FxwB4wh WRdRz0+GidDotVH+QBHuv2RKcwfnSrIsuvz/7a5WZQ== X-Google-Smtp-Source: AIpwx487VMMMYdp7KH4QAR4YBhhVw6ANWT6kd2leNj+uYqOwNmiN1bDiXVBRDGHfTh02E0ZzHbtwXkHfEblBtEIUaZU= X-Received: by 10.46.118.22 with SMTP id r22mr388745ljc.144.1523943220339; Mon, 16 Apr 2018 22:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e913:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 22:33:19 -0700 (PDT) In-Reply-To: References: From: Dave Tonge Date: Tue, 17 Apr 2018 07:33:19 +0200 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="f4f5e807c0584e82fa056a04ae11" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 05:36:49 -0000 --f4f5e807c0584e82fa056a04ae11 Content-Type: text/plain; charset="UTF-8" I support the adoption of Reciprocal OAuth On 17 April 2018 at 07:11, Samuel Erdtman wrote: > I support the adoption of *Reciprocal OAuth* as a WG document > > On Mon, Apr 16, 2018 at 5:19 PM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > >> Hi all, >> >> we had gotten positive feedback from the group on Reciprocal OAuth at the >> virtual interim meeting earlier this year and also at the London IETF >> meeting. >> >> We would therefore like to get a final confirmation on the mailing list >> for the adoption of the *Reciprocal OAuth* as a WG document >> https://tools.ietf.org/html/draft-hardt-oauth-mutual-02 >> >> Please, let us know if you support or object to the adoption of this >> document by April 25th. >> >> Ciao >> Hannes & Rifaat >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- --f4f5e807c0584e82fa056a04ae11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption of Reciprocal OAuth=C2=A0

On 17 April 2018 at 0= 7:11, Samuel Erdtman <samuel@erdtman.se> wrote:
I support the adoption of *Reciproca= l OAuth* as a WG document
=

On Mon, Apr 16, 2= 018 at 5:19 PM, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; wrote:
Hi all,

we had gotten positive feedback from the group on Reciprocal OAuth at the v= irtual interim meeting earlier this year and also at the London IETF meetin= g.

We would therefore like to get a final confirmation on the mailing list for= the adoption of the *Reciprocal OAuth* as a WG document
https://tools.ietf.org/html/draft-hardt-= oauth-mutual-02

Please, let us know if you support or object to the adoption of this docume= nt by April 25th.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.

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


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




--
=

=