From nobody Tue Apr 7 20:50:57 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAC73A0A11 for ; Tue, 7 Apr 2020 20:50:55 -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, SPF_HELO_NONE=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 nncOJ35oxD2P for ; Tue, 7 Apr 2020 20:50:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9943A0A0D for ; Tue, 7 Apr 2020 20:50:53 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Apr 2020 20:50:48 -0700 From: Jim Schaad To: Date: Tue, 7 Apr 2020 20:50:47 -0700 Message-ID: <04eb01d60d58$e46118a0$ad2349e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYNWHB1Fm2C+zXUQ32lzye+/t7CPg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Scheduling additional interim meetings X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 03:50:56 -0000 Daniel and I would like to schedule two additional interim meetings to occur in May and June. I have created a doodle poll for the times that I know that I am available and would like to get people to fill it in. The poll has options for May dates in it. The June dates would be 4 weeks later so please look at both the May and June dates when filling out the poll. As an example, May 12th and June 9th are represented as May 12th in the poll. https://doodle.com/poll/e7vtvi5zx3eekcgw Thanks for filling this in. We should be able to announce the final dates at the April 15th interim meeting. Jim From nobody Tue Apr 14 09:20:59 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D853E3A0B56; Tue, 14 Apr 2020 09:20:56 -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, SPF_HELO_NONE=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 wQAR3rkFw340; Tue, 14 Apr 2020 09:20:45 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3F13A0B62; Tue, 14 Apr 2020 09:20:41 -0700 (PDT) Received: from wangari.tzi.org (client-0110.vpn.uni-bremen.de [134.102.107.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 491rLv0nQwzyYs; Tue, 14 Apr 2020 18:20:39 +0200 (CEST) From: Olaf Bergmann To: Benjamin Kaduk Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org References: <20200102234020.GI35479@kduck.mit.edu> Date: Tue, 14 Apr 2020 18:20:38 +0200 In-Reply-To: <20200102234020.GI35479@kduck.mit.edu> (Benjamin Kaduk's message of "Thu, 2 Jan 2020 15:40:20 -0800") Message-ID: <87pnca9gyx.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 16:20:57 -0000 Ben, Thanks again for the thorough review of the ACE DTLS profile and my sincere apologies for the long time it took to process. Please find our comments inline. As this comprises a lot of changes, the proposed text already has been included in the Editor's copy [1]. Our proposals for new text are in the section-by-section comments. [1] https://ace-wg.github.io/ace-dtls-profile/ Benjamin Kaduk writes: > Hi all, > > Some high-level remarks before delving into the section-by-section > comments: > > This document is pretty clearly DTLS 1.2-specific -- it talks about > particular protocol messages, message fields, and cipher suites that > simply do not apply to DTLS 1.3. In order to use this profile with DTLS > 1.3, we'd need to specify the analogous behavior/requirements to these > (including standalone signature schemes and key-exchange groups, which > are now both separately negotiated from the cipher suite). > Given that DTLS 1.3 is past WGLC and only a few documents behind this > one in my review queue, it seems fairly prudent to spend some time and > cover how DTLS 1.3 would work here, since otherwise this document will > become stale shortly after (or even before!) its publication as an RFC. > > There's probably some additional discussion to include about the usage of > key identifiers in this document versus the potential uses described in > the core framework. Specifically, the framework reminds us that "no > assumptions should be made that it is unique in the domains of either > the client or the RS" yet this document is using the kid as input to a > KDF that produces keys that must be unique across all clients, and > allowing live/instant authorization updates based on matching "kid". > How shall we resolve this apparent conflict? > > We also are potentially in violation of the framework's requirements > with respect to the independent selection of profiles for client/AS and > client/RS interactions -- at present, when DTLS+RPK is used for > client/RS, we require that DTLS+RPK is also used for client/AS, in order > to prove possession of the key. We could perhaps weasel our way out by > saying that the framework's requirement applies at the profile > granularity, and with symmetric PSK we can be fully independent, but we > still need to say something about this property and the interaction with > the framework's requirements. > > This profile is mostly applicable to the client/RS communications and > feels like it only provides some of the picture for use with client/AS > interactions. (It doesn't really say much of anything about RS/AS > interactions.) The introductory discussion does not do a great job of > painting that picture, and I'd like to see it more clearly introduced > that the bulk of our coverage is for the client/RS interaction. We also > lean heavily on the existing out-of-band configuration and key material > shared between client and AS to secure the client/AS communications; we > could probably tighten up the discussion about exactly what parameters > of client/AS communication are specified by this profile. The introduction has been revised according to your suggested text, see below. We also have included some text on the out-of-band configuration in a new subsection in the security considerations. The important thing here really are the client/RS and client/AS interactions. Regarding client/AS, much of this is out of scope as there are certain OAuth-related assumptions on how these entities get in touch with each other; neither the framework nor the profile can do much about it without creating a new enrollment protocol. Regarding the RS/AS interaction, there is normative language that describes what each of these entities needs to do in each protocol step covered by the document. The necessary out-of-band configuration again is described in the new subsection in the security considerations as well as some clarifications in the text, see below. > We do not say anything about DTLS session resumption (or renegotiation, > though not talking about that one is perfectly fine); that's a fairly > core DTLS concept that we should give some guidance on. Not sure if we really need to but if you think this is necessary, we can comment on this, of course. > Looking through Appendix C ("Requirements on Profiles") of the > framework, do we want to say anything about: > > - using the client credentials grant with this profile, as that's IIRC > the only example we show Do you think we need to say anything here? The actual grant used to make the client known to the AS is out of scope for the profile as long as the requirements given here are met. > - require that DTLS be used in a mode that provides replay protection Added as a requirement in Section 2. > - when the client uses the authz-info endpoint instead of the > "psk_identity" field to convey the token to the RS, how does the RS > know which client is connecting (and thus what PSK to use), and what > does the client actually *put* in the "psk_identity" field? (The > other aspects of "how to select a proof-of-possession protocol" seem > to fall out naturally from the DTLS usage.) We have included more explanatory text in section 3.3.1 on how this is supposed to work. > - whether/how introspection is used? We have added text stating that token introspection may be used but is out of scope for the profile spec. > - give more details of what this profile mandates when used for > client/AS interactions (as mentioned above) This should be covered now, see detailed responses below. > - explicitly state that the authz-info endpoint is unprotected (or that > it might be protected if, e.g., the RS has a trustable certificate > that would be used instead of RPK or PSK, or by supplying the > token as the "psk_identity" when symmetric PoP is used, or by only > doing server-authentication with RPK as known by the client by the > rs_cnf access information I am not sure which security gain we would yield by trustable certificates: The client does not need to authenticate the resource server for the authz-info upload. The important aspect here is that the access token must be integrity-protected by the AS and encrypted if it contains information to be kept confidential (esp. a shared secret but possibly other data as well). We have added some text on this to the security considerations. > And now, on to the section-by-section comments. > > Section 1 > > a DTLS session. The communication between client and authorization > server may also be secured with DTLS. This specification supports > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys > (PSK) [RFC4279]. > > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called > "external") PSKs.] (See general discussion on wether DTLS 1.3 needs to be addressed at this time.) > The DTLS handshake requires the client and server to prove that they > can use certain keying material. In the RPK mode, the client proves > with the DTLS handshake that it can use the RPK bound to the token > and the server shows that it can use a certain RPK. The access token > must be presented to the resource server. For the RPK mode, the > access token needs to be uploaded to the resource server before the > handshake is initiated, as described in Section 5.8.1 of the ACE > framework [I-D.ietf-ace-oauth-authz]. > > This seems to be making some implicit assumptions about the message flow > that have not yet been covered by this document and are only somewhat > covered by the core framework spec. I'd propose: > > % The ACE framework requires that client and server mutually > % authenticate each other before any other protocol exchanges take > % place. Actually, this is not true: The client can upload data to the resource server's authorization endpoint without authentication. I suggest to rephrase this as "The ACE framework requires that client and server mutually authenticate each other before any application data is exchanged.", see below. > % In order for DTLS to provide mutual authentication, both > % client and server must prove their ability to use certain keying > % material (tied to the authenticated identity) as part of the DTLS > % handshake. The AS assists in this process by incorporating key > % material (or information about key material) into the access token, > % which is considered a "proof of possession" token. In the RPK mode, > % the client proves that it can use the RPK bound to the token and the > % server shows that it can use a certain RPK (as indicated by the AS to > % the client). The resource server needs access to the token in order > % to complete this exchange. For the RPK mode, the access token needs > % to be uploaded to the resource server before the handshake is > % initiated, as described in Section 5.8.1 of the ACE framework > % [I-D.ietf-ace-oauth-authz]. > > though I recognize that my text tends to be a bit more verbose than is > strictly needed, so please feel free to edit it down. We propose the following change: OLD: The DTLS handshake requires the client and server to prove that they can use certain keying material. In the RPK mode, the client proves with the DTLS handshake that it can use the RPK bound to the token and the server shows that it can use a certain RPK. The access token must be presented to the resource server. For the RPK mode, the access token needs to be uploaded to the resource server before the handshake is initiated, as described in Section 5.8.1 of the ACE framework {{I-D.ietf-ace-oauth-authz}}. NEW: The ACE framework requires that client and server mutually authenticate each other before any application data is exchanged. DTLS enables mutual authentication if both client and server prove their ability to use certain keying material in the DTLS handshake. The authorization server assists in this process on the server side by incorporating keying material (or information about keying material) into the access token, which is considered a "proof of possession" token. In the RPK mode, the client proves that it can use the RPK bound to the token and the server shows that it can use a certain RPK (as indicated by the authorization server to the client). The resource server needs access to the token in order to complete this exchange. For the RPK mode, the client must upload the access token to the resource server before initiating the handshake, as described in Section 5.8.1 of the ACE framework {{I-D.ietf-ace-oauth-authz}}. > Section 2 > > The CoAP-DTLS profile for ACE specifies the transfer of > authentication information and, if necessary, authorization > information between the client (C) and the resource server (RS) > during setup of a DTLS session for CoAP messaging. It also specifies > how C can use CoAP over DTLS to retrieve an access token from the > authorization server (AS) for a protected resource hosted on the > resource server. > > I suggest reiterating that "As specified in Section 6.7 of > [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these > interactions is completely independent". done > To determine the AS in charge of a resource hosted at the RS, C MAY > send an initial Unauthorized Resource Request message to the RS. The > > This is part of the core framework, so the "MAY" may be overkill. > (Lowercase "can" would do just fine.) done > Once the client knows the authorization server's address, it can send > an access token request to the token endpoint at the AS as specified > > Hmm. There's some level of "the client needs to have already been > configured that that AS is a valid AS" verification that's done here, > but I'm not sure if that's too much detail to include at this stage > (since we're really just summarizing the framework here). Yes, there has been a discussion on this. The issue with this three corner model is that the client needs a pretty tight relationship with the AS, meaning that it must be able to recognize an AS depicted in the AS Request Creation Hints as trustworthy. > in [I-D.ietf-ace-oauth-authz]. As the access token request as well > as the response may contain confidential data, the communication > between the client and the authorization server MUST be > > (This "MUST" is already a requirement from the core framework, so we > don't necessarily need to repeat it as normative language.) Okay, changed to lower case. > confidentiality-protected and ensure authenticity. C may have been > registered at the AS via the OAuth 2.0 client registration mechanism > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. > > Section 5.3 of oauth-authz says that registration is "out of scope"; is > this still the right reference? It is the correct reference but unfortunately, Section 5.3 of the framework document just says that "Authentication of the client is mandatory". The issue here is that the framework as well as OAuth requires a prior registration of the client. Otherwise, the AS would not be able to authorize the client in the three corner model. Not including the reference would mean to repeat the requirement of client registration here. > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric > proof-of-possession key in the DTLS handshake, the procedure as above > MAY be used, or alternatively, the access token MAY instead be > transferred in the DTLS ClientKeyExchange message (see > Section 3.3.1). > > (This is not DTLS 1.3-compatible.) Agreed. This would need a change if we decided to add-in support for DTLS 1.3. > Section 3 > > secured. Depending on the used CoAP security mode (see also > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client > response and DTLS session establishment carry slightly different > information. [...] > > At this point in the document it's pretty unclear what "Client-to-AS > request", "AS-to-Client response", and "DTLS session establishment" are > and how they relate to each other. The "Client-to-AS request" and "AS-to-Client response" are introduced by the ACE framework document. Maybe an explicit reference helps to avoid confusion. OLD: Depending on the used CoAP security mode (see also Section 9 of {{RFC7252}}, the Client-to-AS request, AS-to-Client response and DTLS session establishment carry slightly different information. {{rpk-mode}} addresses the use of raw public keys while {{psk-mode}} defines how pre-shared keys are used in this profile. NEW: Depending on the used CoAP security mode (see also Section 9 of {{RFC7252}}, the Client-to-AS request, AS-to-Client response (see Section 5.6 of {{I-D.ietf-ace-oauth-authz}}) and DTLS session establishment carry slightly different information. {{rpk-mode}} > Also, it seems like the behavior in Section 3.2 and 3.3 are relating to > the mode used for the client/RS interactions, which relates to the > client/AS interactions only in the form of how PoP information is bound > to/with the token. I am not sure if there is anything else to say about the client/AS interactions that is not covered by the framework. > Section 3.1 > > establish a secure communication channel. C MUST securely have > obtained keying material to communicate with AS. Furthermore, C MUST > verify that AS is authorized to provide access tokens (including > authorization information) about RS to C. Also, AS MUST securely > have obtained keying material for C, and obtained authorization rules > approved by the resource owner (RO) concerning C and RS that relate > to this keying material. [...] > > The way this is written right now, we're going to get lots of questions > from reviewers about "how does this happen?" and for more details about > it. We are effectively assuming that this stuff is all provisioned > already as part of the device configuration or during enrollment, we > should say something about these being requirements on device > provisioning, not on the operation of the ACE protocol. The following new text has been added for clarification: NEW: This profile assumes that the keying material to secure this communication channel has securely been obtained either by manual configuration or in an automated provisioning process. > between C and AS is bootstrapped is not part of this document. C and > AS MUST ensure the confidentiality, integrity and authenticity of all > exchanged messages. > > I think this is also restating requirements from the core framework, and > may not need normative language in this manner. done > Section 3.2 > > I know that the section heading says "RawPublicKey Mode" already, but > I'd recommend adding a sentence in the preface that repeats that "When > the client and RS use RawPublicKey authentication, the procedure is as > follows"; we might get complaints otherwise that we are saying that the > client MUST do things that are not universal requirements. > (Section 3.3 does already have something like this for the symmetric-key > case.) done > previously made known to the authorization server. To prove that the > client is in possession of this key, C MUST use the same keying > material that it uses to secure the communication with AS, e.g., the > DTLS session. > > This seems in conflict with the core framework's requirement that the > client/AS profile and client/RS profile are severable. This profile explicitly specifies the communication flow between C and AS on one side and between C and RS on the other. As both legs are part of this profile, there is no combination of profiles involved. In that regard, there is no such assumption as indicated in Section 6.7 of the framework. *) https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-6.7 We could weaken the security here by removing the "To prove"-statement. However, it is advisable not to do this because by using the keying material in the C/AS communication, C shows that it is actually in possession of the respective private key. This would raise the bar for the client to retrieve access tokens in the name of other clients. The preferred alternative would be replace MUST with SHOULD: OLD: previously made known to the authorization server. To prove that the client is in possession of this key, C MUST use the same keying material that it uses to secure the communication with AS, e.g., the DTLS session. NEW: previously made known to the authorization server. To prove that the client is in possession of this key, C SHOULD use the same keying material that it uses to secure the communication with AS, e.g., the DTLS session. > AS MUST check if the client that it communicates with is associated > with the RPK in the cnf object before issuing an access token to it. > > Earlier in the section we noted a requirement to prove possession of the > key by using it in DTLS; why is there a separate "association" > requirement? This is the same rationale as above. The AS needs some way to decide which authorization rules apply to the requesting client. There was a discussion on the mailing list that the client may use a different RPK in the communication with AS than it uses in the communication with the resource server. AS then must ensure two things: First, that the authorization decision coded into the access token applies to the RPK provided by C. Second, that the access token is transferred to the same C. The following text has been added to the Security Considerations to explain the problems that arise from using different RPKs for the C/AS and C/RS communication: NEW: The authorization server must ascertain that the keying material for the client that it provides to the resource server actually is associated with this client. Malicious clients may hand over access tokens containing their own access permissions to other entities. This problem cannot be completely eliminated. Nevertheless, in RPK mode it should not be possible for clients to request access tokens for arbitrary public keys, since that would allow the client to relay tokens without the need to share its own credentials with others. The authorization server therefore should at some point validate that the client can actually use the private key corresponding to the client's public key. > also, nit: "The AS". done > which case it does not have to be sent. The response also contains > an access token and an "rs_cnf" parameter containing information > about the public key that is used by the resource server. AS MUST > > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when > DTLS-RPK is used for client-RS interactions?) Done as follows: OLD: The response also contains an access token and an "rs_cnf" parameter containing information about the public key that is used by the resource server. AS MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource server that C wants to communicate with. NEW: The response also contains an access token with information about the public key that is used by the resource server. The authorization server MUST return in its response the parameter "rs_cnf" unless it is certain that the client already knows the public key of the resource server. The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource server that the client wants to communicate with. > nit: "The AS" again (and throughought, to a large extent). [Okay, we will change these for I-D submission.] > server that C wants to communicate with. AS MUST protect the > integrity of the token. If the access token contains confidential > data, AS MUST also protect the confidentiality of the access token. > > This requirement ("protect the integrity of the token") feels a little > underspecified, as it doesn't say protection over what workflow or who > will verify the integrity (the RS). done, by adding NEW: to ensure that the resource server can detect unauthorized changes. > C MUST ascertain that the access token response belongs to a certain > previously sent access token request, as the request may specify the > resource server with which C wants to communicate. > > nit: I recomment rewording "belongs to", perhaps as "corresponds to". > DTLS can provide this guarantee when configured to do so, though it is > not a guaranteed property from DTLS. Changed to: OLD: C MUST ascertain that the access token response corresponds to a certain previously sent access token request,... NEW: the client MUST check if the access token response is bound to a certain previously sent access token request, > We'll probably get some grief about the "access_token" contents in the > example not being valid CBOR, due to the parenthetical comment. We > could probably put a note in the preface that the value is truncated for > readability. Also, nit: "the client's" with article and apostrophe. Okay. For now, I have put in a disclaimer into the description of the two examples where this occurs. > Section 3.2.1 > > Before the client initiates the DTLS handshake with the resource > server, C MUST send a "POST" request containing the new access token > to the authz-info resource hosted by the resource server. After the > client > > nit: we don't require single-use tokens, so "new" is probably overkill; > just "its access token" should suffice. > nit: formatting issue with spurious line break here. done > server. To use the RawPublicKey mode, the client MUST specify the > public key that AS defined in the "cnf" field of the access token > response in the SubjectPublicKeyInfo structure in the DTLS handshake > as specified in [RFC7250]. > > IIRC the access token response does not have to include a "cnf" field > (e.g., if the AS accepts the req_cnf from the request), so "defined in > the field of the response" doesn't seem like quite the right wording. Done: OLD: To use the RawPublicKey mode, the client MUST specify the public key that AS defined in the `cnf` field of the access token response in the SubjectPublicKeyInfo structure in the DTLS handshake as specified in {{RFC7250}}. NEW: The client MUST use its correct public key in the DTLS handshake. If the authorization server has specified a `cnf` field in the access token response, the client MUST use this key. Otherwise, the client MUST use the public key that it specified in the `req_cnf` of the access token request. The client MUST specify this public key in the SubjectPublicKeyInfo structure of the DTLS handshake as described in [RFC7250]. > An implementation that supports the RPK mode of this profile MUST at > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > > I understand that making the full-width-tag ciphersuite MTI would > exclude some devices, though it feels like some recommendation to use > the full-length tag when possible would be appropriate. That said, I do > see that RFC 7252 makes no such remark, and thus consistency would have > us not say anything either. We have now included more text on the tag length in the Security Considerations, see below. > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). > > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE > operation is called x25519, and both algorithms make use of the > elliptical curve known as curve25519. Since we are using both ECDHE and > ECDSA, it's probably simplest to just refer to "curve25519", though > mentioning both ed25519 and x25519 would also work. This has been a WG decision at some point but the authors agree that curve25519 is the best to go for and propose the following change which also gets rid of the ugly note in favor of more coherent text: OLD: An implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). NEW: To be consistent with {{RFC7252}} which allows for shortened MAC tags in constrained environments, an implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CCM\_8 {{RFC7251}}. As discussed in {{RFC7748}}, new ECC curves have been defined recently that are considered superior to the so-called NIST curves. This specification therefore mandates implementation support for curve25519 (cf. {{RFC8032}}, {{RFC8422}}) as this curve said to be efficient and less dangerous regarding implementation errors than the secp256r1 curve mandated in {{RFC7252}}. > RS MUST check if the access token is still valid, if RS is the > intended destination, i.e., the audience, of the token, and if the > token was issued by an authorized AS. The access token is > > nit: "i.e., the audience" is in effect a parenthetical, so using commas > to offset it inside a comma-separated list is potentially confusing; I'd > suggest using actual parentheses instead of commas around it. done > reference to this key. If the authorization server has no certain > knowledge that the Client's key is already known to the resource > server, the Client's public key MUST be included in the access > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the > > Is talking about """the access token's "cnf" parameter" consistent with > allowing the use of non-CWT (non-JWT) token formats? This has been addressed by adding the following paragraph to the introduction: NEW: As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this specification uses CBOR web tokens to convey claims within an access token issued by the server. While other formats could be used as well, those are out of scope for this document. > keying material in the handshake that AS specified in the rs_cnf > parameter in the access token. Thus, the handshake only finishes if > C and RS are able to use their respective keying material. > > I suggest being explicit about "the DTLS handshake with the client", > perhaps as "MUST use in the DLTS handshake with the client the keying > material that the AS specified in the rs_cnf parameter in the access > token". Done, see next comment. > The same caveat about "parameter in the access token" > applies here, though I guess there is an additional complication for > "rs_cnf" in that it's an token response parameter but I don't remember > that we say a huge amount about it also being included in the token > itself -- the token response is directed to the client but the token is > directed to the RS. As we have found, the mailing list discussion concluded that the access token does not contain an rs_cnf claim at all. This occurrence most likely was an artefact. This now has been changed as follows: OLD: RS MUST use the keying material in the handshake that AS specified in the rs_cnf parameter in the access token. Thus, the handshake only finishes if C and RS are able to use their respective keying material. NEW: The resource server MUST use its own raw public key in the DTLS handshake with the client. If the resource server has several raw public keys, it must already know which key it is supposed to use with this client. How this is achieved is not part of this profile. > Section 3.3 > > token. AS MUST check if the identifier refers to a symmetric key > that was previously generated by AS as a shared secret for the > communication between this client and the resource server. > > "What does the AS do if this check fails?" The following text has been added to avoid additional roundtrips for the client: NEW: If no such symmetric key was found, the AS MUST generate a new symmetric key that is returned in its response to the client. > The authorization server MUST determine the authorization rules for > the C it communicates with as defined by RO and generate the access > > nit: it's surprising to see "authorization server" spelled out in the > same sentence as "C" and "RO" (which, incidentally, we don't seem to use > in abbreviation form anywhere other than where we define it). There has been some discussion about the short forms. We will harmonize this before submitting the next I-D version. > wants to communicate with. Also, AS MUST protect the integrity of > the access token. If the token contains confidential data such as > the symmetric key, the confidentiality of the token MUST also be > protected. Depending on the requested token type and algorithm in > > (same comment about "protect the integrity" or "protect" as for the RPK > case.) Done, by adding: NEW: to ensure that the resource server can detect unauthorized changes. > that is to be used between C and the resource server. The access > token MUST be bound to the same symmetric key by means of the cnf > claim. > > Now we call it a "claim" rather than a "token parameter", but this again > seems to be implicitly assuming CWT/JWT for tokens. We distinguish between the (semantic) information conveyed by an access token of the syntactic description of data objects. To make this more explicit, we now have added some text in the Terminology section that refers to the same usage of the term 'claim' as in the framework document. > (Also, this "MUST" seems like something that the framework should > guarantee and not a new requirement that the DTLS profile imposes.) As this as been a bit misleading as well, it has been rephrased as follows: OLD: The access token MUST be bound to the same symmetric key by means of the cnf claim. NEW: To convey the same secret to the resource server, the authorization server either includes it directly in the access token by means of the `cnf` claim or it provides sufficient information to enable the resource server to derive the key from the access token using key derivation. > Figure 5: Example Access Token Request, symmetric PoP-key > > Maybe we could include "(implicit)" in the caption, since symmetric PoP > key is the default. done > An example access token response is illustrated in Figure 6. In this > > Is it accurate to say "A corresponding example access token response"? > It's nice to the reader if we can tie the examples together like that. done > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment > about having the parenthetical comment in the example body vs. preface.) New text was added as follows to clarify that inconsistencies with cached responses should be avoided. For a more realistic example, the value of Max-Age in the examples has been decreased to be sufficiently below expires_in: NEW: Caching proxies process the Max-Age option in the CoAP response which has a default value of 60 seconds (Section 5.6.1 of [RFC7252]). The authorization server SHOULD adjust the Max-Age option such that it does not exceed the `expires_in` parameter to avoid stale responses. > token_type : pop, > > Didn't we switch this to being capitalized as "PoP"? done > "COSE_Encrypt0" structure. The AS MUST use the keying material > shared with the RS to encrypt the token. > > nit: I suggest s/shared with/it shares with/ done > We should probably say something about why the kid in Figure 7 is > different from the one in Figure 6. As it seems more clear if both examples use the same kid, this now has been harmonized. > 4.00 Bad Request > Content-Format: application/ace+cbor > Payload: > { > error : invalid_request > } > > Figure 8: Example Access Token Response With Reject > > RFC 6749's description of "invalid_request" seems to imply that it's > mostly about malformed requests, as opposed to the AS deciding that the > client is not authorized for any access to the requested resource (which > is maybe what's implied by the previous paragraph). This is not > necessarily a problem, but perhaps we could make the text and example > more consistent. This example is actually about malformed requests (4.00). We now have added text to clarify this. > The method for how the resource server determines the symmetric key > from an access token containing only a key identifier is application > specific, the remainder of this section provides one example. > > nit: hyphenate "application-specific", and this is a comma splice. done > resource server. This key needs to be securely stored and processed > in the same way as the key used to protect the communication between > AS and RS. > > nit: is this better as "processed" or "protected"? "processed" because this part is about the handling not the characteristics of the data. > The fields in the context information "COSE_KDF_Context" > (Section 11.2 of [RFC8152]) have the following values: > > o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" > > RFC 8152 says that these AlgorithmID values come from the COSE > Algorithms registry, which this does not (unless we register it there, > which we don't currently). Also, since the output is used directly for > DTLS PSK, I don't think the "key-derivation" portion is needed. > > o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) > > (8152 seems to prefer "nil" over "null".) > > o keyDataLength needs to be defined by the application > > o protected MUST be a zero length bstr > > o other is a zero length bstr > > (These three are all members of the "SuppPubInfo" field, which is not > very clear from how we include them in the same list as top-level > fields.) The example now has updated and rephrased according to HKDF usage. > Section 3.3.1 > > When a client receives an access token response from an authorization > server, C MUST ascertain that the access token response belongs to a > certain previously sent access token request, as the request may > specify the resource server with which C wants to communicate. > > (Same bit about "belongs to".) done > If a resource server receives a ClientKeyExchange message that > contains a "psk_identity" with a length greater zero, it uses the > contents as index for its key store (i.e., treat the contents as key > > (This is not DTLS 1.3-compatible.) See side discussion on DTLS versions. > nits: "greater than", "as an index", "as a key identifier" done > identifier). The resource server MUST check if it has one or more > access tokens that are associated with the specified key. > > I don't understand this sentence -- isn't the access token the precise > contents of the "psk_identity" field, so that there would be a key > associated with the access token, not the other way around? Now clarified that the psk_identity must contain the opaque access token: OLD: Alternatively, the client MAY provide the most recent access token in the `psk_identity` field of the ClientKeyExchange message. To do so, the client MUST treat the contents of the `access_token` field from the AS-to-Client response as opaque data and not perform any re-coding. Note: As stated in Section 4.2 of [RFC7925], the PSK identity should be treated as binary data in the Internet of Things space and not assumed to have a human-readable form of any sort. NEW: As an alternative to the access token upload, the client can provide the most recent access token in the `psk_identity` field of the ClientKeyExchange message. To do so, the client MUST treat the contents of the `access_token` field from the AS-to-Client response as opaque data as specified in Section 4.2 of [RFC7925] and not perform any re-coding. This allows the resource server to retrieve the shared secret directly from the `cnf` claim of the access token. > If no key with a matching identifier is found, the resource server > MAY process the contents of the "psk_identity" field as access token > > Similarly here, the causality feels reversed. Hopefully, this has been sufficiently clarified by the previous comment. Moreover, the following change is proposed to emphasize the aforementioned behavior of RS. The access token now must always be parsed but may contain a kid for an already known key: OLD: If a resource server receives a ClientKeyExchange message that contains a `psk_identity` with a length greater than zero, it uses the contents as an index for its key store[...] [...] session setup is terminated with an `illegal_parameter` DTLS alert message. =20=20=20 NEW:=20 If a resource server receives a ClientKeyExchange message that contains a `psk_identity` with a length greater than zero, it MUST process the contents of the `psk_identity` field as access token that is stored with the authorization information endpoint, before continuing the DTLS handshake. If the contents of the `psk_identity` do not yield a valid access token for the requesting client, the resource server aborts the DTLS handshake with an `illegal_parameter` alert. > continuing the DTLS handshake. If the contents of the "psk_identity" > do not yield a valid access token for the requesting client, the DTLS > session setup is terminated with an "illegal_parameter" DTLS alert > message. > > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' ale= rt" > would be more conventional phrasing. done > Note2: According to [RFC7252], CoAP implementations MUST support the > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is > therefore expected to offer at least this ciphersuite to the > resource server. > > Do we want to say anything about the (EC)DHE variants? Short-lived access > tokens with the AS generating new symmetric keys can provide similar > forward-secrecy properties to using DHE, but there is in general a trend > in the IETF towards defaulting to providing forward secrecy in key > exchanges. Yes, this makes a lot of sense. We have added the following text to the Security Considerations to give advice: NEW: The PSK mode of this profile offers a distribution mechanism to convey authorization tokens together with a shared secret to a client and a server. As this specification aims at constrained devices and uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite TLS\_PSK\_WITH\_AES\_128\_CCM\_8 {{RFC6655}} should be supported. The access tokens and the corresponding shared secrets generated by the authorization server are expected to be sufficiently short-lived to provide similar forward-secrecy properties to using ephemeral Diffie-Hellman (DHE) key exchange mechanisms. For longer-lived access tokens, DHE ciphersuites should be used. > When RS receives an access token, RS MUST check if the access token > is still valid, if RS is the intended destination, i.e., the audience > of the token, and if the token was issued by an authorized AS. This > > As above, "i.e., the audience of the token" would probably be better > when offset in parentheses than by commas. done > While the client can retrieve the shared secret from the contents of > the "cnf" parameter in the AS-to-Client response, the resource server > uses the information contained in the "cnf" claim of the access token > to determine the actual secret when no explicit "kid" was provided in > the "psk_identity" field. If key derivation is used, the RS uses the > "COSE_KDF_Context" information as described above. > > "psk_identity" is a field in ClientKeyExchange, and we say that its > contents are the raw access token for our usage. It does not have a > direct COSE structure for this talk of "kid" to make much sense without > further explanation. Yes, this is misleading. We propose the following to clarify the processing of access tokens (independent whether this has been uploaded or carried in the psk_identity) on the RS: OLD: While the client can retrieve the shared secret from the contents of the `cnf` parameter in the AS-to-Client response, the resource server uses the information contained in the `cnf` claim of the access token to determine the actual secret when no explicit `kid` was provided in the `psk_identity` field. If key derivation is used, the RS uses the `COSE_KDF_Context` information as described above. NEW: While the client can retrieve the shared secret from the contents of the `cnf` parameter in the AS-to-Client response, the resource server uses the information contained in the `cnf` claim of the access token to determine the actual secret. To retrieve the `cnf` claim and determine the shared secret for the session between the client and the resource server, the resource server first has to decrypt the access token if it is enclosed in a `COSE_Encrypt0` structure and then parse the access token. The parsed access token then is associated with the `kid` for the contained shared secret, if any. If key derivation is used, the resource server calculates the shared secret from the `COSE_KDF_Context` information as described above. > Section 3.4 > > We may get some requests for a more explicit definition of what the > "authorization information" tied to a client is. > > Once a DTLS channel has been established as described in Section 3.2 > and Section 3.3, respectively, the client is authorized to access > > nit: I think "or" is more appropriate to join the sections listed, as > only one is applicable to a given connection. done > With the successful establishment of the DTLS channel, C and RS have > proven that they can use their respective keying material. An access > token that is bound to the client's keying material is associated > with the channel. Any request that the resource server receives on > this channel MUST be checked against these authorization rules. RS > > nit: I'd s/these/the following/ done > MUST check for every request if the access token is still valid. > Incoming CoAP requests that are not authorized with respect to any > access token that is associated with the client MUST be rejected by > the resource server with 4.01 response as described in Section 5.1.1 > of [I-D.ietf-ace-oauth-authz]. > > "any access token" implies there might be more than one, though I seem > to recall discussion of updated tokens overwriting any previous one, so > that only one token per client is active at any given time. What did we > end up settling on? done OLD: Any request that the resource server receives on this channel MUST be checked against these authorization rules. RS MUST check for every request if the access token is still valid. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 response as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. NEW: According to section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access token for each client. New access tokens issued by the authorization server are supposed to replace previously issued access tokens for the respective client. The resource server therefore must have a common understanding with the authorization server how access tokens are ordered. Any request that the resource server receives on a DTLS channel that is tied to an access token via its keying material MUST be checked against the authorization rules that can be determined with the access token. The resource server MUST check for every request if the access token is still valid. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 response. The response MAY include AS Request Creation Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. =20 > Also, the referenced framework Section 5.1.1 does not actually mandate > the 4.01 response code. Fixed in the proposed text for the previous comment: We now require the 4.01 and do not imply that this is required by section 5.1.1 of the framework document which is silent on the proper response codes. > The resource server SHOULD treat an incoming CoAP request as > authorized if the following holds: > > We could say more about this "SHOULD" (or change the way we discuss it) > -- is it the minimum baseline of checks and additional checks may be > applied, or do some of them not apply in some cases, or ...? These are the minimum checks that the RS needs to do. The following proposal should make this clearer: OLD: The resource server SHOULD treat an incoming CoAP request as authorized if the following holds: NEW: The resource server MUST only accept an incoming CoAP request as authorized if the following holds: > Incoming CoAP requests received on a secure DTLS channel that are not > thus authorized MUST be rejected according to Section 5.8.2 of > [I-D.ietf-ace-oauth-authz] > > We may also get some questions asking about what the difference is > between the "not authorized with respect to any access token" in the > previous quoted snippet" and "not thus authorized" in this quoted > snippet. We hope that the previous change should have fixed this as well. > The client cannot always know a priori if an Authorized Resource > Request will succeed. It MUST check the validity of its keying > material before sending a request or processing a response. If the > > What does "check the validity of its keying material" mean? The following change should make this more clear as the only thing that the client can do is to check if the keying material is still valid: OLD: The client cannot always know a priori if an Authorized Resource Request will succeed. It MUST check the validity of its keying material before sending a request or processing a response. NEW: The client MUST ascertain that its keying material is still valid before sending a request or processing a response. > client repeatedly gets error responses containing AS Creation Hints > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its > requests, it SHOULD request a new access token from the authorization > server in order to continue communication with the resource server. > > Why should this only be done in the case of *repeatedly* getting such > error responses; I thought the idea of the AS Request Creation Hints was > to take immediate effect. Correct. The intention was to deal with the race condition for the upload mechanism. But as this affects different communication channels, it is safe to just remove the word "repeatedly": OLD: client repeatedly gets error responses containing AS Creation Hints NEW: client gets an error response containing AS Request Creation Hints > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) done > Section 4 > > The client can update the authorization information stored at the > resource server at any time without changing an established DTLS > session. To do so, the Client requests a new access token from the > authorization server for the intended action on the respective > resource and uploads this access token to the authz-info resource on > the resource server. > > I suggest adding another sentence similar to "Because ACE tokens are > proof-of-possession tokens, the updated authorization information only > takes immediate effect if such proof has already been provided, e.g., if > the PoP key associated with the new token is the same as the one > currently in use." This is further detailed in the following > paragraphs, but not stated concretely as a key principle. The term "ACE tokens" may be a bit misleading. In this profile, we always use PoP tokens. Our proposal is to move the note from the end upwards: OLD: The client can update... NEW: Resource servers must only use a new access token to update the authorization information for a DTLS session if the keying material that is bound to the token is the same that was used in the DTLS handshake. By associating the access tokens with the identifier of an existing DTLS session, the authorization information can be updated without changing the cryptographic keys for the DTLS communication between the client and the resource server, i.e. an existing session can be used with updated permissions. The client can therefore update... > Section 5 > > DTLS sessions that have been established in accordance with this > profile are always tied to a specific access token. As this token > > Doesn't the dynamic authorization update mechanism allow that token to > be swapped out during the lifetime of the connection? > Also, as a terminology point, I think "DTLS association" is more > appropriate than "DTLS session" for what we describe, since the token is > is tied to the client and consulted at the start of the handshake, as > opposed to being a property of the DTLS session and carried across > resumptions. We propose the following text as a clarification. This also takes into account the "session" vs. "association" part which looks a bit weird. If we come to the conclusion that this is a better term, we would have to revise the rest of the document accordingly: OLD: DTLS sessions that have been established in accordance with this profile are always tied to a specific access token. As this token may become invalid at any time (e.g. because it has expired), the session may become useless at some point. A resource server therefore MUST terminate existing DTLS sessions after the access token for this session has been deleted. NEW: The resource server MUST delete access tokens that are no longer valid. DTLS associations that have been setup in accordance with this profile are always tied to specific tokens (which may be exchanged with a dynamic update as described in Section 4). As tokens may become invalid at any time (e.g. because they have expired), the association may become useless at some point. A resource server therefore MUST terminate existing DTLS association after the last access token associated with this association has expired. > may become invalid at any time (e.g. because it has expired), the > session may become useless at some point. A resource server > therefore MUST terminate existing DTLS sessions after the access > token for this session has been deleted. > > I assume that using "been deleted" vs. "has expired" is a deliberate > choice? If we don't say anything else about when to delete tokens, it > doesn't post much of a requirement, though. Good point. This is missing in Section 3.4. We now have added an explicit requirement to remove expired (or otherwise invalid) access tokens: OLD: The resource server MUST check for every request if the access token is still valid. NEW: The resource server MUST check for every request if the access token is still valid. If the token has expired, the resource server MUST remove it. > Section 6 > > endpoint. The use of CoAP and DTLS for this communication is > RECOMMENDED in this profile, other protocols (such as HTTP and TLS or > CoAP and OSCORE) MAY be used instead. > > nit: comma splice done > Also, we could potentially refer to the OSCORE profile document here > (informatively). done > If other means of securing the communication with the AS are used, > the security protocol MUST fulfill the communication security > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. > > I suggest phrasing more like "the communication security requirements > from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since > there's no need to add another MUST to the ones already in the framework > document. Done, although "remain applicable" seems a bit weak. > Section 7 > > I have a few suggestions for potential additions to this section as well > as comments on the existing contents. > > We might consider adding a brief note about the use of 8-byte > authentication tags in DTLS ciphers and how that affects the risk > profile. Done. New text has been added as follows. NEW: As this specification targets at constrained environments, message payloads exchanged between the client and the resource server are expected to be small and rare. CoAP {{RFC7252}} mandates the implementation of cipher suites with abbreviated, 8-byte tags for message integrity protection. For consistency, this profile requires implementation of the same cipher suites. For application scenarios where the cost of full-width authentication tags is low compared to the overall amount of data being transmitted, the use of cipher suites with 16-byte integrity protection tags is preferred. > The use of "live" authorization upgrades on an existing DTLS connection > by posting a new token to the authz-info endpoint does not provide much > guarantee about the order in which operations occur (and thus which > authorization info is used to process a given client request), > especially in the face of an attacker that can delay and reorder > packets. This does not necessarily mean that we should not bother to > define that mechanism, but we should point out that there is only a weak > ordering property provided, note that other mechanisms should be used > when strict serialization is important, and caution that when the > later-issued token contains a reduction in authorization from the > initial token, it is impossible to guarantee that the reduction in > authorization will take effect prior to the expiration of the original > token. Exactly! To address this, the following text has been added to the Security Considerations: NEW: Even when a single access token per client is used, an attacker could compromise the dynamic update mechanism for existing DTLS connections by delaying or reordering packets destined for the authz-info endpoint. Thus, the order in which operations occur at the resource server (and thus which authorization info is used to process a given client request) cannot be guaranteed. Especially in the presence of later-issued access tokens that reduce the client's permissions from the initial access token, it is impossible to guarantee that the reduction in authorization will take effect prior to the expiration of the original token. > We rely heavily on the AS to accurately provide binding of raw key > material to authorization information and endpoint identinty; I think > this is a stronger reliance than just that implied by the core > architecture, and so might merit a mention here. (This relates to all > the checks about "MUST check that [client/...] is associated with > [RPK/PSK]" that appear throughout the document.) We are not sure if this is specific to this profile. For any profile within the ACE framework, the AS must know C and RS and must know their keys. In this profile, we just describe what the AS needs to do to address these requirements. > I'd also suggest reiterating all the places where we rely on out-of-band > configuration, as there's always a risk of such configuration becoming > stale (or getting attacked directly). Most parts of the document already now do this. We have added an additional remark in Section 3.1 to ensure that the client checks that the authorization information about the AS is still valid. We have also added a new subsection to the Security Considerations that describes the configuration and authorization information that must be provided to the authorization server, the resource server, and the client outside of the ACE DTLS profile. NEW: 7.1 Out-of-Band Configuration To communicate securely, the authorization server, the client and the resource server require certain information that must be exchanged outside the protocol flow described in this document. The authorization server must have obtained authorization information concerning the client and the resource server that is approved by the resource owner as well as corresponding keying material. The resource server must have received authorization information approved by the resource owner concerning its authorization managers and the respective keying material. The client must have obtained authorization information concerning the authorization server approved by its owner as well as the corresponding keying material. Also, the client's owner must have approved of the client's communication with the resource server. The client and the authorization server must have obtained a common understanding how this resource server is identified to ensure that the client obtains access token and keying material for the correct resource server. If the client is provided with a raw public key for the resource server, it must be ascertained to which resource server (which identifier and authorization information) the key is associated. All authorization information and keying material must be kept up to date. > I'd consider reiterating that when the KDF scheme is in use between RS > and AS, that kid uniqueness is paramount, as using the same kid for > multiple clients and the same RS would have potentially disasterous > consequences in that case. Not sure if this is specific to the key generation through KDF, as the kid is typically used to find the access token that was uploaded to the auth-info endpoint? > Similarly (though this is inherent to symmetric PoP and may not actually > need reiterating), when we use symmetric PSKs for PoP, they lose almost > all value if any given PSK is known to more than one client or RS. (The > secdir review on the framework has us putting in MUST-level requirements > to not share further than that, so it seems pretty reasonable to not > duplicate that warning here.) Okay. This was one of things that we deemed obvious=E2=80=A6 > This document specifies a profile for the Authentication and > Authorization for Constrained Environments (ACE) framework > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general > approach, the general security considerations from section 6 also > apply to this profile. > > (The HTMLized link will only do the right thing if you use the redundant > "section 6 of [I-D.ietf-ace-oauth-authz]".) done > The use of multiple access tokens for a single client increases the > strain on the resource server as it must consider every access token > and calculate the actual permissions of the client. Also, tokens may > contradict each other which may lead the server to enforce wrong > permissions. If one of the access tokens expires earlier than > others, the resulting permissions may offer insufficient protection. > Developers SHOULD avoid using multiple access tokens for a client. > > I think I touched on this above; did we want to make a stronger > statement about "only one active token per client"? At the time this was written, the framework document was pretty unclear about this. Now, it would be possible to have multiple access tokens for a client if you knew how to merge the authorization rules. We have changed the update mechanism to clearly state that a new token replaces the old one. The question is if we still need this paragraph. > Section 8 > > information as possible in an unencrypted response. When a DTLS > session between the client and the resource server already exists, > more detailed information MAY be included with an error response to > provide the client with sufficient information to react on that > particular error. > > I'd suggest adding a caveat like "an authenticated client" or > "a known client", since DTLS itself does not guarantee that the client > is not an attacker. done > Section 9 > > Profile ID: 1 > > I think this has to be merely a "suggested value", as IANA will control > the actual allocations, in the absence of a reservation of this value in > the framework document. done > Section 10.1 > > We don't currently reference RFC 7925 in any way that would require it > to be a normative reference. We probably should, though -- somehow pull > in that we require/recommend conformance with that profile of DTLS. We are not sure if there is anything special about RFC 7925 that we explicitly want to point out. However, as we have the requirement of treating the access token in the psk_identity as opaque binary data, we have moved the reference RFC 7925 into the normative section. > Section 10.2 > > I think RFCs 7250, 7251, and 8422 need to be normative. done Gr=C3=BC=C3=9Fe Olaf From nobody Tue Apr 14 11:36:10 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFD53A0D9A for ; Tue, 14 Apr 2020 11:36:06 -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, SPF_HELO_NONE=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 dD5JCw6ErV-H for ; Tue, 14 Apr 2020 11:36:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26CB3A0AB1 for ; Tue, 14 Apr 2020 11:35:42 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 14 Apr 2020 11:35:36 -0700 From: Jim Schaad To: References: <04eb01d60d58$e46118a0$ad2349e0$@augustcellars.com> In-Reply-To: <04eb01d60d58$e46118a0$ad2349e0$@augustcellars.com> Date: Tue, 14 Apr 2020 11:35:34 -0700 Message-ID: <014201d6128b$7d65dc70$78319550$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHiZysu6VRNEHJwBAjrX9ZCwws0sqhgSICw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Scheduling additional interim meetings X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 18:36:08 -0000 Reminder - If you want to have input on when the next two meetings are going to be, you need to fill out the doodle poll. Jim -----Original Message----- From: Ace On Behalf Of Jim Schaad Sent: Tuesday, April 7, 2020 8:51 PM To: ace@ietf.org Subject: [Ace] Scheduling additional interim meetings Daniel and I would like to schedule two additional interim meetings to occur in May and June. I have created a doodle poll for the times that I know that I am available and would like to get people to fill it in. The poll has options for May dates in it. The June dates would be 4 weeks later so please look at both the May and June dates when filling out the poll. As an example, May 12th and June 9th are represented as May 12th in the poll. https://doodle.com/poll/e7vtvi5zx3eekcgw Thanks for filling this in. We should be able to announce the final dates at the April 15th interim meeting. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Wed Apr 15 09:26:54 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841A53A0BA3 for ; Wed, 15 Apr 2020 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 w9oHGkK_OSfX for ; Wed, 15 Apr 2020 09:26:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53773A0985 for ; Wed, 15 Apr 2020 09:26:51 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 15 Apr 2020 09:26:47 -0700 From: Jim Schaad To: Date: Wed, 15 Apr 2020 09:26:44 -0700 Message-ID: <000701d61342$a8c6f9f0$fa54edd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYTQpj/DPh/VELaT3+yB6Qb6UYhJg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Minutes have been uploaded X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 16:26:54 -0000 I have uploaded minutes to the Datatracker. Please review and comment with corrections. Jim From nobody Sun Apr 19 19:19:58 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9923B3A0C70; Sun, 19 Apr 2020 19:19:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, ace-chairs@ietf.org, mglt.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158734919751.19053.2274253984414663555@ietfa.amsl.com> Date: Sun, 19 Apr 2020 19:19:57 -0700 Archived-At: Subject: [Ace] ace - New Interim Meeting Request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 02:19:58 -0000 A new interim meeting series request has just been submitted by Daniel Migault. This request requires approval by the Area Director of the Security Area The meetings can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-06 https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-07 Meeting: 1 --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Meeting Type: Virtual Meeting Session 1: Date: 2020-05-18 Start Time: 10:00 America/New_York Duration: 01:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee Agenda Note: --------------------------------------------------------- Meeting: 2 --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Meeting Type: Virtual Meeting Session 1: Date: 2020-06-22 Start Time: 10:00 America/New_York Duration: 01:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee Agenda Note: --------------------------------------------------------- From nobody Sun Apr 19 19:20:07 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A43373A0CC0; Sun, 19 Apr 2020 19:20:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, ace@ietf.org, ace-chairs@ietf.org, mglt.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158734920422.18667.7936233982184966743@ietfa.amsl.com> Date: Sun, 19 Apr 2020 19:20:04 -0700 Archived-At: Subject: [Ace] ace - New Interim Meeting Request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 02:20:06 -0000 A new interim meeting series request has just been submitted by Daniel Migault. This request requires approval by the Area Director of the Security Area The meetings can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-08 https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-09 Meeting: 1 --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Meeting Type: Virtual Meeting Session 1: Date: 2020-05-18 Start Time: 10:00 America/New_York Duration: 01:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee Agenda Note: --------------------------------------------------------- Meeting: 2 --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Meeting Type: Virtual Meeting Session 1: Date: 2020-06-22 Start Time: 10:00 America/New_York Duration: 01:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee Agenda Note: --------------------------------------------------------- From nobody Mon Apr 20 18:53:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEBE3A151C; Mon, 20 Apr 2020 18:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 JRb1y5k1Vz1I; Mon, 20 Apr 2020 18:53:45 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AA4F23A151A; Mon, 20 Apr 2020 18:53:45 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03L1ref2014139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Apr 2020 21:53:42 -0400 Date: Mon, 20 Apr 2020 18:53:40 -0700 From: Benjamin Kaduk To: IETF Meeting Session Request Tool Cc: ace-chairs@ietf.org, mglt.ietf@gmail.com, ace@ietf.org Message-ID: <20200421015340.GJ27494@kduck.mit.edu> References: <158734919751.19053.2274253984414663555@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158734919751.19053.2274253984414663555@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] ace - New Interim Meeting Request X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 01:53:48 -0000 FYI these showed up in the system as duplicates. I think I approved one set and cancelled the other, but please let me know if I fat-fingered it. -Ben On Sun, Apr 19, 2020 at 07:19:57PM -0700, IETF Meeting Session Request Tool wrote: > > A new interim meeting series request has just been submitted by Daniel Migault. > > This request requires approval by the Area Director of the Security Area > > The meetings can be approved here: > https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-06 > https://datatracker.ietf.org/meeting/interim/request/interim-2020-ace-07 > > > Meeting: 1 > --------------------------------------------------------- > Working Group Name: Authentication and Authorization for Constrained Environments > Area Name: Security Area > Session Requester: Daniel Migault > > Meeting Type: Virtual Meeting > > Session 1: > > Date: 2020-05-18 > Start Time: 10:00 America/New_York > Duration: 01:30 > Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee > Agenda Note: > > --------------------------------------------------------- > Meeting: 2 > --------------------------------------------------------- > Working Group Name: Authentication and Authorization for Constrained Environments > Area Name: Security Area > Session Requester: Daniel Migault > > Meeting Type: Virtual Meeting > > Session 1: > > Date: 2020-06-22 > Start Time: 10:00 America/New_York > Duration: 01:30 > Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee > Agenda Note: > > --------------------------------------------------------- > > From nobody Mon Apr 20 19:12:27 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5C53A14CC; Mon, 20 Apr 2020 19:12:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158743514464.14263.8072013608148073068@ietfa.amsl.com> Date: Mon, 20 Apr 2020 19:12:24 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 02:12:25 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_York (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee From nobody Mon Apr 20 19:12:54 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1333A1597; Mon, 20 Apr 2020 19:12:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158743516301.30959.10002529037129135480@ietfa.amsl.com> Date: Mon, 20 Apr 2020 19:12:43 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-06-22 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 02:12:53 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-06-22 from 10:00 to 11:30 America/New_York (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee From nobody Tue Apr 21 09:07:46 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE23A0D75 for ; Tue, 21 Apr 2020 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 y3cN70o6KT-4 for ; Tue, 21 Apr 2020 09:07:41 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (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 038A93A0E99 for ; Tue, 21 Apr 2020 09:07:22 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id QvQfjZ4Pn4NFGQvQgjCxdo; Tue, 21 Apr 2020 09:07:22 -0700 X-CMAE-Analysis: v=2.3 cv=EPx4LGRC c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=WMtHHQaCRWcHGEDLbcIA:9 a=QEXdDO2ut3YA:10 a=UcTN6IUWVUINGMuQfjEA:9 a=4RQ5A1VLkLRPNQEQ:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 Apr 2020 09:07:21 -0700 In-Reply-To: <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com> Cc: "Smith, Ned" , Henk Birkholz , "rats@ietf.org" , Jim Schaad , "cbor@ietf.org" , Ace Wg To: Carsten Bormann References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfF4SID21nOVc+Hqcj19ynLHV7g/QQGgOBc80lxQWhb31uVS8bzgJSRGrKKs5kEBtve7L9ao0lrmNkaN48tHAnA5q2mNwC1+caCmrbjyHqHFeZiK3ki3y AsrRKKAJLFnqgBOGaz4Q+lYRnF3ZS1x6YAaqpVG12nt8gqEcUZWdL14DFJDzLzjDg/+07PQ9+U+GHtJG7cgWYprmER7jUMINTAjlS38PFS1M5p9pCOqbq3dV hHcqjtdS/d92ofjRftV5b++eMz48n6u+QrrwxO+MxqsKJM2+QAvk1d1ADxIA8R2BjNZvjFkIgP2v34OZGtz202KV96LVfH0jfjtJiUpaPsQ= Archived-At: Subject: Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 16:07:44 -0000 --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have created a PR = against the EAT draft for UCCS and UJCS. I=E2=80=99m not sure this = really belongs in the EAT draft, but I thought I=E2=80=99d start by = putting it there. LL P.S. If we were do an update to CWT to accommodate this, it would also = be good to add CDDL describing CWT. That is another thing I=E2=80=99ve = got in the EAT draft, that probably belongs elsewhere. > On Mar 6, 2020, at 6:27 PM, Laurence Lundblade = wrote: >=20 > Pretty sure UCCS as Carsten describes below works for me provided: >=20 > - All the rules and requirements from CWT explicilty apply except = signing/encryption > - It uses the same registry > - There is a tag defined for it > - You get an (untagged) UCCS when you remove all signing and = encryption layers >=20 > LL >=20 >=20 >> On Mar 6, 2020, at 12:04 PM, Carsten Bormann wrote: >>=20 >> Hi Ned, >>=20 >> What I was trying to say is that the Unprotected CWT Claims Set = (UCCS) is not a CWT, but an UCCS. So I wouldn=E2=80=99t call it a token = (which implies some form of protection to me). But it is still a useful = data structure to carry around. >>=20 >>> On 2020-03-06, at 20:59, Smith, Ned wrote: >>>=20 >>> The earlier thread suggested that a naked token could be given to a = parser that was programmed correctly and it would 'just work'. But if = the definition of a CWT/JWT is that it must have bounding signature, = mac, encryption enveloping, then the parser should reject naked tokens = (tagged as such or not).=20 >>=20 >> A CWT decoder would diagnose an UCCS as =E2=80=9Cnot a CWT=E2=80=9D. >> A CWT/UCCS decoder would diagnose it as =E2=80=9CUCCS=E2=80=9D. >>=20 >>> If the naked token is defined and the map has a tag that indicates = it was formed without secure enveloping then the parser should accept = it, but the code using the parser needs to find some other way to ensure = security.=20 >>=20 >> Right. An UCCS is only a useful assertion if received over a secure = channel with the right properties to make it a useful assertion. >>=20 >>> If a parser receives a map with both security enveloping and the = naked token tag, then it should return both the map and the security = envelope context and let the code using the parser decide if the = security context satisfies the security requirement. >>=20 >> Well, it should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not = an UCCS either). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have created a PR against the EAT draft for UCCS and UJCS. =  I=E2=80=99m not sure this really belongs in the EAT draft, but I = thought I=E2=80=99d start by putting it there.

