Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id CD3C01A1EFE
 for <oauth@ietfa.amsl.com>; Mon,  1 Dec 2014 07:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001]
 autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id l5jMGb3mcS89 for <oauth@ietfa.amsl.com>;
 Mon,  1 Dec 2014 07:23:28 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 59AFA1A6EE5
 for <oauth@ietf.org>; Mon,  1 Dec 2014 07:22:26 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id l2so14431692wgh.13
 for <oauth@ietf.org>; Mon, 01 Dec 2014 07:22:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:content-type:mime-version:subject:from
 :in-reply-to:date:cc:message-id:references:to;
 bh=XtA+UVhce/pDDgfW1NOw4w8exTDnsI6ZZz2UiK2eMoM=;
 b=MJdnKs5H11cuXCbl2fXd5QyKODmyd54n1UoVyjkY2CgQmJz6e35jsnf60w1HjEI7Gf
 /BlAZ7X6N68Eyz0BqXPzQarq6xkBG8fR1MVQcLTYg6DLRx6M5i7iJXr6DWI5sBXuuEtA
 WhRsah+13x2imjG1SrdoZ4UAiAVOIk5sgNTJSuyAa7YVvvu5UK7ycQlzMjs2TLTe21Tc
 jGoY50QM08a0LEFpOJ/ywDK8HWAV07jiYjjtThgXIdpGJHdKvIbbJWmqWkj6iZTCdAyV
 sRoqLM52t4tv2O99Fe+xzIMqmeJXVku7k1OU+y6OeRGVU93+v9iQHxYg4keGl+Chv2kQ
 L4Ig==
X-Gm-Message-State: ALoCoQl3SEYOxdd1fiyK6w7+aPCirf6tecqUWvzsClrpbxzKlBPyYfS5pFqrvp7cA49f81baBTuv
X-Received: by 10.194.133.66 with SMTP id pa2mr50022866wjb.134.1417447343944; 
 Mon, 01 Dec 2014 07:22:23 -0800 (PST)
Received: from [10.47.81.161] (host217-39-14-209.in-addr.btopenworld.com.
 [217.39.14.209])
 by mx.google.com with ESMTPSA id h14sm28852477wic.8.2014.12.01.07.22.21
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 01 Dec 2014 07:22:22 -0800 (PST)
Content-Type: multipart/signed;
 boundary="Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63";
 protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <547C7C88.1010000@gmx.net>
Date: Mon, 1 Dec 2014 12:21:03 -0300
Message-Id: <99059A3E-9D42-45FB-8DF9-3C33022F92C9@ve7jtb.com>
References: <54739067.3020602@gmx.net>
 <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net>
 <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu>
 <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <547C347C.7070908@gmx.net>
 <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> <547C7C88.1010000@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BNEVZ_3QalBPbrFR0hcMuN2j6qg
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd Review of
 draft-ietf-oauth-dyn-reg-management-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>,
 <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>,
 <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 15:23:39 -0000


--Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Inline
> On Dec 1, 2014, at 11:34 AM, Hannes Tschofenig =
<hannes.tschofenig@gmx.net> wrote:
>=20
> Hi John,
>=20
> thanks for jumping in.
>=20
> On 12/01/2014 01:18 PM, John Bradley wrote:
>> Hannes,
>>=20
>> You seem not to like the idea of client credential rotation.
>=20
> It is not that I do not like it but I would like to accomplish a few
> things with my shepherd review:
>=20
> * Ensure that the document is consistent and that nothing is missing.
> * Double-check whether the design decisions have really been =
understood.
> * Avoid unnecessary complexity.
> * Document design decisions so that the reader also understands them
> rather than having to read through the mailing list achieve.
>=20
>=20
>> This is something we have wrestled with from the very beginning of
>> Connect Dynamic client registration. In the early drafts we re-used
>> the client secret for authentication to the registration/update
>> endpoint.
>=20
> Actually, I would see the client secret and the credential rotation as
> two separate issues.
>=20
They are unless you need the client secret to do the update.  If you do =
that causes problems with using the secret to update the secret.

>>=20
>> That was rejected by developers as too likely to cause unrecoverable
>> errors if transactions fail. eg the server thinks it has rotated the
>> secret, but the client doesn't  correctly get the response. They also
>> found the dual use of client secret confusing.
>=20
> It is always good to hear developer feedback. I guess that feedback =
was
> given in person rather than on the mailing list.
>=20
That happened before the contribution Connect work as a IETF draft and =
is on the Connect mailing list.