LL

P.S. If we were do an = update to CWT to accommodate this, it would also be good to add CDDL = describing CWT. That is another thing I=E2=80=99ve got in the EAT draft, = that probably belongs elsewhere.



On Mar = 6, 2020, at 6:27 PM, Laurence Lundblade <lgl@island-resort.com> wrote:

Pretty= sure UCCS as Carsten describes below works for me provided:

- All the rules and requirements from CWT = explicilty apply except signing/encryption
- It uses the = same registry
- There is a tag defined for it
- You get an (untagged) UCCS when you remove all signing and = encryption layers

LL


On Mar 6, = 2020, at 12:04 PM, Carsten Bormann <cabo@tzi.org> wrote:

Hi = Ned,

What I was trying to say is that the = Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS.  So I = wouldn=E2=80=99t call it a token (which implies some form of protection = to me).  But it is still a useful data structure to carry = around.

On 2020-03-06, at 20:59, Smith, Ned <ned.smith@intel.com>= wrote:

The earlier thread suggested that a = naked token could be given to a parser that was programmed correctly and = it would 'just work'. But if the definition of a CWT/JWT is that it must = have bounding signature, mac, encryption enveloping, then the parser = should reject naked tokens (tagged as such or not).

A CWT decoder would diagnose an = UCCS as =E2=80=9Cnot a CWT=E2=80=9D.
A CWT/UCCS decoder = would diagnose it as =E2=80=9CUCCS=E2=80=9D.

If the naked token is = defined and the map has a tag that indicates it was formed without = secure enveloping then the parser should accept it, but the code using = the parser needs to find some other way to ensure security.

Right.  An UCCS is only a = useful assertion if received over a secure channel with the right = properties to make it a useful assertion.

If a parser receives a = map with both security enveloping and the naked token tag, then it = should return both the map and the security envelope context and let the = code using the parser decide if the security context satisfies the = security requirement.

Well, it = should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not an UCCS = either).

Gr=C3=BC=C3=9Fe, Carsten

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

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

= --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA-- From nobody Wed Apr 22 08:23:16 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078A83A0E82 for ; Wed, 22 Apr 2020 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 feTcMsfnHRk4 for ; Wed, 22 Apr 2020 08:23:13 -0700 (PDT) Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 9DDDE3A0E7F for ; Wed, 22 Apr 2020 08:23:13 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id RHDUjCnJxaTvaRHDVjsdok; Wed, 22 Apr 2020 08:23:13 -0700 X-CMAE-Analysis: v=2.3 cv=YYnDGDZf c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=ZbKh0HJnzUMA:10 a=IkcTkHD0fZMA:10 a=H_2F2HXJbL2iPrxgAqoA:9 a=QEXdDO2ut3YA:10 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=jd6J4Gguk5HxikPWLKER:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <44737D23-ADDF-4F43-8C68-B898C06DBD69@island-resort.com> Date: Wed, 22 Apr 2020 08:23:12 -0700 To: Ace Wg X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfFHgWumhipfJNzOWZSYDVpWenmslk52np0b6UKeql4oeJoryazGV1b2ZpCsqzpS5Wzq4YXZMC57ck5wAUY8O9A1T+VXj+UJkkMdCTQIWjzoFPewFBuUM OJPXffF9fmuuNrWcvu2OxLXW1ChcvvPXrczD5dgq3L3qoIP3ODzavOGC Archived-At: Subject: [Ace] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 15:23:15 -0000 I have a few comments / questions about = draft-raza-ace-cbor-certificates-04.txt section 6 on native CBOR certs When you sign CBOR, usually it is wrapped in a bstr. This is important = to be able to use typical CBOR encoders/decoders. This doesn=E2=80=99t = seem to be the case here, at least I don=E2=80=99t see it in the text = near the end of section 3. Was any consideration given to using the COSE algorithm registry rather = than defining a new one? But of most interest to me is whether the COSE was considered as the = signing format for native CBOR certs. If COSE is used, then this looks = almost identical to CWT and may be a native CBOR cert is a variant of a = CWT? One advantage of this would be reuse of some of the CWT (and EAT) = code. Some of the fields in the CBOR cert might overlap with CWT claims. = That might be a good thing. LL From nobody Fri Apr 24 04:35:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA33A0942 for ; Fri, 24 Apr 2020 04:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_BLOCKED=0.001, 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=risecloud.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 dDdJuC2cnDTw for ; Fri, 24 Apr 2020 04:35:36 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40067.outbound.protection.outlook.com [40.107.4.67]) (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 415013A0940 for ; Fri, 24 Apr 2020 04:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZBI5MMkxvLUAuJMux46A/WmC6SGH2QCS9QEbUsW4UKeJHE6e/6Oq15kyJjdzBlAr3iRo3g6RLT3xD+JdBxCf8GMwhQCiyZueesFtUIHND3slg4adiz328QLoCH/bsPdPfs4xYht5AtBdEXMOv89gBHeNa/EFKR10fzs5S36Nh06j3Y0WwF5pm75o2XP+nKMXJO5cq6s9lGdEG/J2TJXVsqj7z0pcq4KW89uyTTFXEru1ZUEFEN1hE5x4aNZ2nTIE6ut9av247xU4tBQzyx+P1pkbMsDxMGPM3EoDNKkUDs93FENoHJRLhzGjaN0npqw/5AoIUykqYh8y4Jb2XzZ5eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NayDq7Ow32qipLzd8xcx4McdqMAMgwZlU02yhPggp5I=; b=nQDSkzIHQ+yMG5/yft0H/hbEpiMi/gm6i7EGDQxUJIWoiAZlT6M/a69ha9nNRvvjgdziAeTr7RQADxFOVO9XVro/CrDpYVONLqjky9yslnUVJFMyy0DjcoX6Alm0SoIkYeX8P2v+YKrUUWu0RDW9Pq0K++i2Q9BSmG7MFFcvXoMi8hx1+Idb/gpypufhy3B753AA9PZRQm0yI5uheS4l0tIHSRoXADBQyDZ43Uw8LEXAUpfho7dhLCVY1eL83zdmQI/iZ8xDo9Y7eu6SAGY66N4X8QuyjvR2ti0hHJ5MzbC1KDRd3uHzFnOQ+LZwxh6QzylSJW1DyC88wAkwxoP/ZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NayDq7Ow32qipLzd8xcx4McdqMAMgwZlU02yhPggp5I=; b=g5JC5WHaxVBHHoZRmWj8jitGLaxCx2+n6gnPUy7Ybcm/GB774yFXJxmheblgilNXWU1FfAt/TdKtmMJwHKZ04V23JihuqRN5ASsj/8HxPf8JHhuscym+rCWEC0JIXsBcsKiq3uX9o1Txf6GyY+eE1QH/mzklQm5CHiQ0YErqRgo= Received: from HE1P189MB0363.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:59::22) by HE1P189MB0347.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:58::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr 2020 11:35:33 +0000 Received: from HE1P189MB0363.EURP189.PROD.OUTLOOK.COM ([fe80::611d:120e:2090:38e4]) by HE1P189MB0363.EURP189.PROD.OUTLOOK.COM ([fe80::611d:120e:2090:38e4%3]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 11:35:33 +0000 From: =?Windows-1252?Q?Joel_H=F6glund?= To: Ace Wg Thread-Topic: [Ace] draft-raza-ace-cbor-certificates-04.txt Thread-Index: AQHWGLoC6fimJTZ8RE2inCVQn/ODz6iIJw4l Date: Fri, 24 Apr 2020 11:35:33 +0000 Message-ID: References: <44737D23-ADDF-4F43-8C68-B898C06DBD69@island-resort.com> In-Reply-To: <44737D23-ADDF-4F43-8C68-B898C06DBD69@island-resort.com> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=joel.hoglund@ri.se; x-originating-ip: [79.136.50.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 839fd0d2-983c-43a9-b374-08d7e843998f x-ms-traffictypediagnostic: HE1P189MB0347: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1P189MB0363.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39860400002)(136003)(396003)(376002)(9686003)(81156014)(8676002)(5660300002)(33656002)(8936002)(316002)(66574012)(6506007)(86362001)(52536014)(478600001)(186003)(55016002)(66476007)(2906002)(966005)(26005)(19627405001)(76116006)(7696005)(66946007)(64756008)(66556008)(6916009)(71200400001)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pm0SC+M3ER0sV++LKPe9BpoExxPUymIV1aCycdlpNF3GjhNKPaGLkWyzOUeuZcL+kPBeDt6PjxuBCwWTPR2QW+fZ2hdp28Clv3XiBnrzQPJ0OMq18VjtbgEDTimIkAIl1Vm/0Y6XE7EPBpSd1z/OIpcoJv7kgRtcXEipsA5McHPzXq6yxIkREeyB+lSm3p9KCsHIfSsV1QyPfFISzMI5E4Rc7gd9YZsPjDDbrPPerYZkTOc3hMZNMNP1+seYBXo/nHezvy+ydg2/sRYxQ0IKhws7cUhtBbPA8+9pDvLw/NxVkRjID9hOheudysSytk4GiOmymv2x0EIaRisfCzxK+mW3CJnWGLl+x6JVPlf9bmbtD1oalwJBFL7Z4lDImDzT4CBs3ZkLz9cpiDF96U4Q79nebv+lvZAzI8uyEWmDMPXFduCR2X/efFw+XcZnYdjwX6YdW+caqv04XABlXFWYkRtsPwBzYxOVtEdUwWG2DbNC6MFin0dMSiQyOStkQBazPayYEfRypdz/GSZ/LFTedQ== x-ms-exchange-antispam-messagedata: HB6zKJ3L7YamfHeupI9lxn00bsap7pCt4YYUAfQCpgc1qLDDPeELU5v8IYuzs1UhhDExXbU0vjRKJn2yGRSxRU1i/q/ggwfMgFiVLLur2dBw+LaURksALch9KHuaOTl3PYniO6yFKKRE9tdYGKJANtFk0e/f4dXpv4zjRTYhvLdakn4zGbxj6Ua9qs4TK8qCoHewQ9Z1ADMS+RMb3939RK3sAtQyLVDpOZiVf9MMVBTwjo8eO2XVpxNKqCfVclUOXZILdZMai/6rPxVqniCXrN0A6SKhxxTwufJ6UXnvap0AaQdsScoXnPmgdlJ9byHweE3aTMfrXuHlMm4OLNcia4Dn2h+osN0ZNkPS4XL9LeR8acSJ2oUUETXKDe0L9uCU+le4JcLk7iPv3sxrnogUv0e7woSeqbf6sYP65ehdP2k80sdLs+ZQKc0vcdgae6NaeUkRrYKBQvdXL5OJlORludeu9s2XyIqQtLpngflrK8rsQMwje3iwxxeJo6g0ldJK3RjIEIiBc8YShmBNgBVihWPdGy2Nt8DzG262EcTFVsBU2r9p9hIv9uro9SCrg3kX7uVKlfUxFvovpOfE3bFG1JJONvcSawUMGRmvyAUTD/X+lAesivLjJns1v74sxTZyiWoUonJGsJ3AnpTEqscvgtj6uA9V3RQ3qL70vdG+IxlIp1JDFbW6x/OHfqna8frw/3urDEF9ejOFHb66l2HpQ83G71DIHvLAmIP9x2/gQ2b+znP60Q1uOe5wjwRSJDjCS7mJ4kKxOGTdORr8zfDwNKo/E3auFDn+ax7jQstgUv8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1P189MB0363DD95A30BB2C2356F9C8288D00HE1P189MB0363EURP_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 839fd0d2-983c-43a9-b374-08d7e843998f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 11:35:33.1719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5xDDiJuFWgzDQnyKrIhTWNqEqbBYzjYrjcDsLk2CTasXNsraY+gwU81MO5BWp2RO+9P03MGp1YmD6qfBzfiHuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P189MB0347 Archived-At: Subject: Re: [Ace] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 11:35:39 -0000 --_000_HE1P189MB0363DD95A30BB2C2356F9C8288D00HE1P189MB0363EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! First a meta comment: I=92m now answering to both the ACE and the CORE mail= ing list. If the working group chairs have recommendations on where to keep= the continued discussion I=92m eager to hear. Thank you for your review! Some answers to the questions are inline below. > When you sign CBOR, usually it is wrapped in a bstr. This is important > to be able to use typical CBOR encoders/decoders. This doesn=92t seem > to be the case here, at least I don=92t see it in the text near the end o= f > section 3. Since this bstr wrapping has become the expected norm we agree this is a go= od suggestion for an improvement with low overhead, which we will add for t= he next version. > Was any consideration given to using the COSE algorithm registry rather > than defining a new one? Yes, it is still work in progress to determine if the COSE algorithm regist= ry can accommodate the algorithms deemed useful for inclusion. > But of most interest to me is whether the COSE was considered as the > signing format for native CBOR certs. If COSE is used, then this looks > almost identical to CWT and may be a native CBOR cert is a variant of > a CWT? =85 =85 Our starting point has been to stay close to the original X.509 format whil= e minimizing size. A COSE encoding would re-add some format overhead (close= to 10% for the provided example certificate). But if a COSE encoding would= help making the format accepted and used, it can definitely be further dis= cussed. Once again, thank you for your comments! and Best Regards Joel H=F6glund ________________________________ Fr=E5n: Ace f=F6r Laurence Lundblade Skickat: den 22 april 2020 17:23 Till: Ace Wg =C4mne: [Ace] draft-raza-ace-cbor-certificates-04.txt I have a few comments / questions about draft-raza-ace-cbor-certificates-04= .txt section 6 on native CBOR certs When you sign CBOR, usually it is wrapped in a bstr. This is important to b= e able to use typical CBOR encoders/decoders. This doesn=92t seem to be the= case here, at least I don=92t see it in the text near the end of section 3= . Was any consideration given to using the COSE algorithm registry rather tha= n defining a new one? But of most interest to me is whether the COSE was considered as the signin= g format for native CBOR certs. If COSE is used, then this looks almost ide= ntical to CWT and may be a native CBOR cert is a variant of a CWT? One adva= ntage of this would be reuse of some of the CWT (and EAT) code. Some of the= fields in the CBOR cert might overlap with CWT claims. That might be a goo= d thing. LL _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_HE1P189MB0363DD95A30BB2C2356F9C8288D00HE1P189MB0363EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi!


First a meta comment: I=92m now answering to both the AC= E and the CORE mailing list. If the working group chairs have recommendations on where to keep the continued discussio= n I=92m eager to hear.


Thank you for your review! Some answers to the questions= are inline below.


> When you sign CBOR, usually it is wrapped in a bstr= . This is important

> to be able to use typical CBOR encoders/decoders. T= his doesn=92t seem

> to be the case here, at least I don=92t see it in t= he text near the end of

> section 3.


Since this bstr wrapping has become the expected norm we= agree this is a good suggestion for an improvement with low overhead, which we will add for the next version.


> Was any consideration given to using the COSE algor= ithm registry rather

> than defining a new one?


Yes, it is still work in progress to determine if the CO= SE algorithm registry can accommodate the algorithms deemed useful for inclusion.


> But of most interest to me is whether the COSE was = considered as the

> signing format for native CBOR certs. If COSE is us= ed, then this looks

> almost identical to CWT and may be a native CBOR ce= rt is a variant of

> a CWT? =85 =85 


Our starting point has been to stay close to the origina= l X.509 format while minimizing size. A COSE encoding would re-add some format overhead (close to 10% for the pr= ovided example certificate). But if a COSE encoding would help making the f= ormat accepted and used, it can definitely be further discussed.


Once again, thank you for your comments!


and


Best Regards


Joel H=F6glund


Fr=E5n: Ace <ace-bounces= @ietf.org> f=F6r Laurence Lundblade <lgl@island-resort.com>
Skickat: den 22 april 2020 17:23
Till: Ace Wg <ace@ietf.org>
=C4mne: [Ace] draft-raza-ace-cbor-certificates-04.txt
 
I have a few comments / questions about draft-raza= -ace-cbor-certificates-04.txt section 6 on native CBOR certs

When you sign CBOR, usually it is wrapped in a bstr. This is important to b= e able to use typical CBOR encoders/decoders. This doesn=92t seem to be the= case here, at least I don=92t see it in the text near the end of section 3= .

Was any consideration given to using the COSE algorithm registry rather tha= n defining a new one?

But of most interest to me is whether the COSE was considered as the signin= g format for native CBOR certs. If COSE is used, then this looks almost ide= ntical to CWT and may be a native CBOR cert is a variant of a CWT? One adva= ntage of this would be reuse of some of the CWT (and EAT) code. Some of the fields in the CBOR cert might = overlap with CWT claims. That might be a good thing.

LL




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/= mailman/listinfo/ace
--_000_HE1P189MB0363DD95A30BB2C2356F9C8288D00HE1P189MB0363EURP_-- From nobody Mon Apr 27 05:00:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F9D3A045E; Mon, 27 Apr 2020 05:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=ericsson.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 jdj7_PGiqJSf; Mon, 27 Apr 2020 05:00:21 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20044.outbound.protection.outlook.com [40.107.2.44]) (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 5ACE93A044E; Mon, 27 Apr 2020 05:00:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wnd7mc4Zv0K1smI8lVWz2gH9GuqhkenVzTlX3lrZcVg7mxm9pCIJcxhCyy9JRREj3aA8uZLdndJwKO7Q8VXBWTfj6+5vmeX7T2Tyw2aCWiKguGjSxRxT7iReTBRyPQ4HCzOQeDCOh+nIQ/7dpPgJA+1c+m2luJegNChUtN0/O+Aj+PIZEjq+wdN6DrkkFe4xbAiJnwCQ6tToh9g0QlcytKxc1Zy0ZgcXjGu42XL9D6Mq7L/vY8whbI0LUC9dfwKdhCOgJubJpV2iqRRrrQSnTI1NugE7412Ki0bkRSq0V7cLqh+bztFaWiSSzff+8ueQimBaRfEkqlBNFYa6mAEcww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ESZ7szV0th7osmMJtRKG9/i1kia6rEztazeOEIiR5U8=; b=oApymZUhboDIxs6VJ8Qe/dqxaXaNqVeVHtddZIabmCcZazvk4ezpjm2A337oqetsobTHoyz8o5TrMrWYXnSarysZZsFH87F53hUP4hFb8uHSIIcKMVk/KRlN+PVu/CTpHvJ7mDpDbGsYhmiFiZbHtfZfk2/saybHySCh/D/7x029lU/H8pgNPIwyAy7j0vOtrXQN8dKC23oCmASXbhfg9bJq6t0G2F41XXJiV3Gonv/phsdr5efuTWAE3N9NvQhQOke8KUI3ykkm+3HYhm/oixStmfp0jGG0jU7P9d1444l3NCFBogzdhYJA25G4IzFu0wX8qzEk09igzpiID1BtcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ESZ7szV0th7osmMJtRKG9/i1kia6rEztazeOEIiR5U8=; b=QA8uozjKNtSPoiWxwGvYixS/M9VrQKBjvhcR1mQL0CL044BHSd6JrFt6XM+N0B3PwpuNWTTDvVeBLnWOzrHPA1o4D7/AWWUce/WQW283VvO6V6Ued46K1opubjr9zsI/HLx4cAmsAjvnIo1HHfB8Q2G7xgrw084MwE+/LWQMrw4= Received: from VI1PR07MB5023.eurprd07.prod.outlook.com (2603:10a6:803:9e::13) by VI1PR07MB5805.eurprd07.prod.outlook.com (2603:10a6:803:d7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Mon, 27 Apr 2020 12:00:18 +0000 Received: from VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321]) by VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321%7]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 12:00:18 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade , =?utf-8?B?Sm9lbCBIw7ZnbHVuZA==?= CC: "cose@ietf.org" , "ace@ietf.org" Thread-Topic: [COSE] [Ace] draft-raza-ace-cbor-certificates-04.txt Thread-Index: AQHWGjAedUYMYk6mBEmSoRUOvFZ8rKiIoCaAgARj1wA= Date: Mon, 27 Apr 2020 12:00:18 +0000 Message-ID: <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> In-Reply-To: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.246.8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f84a7ff0-ea59-4f21-84a4-08d7eaa28e27 x-ms-traffictypediagnostic: VI1PR07MB5805: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB5023.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(110136005)(316002)(6512007)(6486002)(33656002)(8676002)(36756003)(54906003)(85182001)(85202003)(86362001)(81156014)(53546011)(6506007)(2906002)(71200400001)(2616005)(478600001)(66556008)(4326008)(966005)(66574012)(64756008)(26005)(8936002)(5660300002)(66446008)(76116006)(186003)(91956017)(66476007)(66946007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dnT0jW6SqfbjKgMoi0zw9IZUtguAAQUzQ9ZaEz1cL69DbMK/eBP81CsmARFdhnPuWxuCZoE0ahNfirlcUldspD2NN5i3Wy770qi761PIPj8JJvzd5viyKP5IRqTWSHHkYQXuqwWNh37kajmD7sd2bujSt7yD9PPWa2k7Wr8a4ytTgCcF54U4poElAZdw28uNMMGq59lGPEY1icGPySb8quPVCepNU6ESHFt2BcvAkRS13hdt+bzOyrpy+KpNht3rzb2IV5KLzQdREN7iu7SFBSN4F0ty4lgJJYKgr6d1CauJqTsjmFdodvbf70BXZ/jiCpS0B8NBLEJ3Z4h4YU55p63d7gO3YG7MER3xM5O0cD9xH4PpD9hv2rDjbYMCZ//Dj4HumNhn/L3xBBDbjzN8d5s+4NfAbcXdpXhz3lAOnIzo+yi1sKRODOnzfVfJxYLquRUaBifRV1VtBi0+l9RjvtsEo7TpU1c81UoQQIYDdEEGqyofwrGQXeqxEwVTH0W069L1ZSnqUylf3vWkjOb08g== x-ms-exchange-antispam-messagedata: YWOMbKANK5mPWgZOxW7I3IGnXc+ybGInJYCSL4oJRjYlOyxstpIvPY/T7yvCg2Cwo/lqUzOk0IK6NCz/v/6Ad72akQUY5xlrZrVH+yIDSAGK4VrmcNwtNY3YqElSQ894Iz5EsFV0Y8rmjyM1gRq7S3N4nlisLyWqQYxvJYyL4chCuJOZsqhjXc0U0QYRMTDZhH7eyZ9WX1YRQQfSL2eZHPG6rin2Dv8zT3QcpMAhxo4kS++4Ij5MwuKfNU2atea1oTBPh8MULJ0KcR8xGZmE0YWlXXvajF43vQoQOB6UEPQrrkQoBi9hSzhEKz0NleE1oq9y/Lpf5e1hY7Q/YdZ4mTjnCCAaW4K6uiM8a75macu+Vb58aEQlfBMp5MWN29pFFzaVwzo5m5gqUf3QaSnfax7ZV67blCHV1RU8HuxRdH0LL16CUlldqn5bueB97ePoggVqEsqy6QXeBEpexSCZWU+W+xY2gT+d9ofI5juNVLCtmdEA1tiH0t75MiMlHfdUoC5JdnwZueKry9EiETWOjHUTxewa+qYcE3HJNIG9XUtOGB8i47l/nSn3tdqgk535B/Ag67VYuCVrjAjPdkVHQ09JYPDt4+vH9z7lHxUm8iyc/ZHBspB9t3/NHNcxfLFQ17leU/DZYU1tETf19UZE4ACd6L4e8uksRqL/Js4eouO3altuGSO5oNTcLt0CGfbGQKlqNLFLOCMIStqbGZ/4vRhnqRtbJ0iaObXpK81y9QcgHry2yK71vFM3nOo0m+PPEBl7LAOzt9stdWB3zg9DkzWLqHMEXshIpMcganpoXTQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_964634A47B614CEF8ED06A9A48D984CDericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f84a7ff0-ea59-4f21-84a4-08d7eaa28e27 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 12:00:18.5131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SlrRtgPkCh8IdENHO+B41R8q2rxUlOABoO613PytTJpcB4LkIM/PShgpfUbBp+nsywbpYBAl0c2xa6jQBZ9VLyxLgVMZ6TBqi+6PXmfZU7M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5805 Archived-At: Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 12:00:24 -0000 --_000_964634A47B614CEF8ED06A9A48D984CDericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVuY2UsDQoNCihDb3B5aW5nIGJvdGggQUNFIGFuZCBDT1NFIHBlbmRpbmcgZnVydGhl ciBub3RpY2UgYWJvdXQgcmlnaHQgbWFpbCBsaXN0LikNCg0KQ29tbWVudHMgaW5saW5lLg0KDQpG cm9tOiBDT1NFIDxjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBMYXVyZW5jZSBM dW5kYmxhZGUgPGxnbEBpc2xhbmQtcmVzb3J0LmNvbT4NCkRhdGU6IEZyaWRheSwgMjQgQXByaWwg MjAyMCBhdCAyMDo1OA0KVG86IEpvZWwgSMO2Z2x1bmQgPGpvZWwuaG9nbHVuZEBnbWFpbC5jb20+ DQpDYzogImNvc2VAaWV0Zi5vcmciIDxjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NF XSBbQWNlXSBkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNC50eHQNCg0KDQpPbiBB cHIgMjQsIDIwMjAsIGF0IDU6MDEgQU0sIEpvZWwgSMO2Z2x1bmQgPGpvZWwuaG9nbHVuZEBnbWFp bC5jb208bWFpbHRvOmpvZWwuaG9nbHVuZEBnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBCdXQgb2Yg bW9zdCBpbnRlcmVzdCB0byBtZSBpcyB3aGV0aGVyIHRoZSBDT1NFIHdhcyBjb25zaWRlcmVkIGFz IHRoZQ0KPiBzaWduaW5nIGZvcm1hdCBmb3IgbmF0aXZlIENCT1IgY2VydHMuIElmIENPU0UgaXMg dXNlZCwgdGhlbiB0aGlzIGxvb2tzDQo+IGFsbW9zdCBpZGVudGljYWwgdG8gQ1dUIGFuZCBtYXkg YmUgYSBuYXRpdmUgQ0JPUiBjZXJ0IGlzIGEgdmFyaWFudCBvZg0KPiBhIENXVD8g4oCmIOKApg0K DQpPdXIgc3RhcnRpbmcgcG9pbnQgaGFzIGJlZW4gdG8gc3RheSBjbG9zZSB0byB0aGUgb3JpZ2lu YWwgWC41MDkgZm9ybWF0IHdoaWxlIG1pbmltaXppbmcgc2l6ZS4gQSBDT1NFIGVuY29kaW5nIHdv dWxkIHJlLWFkZCBzb21lIGZvcm1hdCBvdmVyaGVhZCAoY2xvc2UgdG8gMTAlIGZvciB0aGUgcHJv dmlkZWQgZXhhbXBsZSBjZXJ0aWZpY2F0ZSkuIEJ1dCBpZiBhIENPU0UgZW5jb2Rpbmcgd291bGQg aGVscCBtYWtpbmcgdGhlIGZvcm1hdCBhY2NlcHRlZCBhbmQgdXNlZCwgaXQgY2FuIGRlZmluaXRl bHkgYmUgZnVydGhlciBkaXNjdXNzZWQuDQoNCk9uY2UgYWdhaW4sIHRoYW5rIHlvdSBmb3IgeW91 ciBjb21tZW50cyENCg0KSGkgSm9lbCwNCg0KSeKAmW0ganVzdCBmb2N1c2luZyBvbiB0aGUgbmF0 aXZlIENCT1IgY2VydCBoZXJlLg0KDQpbR1NdIFRoYW5rcyBmb3Igc2hvd2luZyBpbnRlcmVzdCEN Cg0KVGhlIG92ZXJoZWFkIGZvciBDT1NFX1NpZ24xIHRvIGVuY29kZSB0aGUgYWxnb3JpdGhtIElE LCBrZXkgaWQgKG9wdGlvbmFsKSwgcGF5bG9hZCwgYW5kIHNpZ25hdHVyZSBpcyB0aW55IGFuZCBp cyBmaXhlZC4gSWYgeW91IGFzc3VtZSBlYWNoIG9mIHRoZXNlIChJRHMsIHBheWxvYWQsIHNpZykg YWxyZWFkeSBoYXZlIHRvIGJlIGEgQ0JPUi1lbmNvZGVkIGludGVnZXIgb3Igc3RyaW5nLCB0aGVu IHRoZSBvdmVyaGVhZCBpcyBwcm9iYWJseSBsZXNzIHRoYW4gdGVuIGJ5dGVzIHRvdGFsLCBtYXli ZSBldmVuIGxlc3MgdGhhbiBmaXZlIGZvciB0aGUgQ09TRSBzdHJ1Y3R1cmUgdGhhdCBncm91cHMg dGhlbS4NCg0KSW4geW91ciBleGFtcGxlIEEuMywgSSBkb27igJl0IHNlZSBob3cgdGhlIHRvLWJl LXNpZ25lZCBieXRlcyBhcmUgaWRlbnRpZmllZC4gU29tZSBzb2x1dGlvbiwgcHJvYmFibHkgdXNp bmcgYnN0ciB3cmFwcGluZyBpcyBuZWVkZWQuIENPU0Ugc29sdmVzIHdpdGggbm8gbW9yZSBvdmVy aGVhZCB0aGFuIG5lY2Vzc2FyeS4gIChZb3UgZG9u4oCZdCBuZWVkIHRoaXMgaW4gZXhhbXBsZSBB LjIsIGJlY2F1c2UgeW91IHJlY29uc3RydWN0IHRoZSBYLjUwOSBBU04uMS9ERVIgd2hpY2ggZG9l cyBpZGVudGlmeSB0aGUgdG8tYmUtc2lnbmVkIGJ5dGVzKS4NCg0KSeKAmW0gbm90IHN1cmUgd2hl cmUgeW91IGdvdCB0aGUgMTAlIG51bWJlciwgYnV0IGl0IHNlZW1zIGhpZ2guIEFsc28sIHRoZSBD T1NFIG92ZXJoZWFkIGlzIGZpeGVkLCBub3QgcHJvcG9ydGlvbmFsIHRvIHRoZSBzaXplIG9mIHRo ZSBjZXJ0aWZpY2F0ZS4NCg0KW0dTXSBJIHRoaW5rIEpvZWwgaXMgbWFraW5nIGEgcm91Z2ggZXN0 aW1hdGUgb2YgdGhlIHNpemUgb2YgYSBDQk9SIGNlcnRpZmljYXRlIHRvIHRoYXQgb2YgYSBDT1NF X1NpZ24xIG9mIGEgQ1dULg0KDQpUbyBnbyBvbiBhIGxpdHRsZSBtb3JlLCBpbiB0aGUgQVNOLjEg d29ybGQsIFguNTA5IGNlcnRzIGRpZG7igJl0IHVzZSBDTVMgc3RydWN0dXJlIGZvciBzaWduaW5n IHdoaWNoIG1lYW50IHRoZXkgY291bGRu4oCZdCBzaGFyZSBpbXBsZW1lbnRhdGlvbnMuIFNlZW1z IGxpa2UgWC41MDkgYW5kIENNUyB3ZXJlIGRldmVsb3BlZCBzZXBhcmF0ZWx5LiBBbHNvLCBDTVMg aXNu4oCZdCB0aGF0IGNvbXBhY3QuDQoNCkhvd2V2ZXIsIENPU0VfU2lnbjEgaXMgdmVyeSBjb21w YWN0IGFuZCBlZmZpY2llbnQuIElmIGl0IGNvdWxkIGJlIHVzZWQgZm9yIGEgbmF0aXZlIENCT1Ig Y2VydCBmb3JtYXQsIHRoZW4gQ09TRSBjb2RlIGNhbiBiZSByZSB1c2VkLiBJbiB1c2UgY2FzZXMg bGlrZSBzaWduZWQgU1cgdXBkYXRlcyBhbmQgc2VjdXJlZCBib290IHRoYXQgdXNlIGNlcnRpZmlj YXRlIGNoYWlucywgYm90aCB0aGUgY2VydGlmaWNhdGUgY2hhaW4gYW5kIHRoZSBzaWduZWQgU1cg dXBkYXRlcyB3b3VsZCB1c2UgdGhlIENPU0UgZm9ybWF0IGFuZCBzaGFyZSBmb3IgdmVyaWZ5aW5n IHNpZ25hdHVyZXMuDQoNCltHU10gVGhlIHJhdGlvbmFsZSBmb3IgbmF0aXZlIENCT1IgY2VydGlm aWNhdGVzIGlzIHRvIHJldXNlIHRoZSBzYW1lIGVuY29kaW5nIGFzIGluIHRoZSBjb21wcmVzc2lv biBzY2hlbWUgZGVmaW5lZCBmb3IgUkZDIDc5MjUsIGJ1dCBzaWduaW5nIHRoZSBDQk9SIGluc3Rl YWQgb2Ygc2lnbmluZyB0aGUgdW5jb21wcmVzc2VkIGRhdGEuIFRoaXMgcHJvdmlkZXMgYSByb2Fk bWFwIHdpdGggbWluaW1hbCBjaGFuZ2VzIHdoZW4gbW92aW5nIGZyb20gY29tcHJlc3NlZCB0byBu YXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMuDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgb3Zl cmhlYWQgb2YgQ09TRV9TaWduMSBvciBDV1QgaXMgbm90IG1ham9yIGFuZCB0aGVzZSBwb2ludHMg YXJlIG9wZW4gZm9yIGRpc2N1c3Npb24uIFRoZSBtb3JlIGltcG9ydGFudCBxdWVzdGlvbiBpcyB3 aGVyZSB0aGlzIHNob3VsZCBiZSBzdGFuZGFyZGl6ZWQuIFRoZSBjb21wcmVzc2lvbiBzY2hlbWUg aXMgbm93IGluY2x1ZGVkIGluIHRoZSBuZXcgZHJhZnQgY2hhcnRlciBmb3IgQ09TRToNCmh0dHBz Oi8vZ2l0aHViLmNvbS9jb3NlLXdnL0NoYXJ0ZXIvYmxvYi9tYXN0ZXIvQ2hhcnRlci5tZA0KVGhl IGNoYXJ0ZXIgaXMgY3VycmVudGx5IG5vdCBleHBsaWNpdGx5IHN1cHBvcnRpbmcgbmF0aXZlIENC T1IgY2VydGlmaWNhdGVzLiBJZiB5b3UgdGhpbmsgaXQgc2hvdWxkLCBpbiBzb21lIHZhcmlhbnQs IHRoZW4gdGhpcyBpcyBhIGdvb2QgdGltZSB0byByYWlzZSB5b3VyIHZvaWNlLg0KDQpHw7ZyYW4N Cg0K --_000_964634A47B614CEF8ED06A9A48D984CDericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9A7C81C4F690BB459DE50A957DE05598@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJlbi1TRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgTGF1cmVuY2UsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+KENvcHlpbmcgYm90aCBBQ0UgYW5kIENPU0UgcGVuZGluZyBmdXJ0aGVy IG5vdGljZSBhYm91dCByaWdodCBtYWlsIGxpc3QuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Q09TRSAmbHQ7Y29zZS1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTGF1cmVuY2UgTHVuZGJsYWRlICZsdDtsZ2xAaXNs YW5kLXJlc29ydC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgMjQgQXByaWwgMjAy MCBhdCAyMDo1ODxicj4NCjxiPlRvOiA8L2I+Sm9lbCBIw7ZnbHVuZCAmbHQ7am9lbC5ob2dsdW5k QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2Nvc2VAaWV0Zi5vcmcmcXVvdDsg Jmx0O2Nvc2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQ09TRV0gW0Fj ZV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIEFwciAyNCwgMjAyMCwgYXQgNTowMSBBTSwgSm9lbCBIw7ZnbHVuZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvZWwuaG9nbHVuZEBnbWFpbC5jb20iPmpvZWwuaG9nbHVuZEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IEJ1dCBvZiBtb3N0IGludGVyZXN0IHRvIG1lIGlzIHdoZXRoZXIgdGhlIENPU0Ug d2FzIGNvbnNpZGVyZWQgYXMgdGhlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBz aWduaW5nIGZvcm1hdCBmb3IgbmF0aXZlIENCT1IgY2VydHMuIElmIENPU0UgaXMgdXNlZCwgdGhl biB0aGlzIGxvb2tzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBhbG1vc3QgaWRl bnRpY2FsIHRvIENXVCBhbmQgbWF5IGJlIGEgbmF0aXZlIENCT1IgY2VydCBpcyBhIHZhcmlhbnQg b2Y8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IGEgQ1dUPyDigKYg4oCmJm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PdXIgc3RhcnRpbmcg cG9pbnQgaGFzIGJlZW4gdG8gc3RheSBjbG9zZSB0byB0aGUgb3JpZ2luYWwgWC41MDkgZm9ybWF0 IHdoaWxlIG1pbmltaXppbmcgc2l6ZS4gQSBDT1NFIGVuY29kaW5nIHdvdWxkIHJlLWFkZCBzb21l IGZvcm1hdCBvdmVyaGVhZCAoY2xvc2UgdG8gMTAlIGZvciB0aGUNCiBwcm92aWRlZCBleGFtcGxl IGNlcnRpZmljYXRlKS4gQnV0IGlmIGEgQ09TRSBlbmNvZGluZyB3b3VsZCBoZWxwIG1ha2luZyB0 aGUgZm9ybWF0IGFjY2VwdGVkIGFuZCB1c2VkLCBpdCBjYW4gZGVmaW5pdGVseSBiZSBmdXJ0aGVy IGRpc2N1c3NlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9u Y2UgYWdhaW4sIHRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyE8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PkhpIEpvZWwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPknigJltIGp1c3QgZm9jdXNpbmcgb24gdGhlIG5hdGl2ZSBDQk9SIGNlcnQgaGVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+W0dTXSZuYnNwO1RoYW5rcyBmb3Igc2hvd2luZyBpbnRlcmVzdCE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBvdmVyaGVhZCBmb3IgQ09TRV9TaWdu MSB0byBlbmNvZGUgdGhlIGFsZ29yaXRobSBJRCwga2V5IGlkIChvcHRpb25hbCksIHBheWxvYWQs IGFuZCBzaWduYXR1cmUgaXMgdGlueSBhbmQgaXMgZml4ZWQuIElmIHlvdSBhc3N1bWUgZWFjaCBv ZiB0aGVzZSAoSURzLCBwYXlsb2FkLCBzaWcpIGFscmVhZHkgaGF2ZSB0byBiZSBhIENCT1ItZW5j b2RlZCBpbnRlZ2VyDQogb3Igc3RyaW5nLCB0aGVuIHRoZSBvdmVyaGVhZCBpcyBwcm9iYWJseSBs ZXNzIHRoYW4gdGVuIGJ5dGVzIHRvdGFsLCBtYXliZSBldmVuIGxlc3MgdGhhbiBmaXZlIGZvciB0 aGUgQ09TRSBzdHJ1Y3R1cmUgdGhhdCBncm91cHMgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4geW91ciBleGFtcGxlIEEuMywgSSBkb27i gJl0IHNlZSBob3cgdGhlIHRvLWJlLXNpZ25lZCBieXRlcyBhcmUgaWRlbnRpZmllZC4gU29tZSBz b2x1dGlvbiwgcHJvYmFibHkgdXNpbmcgYnN0ciB3cmFwcGluZyBpcyBuZWVkZWQuIENPU0Ugc29s dmVzIHdpdGggbm8gbW9yZSBvdmVyaGVhZCB0aGFuIG5lY2Vzc2FyeS4gJm5ic3A7KFlvdSBkb27i gJl0IG5lZWQgdGhpcyBpbiBleGFtcGxlDQogQS4yLCBiZWNhdXNlIHlvdSByZWNvbnN0cnVjdCB0 aGUgWC41MDkgQVNOLjEvREVSIHdoaWNoIGRvZXMgaWRlbnRpZnkgdGhlIHRvLWJlLXNpZ25lZCBi eXRlcykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PknigJltIG5vdCBzdXJlIHdoZXJlIHlvdSBnb3QgdGhlIDEwJSBudW1iZXIsIGJ1dCBpdCBzZWVt cyBoaWdoLiBBbHNvLCB0aGUgQ09TRSBvdmVyaGVhZCBpcyBmaXhlZCwgbm90IHByb3BvcnRpb25h bCB0byB0aGUgc2l6ZSBvZiB0aGUgY2VydGlmaWNhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5bR1NdIEkgdGhpbmsgSm9lbCBpcyBtYWtpbmcgYSByb3VnaCBlc3RpbWF0ZSBvZiB0aGUg c2l6ZSBvZiBhIENCT1IgY2VydGlmaWNhdGUgdG8gdGhhdCBvZiBhIENPU0VfU2lnbjEgb2YgYSBD V1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRvIGdvIG9uIGEgbGl0dGxlIG1vcmUsIGk8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+biB0aGUgQVNOLjEgd29ybGQsIFguNTA5IGNl cnRzIGRpZG7igJl0IHVzZSBDTVMgc3RydWN0dXJlIGZvciBzaWduaW5nIHdoaWNoIG1lYW50IHRo ZXkgY291bGRu4oCZdCBzaGFyZSBpbXBsZW1lbnRhdGlvbnMuIFNlZW1zIGxpa2UgWC41MDkgYW5k IENNUyB3ZXJlIGRldmVsb3BlZA0KIHNlcGFyYXRlbHkuIEFsc28sIENNUyBpc27igJl0IHRoYXQg Y29tcGFjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Ib3dldmVyLCBDT1NFX1Np Z24xIGlzIHZlcnkgY29tcGFjdCBhbmQgZWZmaWNpZW50LiBJZiBpdCBjb3VsZCBiZSB1c2VkIGZv ciBhJm5ic3A7bmF0aXZlIENCT1IgY2VydCBmb3JtYXQsIHRoZW4gQ09TRSBjb2RlIGNhbiBiZSBy ZSB1c2VkLiBJbiB1c2UgY2FzZXMgbGlrZSBzaWduZWQgU1cgdXBkYXRlcyBhbmQgc2VjdXJlZA0K IGJvb3QgdGhhdCB1c2UgY2VydGlmaWNhdGUgY2hhaW5zLCBib3RoIHRoZSBjZXJ0aWZpY2F0ZSBj aGFpbiBhbmQgdGhlIHNpZ25lZCBTVyB1cGRhdGVzIHdvdWxkIHVzZSB0aGUgQ09TRSBmb3JtYXQg YW5kIHNoYXJlIGZvciB2ZXJpZnlpbmcgc2lnbmF0dXJlcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bR1NdIFRoZSByYXRpb25hbGUgZm9y IG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBpcyB0byByZXVzZSB0aGUgc2FtZSBlbmNvZGluZyBh cyBpbiB0aGUgY29tcHJlc3Npb24gc2NoZW1lIGRlZmluZWQgZm9yIFJGQyA3OTI1LCBidXQgc2ln bmluZyB0aGUgQ0JPUiBpbnN0ZWFkIG9mIHNpZ25pbmcgdGhlIHVuY29tcHJlc3NlZCBkYXRhLiBU aGlzIHByb3ZpZGVzIGEgcm9hZG1hcCB3aXRoDQogbWluaW1hbCBjaGFuZ2VzIHdoZW4gbW92aW5n IGZyb20gY29tcHJlc3NlZCB0byBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG92ZXJoZWFkIG9mIENPU0VfU2lnbjEg b3IgQ1dUIGlzIG5vdCBtYWpvciBhbmQgdGhlc2UgcG9pbnRzIGFyZSBvcGVuIGZvciBkaXNjdXNz aW9uLiBUaGUgbW9yZSBpbXBvcnRhbnQgcXVlc3Rpb24gaXMgd2hlcmUgdGhpcyBzaG91bGQgYmUg c3RhbmRhcmRpemVkLiBUaGUgY29tcHJlc3Npb24gc2NoZW1lIGlzIG5vdyBpbmNsdWRlZCBpbg0K IHRoZSBuZXcgZHJhZnQgY2hhcnRlciBmb3IgQ09TRTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL2Nvc2Utd2cvQ2hhcnRlci9ibG9iL21hc3Rlci9DaGFydGVyLm1kIj5odHRwczov L2dpdGh1Yi5jb20vY29zZS13Zy9DaGFydGVyL2Jsb2IvbWFzdGVyL0NoYXJ0ZXIubWQ8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZSBjaGFydGVyIGlzIGN1cnJlbnRseSBub3QgZXhwbGljaXRseSBzdXBwb3J0aW5nIG5h dGl2ZSBDQk9SIGNlcnRpZmljYXRlcy4gSWYgeW91IHRoaW5rIGl0IHNob3VsZCwgaW4gc29tZSB2 YXJpYW50LCB0aGVuIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gcmFpc2UgeW91ciB2b2ljZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkfDtnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_964634A47B614CEF8ED06A9A48D984CDericssoncom_-- From nobody Mon Apr 27 11:12:51 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C813A13FC for ; Mon, 27 Apr 2020 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Lwmn2CNPJBqg for ; Mon, 27 Apr 2020 11:12:44 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 941EF3A13F5 for ; Mon, 27 Apr 2020 11:12:44 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id T8FGjWHD9yxohT8FGjkPdK; Mon, 27 Apr 2020 11:12:43 -0700 X-CMAE-Analysis: v=2.3 cv=D4M51cZj c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=NeJZvmmVAAAA:20 a=8aHrabQ16hnPy60Vl7wA:9 a=WLYB0anuR71vkHwG:21 a=oUvknMVYQ17N8dzp:21 a=QEXdDO2ut3YA:10 a=1FQnyevworvUIDAmB10A:9 a=deDHt174sL9GY5xG:21 a=_0pdXMZ77TLyqXQk:21 a=VIMNpRtCtqaqwis5:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_46B091B9-CE71-4B27-A9DF-B8F1F6999C6E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 27 Apr 2020 11:12:42 -0700 In-Reply-To: <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> Cc: =?utf-8?Q?Joel_H=C3=B6glund?= , "ace@ietf.org" , "cose@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfHCpfS+EpDtJSHNJoUwByozzHqeotVuK0xvXw4KOY9q/a02blW6O12SdXH0UAtuQ+dq64LQ1h0H1rnJ2fqZzRbCKpf63xx5t2rs9CallysKb7Vx63sFA ILOsKDy4VcRsGouFlQamHi8jYF2LI0l+w2z7KBPasdxDxT5A8pu5O5KsRLWwWaBG8DK/mTLlx4XeYIc7/MJFWKH8P8r4S6t7RFJQJFmRS4+htDzJhCjDLQLH A5cq2G5NkHs0X958CnBlU4TeeVapYqGSRqsryON0Ru+uUVwn6YXo6SOMY+vnVAQP Archived-At: Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 18:12:48 -0000 --Apple-Mail=_46B091B9-CE71-4B27-A9DF-B8F1F6999C6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 27, 2020, at 5:00 AM, G=C3=B6ran Selander = wrote: >=20 > [GS] The rationale for native CBOR certificates is to reuse the same = encoding as in the compression scheme defined for RFC 7925, but signing = the CBOR instead of signing the uncompressed data. This provides a = roadmap with minimal changes when moving from compressed to native CBOR = certificates. > =20 > I agree with you that the overhead of COSE_Sign1 or CWT is not major = and these points are open for discussion. The more important question is = where this should be standardized. The compression scheme is now = included in the new draft charter for COSE: > https://github.com/cose-wg/Charter/blob/master/Charter.md = > The charter is currently not explicitly supporting native CBOR = certificates. If you think it should, in some variant, then this is a = good time to raise your voice. To go straight to the issue, I think a designing a native CBOR cert = should be approached differently than compressing / re-encoding an X.509 = cert: Re-encoding - Size is important - Exact compatibility is required - Near zero change to fields and semantics Native CBOR Cert - Clean up some of the mess in X.509; it is an old standard with a lot = of cruft and baggage - Re design extensions so they are in CBOR format - Make many of the fields optional, for example not before can often be = left off, maybe even serial number - Avoid DN structure for issuer and subject for most use cases - Use modern formats like COSE and CWT and COSE_Key - Size is important, but far from the only goal (some size reductions, = like optional fields will be possible here that are not possible with = re-encoding) - Compatibility matters, but not in the same way Seems like the right thing to do here is to remove native CBOR certs = from this document and just focus on compression and re-encoding. Maybe = even call them =E2=80=9CCompressed Certs=E2=80=9D rather than =E2=80=9CCBO= R Certs=E2=80=9D. Where that work should go is above my pay grade. BUT, my main interest here relates to CWT and EAT. CWT seems like a = really good choice on which to base a native CBOR cert. Some of the = fields for an X.509 cert are already defined in CWT (subject, issuer, = expiration, not-before). It has an extension mechanism built in already = in the CWT IANA registry. The crypto and signing are well-handled by = CWT=E2=80=99s use of COSE. In work to fit EAT = in as a CWT, a few issues have come up =E2=80=94 how fields / claims are = managed and registered with IANA, label spaces and other. All these = issues would apply to CWT/COSE/CBOR-based certificate as well.=20 To name just one issue, in CWT the expiration date/time can be a = floating-point number, which is burdensome, not useful. Should we change = CWT to disallow or should it just be disallowed when a CWT is used as an = EAT and when it is used as a Cert? I=E2=80=99m also excited at the idea of re using CWT in a simple form so = there is re use of code between CWT, EAT and native CBOR certs. I=E2=80=99= ve started playing with an implementation like this. LL --Apple-Mail=_46B091B9-CE71-4B27-A9DF-B8F1F6999C6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 27, 2020, at 5:00 AM, G=C3=B6ran Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org> = wrote:

[GS] = The rationale for native CBOR certificates is to reuse the same encoding = as in the compression scheme defined for RFC 7925, but signing the CBOR = instead of signing the uncompressed data. This provides a roadmap with = minimal changes when moving from compressed to native CBOR = certificates.
 
I agree with you that = the overhead of COSE_Sign1 or CWT is not major and these points are open = for discussion. The more important question is where this should be = standardized. The compression scheme is now included in the new draft = charter for COSE:
https://github.com/cose-wg/Charter/blob/master/Charter.md
The charter is currently not explicitly = supporting native CBOR certificates. If you think it should, in some = variant, then this is a good time to raise your = voice.

To go straight to the issue, I think a designing a native = CBOR cert should be approached differently than compressing / = re-encoding an X.509 cert:

Re-encoding
- Size is = important
- Exact compatibility is = required
- Near zero change to fields and = semantics

Native CBOR Cert
- Clean up some of = the mess in X.509; it is an old standard with a lot of cruft and = baggage
- Re design extensions so they are in CBOR = format
- Make many of the fields optional, for = example not before can often be left off, maybe even serial = number
- Avoid DN structure for issuer and subject = for most use cases
- Use modern formats like COSE = and CWT and COSE_Key
- Size is important, but far = from the only goal (some size reductions, like optional fields will be = possible here that are not possible with re-encoding)
- Compatibility matters, but not in the same way

Seems like the right = thing to do here is to remove native CBOR certs from this document and = just focus on compression and re-encoding. Maybe even call them = =E2=80=9CCompressed Certs=E2=80=9D rather than =E2=80=9CCBOR Certs=E2=80=9D= . Where that work should go is above my pay grade.


BUT, my main interest here relates to CWT and EAT. CWT seems = like a really good choice on which to base a native CBOR cert. Some of = the fields for an X.509 cert are already defined in CWT (subject, = issuer, expiration, not-before). It has an extension mechanism built in = already in the CWT IANA registry. The crypto and signing are = well-handled by CWT=E2=80=99s use of COSE.

In work to fit EAT in as a CWT, a few issues have come up =E2=80=94 = how fields / claims are managed and registered with IANA, label spaces = and other.  All these issues would apply to CWT/COSE/CBOR-based = certificate as well. 

To name just one issue, in CWT the expiration date/time can = be a floating-point number, which is burdensome, not useful. Should we = change CWT to disallow or should it just be disallowed when a CWT is = used as an EAT and when it is used as a Cert?

I=E2=80=99m also excited at the idea of = re using CWT in a simple form so there is re use of code between CWT, = EAT and native CBOR certs. I=E2=80=99ve started playing with an = implementation like this.

LL

= --Apple-Mail=_46B091B9-CE71-4B27-A9DF-B8F1F6999C6E-- From nobody Tue Apr 28 03:23:54 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF53A12B1; Tue, 28 Apr 2020 03:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=ericsson.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 yK2PbUblC9MU; Tue, 28 Apr 2020 03:23:35 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00046.outbound.protection.outlook.com [40.107.0.46]) (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 69CF33A12DB; Tue, 28 Apr 2020 03:23:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mTXvjMUSxlrHrYOPHD856VyPiVba+BwkEX7W0BE7jcKkoICnhDwt8kQ8zO2qBjVfZ9oWQ/XEf5QPf5MTZzZ6li1cVaOzvu6xQha1SXjo7AB+JZytHw+2XuyYjKNXUOOtjvVa9tLs6d5AZcFDzRIdZPjrzxFZrR3qaiPxHKUmZ1QWw/uLafCAYsqf4w8UdWYiCEwcCOfIsCFH0M2rTyQRZNCJa4UBFKWvWa46z5SVAev0yR4cAQTzt/cYhLyKP3Na7eL23AohncnQiGNJO1ql8F+nkXT0NO1unWTDShyV6FKoRO+kAHV1MsI89+WTUsjxWPadsfZF0mdqM8AFnNAwpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=opOhOku16BwAH0ODJHVD7RpFoTagNX6OKtnWL3bF45s=; b=CpFiHGjVJrEBHcW/udun2PqkCOKDTPMERo2Zha1Omdh+W6ouQJEYVcDIdoDtl2k2F48P1q2SbPTZ3BFg2LOveBoo8yx41j3yR2Ii/NeIMn2OHCB1TYixr/QdTWAtpyYKRz6CvgfdpUVX6BY07d2ApB91PgJQ8adQfsXu9RSmt4SMSrZWflmd+WnscTsogzJHCpXW2A+z8r4t+2zVKw/Aa/EBJ8dA5LRHHKQTKauP7i6Vlg90+LS8OnWyuClOq7+P5pF6iPd1J7C69u0wf5Jmjb08QPcZZOZW8q0s26zEEes5tTCeoDzRINC24cauQ7klESzv9kMY9mtUiAKGfU/OaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=opOhOku16BwAH0ODJHVD7RpFoTagNX6OKtnWL3bF45s=; b=bJjRZrA28XkgKkVuMhAKrjst1ShdTcxo3SQUp4r+LX5PmYLJXhdAk9gmMK8CNPjM0CjBWYimkLyvx8iu6bbAoSDGJVCYz82E/OQPikfOrBGGZOSA4yz44AJiBGx2PnnFQK23cLW/UufEmi7UyWN2OGB+7/f3TGXhGqHwuYagRbk= Received: from VI1PR07MB5023.eurprd07.prod.outlook.com (2603:10a6:803:9e::13) by VI1PR07MB5966.eurprd07.prod.outlook.com (2603:10a6:803:be::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 10:23:31 +0000 Received: from VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321]) by VI1PR07MB5023.eurprd07.prod.outlook.com ([fe80::7c90:eb1a:e7da:2321%7]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 10:23:31 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Laurence Lundblade , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: =?utf-8?B?Sm9lbCBIw7ZnbHVuZA==?= , "cose@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt Thread-Index: AQHWHL9/AQkz8jksrU+IVD0bq1nzAqiOdicA Date: Tue, 28 Apr 2020 10:23:31 +0000 Message-ID: <3BB4FFA8-AABD-4520-9B21-1F0B0CAFB08C@ericsson.com> References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fef454ab-63af-43a2-1163-08d7eb5e3335 x-ms-traffictypediagnostic: VI1PR07MB5966: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB5023.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(346002)(396003)(136003)(54906003)(6512007)(8676002)(6486002)(186003)(2906002)(26005)(8936002)(66476007)(91956017)(76116006)(66946007)(66574012)(66556008)(66446008)(81156014)(478600001)(64756008)(316002)(85182001)(6506007)(5660300002)(53546011)(85202003)(36756003)(4326008)(110136005)(33656002)(966005)(2616005)(71200400001)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q9jJ3aKmZOVYy4wq5MGPAbua7pMNSDaTDChAFjyUtI4FwNL1WwZ9cCSXvtmBTZLoF13QKMDexmxElZMdGlhk5CuNjoSZkngRUmndUY5xqHVthHwiQzvyT3f18TZTML4lvzJIHtJQnGj/MJIprvWXhHh3WYiz6C1+EqRq5l8JIkKT0MqIdEzhfIYHa4bxocGlngFVUJiE+9a7mLF9F+/2Utzs2M2dYKc7tUI++8VwimDlHwTXtCjVGueoFtagapfO8he8VH8vvrmarrr6bYw9iVUTgctznTHPKnSfoRjOnZh/eQ1H6Y/fh92U2HFhAooDcBTdI2Sdr2x5FIs7vIXoRNId+73fvmNTHCgY8NOVVOw3bYBCZIIiQNxKvb2jjFF9ii7d+4/YffzEifCjE9Deu7E1xqkRacOqXQzJcaQ6rJ/iXZ7CZbJxS9c+8SvaKLy2UgWEviNOy94owE5yJdpx9HtQksu/qFRDHvGoJ+djU3eBkGE/yDiUWW9jp3wukkXooO3J5SiaSe9Q7Obzk4DW+Q== x-ms-exchange-antispam-messagedata: NhNRhoqtI2zb/5gv9OVnk6WSN/FmcLk2nQkyJ7PXf40khcWE3jcxidpyjME6h/rT1iZkIALTtwwb8Ag7OICbbHbE9ZV+T+EyfyQ4Q3usy0MShkeK77AiyHZBXRehq5ztDUl2bSUWb0PVQYVodn+RGKa+JJUTtryf5Mr8obmksf3l1nG2luQ9Qv0svtiHSahc6LSj2NkW9xJ1jB+7IocIYuMywYKAsT9p5Mm4cIOkB2ugs0Aq/a4DczDD+NYD6EJtWilCBh0eDZdsnW9If9QBdj1cLABCd7mldN308BbUeLnKJPo8Kyija7jLpdCnmcua7QUYMcOQ5J/IAYV8oetlMYtti4C9u+pOMRj44CyYDn1M6Dwau57AiwEhosPGQZ1u0t0lDfhjnDTvLbbK3aWSUuNGT0Xcrv97Xwg3p8jUSvjMOsIOtSjMNShwfKB2q5GBuG5TWZYLhx2JIu/SqsbdRqt6CkiLYRZIFwwzSO71GMV/zZWEKuZoNFzLMe6vFM3Dqbec9KKJkdBCmfginjxL3wYuwbUWkcep3Up/VGKJYCRuZX9I1BFdkvoZqbnyxVY/OdJI0aZUMKbKal6pFBNngcXXyoGr9Lik/Ww33prbAMWyao8xzCLTyGdueJhbfHT3ztkqMrgAhWrow+9pC1LopxpWJq4f14M+DZ6fpULrHec2mxIvHFMDE+tx4hM7La9uiSvhXntoUgSgJ4ZfpejacFBIQvldYDYzpCPsH86aTw5/HxdPpcS4kEasIDGuHh+mm+xn+7LWAXPl6ckeW7GQQv0b1WTPM2eBxRjBGdDldXE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3BB4FFA8AABD45209B211F0B0CAFB08Cericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fef454ab-63af-43a2-1163-08d7eb5e3335 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 10:23:31.3044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y/sAem6ofsxz2Dq0lXi1re3AJp8pXah2q+yQhx7LWsW8fWUXCi2jZXtpaMNg/6P5A2Rzu+F0RB7Injvtn/Gl1q2Ov8e7yDGjgr4Ijb4Rbi4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5966 Archived-At: Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 10:23:46 -0000 --_000_3BB4FFA8AABD45209B211F0B0CAFB08Cericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVuY2UsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLiBJdCBzZWVt cyB3ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQgcGF0aHMuDQoNClRoZSBwYXJ0 IHlvdSBjYWxsZWQg4oCcQ29tcHJlc3NlZCBDZXJ0c+KAnSBpcyBhbHJlYWR5IGluIHRoZSBkcmFm dCBDT1NFIGNoYXJ0ZXIgd2hlcmUgaXQgaXMgcmVmZXJyZWQgdG8gYXMg4oCcQSBDQk9SIGVuY29k aW5nIG9mIHRoZSBjb21wcmVzc2VkIGNlcnRpZmljYXRlIHByb2ZpbGUgZGVmaW5lZCBpbiBSRkMg NzkyNeKAnSBzbyB3ZSBjYW4gbGVhdmUgdGhhdCBvdXQgZm9yIG5vdy4NCg0KTXkgY29tbWVudCB3 YXMgYWJvdXQgdGhlIG90aGVyIHBhcnQsIHdoYXQgd2UgYm90aCBjYWxsIOKAnG5hdGl2ZSBDQk9S IGNlcnRpZmljYXRlc+KAnSBidXQgbWVhbiBkaWZmZXJlbnQgdGhpbmdzLiBXaGF0IGlzIGNhbGxl ZCBuYXRpdmUgaW4NCmRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzIGlzIG5vdCBpbnRl bmRlZCBhcyBhIGNlcnRpZmljYXRlIGZvcm1hdCBicmVha2luZyB3aXRoIFguNTA5LiBXaGlsZSB0 aGVyZSBhcmUgbWFueSBwb3RlbnRpYWwgaW1wcm92ZW1lbnRzIHRvIG1ha2Ugb24gWC41MDksIHRo ZXJlIGlzIGEgcmVzaXN0YW5jZSBhZ2FpbnN0IG5ldyBjZXJ0aWZpY2F0ZSBhcmNoaXRlY3R1cmVz IGFzIHdhcyBjbGVhciB3aGVuIHRoaXMgd2FzIGJyb3VnaHQgdXAgaW4gU2VjZGlzcGF0Y2ggYXQg SUVURiAxMDQgYSB5ZWFyIGFnby4gQXMgbWVudGlvbmVkIHByZXZpb3VzbHksIHdoYXQgd2UgbWVh biBieSDigJxuYXRpdmUgQ0JPUuKAnSBpcyB0aGUgbG9zc2xlc3MgY29tcHJlc3Npb24gb2YgdGhl IGNlcnRpZmljYXRlIHByb2ZpbGUgb2YgWC41MDkgaW50byBhIENCT1IgZW5jb2RlZCBmb3JtYXQs IGJ1dCBzaWduaW5nIG92ZXIgdGhlIENCT1IgaW5zdGVhZCBvZiBvbiB0aGUgdW5jb21wcmVzc2Vk IGRhdGEuIEluIHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIGJpamVjdGlvbiBi ZXR3ZWVuIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJvZmlsZWQgWC41MDkgY2VydGlm aWNhdGVzIOKAkyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3NlZCB2ZXJzaW9uIG9mIHRoZSBs YXR0ZXIgd291bGQgYmUgaWRlbnRpY2FsIHRvIHRoZSBmb3JtZXIuIFNvIHRoZSBuYXRpdmUgQ0JP UiBjZXJ0aWZpY2F0ZXMgYXJlIGEgZmFpdGhmdWwgcmVwcmVzZW50YXRpb24gb2YgdGhlc2UgcHJv ZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzLCB1c2luZyB0aGUgc2FtZSBwYXlsb2FkIGFzIGluIHRo ZSBDQk9SIGNvbXByZXNzaW9uIHNjaGVtZS4NCg0KSW4gY29udHJhc3QgdG8gdGhlIGNvbXByZXNz aW9uIHNjaGVtZSwgYSBjb252ZXJzaW9uIGJldHdlZW4gbmF0aXZlIENCT1IgYW5kIFguNTA5IHJl cHJlc2VudGF0aW9ucyByZXF1aXJlcyBhY2Nlc3MgdG8gdGhlIHByaXZhdGUgc2lnbmF0dXJlIGtl eS4NClRoZXJlZm9yZSBhIG1peCBvZiBYLjUwOSBhbmQgbmF0aXZlIENCT1Igd291bGQgcmVxdWly ZSBtdWx0aXBsZSBoYW5kbGVycyBhdCB0aGUgYmFja2VuZCAocGFyc2luZyB0aGUgcGF5bG9hZCB3 b3VsZCBiZSB0aGUgc2FtZSkuIERlZGljYXRlZCBkZXBsb3ltZW50cyBjb3VsZCBvZiBjb3Vyc2Ug dXNlIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBleGNsdXNpdmVseS4NCg0KSW4gdGhlIHNhbWUg d2F5IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGluc3RlYWQgZGVmaW5lIGEgQ09TRV9TaWduMSBh bmQvb3IgYSBDV1QgcmVwcmVzZW50aW5nIHRoZXNlIHByb2ZpbGVkIFguNTA5IGNlcnRpZmljYXRl cywgdGhpcyBpcyB3aGF0IEkgdGhvdWdodCB5b3Ugd2VyZSBhc2tpbmcgYWJvdXQgYnV0IGFwcGFy ZW50bHkgbm90LiBUaGF0IHdvdWxkIGJlIGFuIGFsdGVybmF0aXZlIGFzIGxvbmcgYXMgd2UgY2Fu IGRlY2lkZSBvbiBleGFjdGx5IG9uZSBvZiB0aGVzZSByZXByZXNlbnRhdGlvbnMuDQoNClRoZXJl IGFyZSBhIGxvdCBvZiBmdW4gdGhpbmdzIHRvIGRvIGluIHRoaXMgc3BhY2UsIG15IGNvbmNlcm4g aXMgaG93IHRvIGdldCBvdXQgYSBzdGFuZGFyZC4gVHJ5aW5nIHRvIHJlcGxhY2UgWC41MDkgZG9l c27igJl0IHNlZW0gbGlrZSBhIHByb21pc2luZyB3YXkgZm9yd2FyZCBJ4oCZbSBhZnJhaWQgLiAu IC4NCg0KR8O2cmFuDQoNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIExhdXJlbmNlIEx1bmRibGFkZSA8bGdsQGlzbGFuZC1yZXNvcnQuY29tPg0KRGF0ZTog TW9uZGF5LCAyNyBBcHJpbCAyMDIwIGF0IDIwOjEzDQpUbzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jh bi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBKb2VsIEjDtmds dW5kIDxqb2VsLmhvZ2x1bmRAZ21haWwuY29tPiwgImNvc2VAaWV0Zi5vcmciIDxjb3NlQGlldGYu b3JnPiwgImFjZUBpZXRmLm9yZyIgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWNlXSBb Q09TRV0gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQudHh0DQoNCk9uIEFwciAy NywgMjAyMCwgYXQgNTowMCBBTSwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlcj00MGVy aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nv bi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KW0dTXSBUaGUgcmF0aW9uYWxlIGZvciBu YXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgaXMgdG8gcmV1c2UgdGhlIHNhbWUgZW5jb2RpbmcgYXMg aW4gdGhlIGNvbXByZXNzaW9uIHNjaGVtZSBkZWZpbmVkIGZvciBSRkMgNzkyNSwgYnV0IHNpZ25p bmcgdGhlIENCT1IgaW5zdGVhZCBvZiBzaWduaW5nIHRoZSB1bmNvbXByZXNzZWQgZGF0YS4gVGhp cyBwcm92aWRlcyBhIHJvYWRtYXAgd2l0aCBtaW5pbWFsIGNoYW5nZXMgd2hlbiBtb3ZpbmcgZnJv bSBjb21wcmVzc2VkIHRvIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcy4NCg0KSSBhZ3JlZSB3aXRo IHlvdSB0aGF0IHRoZSBvdmVyaGVhZCBvZiBDT1NFX1NpZ24xIG9yIENXVCBpcyBub3QgbWFqb3Ig YW5kIHRoZXNlIHBvaW50cyBhcmUgb3BlbiBmb3IgZGlzY3Vzc2lvbi4gVGhlIG1vcmUgaW1wb3J0 YW50IHF1ZXN0aW9uIGlzIHdoZXJlIHRoaXMgc2hvdWxkIGJlIHN0YW5kYXJkaXplZC4gVGhlIGNv bXByZXNzaW9uIHNjaGVtZSBpcyBub3cgaW5jbHVkZWQgaW4gdGhlIG5ldyBkcmFmdCBjaGFydGVy IGZvciBDT1NFOg0KaHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cvQ2hhcnRlci9ibG9iL21hc3Rl ci9DaGFydGVyLm1kPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9ZGQxMjc3 MDktODE5YmQ4YzAtZGQxMjM3OTItMGNjNDdhZDkzZTFjLTViNmJhZTg0YWJjNWM0YTAmcT0xJmU9 NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3JnU9aHR0cHMlM0ElMkYlMkZnaXRo dWIuY29tJTJGY29zZS13ZyUyRkNoYXJ0ZXIlMkZibG9iJTJGbWFzdGVyJTJGQ2hhcnRlci5tZD4N ClRoZSBjaGFydGVyIGlzIGN1cnJlbnRseSBub3QgZXhwbGljaXRseSBzdXBwb3J0aW5nIG5hdGl2 ZSBDQk9SIGNlcnRpZmljYXRlcy4gSWYgeW91IHRoaW5rIGl0IHNob3VsZCwgaW4gc29tZSB2YXJp YW50LCB0aGVuIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gcmFpc2UgeW91ciB2b2ljZS4NCg0KVG8g Z28gc3RyYWlnaHQgdG8gdGhlIGlzc3VlLCBJIHRoaW5rIGEgZGVzaWduaW5nIGEgbmF0aXZlIENC T1IgY2VydCBzaG91bGQgYmUgYXBwcm9hY2hlZCBkaWZmZXJlbnRseSB0aGFuIGNvbXByZXNzaW5n IC8gcmUtZW5jb2RpbmcgYW4gWC41MDkgY2VydDoNCg0KUmUtZW5jb2RpbmcNCi0gU2l6ZSBpcyBp bXBvcnRhbnQNCi0gRXhhY3QgY29tcGF0aWJpbGl0eSBpcyByZXF1aXJlZA0KLSBOZWFyIHplcm8g Y2hhbmdlIHRvIGZpZWxkcyBhbmQgc2VtYW50aWNzDQoNCk5hdGl2ZSBDQk9SIENlcnQNCi0gQ2xl YW4gdXAgc29tZSBvZiB0aGUgbWVzcyBpbiBYLjUwOTsgaXQgaXMgYW4gb2xkIHN0YW5kYXJkIHdp dGggYSBsb3Qgb2YgY3J1ZnQgYW5kIGJhZ2dhZ2UNCi0gUmUgZGVzaWduIGV4dGVuc2lvbnMgc28g dGhleSBhcmUgaW4gQ0JPUiBmb3JtYXQNCi0gTWFrZSBtYW55IG9mIHRoZSBmaWVsZHMgb3B0aW9u YWwsIGZvciBleGFtcGxlIG5vdCBiZWZvcmUgY2FuIG9mdGVuIGJlIGxlZnQgb2ZmLCBtYXliZSBl dmVuIHNlcmlhbCBudW1iZXINCi0gQXZvaWQgRE4gc3RydWN0dXJlIGZvciBpc3N1ZXIgYW5kIHN1 YmplY3QgZm9yIG1vc3QgdXNlIGNhc2VzDQotIFVzZSBtb2Rlcm4gZm9ybWF0cyBsaWtlIENPU0Ug YW5kIENXVCBhbmQgQ09TRV9LZXkNCi0gU2l6ZSBpcyBpbXBvcnRhbnQsIGJ1dCBmYXIgZnJvbSB0 aGUgb25seSBnb2FsIChzb21lIHNpemUgcmVkdWN0aW9ucywgbGlrZSBvcHRpb25hbCBmaWVsZHMg d2lsbCBiZSBwb3NzaWJsZSBoZXJlIHRoYXQgYXJlIG5vdCBwb3NzaWJsZSB3aXRoIHJlLWVuY29k aW5nKQ0KLSBDb21wYXRpYmlsaXR5IG1hdHRlcnMsIGJ1dCBub3QgaW4gdGhlIHNhbWUgd2F5DQoN ClNlZW1zIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGhlcmUgaXMgdG8gcmVtb3ZlIG5hdGl2 ZSBDQk9SIGNlcnRzIGZyb20gdGhpcyBkb2N1bWVudCBhbmQganVzdCBmb2N1cyBvbiBjb21wcmVz c2lvbiBhbmQgcmUtZW5jb2RpbmcuIE1heWJlIGV2ZW4gY2FsbCB0aGVtIOKAnENvbXByZXNzZWQg Q2VydHPigJ0gcmF0aGVyIHRoYW4g4oCcQ0JPUiBDZXJ0c+KAnS4uIFdoZXJlIHRoYXQgd29yayBz aG91bGQgZ28gaXMgYWJvdmUgbXkgcGF5IGdyYWRlLg0KDQoNCkJVVCwgbXkgbWFpbiBpbnRlcmVz dCBoZXJlIHJlbGF0ZXMgdG8gQ1dUIGFuZCBFQVQuIENXVCBzZWVtcyBsaWtlIGEgcmVhbGx5IGdv b2QgY2hvaWNlIG9uIHdoaWNoIHRvIGJhc2UgYSBuYXRpdmUgQ0JPUiBjZXJ0LiBTb21lIG9mIHRo ZSBmaWVsZHMgZm9yIGFuIFguNTA5IGNlcnQgYXJlIGFscmVhZHkgZGVmaW5lZCBpbiBDV1QgKHN1 YmplY3QsIGlzc3VlciwgZXhwaXJhdGlvbiwgbm90LWJlZm9yZSkuIEl0IGhhcyBhbiBleHRlbnNp b24gbWVjaGFuaXNtIGJ1aWx0IGluIGFscmVhZHkgaW4gdGhlIENXVCBJQU5BIHJlZ2lzdHJ5LiBU aGUgY3J5cHRvIGFuZCBzaWduaW5nIGFyZSB3ZWxsLWhhbmRsZWQgYnkgQ1dU4oCZcyB1c2Ugb2Yg Q09TRS4NCg0KSW4gd29yayB0byBmaXQgRUFUPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJhdHMtZWF0LTAzPiBpbiBhcyBhIENXVCwgYSBmZXcgaXNzdWVzIGhhdmUgY29t ZSB1cCDigJQgaG93IGZpZWxkcyAvIGNsYWltcyBhcmUgbWFuYWdlZCBhbmQgcmVnaXN0ZXJlZCB3 aXRoIElBTkEsIGxhYmVsIHNwYWNlcyBhbmQgb3RoZXIuICBBbGwgdGhlc2UgaXNzdWVzIHdvdWxk IGFwcGx5IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlmaWNhdGUgYXMgd2VsbC4NCg0KVG8g bmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBpcmF0aW9uIGRhdGUvdGltZSBjYW4g YmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlzIGJ1cmRlbnNvbWUsIG5vdCB1c2Vm dWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93IG9yIHNob3VsZCBpdCBqdXN0IGJl IGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFuIEVBVCBhbmQgd2hlbiBpdCBpcyB1 c2VkIGFzIGEgQ2VydD8NCg0KSeKAmW0gYWxzbyBleGNpdGVkIGF0IHRoZSBpZGVhIG9mIHJlIHVz aW5nIENXVCBpbiBhIHNpbXBsZSBmb3JtIHNvIHRoZXJlIGlzIHJlIHVzZSBvZiBjb2RlIGJldHdl ZW4gQ1dULCBFQVQgYW5kIG5hdGl2ZSBDQk9SIGNlcnRzLiBJ4oCZdmUgc3RhcnRlZCBwbGF5aW5n IHdpdGggYW4gaW1wbGVtZW50YXRpb24gbGlrZSB0aGlzLg0KDQpMTA0KDQo= --_000_3BB4FFA8AABD45209B211F0B0CAFB08Cericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <19AD6466657F8D42A98EC19A4CA5E4A5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVu LVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBMYXVyZW5jZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLiBJdCBzZWVtcyB3 ZSBhcmUgd29ya2luZyBvbiBzbGlnaHRseSBkaWZmZXJlbnQgcGF0aHMuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHBhcnQgeW91IGNh bGxlZCDigJxDb21wcmVzc2VkIENlcnRz4oCdIGlzIGFscmVhZHkgaW4gdGhlIGRyYWZ0IENPU0Ug Y2hhcnRlciB3aGVyZSBpdCBpcyByZWZlcnJlZCB0byBhcyDigJw8L3NwYW4+QSBDQk9SIGVuY29k aW5nIG9mIHRoZSBjb21wcmVzc2VkIGNlcnRpZmljYXRlIHByb2ZpbGUgZGVmaW5lZCBpbiBSRkMg NzkyNTxzcGFuIGxhbmc9IkVOLVVTIj7igJ0gc28gd2UgY2FuIGxlYXZlDQogdGhhdCBvdXQgZm9y IG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk15IGNvbW1lbnQgd2FzIGFib3V0IHRoZSBvdGhlciBw YXJ0LCB3aGF0IHdlIGJvdGggY2FsbCDigJxuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXPigJ0gYnV0 IG1lYW4gZGlmZmVyZW50IHRoaW5ncy4gV2hhdCBpcyBjYWxsZWQgbmF0aXZlIGluDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1yYXphLWFjZS1jYm9y LWNlcnRpZmljYXRlcyA8c3BhbiBsYW5nPSJFTi1VUyI+aXMgbm90IGludGVuZGVkIGFzIGEgY2Vy dGlmaWNhdGUgZm9ybWF0IGJyZWFraW5nIHdpdGggWC41MDkuIFdoaWxlIHRoZXJlIGFyZSBtYW55 IHBvdGVudGlhbCBpbXByb3ZlbWVudHMgdG8gbWFrZSBvbiBYLjUwOSwgdGhlcmUgaXMgYSByZXNp c3RhbmNlIGFnYWluc3QgbmV3IGNlcnRpZmljYXRlIGFyY2hpdGVjdHVyZXMgYXMNCiB3YXMgY2xl YXIgd2hlbiB0aGlzIHdhcyBicm91Z2h0IHVwIGluIFNlY2Rpc3BhdGNoIGF0IElFVEYgMTA0IGEg eWVhciBhZ28uIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5LCB3aGF0IHdlIG1lYW4gYnkg4oCcbmF0 aXZlIENCT1LigJ0gaXMgdGhlIGxvc3NsZXNzIGNvbXByZXNzaW9uIG9mIHRoZSBjZXJ0aWZpY2F0 ZSBwcm9maWxlIG9mIFguNTA5IGludG8gYSBDQk9SIGVuY29kZWQgZm9ybWF0LCBidXQgc2lnbmlu ZyBvdmVyIHRoZSBDQk9SIGluc3RlYWQgb2YNCiBvbiB0aGUgdW5jb21wcmVzc2VkIGRhdGEuIElu IHRoaXMgd2F5IGl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIGJpamVjdGlvbiBiZXR3ZWVuIG5h dGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBhbmQgcHJvZmlsZWQgWC41MDkgY2VydGlmaWNhdGVzIOKA kyB0aGUgcGF5bG9hZCBvZiB0aGUgY29tcHJlc3NlZCB2ZXJzaW9uIG9mIHRoZSBsYXR0ZXIgd291 bGQgYmUgaWRlbnRpY2FsIHRvIHRoZSBmb3JtZXIuIFNvIHRoZSBuYXRpdmUgQ0JPUiBjZXJ0aWZp Y2F0ZXMNCiBhcmUgYSBmYWl0aGZ1bCByZXByZXNlbnRhdGlvbiBvZiB0aGVzZSBwcm9maWxlZCBY LjUwOSBjZXJ0aWZpY2F0ZXMsIHVzaW5nIHRoZSBzYW1lIHBheWxvYWQgYXMgaW4gdGhlIENCT1Ig Y29tcHJlc3Npb24gc2NoZW1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBjb250cmFzdCB0byB0 aGUgY29tcHJlc3Npb24gc2NoZW1lLCBhIGNvbnZlcnNpb24gYmV0d2VlbiBuYXRpdmUgQ0JPUiBh bmQgWC41MDkgcmVwcmVzZW50YXRpb25zIHJlcXVpcmVzIGFjY2VzcyB0byB0aGUgcHJpdmF0ZSBz aWduYXR1cmUga2V5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlZm9yZSBhIG1peCBvZiBYLjUwOSBhbmQgbmF0aXZl IENCT1Igd291bGQgcmVxdWlyZSBtdWx0aXBsZSBoYW5kbGVycyBhdCB0aGUgYmFja2VuZCAocGFy c2luZyB0aGUgcGF5bG9hZCB3b3VsZCBiZSB0aGUgc2FtZSkuIERlZGljYXRlZCBkZXBsb3ltZW50 cyBjb3VsZCBvZiBjb3Vyc2UgdXNlIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyBleGNsdXNpdmVs eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZSBzYW1lIHdheSBpdCB3b3VsZCBiZSBwb3NzaWJs ZSB0byBpbnN0ZWFkIGRlZmluZSBhIENPU0VfU2lnbjEgYW5kL29yIGEgQ1dUIHJlcHJlc2VudGlu ZyB0aGVzZSBwcm9maWxlZCBYLjUwOSBjZXJ0aWZpY2F0ZXMsIHRoaXMgaXMgd2hhdCBJIHRob3Vn aHQgeW91IHdlcmUgYXNraW5nIGFib3V0IGJ1dCBhcHBhcmVudGx5IG5vdC4gVGhhdCB3b3VsZCBi ZSBhbiBhbHRlcm5hdGl2ZQ0KIGFzIGxvbmcgYXMgd2UgY2FuIGRlY2lkZSBvbiBleGFjdGx5IG9u ZSBvZiB0aGVzZSByZXByZXNlbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBhcmUg YSBsb3Qgb2YgZnVuIHRoaW5ncyB0byBkbyBpbiB0aGlzIHNwYWNlLCBteSBjb25jZXJuIGlzIGhv dyB0byBnZXQgb3V0IGEgc3RhbmRhcmQuIFRyeWluZyB0byByZXBsYWNlIFguNTA5IGRvZXNu4oCZ dCBzZWVtIGxpa2UgYSBwcm9taXNpbmcgd2F5IGZvcndhcmQgSeKAmW0gYWZyYWlkIC4gLiAuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5Hw7ZyYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWNlICZsdDthY2UtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIExhdXJlbmNlIEx1bmRibGFkZSAmbHQ7bGdsQGlzbGFuZC1yZXNvcnQu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDI3IEFwcmlsIDIwMjAgYXQgMjA6MTM8 YnI+DQo8Yj5UbzogPC9iPkfDtnJhbiBTZWxhbmRlciAmbHQ7Z29yYW4uc2VsYW5kZXI9NDBlcmlj c3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5Kb2VsIEjDtmdsdW5k ICZsdDtqb2VsLmhvZ2x1bmRAZ21haWwuY29tJmd0OywgJnF1b3Q7Y29zZUBpZXRmLm9yZyZxdW90 OyAmbHQ7Y29zZUBpZXRmLm9yZyZndDssICZxdW90O2FjZUBpZXRmLm9yZyZxdW90OyAmbHQ7YWNl QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0FjZV0gW0NPU0VdIGRyYWZ0 LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzLTA0LnR4dDwvc3Bhbj48YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+T24gQXByIDI3LCAyMDIwLCBhdCA1OjAwIEFNLCBHw7ZyYW4gU2VsYW5kZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlcj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRm Lm9yZyI+Z29yYW4uc2VsYW5kZXI9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5bR1NdIFRoZSByYXRpb25hbGUgZm9yIG5hdGl2ZSBDQk9SIGNlcnRpZmlj YXRlcyBpcyB0byByZXVzZSB0aGUgc2FtZSBlbmNvZGluZyBhcyBpbiB0aGUgY29tcHJlc3Npb24g c2NoZW1lIGRlZmluZWQgZm9yIFJGQyA3OTI1LCBidXQgc2lnbmluZyB0aGUgQ0JPUiBpbnN0ZWFk IG9mIHNpZ25pbmcgdGhlIHVuY29tcHJlc3NlZCBkYXRhLg0KIFRoaXMgcHJvdmlkZXMgYSByb2Fk bWFwIHdpdGggbWluaW1hbCBjaGFuZ2VzIHdoZW4gbW92aW5nIGZyb20gY29tcHJlc3NlZCB0byBu YXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG92ZXJoZWFkIG9mIENPU0Vf U2lnbjEgb3IgQ1dUIGlzIG5vdCBtYWpvciBhbmQgdGhlc2UgcG9pbnRzIGFyZSBvcGVuIGZvciBk aXNjdXNzaW9uLiBUaGUgbW9yZSBpbXBvcnRhbnQgcXVlc3Rpb24gaXMgd2hlcmUgdGhpcyBzaG91 bGQgYmUgc3RhbmRhcmRpemVkLiBUaGUgY29tcHJlc3Npb24NCiBzY2hlbWUgaXMgbm93IGluY2x1 ZGVkIGluIHRoZSBuZXcgZHJhZnQgY2hhcnRlciBmb3IgQ09TRTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9r PWRkMTI3NzA5LTgxOWJkOGMwLWRkMTIzNzkyLTBjYzQ3YWQ5M2UxYy01YjZiYWU4NGFiYzVjNGEw JmFtcDtxPTEmYW1wO2U9NWJiNDEyZmEtZWMxZC00NGEwLThkYmEtYzY2ODQ0ZDFiNzk3JmFtcDt1 PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvc2Utd2clMkZDaGFydGVyJTJGYmxvYiUyRm1h c3RlciUyRkNoYXJ0ZXIubWQiPmh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL0NoYXJ0ZXIvYmxv Yi9tYXN0ZXIvQ2hhcnRlci5tZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGUgY2hhcnRlciBpcyBjdXJyZW50bHkgbm90IGV4cGxpY2l0bHkgc3VwcG9ydGlu ZyBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMuIElmIHlvdSB0aGluayBpdCBzaG91bGQsIGluIHNv bWUgdmFyaWFudCwgdGhlbiB0aGlzIGlzIGEgZ29vZCB0aW1lIHRvIHJhaXNlIHlvdXIgdm9pY2Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+VG8gZ28gc3RyYWlnaHQgdG8gdGhlIGlzc3VlLCBJIHRoaW5rIGEg ZGVzaWduaW5nIGEgbmF0aXZlIENCT1IgY2VydCBzaG91bGQgYmUgYXBwcm9hY2hlZCBkaWZmZXJl bnRseSB0aGFuIGNvbXByZXNzaW5nIC8gcmUtZW5jb2RpbmcgYW4gWC41MDkgY2VydDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHU+UmUtZW5jb2Rp bmc8L3U+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tIFNpemUgaXMgaW1wb3J0YW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4tIEV4YWN0IGNvbXBhdGliaWxpdHkgaXMgcmVxdWlyZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPi0gTmVhciB6ZXJvIGNoYW5nZSB0byBmaWVsZHMgYW5kIHNlbWFudGljczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48dT5OYXRp dmUgQ0JPUiBDZXJ0PC91PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBDbGVhbiB1cCBzb21lIG9m IHRoZSBtZXNzIGluIFguNTA5OyBpdCBpcyBhbiBvbGQgc3RhbmRhcmQgd2l0aCBhIGxvdCBvZiBj cnVmdCBhbmQgYmFnZ2FnZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBSZSBkZXNpZ24gZXh0ZW5z aW9ucyBzbyB0aGV5IGFyZSBpbiBDQk9SIGZvcm1hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LSBN YWtlIG1hbnkgb2YgdGhlIGZpZWxkcyBvcHRpb25hbCwgZm9yIGV4YW1wbGUgbm90IGJlZm9yZSBj YW4gb2Z0ZW4gYmUgbGVmdCBvZmYsIG1heWJlIGV2ZW4gc2VyaWFsIG51bWJlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+LSBBdm9pZCBETiBzdHJ1Y3R1cmUgZm9yIGlzc3VlciBhbmQgc3ViamVjdCBm b3IgbW9zdCB1c2UgY2FzZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gVXNlIG1vZGVybiBmb3Jt YXRzIGxpa2UgQ09TRSBhbmQgQ1dUIGFuZCBDT1NFX0tleTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ LSBTaXplIGlzIGltcG9ydGFudCwgYnV0IGZhciBmcm9tIHRoZSBvbmx5IGdvYWwgKHNvbWUgc2l6 ZSByZWR1Y3Rpb25zLCBsaWtlIG9wdGlvbmFsIGZpZWxkcyB3aWxsIGJlIHBvc3NpYmxlIGhlcmUg dGhhdCBhcmUgbm90IHBvc3NpYmxlIHdpdGggcmUtZW5jb2RpbmcpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4tIENvbXBhdGliaWxpdHkgbWF0dGVycywgYnV0IG5vdCBpbiB0aGUgc2FtZSB3YXk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2VlbXMgbGlr ZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gaGVyZSBpcyB0byByZW1vdmUgbmF0aXZlIENCT1IgY2Vy dHMgZnJvbSB0aGlzIGRvY3VtZW50IGFuZCBqdXN0IGZvY3VzIG9uIGNvbXByZXNzaW9uIGFuZCBy ZS1lbmNvZGluZy4gTWF5YmUgZXZlbiBjYWxsIHRoZW0g4oCcQ29tcHJlc3NlZCBDZXJ0c+KAnSBy YXRoZXIgdGhhbiDigJxDQk9SIENlcnRz4oCdLi4gV2hlcmUgdGhhdA0KIHdvcmsgc2hvdWxkIGdv IGlzIGFib3ZlIG15IHBheSBncmFkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5CVVQsIG15IG1haW4gaW50ZXJlc3QgaGVyZSByZWxhdGVzIHRv IENXVCBhbmQgRUFULiBDV1Qgc2VlbXMgbGlrZSBhIHJlYWxseSBnb29kIGNob2ljZSBvbiB3aGlj aCB0byBiYXNlIGEgbmF0aXZlIENCT1IgY2VydC4gU29tZSBvZiB0aGUgZmllbGRzIGZvciBhbiBY LjUwOSBjZXJ0IGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gQ1dUIChzdWJqZWN0LCBpc3N1ZXIsIGV4 cGlyYXRpb24sDQogbm90LWJlZm9yZSkuIEl0IGhhcyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGJ1 aWx0IGluIGFscmVhZHkgaW4gdGhlIENXVCBJQU5BIHJlZ2lzdHJ5LiBUaGUgY3J5cHRvIGFuZCBz aWduaW5nIGFyZSB3ZWxsLWhhbmRsZWQgYnkgQ1dU4oCZcyB1c2Ugb2YgQ09TRS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4gd29yayB0byBmaXQm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYXRz LWVhdC0wMyI+RUFUPC9hPiZuYnNwO2luIGFzIGEgQ1dULCBhIGZldyBpc3N1ZXMgaGF2ZSBjb21l IHVwIOKAlCBob3cgZmllbGRzIC8gY2xhaW1zIGFyZSBtYW5hZ2VkIGFuZCByZWdpc3RlcmVkIHdp dGggSUFOQSwgbGFiZWwgc3BhY2VzIGFuZCBvdGhlci4gJm5ic3A7QWxsDQogdGhlc2UgaXNzdWVz IHdvdWxkIGFwcGx5IHRvIENXVC9DT1NFL0NCT1ItYmFzZWQgY2VydGlmaWNhdGUgYXMgd2VsbC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ VG8gbmFtZSBqdXN0IG9uZSBpc3N1ZSwgaW4gQ1dUIHRoZSBleHBpcmF0aW9uIGRhdGUvdGltZSBj YW4gYmUgYSBmbG9hdGluZy1wb2ludCBudW1iZXIsIHdoaWNoIGlzIGJ1cmRlbnNvbWUsIG5vdCB1 c2VmdWwuIFNob3VsZCB3ZSBjaGFuZ2UgQ1dUIHRvIGRpc2FsbG93IG9yIHNob3VsZCBpdCBqdXN0 IGJlIGRpc2FsbG93ZWQgd2hlbiBhIENXVCBpcyB1c2VkIGFzIGFuDQogRUFUIGFuZCB3aGVuIGl0 IGlzIHVzZWQgYXMgYSBDZXJ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5J4oCZbSBhbHNvIGV4Y2l0ZWQgYXQgdGhlIGlkZWEgb2YgcmUgdXNpbmcg Q1dUIGluIGEgc2ltcGxlIGZvcm0gc28gdGhlcmUgaXMgcmUgdXNlIG9mIGNvZGUgYmV0d2VlbiBD V1QsIEVBVCBhbmQgbmF0aXZlIENCT1IgY2VydHMuIEnigJl2ZSBzdGFydGVkIHBsYXlpbmcgd2l0 aCBhbiBpbXBsZW1lbnRhdGlvbiBsaWtlIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkxMPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3BB4FFA8AABD45209B211F0B0CAFB08Cericssoncom_-- From nobody Tue Apr 28 10:22:58 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638993A0967 for ; Tue, 28 Apr 2020 10:22:56 -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, SPF_HELO_NONE=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 ugmSvO0j5cNL for ; Tue, 28 Apr 2020 10:22:54 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 37BED3A0965 for ; Tue, 28 Apr 2020 10:22:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03SHMksj023057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 13:22:48 -0400 Date: Tue, 28 Apr 2020 10:22:45 -0700 From: Benjamin Kaduk To: Francesca Palombini Cc: "ace@ietf.org" Message-ID: <20200428172245.GQ27494@kduck.mit.edu> References: <158377224835.5665.8978399627549182400@ietfa.amsl.com> <1EC26EAB-B4BF-4EAB-ACC0-E2E8F18D4655@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1EC26EAB-B4BF-4EAB-ACC0-E2E8F18D4655@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 17:22:56 -0000 Hi Francesca, I took a look through the updates and we are looking in quite good shape. I filed https://github.com/ace-wg/ace-oscore-profile/pull/30 with a few final suggested tweaks, though I cannot quite say that they are all just editorial. In particular, I remove text about "the client MUST include the access token using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT")" since I didn't understand how that was expected to work and it wasn't reflected in the example. I also propose to remove "verification of access rights" from the discussion of the procedure to upload a token that updates the access rights on a given security context -- the "verification of access rights" is superficially parallel to the procedures specified in the previous paragraph, but the previous paragraph talks about regular OSCORE exchanges (that do operations that have access control applied to them), whereas the text in question is just for the one-shot "upload new token" operation. Once the text from Jim arrives, then we should be all set on this one ... to wait for the DTLS profile, that is, so the group of four documents goes to the IESG as a unit. Thanks! -Ben On Tue, Mar 10, 2020 at 09:08:11AM +0000, Francesca Palombini wrote: > Hi Ben, ace, > > These 2 updates (09 and 10) address almost all the AD review comments of v-08. > > V-09 covers the majority of them, as we discussed in this thread: https://mailarchive.ietf.org/arch/msg/ace/rgVfs3dzcWQnNlXn331DdpQfwwQ/ and listed in this issue: https://github.com/ace-wg/ace-oscore-profile/issues/26 > > v-10 covers the remaining: > > * The mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. > 6, 7, 32, 61, 65, > * Define and register 2 new ACE parameters to transport the nonces used in the exchange, instead of using "cnonce". > 3, 53, 60 > > The following issue is still open (during the interim meeting Jim volunteered to give a try to draft some text, and we really appreciate his help) and we should pinpoint what we need to include in the document about: > > * Recommendation about length of nonces N1 and N2 to use. > 5, 52 > > > Thanks, > Francesca > > > On 09/03/2020, 17:44, "Ace on behalf of internet-drafts@ietf.org" wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. > > Title : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework > Authors : Francesca Palombini > Ludwig Seitz > Göran Selander > Martin Gunnarsson > Filename : draft-ietf-ace-oscore-profile-10.txt > Pages : 30 > Date : 2020-03-09 > > Abstract: > This memo specifies a profile for the Authentication and > Authorization for Constrained Environments (ACE) framework. It > utilizes Object Security for Constrained RESTful Environments > (OSCORE) to provide communication security, server authentication, > and proof-of-possession for a key owned by the client and bound to an > OAuth 2.0 access token. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-10 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-10 > > > 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/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > From nobody Tue Apr 28 18:12:27 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9E43A092B; Tue, 28 Apr 2020 18:12:24 -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, SPF_HELO_NONE=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 grakBrfhfZYs; Tue, 28 Apr 2020 18:12:18 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 68E083A0871; Tue, 28 Apr 2020 18:12:17 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03T1CAp6015612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 21:12:13 -0400 Date: Tue, 28 Apr 2020 18:12:10 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200429011210.GC27494@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87pnca9gyx.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 01:12:26 -0000 Hi Olaf, Please go ahead and upload a new version to the datatracker when you get a chance; I do have some further comments below. On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote: > Ben, > > Thanks again for the thorough review of the ACE DTLS profile and my > sincere apologies for the long time it took to process. Please find our > comments inline. As this comprises a lot of changes, the proposed text > already has been included in the Editor's copy [1]. Our proposals for > new text are in the section-by-section comments. > > [1] https://ace-wg.github.io/ace-dtls-profile/ > > Benjamin Kaduk writes: > > > Hi all, > > > > Some high-level remarks before delving into the section-by-section > > comments: > > > > This document is pretty clearly DTLS 1.2-specific -- it talks about > > particular protocol messages, message fields, and cipher suites that > > simply do not apply to DTLS 1.3. In order to use this profile with DTLS > > 1.3, we'd need to specify the analogous behavior/requirements to these > > (including standalone signature schemes and key-exchange groups, which > > are now both separately negotiated from the cipher suite). > > Given that DTLS 1.3 is past WGLC and only a few documents behind this > > one in my review queue, it seems fairly prudent to spend some time and > > cover how DTLS 1.3 would work here, since otherwise this document will > > become stale shortly after (or even before!) its publication as an RFC. > > > > There's probably some additional discussion to include about the usage of > > key identifiers in this document versus the potential uses described in > > the core framework. Specifically, the framework reminds us that "no > > assumptions should be made that it is unique in the domains of either > > the client or the RS" yet this document is using the kid as input to a > > KDF that produces keys that must be unique across all clients, and > > allowing live/instant authorization updates based on matching "kid". > > How shall we resolve this apparent conflict? > > > > We also are potentially in violation of the framework's requirements > > with respect to the independent selection of profiles for client/AS and > > client/RS interactions -- at present, when DTLS+RPK is used for > > client/RS, we require that DTLS+RPK is also used for client/AS, in order > > to prove possession of the key. We could perhaps weasel our way out by > > saying that the framework's requirement applies at the profile > > granularity, and with symmetric PSK we can be fully independent, but we > > still need to say something about this property and the interaction with > > the framework's requirements. > > > > This profile is mostly applicable to the client/RS communications and > > feels like it only provides some of the picture for use with client/AS > > interactions. (It doesn't really say much of anything about RS/AS > > interactions.) The introductory discussion does not do a great job of > > painting that picture, and I'd like to see it more clearly introduced > > that the bulk of our coverage is for the client/RS interaction. We also > > lean heavily on the existing out-of-band configuration and key material > > shared between client and AS to secure the client/AS communications; we > > could probably tighten up the discussion about exactly what parameters > > of client/AS communication are specified by this profile. > > The introduction has been revised according to your suggested text, see > below. We also have included some text on the out-of-band configuration > in a new subsection in the security considerations. The important thing > here really are the client/RS and client/AS interactions. Regarding > client/AS, much of this is out of scope as there are certain > OAuth-related assumptions on how these entities get in touch with each > other; neither the framework nor the profile can do much about it > without creating a new enrollment protocol. Regarding the RS/AS > interaction, there is normative language that describes what each of > these entities needs to do in each protocol step covered by the > document. The necessary out-of-band configuration again is described in > the new subsection in the security considerations as well as some > clarifications in the text, see below. > > > We do not say anything about DTLS session resumption (or renegotiation, > > though not talking about that one is perfectly fine); that's a fairly > > core DTLS concept that we should give some guidance on. > > Not sure if we really need to but if you think this is necessary, we can > comment on this, of course. I think we need to give some guidance about what the semantics are if/when it happens. My inclination would be to say that DTLS resumption can be used to amortize the cost of a handshake, but DTLS 1.2 resumption does not provide forward secrecy and also does not provide an opportunity for the client to prove possession of the PoP key, so servers will want to periodically force a full handshake according to their authentication requirements. I'd also be inclined to forbid renegotiation entirely. > > Looking through Appendix C ("Requirements on Profiles") of the > > framework, do we want to say anything about: > > > > - using the client credentials grant with this profile, as that's IIRC > > the only example we show > > Do you think we need to say anything here? The actual grant used to > make the client known to the AS is out of scope for the profile as > long as the requirements given here are met. I don't think we strictly need to, no. > > - require that DTLS be used in a mode that provides replay protection > > Added as a requirement in Section 2. > > > - when the client uses the authz-info endpoint instead of the > > "psk_identity" field to convey the token to the RS, how does the RS > > know which client is connecting (and thus what PSK to use), and what > > does the client actually *put* in the "psk_identity" field? (The > > other aspects of "how to select a proof-of-possession protocol" seem > > to fall out naturally from the DTLS usage.) > > We have included more explanatory text in section 3.3.1 on how this is > supposed to work. It looks like we now say the client "MUST include an access token that indicates the kid contained in the uploaded access token as psk_identity", which seems to be talking about two different access tokens. Is one of them uploaded to authz-info and the other used to populate the "psk_identity" field? The following sentences seem to imply that, but the quoted sentence is hard to parse. Perhaps just "The client then needs to indicate during the DTLS handshake which previously uploaded access token it intends to use." That proposed text drops the "MUST", so maybe we would want to put that back in the later sentence(s). > > - whether/how introspection is used? > > We have added text stating that token introspection may be used but is > out of scope for the profile spec. > > > - give more details of what this profile mandates when used for > > client/AS interactions (as mentioned above) > > This should be covered now, see detailed responses below. > > > - explicitly state that the authz-info endpoint is unprotected (or that > > it might be protected if, e.g., the RS has a trustable certificate > > that would be used instead of RPK or PSK, or by supplying the > > token as the "psk_identity" when symmetric PoP is used, or by only > > doing server-authentication with RPK as known by the client by the > > rs_cnf access information > > I am not sure which security gain we would yield by trustable > certificates: The client does not need to authenticate the resource > server for the authz-info upload. The important aspect here is that the > access token must be integrity-protected by the AS and encrypted if it > contains information to be kept confidential (esp. a shared secret but > possibly other data as well). We have added some text on this to the > security considerations. It looks like this will be enough to meet the requirements from the framework (though I'm not looking at an actual diff so I'm not 100% sure). > > And now, on to the section-by-section comments. > > > > Section 1 > > > > a DTLS session. The communication between client and authorization > > server may also be secured with DTLS. This specification supports > > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys > > (PSK) [RFC4279]. > > > > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called > > "external") PSKs.] > > (See general discussion on wether DTLS 1.3 needs to be addressed at this > time.) > > > The DTLS handshake requires the client and server to prove that they > > can use certain keying material. In the RPK mode, the client proves > > with the DTLS handshake that it can use the RPK bound to the token > > and the server shows that it can use a certain RPK. The access token > > must be presented to the resource server. For the RPK mode, the > > access token needs to be uploaded to the resource server before the > > handshake is initiated, as described in Section 5.8.1 of the ACE > > framework [I-D.ietf-ace-oauth-authz]. > > > > This seems to be making some implicit assumptions about the message flow > > that have not yet been covered by this document and are only somewhat > > covered by the core framework spec. I'd propose: > > > > % The ACE framework requires that client and server mutually > > % authenticate each other before any other protocol exchanges take > > % place. > > Actually, this is not true: The client can upload data to the > resource server's authorization endpoint without authentication. I > suggest to rephrase this as "The ACE framework requires that client > and server mutually authenticate each other before any application > data is exchanged.", see below. Good catch, thanks! > > % In order for DTLS to provide mutual authentication, both > > % client and server must prove their ability to use certain keying > > % material (tied to the authenticated identity) as part of the DTLS > > % handshake. The AS assists in this process by incorporating key > > % material (or information about key material) into the access token, > > % which is considered a "proof of possession" token. In the RPK mode, > > % the client proves that it can use the RPK bound to the token and the > > % server shows that it can use a certain RPK (as indicated by the AS to > > % the client). The resource server needs access to the token in order > > % to complete this exchange. For the RPK mode, the access token needs > > % to be uploaded to the resource server before the handshake is > > % initiated, as described in Section 5.8.1 of the ACE framework > > % [I-D.ietf-ace-oauth-authz]. > > > > though I recognize that my text tends to be a bit more verbose than is > > strictly needed, so please feel free to edit it down. > > We propose the following change: > > OLD: > > The DTLS handshake requires the client and server to prove that they > can use certain keying material. In the RPK mode, the client proves > with the DTLS handshake that it can use the RPK bound to the token > and the server shows that it can use a certain RPK. The access token > must be presented to the resource server. For the RPK mode, the > access token needs to be uploaded to the resource server before the > handshake is initiated, as described in Section 5.8.1 of the ACE > framework {{I-D.ietf-ace-oauth-authz}}. > > NEW: > > The ACE framework requires that client and server mutually > authenticate each other before any application data is exchanged. > DTLS enables mutual authentication if both client and server prove > their ability to use certain keying material in the DTLS handshake. > The authorization server assists in this process on the server side > by incorporating keying material (or information about keying > material) into the access token, which is considered a "proof of > possession" token. > > In the RPK mode, the client proves that it can use the RPK bound to > the token and the server shows that it can use a certain RPK (as > indicated by the authorization server to the client). > > The resource server needs access to the token in order to complete > this exchange. For the RPK mode, the client must upload the access > token to the resource server before initiating the handshake, as > described in Section 5.8.1 of the ACE framework > {{I-D.ietf-ace-oauth-authz}}. This looks good. > > Section 2 > > > > The CoAP-DTLS profile for ACE specifies the transfer of > > authentication information and, if necessary, authorization > > information between the client (C) and the resource server (RS) > > during setup of a DTLS session for CoAP messaging. It also specifies > > how C can use CoAP over DTLS to retrieve an access token from the > > authorization server (AS) for a protected resource hosted on the > > resource server. > > > > I suggest reiterating that "As specified in Section 6.7 of > > [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these > > interactions is completely independent". > > done > > > To determine the AS in charge of a resource hosted at the RS, C MAY > > send an initial Unauthorized Resource Request message to the RS. The > > > > This is part of the core framework, so the "MAY" may be overkill. > > (Lowercase "can" would do just fine.) > > done > > > Once the client knows the authorization server's address, it can send > > an access token request to the token endpoint at the AS as specified > > > > Hmm. There's some level of "the client needs to have already been > > configured that that AS is a valid AS" verification that's done here, > > but I'm not sure if that's too much detail to include at this stage > > (since we're really just summarizing the framework here). > > Yes, there has been a discussion on this. The issue with this three > corner model is that the client needs a pretty tight relationship with > the AS, meaning that it must be able to recognize an AS depicted in the > AS Request Creation Hints as trustworthy. > > > in [I-D.ietf-ace-oauth-authz]. As the access token request as well > > as the response may contain confidential data, the communication > > between the client and the authorization server MUST be > > > > (This "MUST" is already a requirement from the core framework, so we > > don't necessarily need to repeat it as normative language.) > > Okay, changed to lower case. > > > confidentiality-protected and ensure authenticity. C may have been > > registered at the AS via the OAuth 2.0 client registration mechanism > > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. > > > > Section 5.3 of oauth-authz says that registration is "out of scope"; is > > this still the right reference? > > It is the correct reference but unfortunately, Section 5.3 of the > framework document just says that "Authentication of the client is > mandatory". The issue here is that the framework as well as OAuth > requires a prior registration of the client. Otherwise, the AS would not > be able to authorize the client in the three corner model. Not including > the reference would mean to repeat the requirement of client > registration here. Okay. > > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric > > proof-of-possession key in the DTLS handshake, the procedure as above > > MAY be used, or alternatively, the access token MAY instead be > > transferred in the DTLS ClientKeyExchange message (see > > Section 3.3.1). > > > > (This is not DTLS 1.3-compatible.) > > Agreed. This would need a change if we decided to add-in support for > DTLS 1.3. > > > Section 3 > > > > secured. Depending on the used CoAP security mode (see also > > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client > > response and DTLS session establishment carry slightly different > > information. [...] > > > > At this point in the document it's pretty unclear what "Client-to-AS > > request", "AS-to-Client response", and "DTLS session establishment" are > > and how they relate to each other. > > The "Client-to-AS request" and "AS-to-Client response" are introduced by > the ACE framework document. Maybe an explicit reference helps to avoid > confusion. > > OLD: > > Depending on the used CoAP security mode (see also Section 9 of > {{RFC7252}}, the Client-to-AS request, AS-to-Client response and DTLS > session establishment carry slightly different > information. {{rpk-mode}} addresses the use of raw public keys while > {{psk-mode}} defines how pre-shared keys are used in this profile. > > NEW: > > Depending on the used CoAP security mode (see also Section 9 of > {{RFC7252}}, the Client-to-AS request, AS-to-Client response (see > Section 5.6 of {{I-D.ietf-ace-oauth-authz}}) and DTLS session > establishment carry slightly different information. {{rpk-mode}} Thanks! > > Also, it seems like the behavior in Section 3.2 and 3.3 are relating to > > the mode used for the client/RS interactions, which relates to the > > client/AS interactions only in the form of how PoP information is bound > > to/with the token. > > I am not sure if there is anything else to say about the client/AS > interactions that is not covered by the framework. > > > Section 3.1 > > > > establish a secure communication channel. C MUST securely have > > obtained keying material to communicate with AS. Furthermore, C MUST > > verify that AS is authorized to provide access tokens (including > > authorization information) about RS to C. Also, AS MUST securely > > have obtained keying material for C, and obtained authorization rules > > approved by the resource owner (RO) concerning C and RS that relate > > to this keying material. [...] > > > > The way this is written right now, we're going to get lots of questions > > from reviewers about "how does this happen?" and for more details about > > it. We are effectively assuming that this stuff is all provisioned > > already as part of the device configuration or during enrollment, we > > should say something about these being requirements on device > > provisioning, not on the operation of the ACE protocol. > > The following new text has been added for clarification: > > NEW: > > This profile assumes that the keying material to secure this > communication channel has securely been obtained either by manual > configuration or in an automated provisioning process. Thanks! > > between C and AS is bootstrapped is not part of this document. C and > > AS MUST ensure the confidentiality, integrity and authenticity of all > > exchanged messages. > > > > I think this is also restating requirements from the core framework, and > > may not need normative language in this manner. > > done > > > Section 3.2 > > > > I know that the section heading says "RawPublicKey Mode" already, but > > I'd recommend adding a sentence in the preface that repeats that "When > > the client and RS use RawPublicKey authentication, the procedure is as > > follows"; we might get complaints otherwise that we are saying that the > > client MUST do things that are not universal requirements. > > (Section 3.3 does already have something like this for the symmetric-key > > case.) > > done > > > previously made known to the authorization server. To prove that the > > client is in possession of this key, C MUST use the same keying > > material that it uses to secure the communication with AS, e.g., the > > DTLS session. > > > > This seems in conflict with the core framework's requirement that the > > client/AS profile and client/RS profile are severable. > > This profile explicitly specifies the communication flow between C and > AS on one side and between C and RS on the other. As both legs are part > of this profile, there is no combination of profiles involved. In that > regard, there is no such assumption as indicated in Section 6.7 of the > framework. > > *) https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-6.7 > > We could weaken the security here by removing the "To prove"-statement. > However, it is advisable not to do this because by using the keying > material in the C/AS communication, C shows that it is actually in > possession of the respective private key. This would raise the bar for > the client to retrieve access tokens in the name of other clients. > > The preferred alternative would be replace MUST with SHOULD: > > OLD: > > previously made known to the authorization server. To prove that the > client is in possession of this key, C MUST use the same keying > material that it uses to secure the communication with AS, e.g., the > DTLS session. > > NEW: > > previously made known to the authorization server. To prove that the > client is in possession of this key, C SHOULD use the same keying > material that it uses to secure the communication with AS, e.g., the > DTLS session. That seems like it's going in the right direction, but I'm not sure it's the precise change we want. Basically, we need to keep the requirement that the client prove possession of the key, and we want the recommended way to be to use it for DTLS with the AS, but we can't require that the client use DTLS to talk to the AS, because we "MUST NOT depend on the assumption that the profile is used for all the different types of interactions". So perhaps NEWNEW: % previously made known to the authorization server. It is RECOMMENDED that % C use DTLS with the same keying material to secure the communication with % AS, proving possession of the key as part of the token request, but other % mechanisms for proving possession of the key may be defined in the % future. > > > AS MUST check if the client that it communicates with is associated > > with the RPK in the cnf object before issuing an access token to it. > > > > Earlier in the section we noted a requirement to prove possession of the > > key by using it in DTLS; why is there a separate "association" > > requirement? > > This is the same rationale as above. The AS needs some way to decide > which authorization rules apply to the requesting client. There was a > discussion on the mailing list that the client may use a different RPK > in the communication with AS than it uses in the communication with the > resource server. AS then must ensure two things: First, that the > authorization decision coded into the access token applies to the RPK > provided by C. Second, that the access token is transferred to the same > C. > > The following text has been added to the Security Considerations to > explain the problems that arise from using different RPKs for the C/AS > and C/RS communication: > > NEW: > > The authorization server must ascertain that the keying material > for the client that it provides to the resource server actually is > associated with this client. Malicious clients may hand over > access tokens containing their own access permissions to other > entities. This problem cannot be completely > eliminated. Nevertheless, in RPK mode it should not be possible > for clients to request access tokens for arbitrary public keys, > since that would allow the client to relay tokens without the need > to share its own credentials with others. The authorization server I think this sentence could probably be wordsmithed some more, though I don't have a concrete proposal at the moment. It does seem like we might want to discuss this scenario more in terms of "identity misbinding" than "relay tokens", though. (We had a SAAG talk at IETF 104 about misbinding attacks on device pairing, which is not quite the same, but shares some of the concepts.) > therefore should at some point validate that the client can > actually use the private key corresponding to the client's public > key. Why is this only "should", vs. (e.g.) "needs to"? > > > also, nit: "The AS". > > done > > > which case it does not have to be sent. The response also contains > > an access token and an "rs_cnf" parameter containing information > > about the public key that is used by the resource server. AS MUST > > > > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when > > DTLS-RPK is used for client-RS interactions?) > > Done as follows: > > OLD: > > The response also contains an access token and an "rs_cnf" > parameter containing information about the public key that is used > by the resource server. AS MUST ascertain that the RPK specified > in "rs_cnf" belongs to the resource server that C wants to > communicate with. > > NEW: > > The response also contains an access token with information about > the public key that is used by the resource server. The This sounds like "the information[...]" is part of the access token; maybe "along with"? > authorization server MUST return in its response the parameter > "rs_cnf" unless it is certain that the client already knows the > public key of the resource server. The authorization server MUST > ascertain that the RPK specified in "rs_cnf" belongs to the resource > server that the client wants to communicate with. > > > nit: "The AS" again (and throughought, to a large extent). > > [Okay, we will change these for I-D submission.] > > > server that C wants to communicate with. AS MUST protect the > > integrity of the token. If the access token contains confidential > > data, AS MUST also protect the confidentiality of the access token. > > > > This requirement ("protect the integrity of the token") feels a little > > underspecified, as it doesn't say protection over what workflow or who > > will verify the integrity (the RS). > > done, by adding > > NEW: > > to ensure that the resource server can detect unauthorized changes. > > > C MUST ascertain that the access token response belongs to a certain > > previously sent access token request, as the request may specify the > > resource server with which C wants to communicate. > > > > nit: I recomment rewording "belongs to", perhaps as "corresponds to". > > DTLS can provide this guarantee when configured to do so, though it is > > not a guaranteed property from DTLS. > > Changed to: > > OLD: > > C MUST ascertain that the access token response corresponds to a > certain previously sent access token request,... > > NEW: > > the client MUST check if the access token response is bound to a > certain previously sent access token request, > > > We'll probably get some grief about the "access_token" contents in the > > example not being valid CBOR, due to the parenthetical comment. We > > could probably put a note in the preface that the value is truncated for > > readability. Also, nit: "the client's" with article and apostrophe. > > Okay. For now, I have put in a disclaimer into the description of the > two examples where this occurs. Thanks! > > Section 3.2.1 > > > > Before the client initiates the DTLS handshake with the resource > > server, C MUST send a "POST" request containing the new access token > > to the authz-info resource hosted by the resource server. After the > > client > > > > nit: we don't require single-use tokens, so "new" is probably overkill; > > just "its access token" should suffice. > > nit: formatting issue with spurious line break here. > > done > > > server. To use the RawPublicKey mode, the client MUST specify the > > public key that AS defined in the "cnf" field of the access token > > response in the SubjectPublicKeyInfo structure in the DTLS handshake > > as specified in [RFC7250]. > > > > IIRC the access token response does not have to include a "cnf" field > > (e.g., if the AS accepts the req_cnf from the request), so "defined in > > the field of the response" doesn't seem like quite the right wording. > > Done: > > OLD: > > To use the RawPublicKey mode, the client MUST specify the public > key that AS defined in the `cnf` field of the access token response > in the SubjectPublicKeyInfo structure in the DTLS handshake as > specified in {{RFC7250}}. > > NEW: > > The client MUST use its correct public key in the DTLS > handshake. If the authorization server has specified a `cnf` field > in the access token response, the client MUST use this > key. Otherwise, the client MUST use the public key that it > specified in the `req_cnf` of the access token request. The client > MUST specify this public key in the SubjectPublicKeyInfo structure > of the DTLS handshake as described in [RFC7250]. > > > An implementation that supports the RPK mode of this profile MUST at > > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > > > > I understand that making the full-width-tag ciphersuite MTI would > > exclude some devices, though it feels like some recommendation to use > > the full-length tag when possible would be appropriate. That said, I do > > see that RFC 7252 makes no such remark, and thus consistency would have > > us not say anything either. > > We have now included more text on the tag length in the Security > Considerations, see below. Thanks; I think that text strikes a good balance. > > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). > > > > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE > > operation is called x25519, and both algorithms make use of the > > elliptical curve known as curve25519. Since we are using both ECDHE and > > ECDSA, it's probably simplest to just refer to "curve25519", though > > mentioning both ed25519 and x25519 would also work. > > This has been a WG decision at some point but the authors agree that > curve25519 is the best to go for and propose the following change which > also gets rid of the ugly note in favor of more coherent text: > > OLD: > > An implementation that supports the RPK mode of this profile MUST > at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). > > NEW: > > To be consistent with {{RFC7252}} which allows for shortened MAC > tags in constrained environments, an implementation that supports > the RPK mode of this profile MUST at least support the ciphersuite > TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CCM\_8 {{RFC7251}}. As discussed > in {{RFC7748}}, new ECC curves have been defined recently that are > considered superior to the so-called NIST curves. This specification > therefore mandates implementation support for curve25519 > (cf. {{RFC8032}}, {{RFC8422}}) as this curve said to be efficient > and less dangerous regarding implementation errors than the > secp256r1 curve mandated in {{RFC7252}}. > > > RS MUST check if the access token is still valid, if RS is the > > intended destination, i.e., the audience, of the token, and if the > > token was issued by an authorized AS. The access token is > > > > nit: "i.e., the audience" is in effect a parenthetical, so using commas > > to offset it inside a comma-separated list is potentially confusing; I'd > > suggest using actual parentheses instead of commas around it. > > done > > > reference to this key. If the authorization server has no certain > > knowledge that the Client's key is already known to the resource > > server, the Client's public key MUST be included in the access > > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as > > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as > > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the > > > > Is talking about """the access token's "cnf" parameter" consistent with > > allowing the use of non-CWT (non-JWT) token formats? > > This has been addressed by adding the following paragraph to the > introduction: > > NEW: > > As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this > specification uses CBOR web tokens to convey claims within an > access token issued by the server. While other formats could be > used as well, those are out of scope for this document. I think that will work; thanks. > > keying material in the handshake that AS specified in the rs_cnf > > parameter in the access token. Thus, the handshake only finishes if > > C and RS are able to use their respective keying material. > > > > I suggest being explicit about "the DTLS handshake with the client", > > perhaps as "MUST use in the DLTS handshake with the client the keying > > material that the AS specified in the rs_cnf parameter in the access > > token". > > Done, see next comment. > > > The same caveat about "parameter in the access token" > > applies here, though I guess there is an additional complication for > > "rs_cnf" in that it's an token response parameter but I don't remember > > that we say a huge amount about it also being included in the token > > itself -- the token response is directed to the client but the token is > > directed to the RS. > > As we have found, the mailing list discussion concluded that the access > token does not contain an rs_cnf claim at all. This occurrence most > likely was an artefact. This now has been changed as follows: > > OLD: > > RS MUST use the keying material in the handshake that AS specified > in the rs_cnf parameter in the access token. Thus, the handshake > only finishes if C and RS are able to use their respective keying > material. > > NEW: > > The resource server MUST use its own raw public key in the DTLS > handshake with the client. If the resource server has several raw > public keys, it must already know which key it is supposed to use > with this client. How this is achieved is not part of this profile. > > > Section 3.3 > > > > token. AS MUST check if the identifier refers to a symmetric key > > that was previously generated by AS as a shared secret for the > > communication between this client and the resource server. > > > > "What does the AS do if this check fails?" > > The following text has been added to avoid additional roundtrips for the > client: > > NEW: > > If no such symmetric key was found, the AS MUST generate a new > symmetric key that is returned in its response to the client. :) > > The authorization server MUST determine the authorization rules for > > the C it communicates with as defined by RO and generate the access > > > > nit: it's surprising to see "authorization server" spelled out in the > > same sentence as "C" and "RO" (which, incidentally, we don't seem to use > > in abbreviation form anywhere other than where we define it). > > There has been some discussion about the short forms. We will > harmonize this before submitting the next I-D version. Okay, thanks. > > wants to communicate with. Also, AS MUST protect the integrity of > > the access token. If the token contains confidential data such as > > the symmetric key, the confidentiality of the token MUST also be > > protected. Depending on the requested token type and algorithm in > > > > (same comment about "protect the integrity" or "protect" as for the RPK > > case.) > > Done, by adding: > > NEW: > > to ensure that the resource server can detect unauthorized changes. > > > that is to be used between C and the resource server. The access > > token MUST be bound to the same symmetric key by means of the cnf > > claim. > > > > Now we call it a "claim" rather than a "token parameter", but this again > > seems to be implicitly assuming CWT/JWT for tokens. > > We distinguish between the (semantic) information conveyed by an access > token of the syntactic description of data objects. To make this more > explicit, we now have added some text in the Terminology section that > refers to the same usage of the term 'claim' as in the framework > document. Thank you! > > (Also, this "MUST" seems like something that the framework should > > guarantee and not a new requirement that the DTLS profile imposes.) > > As this as been a bit misleading as well, it has been rephrased as > follows: > > OLD: > > The access token MUST be bound to the same symmetric key by means > of the cnf claim. > > NEW: > > To convey the same secret to the resource server, the > authorization server either includes it directly in the access > token by means of the `cnf` claim or it provides sufficient > information to enable the resource server to derive the key from > the access token using key derivation. > > > Figure 5: Example Access Token Request, symmetric PoP-key > > > > Maybe we could include "(implicit)" in the caption, since symmetric PoP > > key is the default. > > done > > > An example access token response is illustrated in Figure 6. In this > > > > Is it accurate to say "A corresponding example access token response"? > > It's nice to the reader if we can tie the examples together like that. > > done > > > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment > > about having the parenthetical comment in the example body vs. preface.) > > New text was added as follows to clarify that inconsistencies with > cached responses should be avoided. For a more realistic example, the > value of Max-Age in the examples has been decreased to be sufficiently > below expires_in: > > NEW: > > Caching proxies process the Max-Age option in the CoAP response > which has a default value of 60 seconds (Section 5.6.1 of > [RFC7252]). The authorization server SHOULD adjust the Max-Age > option such that it does not exceed the `expires_in` parameter to > avoid stale responses. > > > token_type : pop, > > > > Didn't we switch this to being capitalized as "PoP"? > > done > > > "COSE_Encrypt0" structure. The AS MUST use the keying material > > shared with the RS to encrypt the token. > > > > nit: I suggest s/shared with/it shares with/ > > done > > > We should probably say something about why the kid in Figure 7 is > > different from the one in Figure 6. > > As it seems more clear if both examples use the same kid, this now has > been harmonized. > > > 4.00 Bad Request > > Content-Format: application/ace+cbor > > Payload: > > { > > error : invalid_request > > } > > > > Figure 8: Example Access Token Response With Reject > > > > RFC 6749's description of "invalid_request" seems to imply that it's > > mostly about malformed requests, as opposed to the AS deciding that the > > client is not authorized for any access to the requested resource (which > > is maybe what's implied by the previous paragraph). This is not > > necessarily a problem, but perhaps we could make the text and example > > more consistent. > > This example is actually about malformed requests (4.00). We now have > added text to clarify this. Ah, looks good :) > > The method for how the resource server determines the symmetric key > > from an access token containing only a key identifier is application > > specific, the remainder of this section provides one example. > > > > nit: hyphenate "application-specific", and this is a comma splice. > > done > > > resource server. This key needs to be securely stored and processed > > in the same way as the key used to protect the communication between > > AS and RS. > > > > nit: is this better as "processed" or "protected"? > > "processed" because this part is about the handling not the > characteristics of the data. > > > The fields in the context information "COSE_KDF_Context" > > (Section 11.2 of [RFC8152]) have the following values: > > > > o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" > > > > RFC 8152 says that these AlgorithmID values come from the COSE > > Algorithms registry, which this does not (unless we register it there, > > which we don't currently). Also, since the output is used directly for > > DTLS PSK, I don't think the "key-derivation" portion is needed. > > > > o PartyUInfo = PartyVInfo = ( null, null, null ) > > > > (8152 seems to prefer "nil" over "null".) > > > > o keyDataLength needs to be defined by the application > > > > o protected MUST be a zero length bstr > > > > o other is a zero length bstr > > > > (These three are all members of the "SuppPubInfo" field, which is not > > very clear from how we include them in the same list as top-level > > fields.) > > The example now has updated and rephrased according to HKDF usage. The formatting/discussion looks good, but I'll need to cross-check the data structures once the new revision is uploaded. > > Section 3.3.1 > > > > When a client receives an access token response from an authorization > > server, C MUST ascertain that the access token response belongs to a > > certain previously sent access token request, as the request may > > specify the resource server with which C wants to communicate. > > > > (Same bit about "belongs to".) > > done > > > If a resource server receives a ClientKeyExchange message that > > contains a "psk_identity" with a length greater zero, it uses the > > contents as index for its key store (i.e., treat the contents as key > > > > (This is not DTLS 1.3-compatible.) > > See side discussion on DTLS versions. > > > nits: "greater than", "as an index", "as a key identifier" > > done > > > identifier). The resource server MUST check if it has one or more > > access tokens that are associated with the specified key. > > > > I don't understand this sentence -- isn't the access token the precise > > contents of the "psk_identity" field, so that there would be a key > > associated with the access token, not the other way around? > > Now clarified that the psk_identity must contain the opaque access > token: > > OLD: > > Alternatively, the client MAY provide the most recent access > token in the `psk_identity` field of the ClientKeyExchange > message. To do so, the client MUST treat the contents of the > `access_token` field from the AS-to-Client response as opaque data > and not perform any re-coding. > > Note: > As stated in Section 4.2 of [RFC7925], the PSK identity should be > treated as binary data in the Internet of Things space and not > assumed to have a human-readable form of any sort. > > NEW: > > As an alternative to the access token upload, the client can > provide the most recent access token in the `psk_identity` field of > the ClientKeyExchange message. To do so, the client MUST treat the > contents of the `access_token` field from the AS-to-Client response > as opaque data as specified in Section 4.2 of [RFC7925] and not > perform any re-coding. This allows the resource server to retrieve > the shared secret directly from the `cnf` claim of the access > token. > > > If no key with a matching identifier is found, the resource server > > MAY process the contents of the "psk_identity" field as access token > > > > Similarly here, the causality feels reversed. > > Hopefully, this has been sufficiently clarified by the previous > comment. Moreover, the following change is proposed to emphasize the > aforementioned behavior of RS. The access token now must always be > parsed but may contain a kid for an already known key: I think I confused myself with the previous diff, but your description here and the text in the editor's copy seem to make sense, so I'm willing to say that I got confused earlier and move on. > OLD: > > If a resource server receives a ClientKeyExchange message that > contains a `psk_identity` with a length greater than zero, it uses > the contents as an index for its key store[...] > > [...] session setup is terminated with an `illegal_parameter` DTLS > alert message. > > NEW: > > If a resource server receives a ClientKeyExchange message that > contains a `psk_identity` with a length greater than zero, it MUST > process the contents of the `psk_identity` field as access token > that is stored with the authorization information endpoint, before > continuing the DTLS handshake. If the contents of the > `psk_identity` do not yield a valid access token for the requesting > client, the resource server aborts the DTLS handshake with an > `illegal_parameter` alert. > > > continuing the DTLS handshake. If the contents of the "psk_identity" > > do not yield a valid access token for the requesting client, the DTLS > > session setup is terminated with an "illegal_parameter" DTLS alert > > message. > > > > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' alert" > > would be more conventional phrasing. > > done > > > Note2: According to [RFC7252], CoAP implementations MUST support the > > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is > > therefore expected to offer at least this ciphersuite to the > > resource server. > > > > Do we want to say anything about the (EC)DHE variants? Short-lived access > > tokens with the AS generating new symmetric keys can provide similar > > forward-secrecy properties to using DHE, but there is in general a trend > > in the IETF towards defaulting to providing forward secrecy in key > > exchanges. > > Yes, this makes a lot of sense. We have added the following text to > the Security Considerations to give advice: > > NEW: > > The PSK mode of this profile offers a distribution mechanism to > convey authorization tokens together with a shared secret to a > client and a server. As this specification aims at constrained > devices and uses CoAP [RFC7252] as transfer protocol, at least the > ciphersuite TLS\_PSK\_WITH\_AES\_128\_CCM\_8 {{RFC6655}} should be > supported. The access tokens and the corresponding shared secrets > generated by the authorization server are expected to be > sufficiently short-lived to provide similar forward-secrecy > properties to using ephemeral Diffie-Hellman (DHE) key exchange > mechanisms. For longer-lived access tokens, DHE ciphersuites should > be used. Nicely said! > > When RS receives an access token, RS MUST check if the access token > > is still valid, if RS is the intended destination, i.e., the audience > > of the token, and if the token was issued by an authorized AS. This > > > > As above, "i.e., the audience of the token" would probably be better > > when offset in parentheses than by commas. > > done > > > While the client can retrieve the shared secret from the contents of > > the "cnf" parameter in the AS-to-Client response, the resource server > > uses the information contained in the "cnf" claim of the access token > > to determine the actual secret when no explicit "kid" was provided in > > the "psk_identity" field. If key derivation is used, the RS uses the > > "COSE_KDF_Context" information as described above. > > > > "psk_identity" is a field in ClientKeyExchange, and we say that its > > contents are the raw access token for our usage. It does not have a > > direct COSE structure for this talk of "kid" to make much sense without > > further explanation. > > Yes, this is misleading. We propose the following to clarify the > processing of access tokens (independent whether this has been uploaded > or carried in the psk_identity) on the RS: > > OLD: > > While the client can retrieve the shared secret from the contents > of the `cnf` parameter in the AS-to-Client response, the resource > server uses the information contained in the `cnf` claim of the > access token to determine the actual secret when no explicit `kid` > was provided in the `psk_identity` field. If key derivation is > used, the RS uses the `COSE_KDF_Context` information as described > above. > > NEW: > > While the client can retrieve the shared secret from the contents > of the `cnf` parameter in the AS-to-Client response, the resource > server uses the information contained in the `cnf` claim of the > access token to determine the actual secret. To retrieve the `cnf` > claim and determine the shared secret for the session between the > client and the resource server, the resource server first has to > decrypt the access token if it is enclosed in a `COSE_Encrypt0` > structure and then parse the access token. The parsed access > token then is associated with the `kid` for the contained shared > secret, if any. If key derivation is used, the resource server > calculates the shared secret from the `COSE_KDF_Context` > information as described above. > > > Section 3.4 > > > > We may get some requests for a more explicit definition of what the > > "authorization information" tied to a client is. > > > > Once a DTLS channel has been established as described in Section 3.2 > > and Section 3.3, respectively, the client is authorized to access > > > > nit: I think "or" is more appropriate to join the sections listed, as > > only one is applicable to a given connection. > > done > > > With the successful establishment of the DTLS channel, C and RS have > > proven that they can use their respective keying material. An access > > token that is bound to the client's keying material is associated > > with the channel. Any request that the resource server receives on > > this channel MUST be checked against these authorization rules. RS > > > > nit: I'd s/these/the following/ > > done > > > MUST check for every request if the access token is still valid. > > Incoming CoAP requests that are not authorized with respect to any > > access token that is associated with the client MUST be rejected by > > the resource server with 4.01 response as described in Section 5.1.1 > > of [I-D.ietf-ace-oauth-authz]. > > > > "any access token" implies there might be more than one, though I seem > > to recall discussion of updated tokens overwriting any previous one, so > > that only one token per client is active at any given time. What did we > > end up settling on? > > done > > OLD: > > Any request that the resource server receives on this channel MUST > be checked against these authorization rules. RS MUST check for > every request if the access token is still valid. Incoming CoAP > requests that are not authorized with respect to any access token > that is associated with the client MUST be rejected by the resource > server with 4.01 response as described in Section 5.1.1 of > [I-D.ietf-ace-oauth-authz]. > > NEW: > > According to section 5.8.1 of [I-D.ietf-ace-oauth-authz], there > should be only one access token for each client. New access tokens > issued by the authorization server are supposed to replace > previously issued access tokens for the respective client. The > resource server therefore must have a common understanding with > the authorization server how access tokens are ordered. > > Any request that the resource server receives on a DTLS channel > that is tied to an access token via its keying material MUST be > checked against the authorization rules that can be determined > with the access token. The resource server MUST check for every > request if the access token is still valid. Incoming CoAP requests > that are not authorized with respect to any access token that is > associated with the client MUST be rejected by the resource server > with 4.01 response. The response MAY include AS Request Creation > Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. I think this is good; it repeats the hints from the core framework that getting things right with multiple active tokens is hard, but doesn't strictly forbid it. > > Also, the referenced framework Section 5.1.1 does not actually mandate > > the 4.01 response code. > > Fixed in the proposed text for the previous comment: We now require the > 4.01 and do not imply that this is required by section 5.1.1 of the > framework document which is silent on the proper response codes. > > > The resource server SHOULD treat an incoming CoAP request as > > authorized if the following holds: > > > > We could say more about this "SHOULD" (or change the way we discuss it) > > -- is it the minimum baseline of checks and additional checks may be > > applied, or do some of them not apply in some cases, or ...? > > These are the minimum checks that the RS needs to do. The following > proposal should make this clearer: > > OLD: > > The resource server SHOULD treat an incoming CoAP request as > authorized if the following holds: > > NEW: > > The resource server MUST only accept an incoming CoAP request as > authorized if the following holds: That's good. I didn't think very hard about whether adding a brief note after the list along the lines of "additional checks may be applied according to local policy" would add value; it may well go without saying. > > Incoming CoAP requests received on a secure DTLS channel that are not > > thus authorized MUST be rejected according to Section 5.8.2 of > > [I-D.ietf-ace-oauth-authz] > > > > We may also get some questions asking about what the difference is > > between the "not authorized with respect to any access token" in the > > previous quoted snippet" and "not thus authorized" in this quoted > > snippet. > > We hope that the previous change should have fixed this as well. That seems likely :) > > The client cannot always know a priori if an Authorized Resource > > Request will succeed. It MUST check the validity of its keying > > material before sending a request or processing a response. If the > > > > What does "check the validity of its keying material" mean? > > The following change should make this more clear as the only thing that > the client can do is to check if the keying material is still valid: > > OLD: > > The client cannot always know a priori if an Authorized Resource > Request will succeed. It MUST check the validity of its keying > material before sending a request or processing a response. > > NEW: > > The client MUST ascertain that its keying material is still valid > before sending a request or processing a response. > > > > client repeatedly gets error responses containing AS Creation Hints > > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its > > requests, it SHOULD request a new access token from the authorization > > server in order to continue communication with the resource server. > > > > Why should this only be done in the case of *repeatedly* getting such > > error responses; I thought the idea of the AS Request Creation Hints was > > to take immediate effect. > > Correct. The intention was to deal with the race condition for the > upload mechanism. But as this affects different communication channels, > it is safe to just remove the word "repeatedly": > > OLD: > > client repeatedly gets error responses containing AS Creation Hints > > NEW: > > client gets an error response containing AS Request Creation Hints > > > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) > > done > > > Section 4 > > > > The client can update the authorization information stored at the > > resource server at any time without changing an established DTLS > > session. To do so, the Client requests a new access token from the > > authorization server for the intended action on the respective > > resource and uploads this access token to the authz-info resource on > > the resource server. > > > > I suggest adding another sentence similar to "Because ACE tokens are > > proof-of-possession tokens, the updated authorization information only > > takes immediate effect if such proof has already been provided, e.g., if > > the PoP key associated with the new token is the same as the one > > currently in use." This is further detailed in the following > > paragraphs, but not stated concretely as a key principle. > > The term "ACE tokens" may be a bit misleading. In this profile, we > always use PoP tokens. Our proposal is to move the note from the end > upwards: > > OLD: > > The client can update... > > NEW: > > Resource servers must only use a new access token to update the > authorization information for a DTLS session if the keying > material that is bound to the token is the same that was used in > the DTLS handshake. By associating the access tokens with the > identifier of an existing DTLS session, the authorization > information can be updated without changing the cryptographic keys > for the DTLS communication between the client and the resource > server, i.e. an existing session can be used with updated > permissions. This looks like it will work; I can handle the lack of my preferred phrasing about the "proof has already been provided" :) > The client can therefore update... > > > Section 5 > > > > DTLS sessions that have been established in accordance with this > > profile are always tied to a specific access token. As this token > > > > Doesn't the dynamic authorization update mechanism allow that token to > > be swapped out during the lifetime of the connection? > > Also, as a terminology point, I think "DTLS association" is more > > appropriate than "DTLS session" for what we describe, since the token is > > is tied to the client and consulted at the start of the handshake, as > > opposed to being a property of the DTLS session and carried across > > resumptions. > > We propose the following text as a clarification. This also takes > into account the "session" vs. "association" part which looks a bit > weird. If we come to the conclusion that this is a better term, we > would have to revise the rest of the document accordingly: > > OLD: > > DTLS sessions that have been established in accordance with this > profile are always tied to a specific access token. As this token > may become invalid at any time (e.g. because it has expired), the > session may become useless at some point. A resource server > therefore MUST terminate existing DTLS sessions after the access > token for this session has been deleted. > > NEW: > > The resource server MUST delete access tokens that are no longer > valid. DTLS associations that have been setup in accordance with > this profile are always tied to specific tokens (which may be > exchanged with a dynamic update as described in Section 4). As > tokens may become invalid at any time (e.g. because they have > expired), the association may become useless at some point. A > resource server therefore MUST terminate existing DTLS association > after the last access token associated with this association has > expired. This looks good (modulo the nit: comma after "e.g."). > > may become invalid at any time (e.g. because it has expired), the > > session may become useless at some point. A resource server > > therefore MUST terminate existing DTLS sessions after the access > > token for this session has been deleted. > > > > I assume that using "been deleted" vs. "has expired" is a deliberate > > choice? If we don't say anything else about when to delete tokens, it > > doesn't post much of a requirement, though. > > Good point. This is missing in Section 3.4. We now have added an > explicit requirement to remove expired (or otherwise invalid) access > tokens: > > OLD: > > The resource server MUST check for every request if the access > token is still valid. > > NEW: > > The resource server MUST check for every request if the access > token is still valid. If the token has expired, the resource > server MUST remove it. Ah, thanks. > > Section 6 > > > > endpoint. The use of CoAP and DTLS for this communication is > > RECOMMENDED in this profile, other protocols (such as HTTP and TLS or > > CoAP and OSCORE) MAY be used instead. > > > > nit: comma splice > > done > > > Also, we could potentially refer to the OSCORE profile document here > > (informatively). > > done > > > If other means of securing the communication with the AS are used, > > the security protocol MUST fulfill the communication security > > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. > > > > I suggest phrasing more like "the communication security requirements > > from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since > > there's no need to add another MUST to the ones already in the framework > > document. > > Done, although "remain applicable" seems a bit weak. > > > Section 7 > > > > I have a few suggestions for potential additions to this section as well > > as comments on the existing contents. > > > > We might consider adding a brief note about the use of 8-byte > > authentication tags in DTLS ciphers and how that affects the risk > > profile. > > Done. New text has been added as follows. > > NEW: > > As this specification targets at constrained environments, message > payloads exchanged between the client and the resource server are > expected to be small and rare. CoAP {{RFC7252}} mandates the > implementation of cipher suites with abbreviated, 8-byte tags for > message integrity protection. For consistency, this profile requires > implementation of the same cipher suites. For application scenarios > where the cost of full-width authentication tags is low compared to > the overall amount of data being transmitted, the use of cipher > suites with 16-byte integrity protection tags is preferred. > > > The use of "live" authorization upgrades on an existing DTLS connection > > by posting a new token to the authz-info endpoint does not provide much > > guarantee about the order in which operations occur (and thus which > > authorization info is used to process a given client request), > > especially in the face of an attacker that can delay and reorder > > packets. This does not necessarily mean that we should not bother to > > define that mechanism, but we should point out that there is only a weak > > ordering property provided, note that other mechanisms should be used > > when strict serialization is important, and caution that when the > > later-issued token contains a reduction in authorization from the > > initial token, it is impossible to guarantee that the reduction in > > authorization will take effect prior to the expiration of the original > > token. > > Exactly! To address this, the following text has been added to the > Security Considerations: > > NEW: > > Even when a single access token per client is used, an attacker > could compromise the dynamic update mechanism for existing DTLS > connections by delaying or reordering packets destined for the > authz-info endpoint. Thus, the order in which operations occur at > the resource server (and thus which authorization info is used to > process a given client request) cannot be guaranteed. Especially > in the presence of later-issued access tokens that reduce the > client's permissions from the initial access token, it is > impossible to guarantee that the reduction in authorization will > take effect prior to the expiration of the original token. > > > We rely heavily on the AS to accurately provide binding of raw key > > material to authorization information and endpoint identinty; I think > > this is a stronger reliance than just that implied by the core > > architecture, and so might merit a mention here. (This relates to all > > the checks about "MUST check that [client/...] is associated with > > [RPK/PSK]" that appear throughout the document.) > > We are not sure if this is specific to this profile. For any profile > within the ACE framework, the AS must know C and RS and must know their > keys. In this profile, we just describe what the AS needs to do to > address these requirements. Okay. > > I'd also suggest reiterating all the places where we rely on out-of-band > > configuration, as there's always a risk of such configuration becoming > > stale (or getting attacked directly). > > Most parts of the document already now do this. We have added an > additional remark in Section 3.1 to ensure that the client checks that > the authorization information about the AS is still valid. > We have also added a new subsection to the Security Considerations that > describes the configuration and authorization information that must > be provided to the authorization server, the resource server, and the > client outside of the ACE DTLS profile. > > NEW: > > 7.1 Out-of-Band Configuration > > To communicate securely, the authorization server, the client and > the resource server require certain information that must be > exchanged outside the protocol flow described in this > document. The authorization server must have obtained > authorization information concerning the client and the resource > server that is approved by the resource owner as well as > corresponding keying material. The resource server must have > received authorization information approved by the resource owner > concerning its authorization managers and the respective keying (Do we use the phrase "authorization manager" elsewhere?) > material. The client must have obtained authorization information > concerning the authorization server approved by its owner as well > as the corresponding keying material. Also, the client's owner > must have approved of the client's communication with the resource > server. The client and the authorization server must have obtained > a common understanding how this resource server is identified to > ensure that the client obtains access token and keying material > for the correct resource server. If the client is provided with a > raw public key for the resource server, it must be ascertained to > which resource server (which identifier and authorization > information) the key is associated. All authorization information > and keying material must be kept up to date. > > > I'd consider reiterating that when the KDF scheme is in use between RS > > and AS, that kid uniqueness is paramount, as using the same kid for > > multiple clients and the same RS would have potentially disasterous > > consequences in that case. > > Not sure if this is specific to the key generation through KDF, as the > kid is typically used to find the access token that was uploaded to the > auth-info endpoint? I think it is specific to key generation through KDF, but let me try to walk through it. Up in Section 3.3 we talk about a case where the AS and RS are assumed to share a key derivation key that's used to derive symmetric keys for the RS to share with the client. The KDF input is the IKM and the 'info' (since 'salt' is empty), and the IKM is just that same "key derivation key". So the only input to HKDF that changes for different clients (and the same RS) is the 'info'. The 'info', in turn contains a string constant 'type' plus the 'kid' and (presumably fixed) output length. If I'm reading this correctly, the 'kid' is the only HKDF input that varies between clients, so if the 'kid' was reused for different clients, the AS and RS would derive the same symmetric key for those distinct client/RS pairs. Furthermore, since the AS returns the actual symmetric key to the client in the token response, that means that the symmetric key is shared by *three* parties (vs. just client and RS, ignoring in the count the AS which knows everything). I guess technically this is not the scenario forbidden by the core framework (which is to have the same symmetric key used at multiple RSes, but it still is bad hygeine and would let one client impersonate the other. In cases not using the KDF, the 'kid' is just a hint to finding the actual key, and the actual key is assumed to be constructed uniquely by the AS each time. > > Similarly (though this is inherent to symmetric PoP and may not actually > > need reiterating), when we use symmetric PSKs for PoP, they lose almost > > all value if any given PSK is known to more than one client or RS. (The > > secdir review on the framework has us putting in MUST-level requirements > > to not share further than that, so it seems pretty reasonable to not > > duplicate that warning here.) > > Okay. This was one of things that we deemed obvious… > > > This document specifies a profile for the Authentication and > > Authorization for Constrained Environments (ACE) framework > > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general > > approach, the general security considerations from section 6 also > > apply to this profile. > > > > (The HTMLized link will only do the right thing if you use the redundant > > "section 6 of [I-D.ietf-ace-oauth-authz]".) > > done Though I guess we're on v3 XML now (yay! very pretty!), which hopefully does not have the same artificial limitations. > > The use of multiple access tokens for a single client increases the > > strain on the resource server as it must consider every access token > > and calculate the actual permissions of the client. Also, tokens may > > contradict each other which may lead the server to enforce wrong > > permissions. If one of the access tokens expires earlier than > > others, the resulting permissions may offer insufficient protection. > > Developers SHOULD avoid using multiple access tokens for a client. > > > > I think I touched on this above; did we want to make a stronger > > statement about "only one active token per client"? > > At the time this was written, the framework document was pretty unclear > about this. Now, it would be possible to have multiple access tokens for > a client if you knew how to merge the authorization rules. We have > changed the update mechanism to clearly state that a new token replaces > the old one. The question is if we still need this paragraph. I think the discussion is still valid and the only thing I'm not sure about is whether the last sentence is needed. > > Section 8 > > > > information as possible in an unencrypted response. When a DTLS > > session between the client and the resource server already exists, > > more detailed information MAY be included with an error response to > > provide the client with sufficient information to react on that > > particular error. > > > > I'd suggest adding a caveat like "an authenticated client" or > > "a known client", since DTLS itself does not guarantee that the client > > is not an attacker. > > done > > > Section 9 > > > > Profile ID: 1 > > > > I think this has to be merely a "suggested value", as IANA will control > > the actual allocations, in the absence of a reservation of this value in > > the framework document. > > done > > > Section 10.1 > > > > We don't currently reference RFC 7925 in any way that would require it > > to be a normative reference. We probably should, though -- somehow pull > > in that we require/recommend conformance with that profile of DTLS. > > We are not sure if there is anything special about RFC 7925 that we > explicitly want to point out. However, as we have the requirement of > treating the access token in the psk_identity as opaque binary data, we > have moved the reference RFC 7925 into the normative section. Okay, thanks. > > Section 10.2 > > > > I think RFCs 7250, 7251, and 8422 need to be normative. > > done And thanks for all the updates that I didn't specifically comment upon! I'm looking forward to seeing the -10! Thanks, Ben From nobody Tue Apr 28 23:06:54 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90473A0962; Tue, 28 Apr 2020 23:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 iJj5_ialgh6h; Tue, 28 Apr 2020 23:06:48 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD10F3A0965; Tue, 28 Apr 2020 23:06:48 -0700 (PDT) Received: from wangari.tzi.org (p54BDED4C.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49Bp1f4RvCz108k; Wed, 29 Apr 2020 08:06:46 +0200 (CEST) From: Olaf Bergmann To: Benjamin Kaduk Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> Date: Wed, 29 Apr 2020 08:06:46 +0200 In-Reply-To: <20200429011210.GC27494@kduck.mit.edu> (Benjamin Kaduk's message of "Tue, 28 Apr 2020 18:12:10 -0700") Message-ID: <87blnaakqx.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 06:06:52 -0000 Hi Benjamin, Benjamin Kaduk writes: > Please go ahead and upload a new version to the datatracker when you get a > chance; I do have some further comments below. Thank you very much for the quick reply. I will submit -10 based on your comments shortly. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Apr 28 23:32:19 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1B33A0A4F; Tue, 28 Apr 2020 23:32:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <158814193798.11856.15297747087687871947@ietfa.amsl.com> Date: Tue, 28 Apr 2020 23:32:18 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-13.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 06:32:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-13.txt Pages : 11 Date : 2020-04-28 Abstract: This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server uses to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-13 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-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 Tue Apr 28 23:34:26 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36B3A0A51 for ; Tue, 28 Apr 2020 23:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 3V2wtPIqL_ja for ; Tue, 28 Apr 2020 23:34:22 -0700 (PDT) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 AD6B83A0A45 for ; Tue, 28 Apr 2020 23:34:21 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 03T6YJOS014575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Apr 2020 08:34:19 +0200 Received: from corpappl16594.corp.saab.se (corpappl16594.corp.saab.se [10.12.12.126]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 03T6Y6UM031478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Apr 2020 08:34:06 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16594.corp.saab.se (10.12.12.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Wed, 29 Apr 2020 08:34:06 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1847.009; Wed, 29 Apr 2020 08:34:06 +0200 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-params-13.txt Thread-Index: AQHWHe/7dO98aug+eUirKgheCC38e6iPpEIw Date: Wed, 29 Apr 2020 06:34:06 +0000 Message-ID: References: <158814193828.11856.12782873364696591335@ietfa.amsl.com> In-Reply-To: <158814193828.11856.12782873364696591335@ietfa.amsl.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 03T6Y6UM031478 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.499, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_05 -0.50, SURBL_BLOCKED 1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1588746847.5255@poYTTWXhVb17kdNVRzZvaA X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Wed, 29 Apr 2020 08:34:19 +0200 (CEST) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-params-13.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 06:34:25 -0000 SGVsbG8gQUNFLA0KDQpUaGlzIHVwZGF0ZSBleHBhbmRzIHRoZSBmaXJzdCB1c2Ugb2YgQ29BUCBh bmQgQ0JPUiAocGVyIHJlcXVlc3Qgb2YgYSByZXZpZXdlcikuDQoNCi9MdWR3aWcNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiANClNlbnQ6IGRlbiAyOSBhcHJpbCAyMDIwIDA4OjMyDQpU bzogU2VpdHogTHVkd2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMTMu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFt cy0xMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTHVkd2lnIFNlaXR6 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYt YWNlLW9hdXRoLXBhcmFtcw0KUmV2aXNpb246CTEzDQpUaXRsZToJCUFkZGl0aW9uYWwgT0F1dGgg UGFyYW1ldGVycyBmb3IgQXV0aG9yaXphdGlvbiBpbiBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMg KEFDRSkNCkRvY3VtZW50IGRhdGU6CTIwMjAtMDQtMjkNCkdyb3VwOgkJYWNlDQpQYWdlczoJCTEx DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0xMy50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNl LW9hdXRoLXBhcmFtcy0xMw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zDQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWNlLW9hdXRo LXBhcmFtcy0xMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIG5l dyBwYXJhbWV0ZXJzIGFuZCBlbmNvZGluZ3MgZm9yIHRoZSBPQXV0aA0KICAgMi4wIHRva2VuIGFu ZCBpbnRyb3NwZWN0aW9uIGVuZHBvaW50cyB3aGVuIHVzZWQgd2l0aCB0aGUgZnJhbWV3b3JrDQog ICBmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gZm9yIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cw0KICAgKEFDRSkuICBUaGVzZSBhcmUgdXNlZCB0byBleHByZXNzIHRoZSBwcm9v Zi1vZi1wb3NzZXNzaW9uIGtleSB0aGUNCiAgIGNsaWVudCB3aXNoZXMgdG8gdXNlLCB0aGUgcHJv b2Ytb2YtcG9zc2Vzc2lvbiBrZXkgdGhhdCB0aGUNCiAgIEF1dGhvcml6YXRpb24gU2VydmVyIGhh cyBzZWxlY3RlZCwgYW5kIHRoZSBrZXkgdGhlIFJlc291cmNlIFNlcnZlcg0KICAgdXNlcyB0byBh dXRoZW50aWNhdGUgdG8gdGhlIGNsaWVudC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0KDQo= From nobody Wed Apr 29 23:57:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF0A3A0991 for ; Wed, 29 Apr 2020 23:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl 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 nmehnttSaMW1 for ; Wed, 29 Apr 2020 23:57:20 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ED13A098C for ; Wed, 29 Apr 2020 23:57:19 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 2AAC7100E7B44 for ; Thu, 30 Apr 2020 06:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :message-id; s=key; bh=3/8I0osKZuNhT/s/ntHccXpfddnmds/BojaiQfJPX GM=; b=ls1qyoZanODzAKYMitxqB27AyFW1FdbWCitNrjTSml+O4moV9ptl+3xbw 1AF0Y7N8Cdc8VrXtFyC3aBTVFSwjK6YRIyVHxj9cYNuyNGyes3VApMCRWN64zbm5 BMFpG7a2UEvaCasNhNq3jURcQMzGttTKnr02WlGAI3ujgsGpO0= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:41:72:152:355:379:582:800:962:967:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1436:1437:1516:1517:1518:1534:1540:1561:1575:1588:1589:1592:1594:1711:1714:1730:1776:1792:2525:2561:2564:2682:2685:2829:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3866:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4362:4659:5007:6261:6298:6659:8603:9015:9025:9177:10004:10214:10400:10848:11232:11658:11914:12043:12109:12114:12555:12679:12895:12986:13071:13139:13199:13229:13846:13972:14096:14180:14181:14721:21060:21067:21080:21433:21451:21625:21691:21939:30048:30054, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none X-HE-Tag: scent73_797fa4a246212 X-Filterd-Recvd-Size: 2454 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA for ; Thu, 30 Apr 2020 06:57:14 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4c256621b14bc5035205e68a7adc14f3" Date: Thu, 30 Apr 2020 08:57:14 +0200 From: Peter van der Stok To: Ace Reply-To: consultancy@vanderstok.org User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <56d31e581571721e176b59db20e08c23@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 06:57:22 -0000 --=_4c256621b14bc5035205e68a7adc14f3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi authz authors,, While implementing a version of AS, I noticed that there is no resource type (rt) registered for /.well-known/core discovery. Is this voluntary? If not, can it still be added? thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_4c256621b14bc5035205e68a7adc14f3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi authz authors,,

While implementing a version of AS, I noticed= that there is no resource type (rt) registered for /.well-known/core disco= very.
Is this voluntary?
If not, can it still be added?

thanks,

peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www= =2Evanderstok.org
tel NL: +31(0)492474673     = F: +33(0)966015248
--=_4c256621b14bc5035205e68a7adc14f3-- From nobody Thu Apr 30 08:29:02 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A973A126E for ; Thu, 30 Apr 2020 08:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 sJH3Up7TzOAP for ; Thu, 30 Apr 2020 08:28:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9BD3A0B93 for ; Thu, 30 Apr 2020 08:25:57 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Apr 2020 08:25:51 -0700 From: Jim Schaad To: , 'Ace' References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> In-Reply-To: <56d31e581571721e176b59db20e08c23@bbhmail.nl> Date: Thu, 30 Apr 2020 08:25:49 -0700 Message-ID: <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D61EC8.F60E67C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvvEQrX2wOjMB2/s9A8vau6YKJYqdejonQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 15:28:46 -0000 ------=_NextPart_000_00F2_01D61EC8.F60E67C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What do you expect to see? By default a client needs to know that = something is an AS and have a key to interact with that AS. =20 Jim =20 =20 From: Ace On Behalf Of Peter van der Stok Sent: Wednesday, April 29, 2020 11:57 PM To: Ace Subject: [Ace] draft-ietf-ace-oauth-authz =20 Hi authz authors,, While implementing a version of AS, I noticed that there is no resource = type (rt) registered for /.well-known/core discovery. Is this voluntary? If not, can it still be added? thanks, peter=20 --=20 Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org , = stokcons@bbhmail.nl =20 www: www.vanderstok.org =20 tel NL: +31(0)492474673 F: +33(0)966015248 ------=_NextPart_000_00F2_01D61EC8.F60E67C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

What do = you expect to see?=C2=A0=C2=A0 By default a client needs to know that = something is an AS and have a key to interact with that = AS.

 

Jim

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Peter van der = Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: = Ace <ace@ietf.org>
Subject: [Ace] = draft-ietf-ace-oauth-authz

 

Hi authz = authors,,

While implementing a version of AS, I noticed that = there is no resource type (rt) registered for /.well-known/core = discovery.
Is this voluntary?
If not, can it still be = added?

thanks,

peter

-- =

Peter van der = Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org= , stokcons@bbhmail.nl
www: = www.vanderstok.org
tel NL: +31(0)492474673 =     F: = +33(0)966015248

------=_NextPart_000_00F2_01D61EC8.F60E67C0-- From nobody Thu Apr 30 10:38:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EBA3A0FD7 for ; Thu, 30 Apr 2020 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EMef095YmU2A for ; Thu, 30 Apr 2020 10:38:03 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 8FFB73A0DC5 for ; Thu, 30 Apr 2020 10:37:50 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id UD89jfnKv5n10UD89jKhC0; Thu, 30 Apr 2020 10:37:50 -0700 X-CMAE-Analysis: v=2.3 cv=PaaBeRpd c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=pGLkceISAAAA:8 a=NeJZvmmVAAAA:20 a=2JLUh5-gAAAA:8 a=KHoinL0bdrCUc9T8JBIA:9 a=7U3Y6lsKD65v4cBh:21 a=AMCCSmdhPkw5JGql:21 a=QEXdDO2ut3YA:10 a=M3rSEH9b8GxZNhH0rw4A:9 a=vwBSpVPjVxuxrbGC:21 a=JlChb8WPFpb-Vmlo:21 a=atAyMpVNZEWOX9xN:21 a=_W_S_7VecoQA:10 a=l1rpMCqCXRGZwUSuRcM3:22 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=hnrGVjIjb-X0WoHtSFqa:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B9BF06-13E0-4B91-9919-5D6573C5F4A1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 Apr 2020 10:37:49 -0700 In-Reply-To: <3BB4FFA8-AABD-4520-9B21-1F0B0CAFB08C@ericsson.com> Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , =?utf-8?Q?Joel_H=C3=B6glund?= , "cose@ietf.org" , "ace@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: <8B4A9572-3770-416E-B937-1902AFC07DA7@island-resort.com> <964634A4-7B61-4CEF-8ED0-6A9A48D984CD@ericsson.com> <3BB4FFA8-AABD-4520-9B21-1F0B0CAFB08C@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfC2iBkIfVmcy9LX1RhBjdfpMwH3B1B9T8S+n+MBsBnZQ4EbV9/Sum27hGfCbI3J6ekEWh2b+7wH0St84Il1iri8hZn5Ts3oW1YN0aQRb8FgxYIsG/wQU CCgLVjLwzLfO2rxJXu5MJuWFKFTk+f1aPdiIgZjPfUj+cj2asdk0B2PUOO5JBTF1VgB2LUFRm4ioHJQZfYKfNdpjR0EC8X69dOlPQ2sHT2miirTVizidVSnr VCIcrvI2R5MyX8UpRNnQd7IqA2K0uMh+ifBE5qlWWHaoLsWdNr1DVRjmiC307Tl60DEwj9Usw1yrNG6gIz/1HP+RtlkX9ZWT9ICgV2b7Xw8= Archived-At: Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 17:38:18 -0000 --Apple-Mail=_E5B9BF06-13E0-4B91-9919-5D6573C5F4A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi G=C3=B6ran, I understand your two types of native CBOR certs, and raise you by one. = I=E2=80=99ve assumed COSE because it seems a clear choice to me (no size = issue, code re use). 0) Compressed/re-encoded - Uses CBOR Sequence that exactly mirrors X.509 from Raza draft - Reduces size of cert, but increased code complexity; both CBOR and DER = encoding / decoding needed - Can transform to/from X.509 mechanically without the private key 1) COSE + Mirroring with CBOR Sequence from Raza draft - Uses the CBOR sequence that exactly mirrors X.509 - Reduces size of cert and lowers code complexity; no DER encoding / = decoding - Must have private key to generate; must be generated by the CA 2) COSE + Mirroring with CWT Claims - A set of CWT claims are defined that exactly mirror X.509 fields - Reduces size of cert and lowers code complexity; no DER encoding / = decoding; can re use some CWT code - Must have private key to generate; must be generated by the CA 3) COSE + Improved CWT Claims - A set of CWT claims that don=E2=80=99t necessarily mirror X.509 = exactly, but give similar semantics - Reduces size of cert and lowers code complexity; no DER encoding / = decoding; can re use some CWT code - Must have private key to generate; must be generated by the CA I was definitely talking about 3) in my last email. It is clearly not in = the charter. So maybe the debate is between 1) and 2). Both are in the charter. Some = advantages of 2) are: - Can re use some of the CWT code - Can move to 3) incrementally when the time comes - Can drop fields that are not used possibly giving the smallest cert = size on the wire of any of the options LL > On Apr 28, 2020, at 3:23 AM, G=C3=B6ran Selander = wrote: >=20 > Hi Laurence, > =20 > Thanks for sharing your thoughts. It seems we are working on slightly = different paths. > =20 > The part you called =E2=80=9CCompressed Certs=E2=80=9D is already in = the draft COSE charter where it is referred to as =E2=80=9CA CBOR = encoding of the compressed certificate profile defined in RFC 7925=E2=80=9D= so we can leave that out for now. > =20 > My comment was about the other part, what we both call =E2=80=9Cnative = CBOR certificates=E2=80=9D but mean different things. What is called = native in > draft-raza-ace-cbor-certificates is not intended as a certificate = format breaking with X.509. While there are many potential improvements = to make on X.509, there is a resistance against new certificate = architectures as was clear when this was brought up in Secdispatch at = IETF 104 a year ago. As mentioned previously, what we mean by =E2=80=9Cnat= ive CBOR=E2=80=9D is the lossless compression of the certificate profile = of X.509 into a CBOR encoded format, but signing over the CBOR instead = of on the uncompressed data. In this way it is possible to define a = bijection between native CBOR certificates and profiled X.509 = certificates =E2=80=93 the payload of the compressed version of the = latter would be identical to the former. So the native CBOR certificates = are a faithful representation of these profiled X.509 certificates, = using the same payload as in the CBOR compression scheme. > =20 > In contrast to the compression scheme, a conversion between native = CBOR and X.509 representations requires access to the private signature = key. > Therefore a mix of X.509 and native CBOR would require multiple = handlers at the backend (parsing the payload would be the same). = Dedicated deployments could of course use native CBOR certificates = exclusively. > =20 > In the same way it would be possible to instead define a COSE_Sign1 = and/or a CWT representing these profiled X.509 certificates, this is = what I thought you were asking about but apparently not. That would be = an alternative as long as we can decide on exactly one of these = representations. > =20 > There are a lot of fun things to do in this space, my concern is how = to get out a standard. Trying to replace X.509 doesn=E2=80=99t seem like = a promising way forward I=E2=80=99m afraid . . . > =20 > G=C3=B6ran > =20 > =20 > From: Ace on behalf of Laurence Lundblade = > Date: Monday, 27 April 2020 at 20:13 > To: G=C3=B6ran Selander = > Cc: Joel H=C3=B6glund , "cose@ietf.org" = , "ace@ietf.org" > Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt >=20 >> On Apr 27, 2020, at 5:00 AM, G=C3=B6ran Selander = > wrote: >> =20 >> [GS] The rationale for native CBOR certificates is to reuse the same = encoding as in the compression scheme defined for RFC 7925, but signing = the CBOR instead of signing the uncompressed data. This provides a = roadmap with minimal changes when moving from compressed to native CBOR = certificates. >> =20 >> I agree with you that the overhead of COSE_Sign1 or CWT is not major = and these points are open for discussion. The more important question is = where this should be standardized. The compression scheme is now = included in the new draft charter for COSE: >> https://github.com/cose-wg/Charter/blob/master/Charter.md = = >> The charter is currently not explicitly supporting native CBOR = certificates. If you think it should, in some variant, then this is a = good time to raise your voice. >=20 > =20 > To go straight to the issue, I think a designing a native CBOR cert = should be approached differently than compressing / re-encoding an X.509 = cert: > =20 > Re-encoding > - Size is important > - Exact compatibility is required > - Near zero change to fields and semantics > =20 > Native CBOR Cert > - Clean up some of the mess in X.509; it is an old standard with a lot = of cruft and baggage > - Re design extensions so they are in CBOR format > - Make many of the fields optional, for example not before can often = be left off, maybe even serial number > - Avoid DN structure for issuer and subject for most use cases > - Use modern formats like COSE and CWT and COSE_Key > - Size is important, but far from the only goal (some size reductions, = like optional fields will be possible here that are not possible with = re-encoding) > - Compatibility matters, but not in the same way > =20 > Seems like the right thing to do here is to remove native CBOR certs = from this document and just focus on compression and re-encoding. Maybe = even call them =E2=80=9CCompressed Certs=E2=80=9D rather than =E2=80=9CCBO= R Certs=E2=80=9D.. Where that work should go is above my pay grade. > =20 > =20 > BUT, my main interest here relates to CWT and EAT. CWT seems like a = really good choice on which to base a native CBOR cert. Some of the = fields for an X.509 cert are already defined in CWT (subject, issuer, = expiration, not-before). It has an extension mechanism built in already = in the CWT IANA registry. The crypto and signing are well-handled by = CWT=E2=80=99s use of COSE. > =20 > In work to fit EAT = in as a CWT, a few = issues have come up =E2=80=94 how fields / claims are managed and = registered with IANA, label spaces and other. All these issues would = apply to CWT/COSE/CBOR-based certificate as well.=20 > =20 > To name just one issue, in CWT the expiration date/time can be a = floating-point number, which is burdensome, not useful. Should we change = CWT to disallow or should it just be disallowed when a CWT is used as an = EAT and when it is used as a Cert? > =20 > I=E2=80=99m also excited at the idea of re using CWT in a simple form = so there is re use of code between CWT, EAT and native CBOR certs. = I=E2=80=99ve started playing with an implementation like this. > =20 > LL --Apple-Mail=_E5B9BF06-13E0-4B91-9919-5D6573C5F4A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi G=C3=B6ran,

I understand your two types of native = CBOR certs, and raise you by one. I=E2=80=99ve assumed COSE because it = seems a clear choice to me (no size issue, code re use).

0) = Compressed/re-encoded
- Uses CBOR Sequence that = exactly mirrors X.509 from Raza draft
- Reduces = size of cert, but increased code complexity; both CBOR and DER encoding = / decoding needed
- Can transform to/from X.509 = mechanically without the private key