>=20
>>=20
>> When we added OAuth protection to registration,  it made sense to use
>> the same mechanism to protect the endpoint for updates. This allowed
>> the client secret rotation to be recoverable if there was a problem.
>=20
> It certainly makes sense to re-use mechanisms.
>=20
>>=20
>> Ultimately we didn't do updates for symmetric client secrets in the
>> Connect version, leaving that for the IETF draft.
>=20
> Interesting. Do you expect to later inherit the work back to the =
OpenID
> Connect?

If there is a RFC that Connect can reference and profile to add the =
additional
configuration attributes that Connect registration has then that would =
be a good outcome in my=20
opinion.   I don't think we have ever intended to have two incomparable =
registration specs.
>=20
>>=20
>> Via registration of a jwks_uri in Dynamic Client registation, server
>> based clients can rotate asymmetric keys. However that doesn't  help
>> native clients at all, given that they can't publish a jwks_uri
>> without some other protocol and credentials to push it to a server
>> (Turtles).
>>=20
>> You ask why have the complexity of key rollover when the client can
>> just re-register (start the protocol flow from the start)
>>=20
>> The answer to that is that many AS use sticky scopes.  If a client_id
>> is granted scope "x" by a user then the user is not re-prompted to
>> authorize scope "x"  again for that client if the client asks for
>> scopes "x" and "y" on a later request.   When the client's
>> access/refresh tokens expire and the user is sent back to the AS for
>> a new code the AS wants to reduce the complexity of the dialogs.=20
>> (Privacy people may argue that people should be re-prompted every
>> time but that is not the current practice)
>=20
> I am not sure whether this has anything to do with the dynamic client
> registration management API.
>=20
> I was not under the assumption that the user would be asked to approve
> interactions with the dynamic client registration management API.

The user is not involved in consenting to the registration.

However if you create a new client_id to rotate the key the user must re =
do all the consents
that they had previously granted as it is a new client from the =
perspective of the AS.

So in that solution to key rollover you do ultimately involve the user,=20=

something that we are trying to avoid.

>=20
>>=20
>> If the client must get a new client_id every time it rotates it's
>> secret, then all of the previous grants are going to get blown away,
>> and it would need to invalidate all it's refresh tokens and start
>> again re authorizing every user.   That is such a scary idea to
>> clients that they would just never volunteer to rotate credentials,
>> servers would also probably never enforce rotation as well as this
>> would be seen as breaking OAuth.
>=20
> I had naively thought that a new protocol run with the dynamic client
> registration protocol would not lead to a new client id when the =
client
> already has one.
>=20
> It turns out, after re-reading the dynamic client registration =
protocol
> document, that the Client Registration Request does not offer a way =
for
> the client to transmit a previously obtained client id to the AS.
> Hence, the AS allocates a new client id (and a new client secret) =
unless
> it has some other unspecified ways to find out whether this is an
> already registered client or not.
>=20
> Because of the way how the dynamic client registration protocol is
> written requires you to introduce another credential, the registration
> access token.

I think one thing that may be confusing people is that we are trying to =
use REST (irony).

Originally updates happened at the registration endpoint using the =
registration access token=20
instead of the initial access token.  Effectively doing what you are =
thinking.

That is still possible if the registration_client_uri returned is the =
same URI at was used to register.

To be REST we create a new resource when a client_id is created and =
perform the update operations on it,
but it is up to the AS how to implement that.=20

I suspect the only real difference is that we are using PUT as it is an =
existing resource rather than POST.


>> Clients needing to have two client_id and secrets to avoid blowing
>> away refresh tokens also adds a lot of complexity to clients and
>> would require a total rewrite.
> I agree that having two client ids and requesting a new client id with
> every new protocol run would be far from ideal.
>=20
>>=20
>> We could somehow migrate grants and refresh tokens over to a new
>> client_id and secret,  however this also seems more complicated for
>> both the client and AS, not really achieving anything more than
>> rotating the secret alone.
>=20
> Sounds certainly complex.
>=20
>>=20
>> So that leaves us with the question of is it necessary to rotate
>> symmetric client secrets in the first place?
>>=20
>> When HTTP basic is used for client authentication the client_secret
>> is a password that is passed in effectively plain text as part of the
>> request.
>>=20
>> There are two issues to consider:
>>=20
>> 1. Brute force attacks,  this can be mitigated by using high entropy
>> passwords (eg 256 bit) however RFC 6749 doesn't  provide any guidance
>> on that point. (I suspect most people based on the examples are using
>> 60-70 bits of entropy)  For low entropy passwords rotation is
>> required(especially since rate limiting may be difficult, yes I do
>> have an attack in mind)
>=20
> We should have given recommendations for the use of the client secret.
> Our fault. But in any case, we are talking about an online attack here
> and doing a brute force attack on a server for the client secret might
> not necessarily be an efficient way to get anywhere.