1) COSE + Mirroring with = CBOR Sequence from Raza draft
- Uses the = CBOR sequence that exactly mirrors X.509
- Reduces = size of cert and lowers code complexity; no DER encoding / = decoding
- Must have private key to generate; must = be generated by the CA

2) COSE + Mirroring with CWT = Claims
- A set of CWT claims are defined that = exactly mirror X.509 fields
- = Reduces size of cert and lowers code complexity; no DER encoding / = decoding; can re use some CWT code
- Must have private key to generate; must be generated by the = CA

3) COSE + Improved CWT = Claims
- A set of CWT = claims that don=E2=80=99t necessarily mirror X.509 exactly, but give = similar semantics
- Reduces size of cert and lowers code complexity; no DER = encoding / decoding; can re use some CWT code
- Must have private key to generate; must be = generated by the CA

I was = definitely talking about 3) in my last email. It is clearly not in the = charter.

So maybe the debate is = between 1) and 2). Both are in the charter. Some advantages of 2) = are:
- Can re use some of the CWT code
- Can move to = 3) incrementally when the time comes
- Can drop fields that = are not used possibly giving the smallest cert size on the wire of any = of the options

LL



On Apr 28, 2020, at 3:23 AM, = G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:

Hi Laurence,
 
Thanks = for sharing your thoughts. It seems we are working on slightly different = paths.
 
The part you called = =E2=80=9CCompressed Certs=E2=80=9D is already in the draft COSE charter = where it is referred to as =E2=80=9CA CBOR encoding of the = compressed certificate profile defined in RFC 7925=E2=80=9D so we can leave that out for now.
 
My = comment was about the other part, what we both call =E2=80=9Cnative CBOR = certificates=E2=80=9D but mean different things. What is called native = in
draft-raza-ace-cbor-certificates is not intended as a certificate format breaking with X.509. = While there are many potential improvements to make on X.509, there is a = resistance against new certificate architectures as was clear when this = was brought up in Secdispatch at IETF 104 a year ago. As mentioned = previously, what we mean by =E2=80=9Cnative CBOR=E2=80=9D is the = lossless compression of the certificate profile of X.509 into a CBOR = encoded format, but signing over the CBOR instead of on the uncompressed = data. In this way it is possible to define a bijection between native = CBOR certificates and profiled X.509 certificates =E2=80=93 the payload = of the compressed version of the latter would be identical to the = former. So the native CBOR certificates are a faithful representation of = these profiled X.509 certificates, using the same payload as in the CBOR = compression scheme.
 
In contrast to the = compression scheme, a conversion between native CBOR and X.509 = representations requires access to the private signature key.
Therefore a mix of X.509 and native CBOR would = require multiple handlers at the backend (parsing the payload would be = the same). Dedicated deployments could of course use native CBOR = certificates exclusively.
 