That depends on how short the secret is and if there is any rate =
limiting.

>=20
>>=20
>> 2. Man in the middle attacks.  SSL encryption is deprecated but I
>> suspect is going to take a while to be turned off on the server side.
>> Mobile clients could loose both there secret and refresh token due to
>> this attack, or other certificate/DNS attacks.   Rotation limits the
>> window that those credentials are good for.  (though in many cases
>> all the damage that could be done can be done in one go)
>=20
> I don't think that any increase of the key length for the client =
secret
> will make any difference here since we are sending the secrets in =
clear
> over the TLS protected channel. If the TLS channel is compromised then
> the attacker will see the keys.

Yes
>=20
>> While I would like to get rid of symmetric key rotation I don't think
>> we can given the current deployment landscape.
>=20
> =46rom the discussion I conclude that the credential rotation is =
needed
> (because of the way how the dynamic client registration is currently
> designed and we don't want to re-design it at this point in time).
>=20
We were told to make registration crate only no updates.  We did that
This spec is how you update.  It is really the same endpoint if you want =
it to be
from an implementation point of view.

John B.

> What would be useful is
> * to explain some of that background in the credential rotation =
section,
> and
> * issue a new draft.
>=20
> I could then go through the document again and see whether I can draw =
a
> state machine to make the interactions a bit clear.
>=20
> Ciao
> Hannes
>=20
>>=20
>> John B.
>>=20
>>> On Dec 1, 2014, at 6:27 AM, Hannes Tschofenig
>>> <hannes.tschofenig@gmx.net> wrote:
>>>=20
>>> Hi Justin,
>>>=20
>>> a few comments inline:
>>>=20
>>> On 11/26/2014 02:32 PM, Justin Richer wrote:
>>>> And by =936790=94 below I obviously mean RFC6749.
>>>>=20
>>>> (Note to self, don=92t write working group emails this early in the
>>>> morning.)
>>>>=20
>>>> =97 Justin
>>>>=20
>>>> On Nov 26, 2014, at 8:31 AM, Justin Richer <jricher@MIT.EDU=20
>>>> <mailto:jricher@MIT.EDU>> wrote:
>>>>=20
>>>>>=20
>>>>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig=20
>>>>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>
>>>>> wrote:
>>>>>=20
>>>>>> Hi Justin,
>>>>>>=20
>>>>>> thanks for your quick response. A few remarks below.
>>>>>>=20
>>>>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote:
>>>>>>> Hannes, thank you for the review. Answers inline.
>>>>>>>=20
>>>>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig=20
>>>>>>> <hannes.tschofenig@gmx.net
>>>>>>> <mailto:hannes.tschofenig@gmx.net>> wrote:
>>>>>>>=20
>>>>>>>> Hi Justin, Mike, John, Maciej,
>>>>>>>>=20
>>>>>>>> as part of my shepherd write-up I carefully read through=20
>>>>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the
>>>>>>>> document is in good shape but I have a few minor
>>>>>>>> clarification questions that should be resolved before
>>>>>>>> the document goes to the IESG.
>>>>>>>>=20
>>>>>>>> In Section 1.4. "Registration Tokens and Client
>>>>>>>> Credentials" you explain the different credential types
>>>>>>>> and I was wondering why you aren't issuing client_secrets
>>>>>>>> to all clients instead of introducing another credential,
>>>>>>>> the registration access token. While you try to explain
>>>>>>>> the reasons those appear somewhat constructed. For
>>>>>>>> example, you say that "not all types of clients have
>>>>>>>> client credentials" but you are the author of the
>>>>>>>> specification and you can essentially decide what to do.
>>>>>>>> The registration access token is essentially the same as
>>>>>>>> the client credential since it is "is uniquely bound to
>>>>>>>> the client identifier".
>>>>>>>>=20
>>>>>>>> I believe we have discussed this issue in the past but I
>>>>>>>> don't remember what the reasoning was. Can you describe
>>>>>>>> what your design rational was (and add it to the
>>>>>>>> document)?
>>>>>>>=20
>>>>>>> That's exactly the question this section is trying to
>>>>>>> answer, and if it can be made clearer then please suggest
>>>>>>> some text that will help that purpose. The rationale for
>>>>>>> the registration access token is very simple: we want to
>>>>>>> have a means to call the management endpoint in a protected
>>>>>>> manner, and treating the management endpoint as an OAuth=20
>>>>>>> Protected Resource makes a lot of sense. RFC6750 gives us
>>>>>>> the means to make an authorized call to an API endpoint, so
>>>>>>> we're re-using that instead of trying to invent some other
>>>>>>> mechanism. Shouldn't we be helping the world get away from
>>>>>>> API passwords?
>>>>>>>=20
>>>>>>> And it's very true that not every client is going to have a
>>>>>>> client secret to use at the token endpoint -- some will
>>>>>>> have no use of one (public and implicit clients) and some
>>>>>>> will be using TLS or asymmetric keys (JWT assertions, for
>>>>>>> instance) or other mechanisms to authenticate that don't
>>>>>>> involve the secret. Instead of forcing these clients to use
>>>>>>> a client secret for one new endpoint, or forcing that=20
>>>>>>> endpoint to potentially support the infinite number of
>>>>>>> client authentication mechanisms, we decided to just use
>>>>>>> OAuth. These are OAuth clients, remember -- they will *all*
>>>>>>> have the ability to send OAuth tokens to a protected
>>>>>>> resource already built in.
>>>>>>>=20
>>>>>>=20
>>>>>> Here is the point I don't quite get: the registration access
>>>>>> token is essentially the same as a client secret. You as a
>>>>>> specification author essentially decides whether clients will
>>>>>> get a client secret or a registration access token. It is
>>>>>> under your control.
>>>>>>=20
>>>>>> To be more specific, here is what you could have done:
>>>>>>=20
>>>>>> C -> S: Client Registration Request C <- S: Client
>>>>>> Information Response (with new client secret)
>>>>>>=20
>>>>>> C -> S: Read or Update Request (with client id/client
>>>>>> secret) C <- S: Client Information Response
>>>>>>=20
>>>>>> Instead, you currently have this exchange:
>>>>>>=20
>>>>>> C -> S: Client Registration Request C <- S: Client
>>>>>> Information Response (with new reg. access token)
>>>>>>=20
>>>>>> C -> S: Read or Update Request (with client id + reg. access
>>>>>> token) C <- S: Client Information Response
>>>>>>=20
>>>>>> Do you see the similarity that I see?
>>>>>=20
>>>>> For clients that use a client secret to authenticate to the
>>>>> token endpoint, your point makes sense, but for clients who
>>>>> would not otherwise have a client secret, it doesn=92t. You end
>>>>> up with a confusing state where you=92re giving somebody a
>>>>> =93client_secret=94 which is defined in 6790 to be used at the
>>>>> token endpoint but then telling them not to use it at the token
>>>>> endpoint (where they use something else or do=92t use it at all)
>>>>> but to use it at this new endpoint instead. Can you see the
>>>>> confusion point here? I think it=92s only going to get worse as
>>>>> we get more clients that use auth mechanisms that don=92t depend
>>>>> on a shared secret (public key, TLS, etc.).
>>>>>=20
>>>>> Instead we=92re giving people an OAuth access token to access a=20
>>>>> protected API, something that OAuth clients ought to know how
>>>>> to do anyway. This mechanism also gives us an opportunity to
>>>>> potentially use the new PoP tokens (once they=92re actually
>>>>> defined) in place of the bearer credential that=92s defined
>>>>> today.
>>>>>=20
>>>=20
>>> I believe I now understand your line of argument.
>>>=20
>>> You are saying that re-using the client secret for this purpose
>>> will confuse developers since the client credential is used in
>>> other places as well.
>>>=20
>>> So, the confusion could then be:
>>>=20
>>> * Client starts the dynamic client registration exchange without a=20=

>>> client secret. * Later than that exchange he gets a client secret,
>>> which is supposed to be used for the dynamic client registration
>>> management only * A developer might think that he can now also use
>>> that client secret with anything else as well where a client secret
>>> can be used.
>>>=20
>>>=20
>>> The questions are now:
>>>=20
>>> a) Is this potential confusion real or just imagined? b) Wouldn't
>>> this be desired behaviour to begin with?
>>>=20
>>> If it is a real concern and if you don=92t' want to have that
>>> behaviour then maybe you want to motivate the design decision in
>>> that direction in Section 1.4.
>>>=20
>>>=20
>>>=20
>>>>>>=20
>>>>>>>>=20
>>>>>>>> In Section 1.4.1. "Credential Rotation" you write:
>>>>>>>>=20
>>>>>>>> " The Authorization Server MAY rotate the client's
>>>>>>>> registration access token and/or client credentials (such
>>>>>>>> as a "client_secret") throughout the lifetime of the
>>>>>>>> client. "
>>>>>>>>=20
>>>>>>>> You might want to add reasons why the authorization
>>>>>>>> server may want to take this step.
>>>>>>>=20
>>>>>>> OK, but there's nothing normative here in my view. It's
>>>>>>> basically up to the auth server to say "well let's make a
>>>>>>> new credential". Can you suggest text that would clarify
>>>>>>> this?
>>>>>>>=20
>>>>>>=20
>>>>>> What about making the spec simpler by not allowing credential
>>>>>> rotation? Rekying is a useful concept under two
>>>>>> circumstances, namely * when they provide a performance
>>>>>> improvement (such as it is the case with session resumption
>>>>>> in TLS where you can do an abbreviated handshake without all
>>>>>> the heavy public key crypto) * when the entrophy of the key
>>>>>> is exhausted, which typically happens if you exceed a number
>>>>>> of data packets sent under a given key. Often this is tied to
>>>>>> the way how freshness is ensured and the need to avoid=20
>>>>>> encrypting data with the same initialization vector/nonce
>>>>>> twice.
>>>>>>=20
>>>>>> Neither of these two cases seem to apply here (IMHO).
>>>>>=20
>>>>>=20
>>>>> Rekeying the client is useful in a whole lot more cases than
>>>>> these two, and most of them boil down to =93Something seems
>>>>> fishy=94. I think if anything we need to eventually figure out
>>>>> how to do *more* secret rotation, including a proactive
>>>>> mechanism started by the client (as Brian has mentioned, among
>>>>> others).
>>>>>=20
>>>=20
>>>=20
>>> The alternative to rekeying (or secret rotation) inside the
>>> dynamic client registration management protocol is to actually
>>> re-start the protocol run from scratch.
>>>=20
>>> To me it is not obvious whether the added complexity for
>>> credential rotation is worth the effort given the alternative.
>>>=20
>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>>>=20
>>>>>>>> There are also a bit too many SHOULDs in the document.
>>>>>>>> Every time you write SHOULD you have to keep in mind to
>>>>>>>> tell the reader what happens in the other case. For
>>>>>>>> example, in Section Section 1.4.1 you write:
>>>>>>>>=20
>>>>>>>> " The registration access token SHOULD be rotated only in
>>>>>>>> response to an update request to the client configuration
>>>>>>>> endpoint, at which point the new registration access
>>>>>>>> token is returned to the client and the old registration
>>>>>>>> access token SHOULD be discarded by both parties. "
>>>>>>>>=20
>>>>>>>> Here the question arises whether you are using the SHOULD
>>>>>>>> to indicate that the authorization server does not always
>>>>>>>> need to rotate the registration access token and if he
>>>>>>>> does then is must only happen in response to an update
>>>>>>>> request or does it indicate that the authorization server
>>>>>>>> could also rotate it in response to other calls?
>>>>>>>=20
>>>>>>> It's more that the server SHOULD NOT throw out a
>>>>>>> registration access token that a client still thinks is
>>>>>>> good without some way to communicate the new token to the
>>>>>>> client. Think of it this way, you've got the token, the
>>>>>>> server decides to chuck it on you -- what do you do? You
>>>>>>> can try calling your READ or UPDATE operations to get the
>>>>>>> new one but no dice, your token is bad. So what we're
>>>>>>> saying here is not to throw out the client's only means of
>>>>>>> finding out if its keys are good anymore.
>>>>>>=20
>>>>>> I think I got confused with the description of the state
>>>>>> management (as described in the document). There is some
>>>>>> fuzziness.
>>>>>>=20
>>>>>> Here I would prefer to have either no rekeying (which would
>>>>>> make the issue go away) or a very deterministic way of
>>>>>> rekeying.
>>>>>>=20
>>>>>> I prefer the former.
>>>>>=20
>>>>> I=92m not a fan of enforcing permanent credentials on the world.
>>>>> And we have the same construct with refresh tokens today, for
>>>>> what it=92s worth.
>>>=20
>>> It is only permanent in the sense of a full dynamic client
>>> registration management protocol run.
>>>=20
>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Also, in the second line one would wonder why the old
>>>>>>>> registration access token isn't mandatorily discarded. If
>>>>>>>> there are good reasons, then tell the reader.
>>>>>>>=20
>>>>>>> We've tried to put requirements on the server discarding
>>>>>>> tokens in the past, but there was significant pushback from
>>>>>>> providers who use non-revocable time-limited tokens. Maybe
>>>>>>> they won't be doing that here, for the reason above.
>>>>>>=20
>>>>>>=20
>>>>>> I wouldn't reflect that in the document. Of course, you can
>>>>>> never be sure that the implementation really discards any
>>>>>> state but for the purpose of the protocol state machine it is
>>>>>> gone.
>>>>>>=20
>>>>>>>=20
>>>>>>>> Furthermore, the text in Section 2.2 seems to contract
>>>>>>>> this statement: " If the authorization server includes a
>>>>>>>> new client secret and/or registration access token in its
>>>>>>>> response, the client MUST immediately discard its
>>>>>>>> previous client secret and/or registration access token.
>>>>>>>> "
>>>>>>>=20
>>>>>>> This is a requirement on the client, not the server, so
>>>>>>> it's not bound by the token lifetime restrictions above.
>>>>>>> We're telling the client to stop using a secret or token
>>>>>>> after it's been given a new one, that's fine.
>>>>>>=20
>>>>>> OK
>>>>>>=20
>>>>>>>=20
>>>>>>>> In Section 2.2 you write: " However, since read
>>>>>>>> operations are intended to be idempotent, the read
>>>>>>>> request itself SHOULD NOT cause changes to the client's
>>>>>>>> registered metadata values. "
>>>>>>>>=20
>>>>>>>> I am wondering whether this SHOULD NOT statement adds a
>>>>>>>> lot of value since you allow the request to change
>>>>>>>> metadata values.
>>>>>>>=20
>>>>>>> I think you're right, since the metadata values might have
>>>>>>> changed through outside forces since the client last read,
>>>>>>> and all the clients need to be able to deal with that. We
>>>>>>> can remove that line.
>>>>>>=20
>>>>>> OK
>>>>>>=20
>>>>>>>=20
>>>>>>>> You also write the security consideration section: " the=20
>>>>>>>> registration access token MAY be rotated when the
>>>>>>>> developer or client does a read or update operation on
>>>>>>>> the client's client configuration endpoint. "
>>>>>>>>=20
>>>>>>>> This means that the content of the registration access
>>>>>>>> token may also change with a read operation.
>>>>>>>=20
>>>>>>> That's correct.
>>>>>>>=20
>>>>>>>> Terminology:
>>>>>>>>=20
>>>>>>>> Sometimes you write "Client Information Response" and
>>>>>>>> sometimes "client information response" The same with
>>>>>>>> "Authorization Server" and "authorization server"
>>>>>>>=20
>>>>>>> They're all supposed to be lower cased, as is the style in
>>>>>>> RFC6749. I tried to bump everything down in a previous edit
>>>>>>> but it looks like I missed some.
>>>>>>>=20
>>>>>>>> Typo:
>>>>>>>>=20
>>>>>>>> " Some values in the response, including the
>>>>>>>> "client_secret" and r"egistration_access_token", MAY be
>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ different from those in the
>>>>>>>> initial registration response. "
>>>>>>>=20
>>>>>>> Thanks, noted!
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> In Section 2.4 "Client Delete Request" you write:
>>>>>>>>=20
>>>>>>>> " The authorization server SHOULD immediately invalidate
>>>>>>>> all existing authorization grants and currently-active
>>>>>>>> tokens associated with this client. "
>>>>>>>>=20
>>>>>>>> Under what circumstances wouldn't the authorization
>>>>>>>> invalidate all grants and active tokens?
>>>>>>>=20
>>>>>>> When it's using a non-revocable stateless token and it
>>>>>>> can't physically do that. Too bad 2119 doesn't have MUST IF
>>>>>>> POSSIBLE or equivalent.
>>>>>>=20
>>>>>> Maybe it would be good to add this information.
>>>>>>=20
>>>>>> It might also be worthwhile whether this notion of a
>>>>>> non-vocable stateless token actually exists in this context
>>>>>> since we are really talking about the same infrastructure
>>>>>> here. This registration management mechanism is really very
>>>>>> central to the authorization server (unlike some other access
>>>>>> token mechanisms where we talk about the resource server,
>>>>>> which may be in a different administrative domain even).
>>>>>=20
>>>>> Why doesn=92t the existing SHOULD cover this?
>>>=20
>>> Because the should does not explain when to revoke the
>>> grants/tokens and when not to do it. You wrote it in this email (in
>>> context of these non-revocable tokens) but how should an
>>> implementer know when he reads through the draft?
>>>=20
>>> The problem is really about assumptions being made that are not=20
>>> explained further. For example, the assumption that there are
>>> tokens that are not revocable and the implications that result from
>>> those on the design of the protocol (potentially at multiple places
>>> in the document).
>>>=20
>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>> You might also want to say what tokens you are talking
>>>>>>>> about since there are at least the following tokens
>>>>>>>> around: - access tokens - refresh tokens - registration
>>>>>>>> access tokens - initial access token
>>>>>>>=20
>>>>>>> OK, we can add that.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> " If the server does not support the delete method, the
>>>>>>>> server MUST respond with an HTTP 405 Not Supported. "
>>>>>>>>=20
>>>>>>>> Why aren't you demanding that the server must support
>>>>>>>> this method? This would essentially mean that there would
>>>>>>>> be some cases where deregistration isn't possible. Of
>>>>>>>> course, there may be the question how important
>>>>>>>> deregistration actually is if the registration=20
>>>>>>>> automatically expires.
>>>>>>>=20
>>>>>>> Because delete is not always an easy operation to
>>>>>>> implement. The client should be able to call the endpoint
>>>>>>> with the DELETE verb and at least know if it's allowed to
>>>>>>> do that or not.
>>>>>>=20
>>>>>> Hmmm. I didn't know that the delete method is difficult to
>>>>>> implement.
>>>>>=20
>>>>> Depends on your infrastructure and how things get propagated
>>>>> between components.
>>>=20
>>> There are a number of unstated assumptions here that would be
>>> worthwhile to point out.
>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> You write: " If the client does not exist on this server,
>>>>>>>> the server MUST respond with HTTP 401 Unauthorized and
>>>>>>>> the registration access token used to make this request
>>>>>>>> SHOULD be immediately revoked. "
>>>>>>>>=20
>>>>>>>> If the client does not exist and someone sends a request
>>>>>>>> with a random registration access token I am not sure
>>>>>>>> what exactly you want to revoke here.
>>>>>>>=20
>>>>>>> It's not the case of a random token, it's the case of a
>>>>>>> client having been deleted but using an otherwise valid
>>>>>>> access token. If the token's no good, you don't get this
>>>>>>> far -- you return a 401 as defined in RFC6750.
>>>>>>=20
>>>>>> I guess it might make sense to add this information.
>>>>>=20
>>>>> It=92s already in there, in the paragraph just before the one you
>>>>> quoted:
>>>>>=20
>>>>> If the registration access token used to make this request is
>>>>> not valid, the server MUST respond with an error as described
>>>>> in OAuth Bearer Token Usage [RFC6750
>>>>> <https://tools.ietf.org/html/rfc6750>].
>>>>>=20
>>>=20
>>>=20
>>> But the argument that you provided is for "the case of a client
>>> having been deleted but using an otherwise valid access token" but
>>> the text you cite talks about the registration access token not
>>> being valid. Those appear to be two different cases.
>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> In Section 3.1. "Client Information Response" you state
>>>>>>>> the new elements that are returned to the client. While
>>>>>>>> the client_secret has an expires_at field the
>>>>>>>> registration_access_token doesn't. Does the expiry value
>>>>>>>> of the client_secret_expires_at automatically indicate
>>>>>>>> the lifetime of the  registration access token? I think=20
>>>>>>>> so. But what happens if the client_secret is not issued?
>>>>>>>> To make it more complicated you write the following text
>>>>>>>> in the security consideration section:
>>>>>>>>=20
>>>>>>>> " While the client secret can expire, the registration
>>>>>>>> access token SHOULD NOT expire while a client is still
>>>>>>>> actively registered. "
>>>>>>>=20
>>>>>>> There isn't a separate expiration for the registration
>>>>>>> access token because it's not supposed to unceremoniously
>>>>>>> expire on a client. It should be good until it gets rotated
>>>>>>> out on a future read/update operation or the client's
>>>>>>> registration is no good anymore.
>>>>>>=20
>>>>>> I think it might be good to have a small section that
>>>>>> explains how state management works.
>>>>>=20
>>>>> Can you suggest text for this beyond the paragraph that=92s
>>>>> already there?
>>>=20
>>> Yes, I can do that. If you could ship a new update then I can read=20=

>>> through the entire document again and figure out how to create a
>>> state machine.
>>>=20
>>> If you, of course, get rid of this credential rotation then I don't
>>> have to do it though.
>>>=20
>>>=20
>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The IANA consideration section is empty. Wouldn't it be
>>>>>>>> necessary to register 'registration_access_token' and=20
>>>>>>>> 'registration_client_uri' into the OAuth Dynamic
>>>>>>>> Registration Client Metadata Registry?
>>>>>>>=20
>>>>>>> No, these are not client metadata. The client can not send
>>>>>>> these in a registration request, so they don't need to be
>>>>>>> in there.
>>>>>>=20
>>>>>> Really?
>>>>>>=20
>>>>>> I thought that the IANA registry created with Section 5.1 of=20
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was
>>>>>> meant to be used with the Client Registration Request and the
>>>>>> Client Registration Response exchange. The
>>>>>> 'registration_access_token' and 'registration_client_uri'
>>>>>> parameters are used in the response.
>>>>>>=20
>>>>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an
>>>>>> inconsistency: The protocol interaction should either be
>>>>>>=20
>>>>>>=20
>>>>>> C -> AS: Client Registration Request C <- AS: Client
>>>>>> Registration Response
>>>>>>=20
>>>>>> OR
>>>>>>=20
>>>>>> C -> AS: Client Registration Request C <- AS: Client
>>>>>> Registration Error Response
>>>>>>=20
>>>>>> Currently, sometimes the term "Client Registration Response"
>>>>>> or "Client Information Response" is used. We need to fix this
>>>>>> since it spills over to the management API document as well.
>>>>>=20
>>>>> Client Information Response and Client Error Response are
>>>>> sub-classes of Client Registration Response. If that=92s not
>>>>> clear from the current document, please suggest new wording to
>>>>> make it clearer.
>>>=20
>>> As a shepherd I read through both documents in detail and I didn't=20=

>>> figure that out. That gives me reasons to believe that others
>>> wouldn't figure that out either.
>>>=20
>>> I would make the change already in Figure 1 of Dynamic Client=20
>>> Registration Protocol document.
>>>=20
>>>=20
>>>=20
>>> +--------(A)- Initial Access Token (OPTIONAL) | |   +----(B)-
>>> Software Statement (OPTIONAL) |   | v   v +-----------+
>>> +---------------+ |           |--(C)- Client Registration Request
>>> -->|    Client     | | Client or |
>>> | Registration  | | Developer |<-(D)- Client Registration
>>> Response---|   Endpoint    | |           |
>>> +---------------+ +-----------+
>>>=20
>>> Client Registration Response:=3D Client Information Response OR=20
>>> Client Error Response
>>>=20
>>> Same change to Figure 1 in the dynamic client registration
>>> management document. You could even indicate in the figure which
>>> parts are already specified in the dynamic client registration spec
>>> and which are added via the dynamic client registration management
>>> doc.
>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Also, I noticed that we say that the server MUST support TLS
>>>>>> 1.2 RFC 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0
>>>>>> anymore.
>>>>>=20
>>>>> Kathleen made a similar comment on dyn-reg and suggested text
>>>>> that we=92ll incorporate (unless there are objections from others
>>>>> on the list).
>>>=20
>>> Ack.
>>>=20
>>>>>=20
>>>>>>=20
>>>>>> In Figure 1 it might be useful to indicate that exchanges A,
>>>>>> B, C, and D are inherited from the dynamic client
>>>>>> registration document and only step D is enhanced with
>>>>>> additional parameters, as described in Section 3.1.
>>>>>> Furthermore, I wonder whether it would make sense to somehow=20
>>>>>> indicate in the figure that the endpoints are actually part
>>>>>> of the Authorization Server.
>>>>>=20
>>>>> While they usually are the same in practice, these endpoints
>>>>> might not be part of the Authorization Server =97 they might be
>>>>> part of a separate (but related) service that handles objects
>>>>> of various kinds within a security domain. No reason to tie
>>>>> them together unnecessarily.
>>>=20
>>> You can state that someone in the text but endpoints by itself
>>> don't exist since they have to be at some server. Even if the
>>> endpoints are in separate boxes there needs to be a close
>>> cooperation between the two since otherwise we create new
>>> interoperability challenges.
>>>=20
>>> Ciao Hannes
>>>=20
>>>>>=20
>>>>> =97 Justin
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Ciao Hannes
>>>>>>=20
>>>>>>>=20
>>>>>>> -- Justin
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________ OAuth mailing
>>>>>> list OAuth@ietf.org <mailto:OAuth@ietf.org>=20
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________ OAuth mailing
>>>>> list OAuth@ietf.org <mailto:OAuth@ietf.org>=20
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> _______________________________________________ OAuth mailing list=20=

>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNDEyMDExNTIxMDRaMCMGCSqGSIb3DQEJBDEWBBQKyD99L9GImvv4a72QnMzu
UZl4UTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAe7r1oCR/Cl6lfzj3nsWZn4IPxLSdU7RGmZu3cZDcN2+ge6BSLyWoA
CRBsOTLS8rv1rLbYsTGfyBMxkCR5PYOIi1G1IfFL049sEfacGQ5w0AGUcboneKhLkye/je/yEUZv
xlCKm2sS6DTHS3hiL62O6IVKleITxSlj6JkfBA/bAAIeKb0/+ro6V3E8+ut42Wiq+O3iPkrlzo61
7fZu20FYZwK0siZwkp0Y6Lb+gd1wx6jK+JbfEv6LoDH4/28IQRfSk+24LlBzbPB3mETnW5ETiYT1
QHUT6JixFWFSwiamOd4h7AkaA7u1A2J5Zh8MllJ6u03g5nhZzMIjxQpHNPRWAAAAAAAA
--Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63--