In the same way it would be = possible to instead define a COSE_Sign1 and/or a CWT representing these = profiled X.509 certificates, this is what I thought you were asking = about but apparently not. That would be an alternative as long as we can = decide on exactly one of these representations.
 
There = are a lot of fun things to do in this space, my concern is how to get = out a standard. Trying to replace X.509 doesn=E2=80=99t seem like a = promising way forward I=E2=80=99m afraid . . .
 
G=C3=B6ran
 
 
From: Ace <ace-bounces@ietf.org> on behalf of Laurence Lundblade = <lgl@island-resort.com>
Date: Monday, 27 April 2020 = at 20:13
To: G=C3=B6ran Selander = <goran.selander=3D40ericsson.com@dmarc.ietf.org>
Cc: Joel H=C3=B6glund = <joel.hoglund@gmail.com>, "cose@ietf.org" <cose@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Subject: Re: [Ace] [COSE] = draft-raza-ace-cbor-certificates-04.txt

On = Apr 27, 2020, at 5:00 AM, G=C3=B6ran Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org> = wrote:
 
[GS] The rationale for native CBOR certificates is to reuse = the same encoding as in the compression scheme defined for RFC 7925, but = signing the CBOR instead of signing the uncompressed data. This provides = a roadmap with minimal changes when moving from compressed to native = CBOR certificates.
 
I agree with you that the overhead of COSE_Sign1 or CWT is = not major and these points are open for discussion. The more important = question is where this should be standardized. The compression scheme is = now included in the new draft charter for COSE:
The charter is = currently not explicitly supporting native CBOR certificates. If you = think it should, in some variant, then this is a good time to raise your = voice.
 
To go straight to the = issue, I think a designing a native CBOR cert should be approached = differently than compressing / re-encoding an X.509 cert:
 
Re-encoding
- Size is important
- Exact compatibility is = required
- Near zero change to fields and = semantics
 
Native CBOR Cert
- Clean up some of the mess in X.509; it is an old standard = with a lot of cruft and baggage
- Re design extensions so = they are in CBOR format
- Make many of the fields = optional, for example not before can often be left off, maybe even = serial number
- Avoid DN structure for issuer and = subject for most use cases
- Use modern formats like = COSE and CWT and COSE_Key
- Size is important, but = far from the only goal (some size reductions, like optional fields will = be possible here that are not possible with re-encoding)
- Compatibility matters, but not in the same way
 
Seems like the right thing to do here = is to remove native CBOR certs from this document and just focus on = compression and re-encoding. Maybe even call them =E2=80=9CCompressed = Certs=E2=80=9D rather than =E2=80=9CCBOR Certs=E2=80=9D.. Where that = work should go is above my pay grade.
 
 
BUT, my main interest here relates to CWT and = EAT. CWT seems like a really good choice on which to base a native CBOR = cert. Some of the fields for an X.509 cert are already defined in CWT = (subject, issuer, expiration, not-before). It has an extension mechanism = built in already in the CWT IANA registry. The crypto and signing are = well-handled by CWT=E2=80=99s use of COSE.
 
In work to fit EAT in as a CWT, a few issues have come up =E2=80=94 = how fields / claims are managed and registered with IANA, label spaces = and other.  All these issues would apply to CWT/COSE/CBOR-based = certificate as well. 
 
To name just one issue, in CWT the expiration = date/time can be a floating-point number, which is burdensome, not = useful. Should we change CWT to disallow or should it just be disallowed = when a CWT is used as an EAT and when it is used as a Cert?
 
I=E2=80=99m also excited at the idea of = re using CWT in a simple form so there is re use of code between CWT, = EAT and native CBOR certs. I=E2=80=99ve started playing with an = implementation like this.
 
LL

= --Apple-Mail=_E5B9BF06-13E0-4B91-9919-5D6573C5F4A1-- From nobody Thu Apr 30 23:56:29 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA69C3A0A99 for ; Thu, 30 Apr 2020 23:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl 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 c9MabwPafInt for ; Thu, 30 Apr 2020 23:56:26 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029C03A0A98 for ; Thu, 30 Apr 2020 23:56:25 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 7BF1B181D341E; Fri, 1 May 2020 06:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=tYUPx73+iaRzaTSgrO 2zelGwOXL5WEPamhZSbbG/E7Y=; b=CzjeZCWmiNtH5OtLI1vT3Xyv6lPuIaDb7e j3WgD607JZ2RKjPv/hRPIZf96eBi91kqEET1Frr3Aw3a9nD11xoV5l88G6xCtZ7K bxO3K2izfgdtjQ1M3g87S2JssI21buRZnkk1k4Jt0v2dGZ/1Fp4w2HA7O+P+c5is 1mHMB2ZXk= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, , RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1730:1775:1792:2068:2069:2198:2199:2525:2526:2527:2551:2553:2557:2566:2682:2685:2689:2829:2859:2898:2900:2901:2902:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:4379:4659:4860:5007:6119:6248:6261:6298:6657:6659:6678:7576:7903:8583:8603:8957:9010:9015:9025:9036:9080:9177:9545:10004:10026:10848:11232:11656:11658:11914:12043:12050:12109:12114:12291:12379:12438:12555:12683:12740:12895:12986:13139:13160:13161:13229:13618:13846:13972:14094:14096:14180:14181:14721:21060:21067:21080:21324:21433:21451:21499:21625:21691:21939:21990:30003:30006:30041:30048:30054:30060:30070:30090:30091, 0 X-HE-Tag: hands03_1a5c1a2e8832c X-Filterd-Recvd-Size: 7596 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf08.hostedemail.com (Postfix) with ESMTPA; Fri, 1 May 2020 06:56:21 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7e2e9b8f3729fd4f6b64419e5a60efbd" Date: Fri, 01 May 2020 08:56:20 +0200 From: Peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, 'Ace' Reply-To: consultancy@vanderstok.org In-Reply-To: <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> References: <56d31e581571721e176b59db20e08c23@bbhmail.nl> <00f101d61f03$a26bb920$e7432b60$@augustcellars.com> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <0873a3115cab89036002cf42b1c97608@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 06:56:28 -0000 --=_7e2e9b8f3729fd4f6b64419e5a60efbd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed HI Jim, I try to answer your question, When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have to type in the IP address of the AS. >From that moment on keys and certificates can be compared to continue initialization. Using service discovery can automate that process. My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS, unless a different process has already been established for AS initialization. Many thanks, peter Jim Schaad schreef op 2020-04-30 17:25: >> > What do you expect to see? By default a client needs to know that something is an AS and have a key to interact with that AS. > > Jim > > From: Ace On Behalf Of Peter van der Stok > Sent: Wednesday, April 29, 2020 11:57 PM > To: Ace > Subject: [Ace] draft-ietf-ace-oauth-authz > > Hi authz authors,, > > While implementing a version of AS, I noticed that there is no resource type (rt) registered for /.well-known/core discovery. > Is this voluntary? > If not, can it still be added? > > thanks, > > peter > > -- > > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl > www: www.vanderstok.org [1] > tel NL: +31(0)492474673 F: +33(0)966015248 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace Links: ------ [1] http://www.vanderstok.org --=_7e2e9b8f3729fd4f6b64419e5a60efbd Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Jim,

I try to answer your question,

When I want to= access an OCF device I can find its IP address through service discovery (= rfc7252 section 7) using an rt-value registered at the IANA core parameters= registry.
For example, when I want to initialize the AS I have to typ= e in the IP address of the AS.
From that moment on keys and certificat= es can be compared to continue initialization.

Using service dis= covery can automate that process.

My request is that authz draft= registers an rt-value in core parameters registry for service discovery of= the AS,
unless a different process has already been established for A= S initialization.

Many thanks,

peter

Jim Schaad schreef op 2020-04-30 17:25:

 

What do you expect to see?   By default = a client needs to know that something is an AS and have a key to interact w= ith that AS.

 

Jim

 

 

From: Ace <ace-bounces@ietf.or= g> On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace &l= t;ace@ietf.org>
Subject: [Ace] draft-ietf-ace-oaut= h-authz

 

Hi authz authors,,

While implementing a vers= ion of AS, I noticed that there is no resource type (rt) registered for /= =2Ewell-known/core discovery.
Is this voluntary?
If not, can it s= till be added?

thanks,

peter

--

Peter van der Stok
vanderstok consultancy
mailto: consultancy@= vanderstok.org, stokcons@bbhmail.nl
www: www.vanderstok.org
t= el NL: +31(0)492474673     F: +33(0)966015248


= _______________________________________________
Ace mailing list
= Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--=_7e2e9b8f3729fd4f6b64419e5a60efbd--