From nobody Wed Aug 3 00:47:17 2016 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 8628F12D98E for ; Wed, 3 Aug 2016 00:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MFqj5__9ecyC for ; Wed, 3 Aug 2016 00:47:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A5512D8F5 for ; Wed, 3 Aug 2016 00:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13108; q=dns/txt; s=iport; t=1470210433; x=1471420033; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=PnFmqAo+WTMpYOZhWw8cjk+7QzthtrtkV+SB45PeEr4=; b=ZdC4ZPOOFvYQW/2Uu2Ck69yBpcZyzLbwfo025VLUBTEQ1Zm5Liy4BhwS CTir9m+Z/VgDKBEMGkMcKLj1TrictYqjX0TxcKjw0x9n0WBUK1ZcmTdSK nADXCOCC5QyBUbPeUQFm9T/yNZ/F0kLOpTbUFHnFqDay2nnQk8ahkLuG4 A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpDwAIoaFX/xbLJq1dhBsqUq0Jhx+HA?= =?us-ascii?q?ySCQoM3AoIRAQEBAQEBXidBDgGEDwEFAQEhSwsQCxgqAgIhBjAGAQwGAgEBF4d?= =?us-ascii?q?8AxcOr0SLWg2DTQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgiglWCQ4FZAYMkg?= =?us-ascii?q?loFmQA0gzqBcIcggjWJU4VsiCuEBYN3VIIRARyBTjoyAYRogi4BASQHgRgBAQE?= X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="asc'?scan'208,217";a="639259215" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 07:46:49 +0000 Received: from [10.61.216.250] ([10.61.216.250]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u737knhq009965; Wed, 3 Aug 2016 07:46:49 GMT To: Michael Richardson , Michael StJohns References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> From: Eliot Lear Message-ID: <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> Date: Wed, 3 Aug 2016 09:47:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <13663.1469714549@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pedi4d7GWjS1oxLAcFvimlfCvqDdaqdm2" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Group Communication Security Disagreements X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 03 Aug 2016 07:47:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pedi4d7GWjS1oxLAcFvimlfCvqDdaqdm2 Content-Type: multipart/mixed; boundary="GhCUDwmSXcn8s7bioVQI52We1ne3pkoci" From: Eliot Lear To: Michael Richardson , Michael StJohns Cc: ace@ietf.org Message-ID: <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> Subject: Re: [Ace] Group Communication Security Disagreements References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> In-Reply-To: <13663.1469714549@obiwan.sandelman.ca> --GhCUDwmSXcn8s7bioVQI52We1ne3pkoci Content-Type: multipart/alternative; boundary="------------74BAA0379F6D272B9D5F3872" This is a multi-part message in MIME format. --------------74BAA0379F6D272B9D5F3872 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Reflecting on this discussion and the adoption of the related draft, if the draft is adopted I would suggest that before it goes forward an auditing section should be added to security considerations so that appropriate advice is given in the case a member of a group is compromised. I could envision several mechanisms to address that concern. Here are a few examples that would need to be considerably fleshed out: * An audit system is admitted to the group and records IP addresses and times of messages received. This may be compared to IPFIX records or packet logs to determine the veracity of sources. * Lower level source validation may be employed to determine the veracity of a source IP address. This validation might take the form of IPSEC-AH. * Endpoints might log transmission and receipt of messages so that information may be compared. Other approaches may be employed as well. On additional authorization methods, one approach to protect group membership would be to use a well known L3 multicast address and a separate application port for communications, thus permitting normal network filtering based on pre-authorization of the device at lower layer= s. The combination of these mechanisms should at least limit potential risk and the threat surface. Eliot On 7/28/16 4:02 PM, Michael Richardson wrote: > Michael StJohns wrote: > > On 7/27/2016 5:56 PM, Michael Richardson wrote: > > > > Kathleen Moriarty wrote: > >>> Mohit Sethi wrote: > >>> > designed/developed/specified for their use-case. I could defi= nitely > >>> > see some IoT startup building a solution that switches on the= lights > >>> > in a room as soon as you unlock the door (thus keeping them i= n the > >>> > same group). > >>> > >>> Or perhaps more usefully, turning the lights (and the oven) off= when you > >>> leave the house. > > >> Good points, but you could do this without them being in the sam= e > >> group with some controller that managed the interactions with ea= ch. > >> This would be a good set of examples for the security considerat= ions > >> sections, providing guidance to use a controller rather than gro= up > >> keys to perform useful functions like these. > > mcr> I agree. > mcr> Perhaps we could convince Mike St.Johns to write that section?= > > msj> Probably not - as long as symmetric key group communications i= s used > msj> as a control protocol. > > Well, who other than Nixon could go to China? > > mcr> And ACE has the right mechanisms to make this work well. > > msj> I agree - public key systems. But that seems to be out of scop= e here. > > I'm not convinced. What I have taken home is that people think they wa= nt to > use symmetric keys, and perhaps it might be safe among completely equiv= alent > devices. I take your point (strongly) that this bubble will be broken, = with > catastrophic results. We need asymmetric methods between bubbles, and = we > need to define that early. > > mcr> We should also consider whether we can use hash-chains, like S= /KEY did, to > mcr> authenticate messages that should only go out in emergencies. = Such messages > mcr> would clearly *need* to be multicast, but once used, they can = never be > mcr> reused. They can't be originated by more than one sender thou= gh.... so it's > mcr> really the message stored by the "EMERGENCY STOP" button. > > msj> That's an interesting idea - but AIRC, hash chains could be or= iginated > msj> by anyone that held the signing/verification key. > > Yes, provided they distributed the initial (asymmetrically signed) h^n(= k) > value out in advance, and gave all the devices enough time to verify th= at > signature. Plus flash to store the n-th hash. > > For the single sender/controller, multiple receiver/actuator situation = this > would be almost as fast as the symmetric group key, yet much more secur= e. > > For the multiple sender situation, you need to replicate things n-times= =2E > But it's still not n*m keys. > > msj> Let's do this the right way. Let's not bow to the "tyranny of = the > msj> light switch" in accepting solutions that are NOT secure, even= for the > msj> limited scope they are proposing. > > +1. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------74BAA0379F6D272B9D5F3872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

Reflecting on this discussion and the adoption of the related draft, if the draft is adopted I would suggest that before it goes forward an auditing section should be added to security considerations so that appropriate advice is given in the case a member of a group is compromised.=C2=A0 I could envision several mechanisms to address that concern.=C2=A0 Here are a few examples t= hat would need to be considerably fleshed out:

  • An audit system is admitted to the group and records IP addresses and times of messages received.=C2=A0 This may be compa= red to IPFIX records or packet logs to determine the veracity of sources.
  • Lower level source validation may be employed to determine the veracity of a source IP address.=C2=A0 This validation might take= the form of IPSEC-AH.
  • Endpoints might log transmission and receipt of messages so that information may be compared.
Other approaches may be employed as well.

On additional authorization methods, one approach to protect group membership would be to use a well known L3 multicast address and a separate application port for communications, thus permitting normal network filtering based on pre-authorization of the device at lower layers.

The combination of these mechanisms should at least limit potential risk and the threat surface.

Eliot

On 7/28/16 4:02 PM, Michael Richardson= wrote:
Michael StJohns <mstjohns@comcast.net> wrote:
    > On 7/27/2016 5:56 PM, Michael Richardson wrote:


    > Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co=
m> wrote:
    >>> Mohit Sethi <mohit.m.sethi@ericsson.com> =
wrote:
    >>> > designed/developed/specified for their use-case. I =
could definitely
    >>> > see some IoT startup building a solution that switc=
hes on the lights
    >>> > in a room as soon as you unlock the door (thus keep=
ing them in the
    >>> > same group).
    >>>
    >>> Or perhaps more usefully, turning the lights (and the ov=
en) off when you
    >>> leave the house.

    >> Good points, but you could do this without them being in the=
 same
    >> group with some controller that managed the interactions wit=
h each.
    >> This would be a good set of examples for the security consid=
erations
    >> sections, providing guidance to use a controller rather than=
 group
    >> keys to perform useful functions like these.

    mcr> I agree.
    mcr> Perhaps we could convince Mike St.Johns to write that section=
?

    msj> Probably not - as long as symmetric key group communications =
is used
    msj> as a control protocol.

Well, who other than Nixon could go to China?

    mcr> And ACE has the right mechanisms to make this work well.

    msj> I agree - public key systems. But that seems to be out of sco=
pe here.

I'm not convinced.  What I have taken home is that people think they want=
 to
use symmetric keys, and perhaps it might be safe among completely equival=
ent
devices. I take your point (strongly) that this bubble will be broken, wi=
th
catastrophic results.  We need asymmetric methods between bubbles, and we=

need to define that early.

    mcr> We should also consider whether we can use hash-chains, like =
S/KEY did, to
    mcr> authenticate messages that should only go out in emergencies.=
  Such messages
    mcr> would clearly *need* to be multicast, but once used, they can=
 never be
    mcr> reused.  They can't be originated by more than one sender tho=
ugh.... so it's
    mcr> really the message stored by the "EMERGENCY STOP" button.

    msj> That's an interesting idea - but AIRC, hash chains could be o=
riginated
    msj> by anyone that held the signing/verification key.

Yes, provided they distributed the initial (asymmetrically signed) h^n(k)=

value out in advance, and gave all the devices enough time to verify that=

signature.  Plus flash to store the n-th hash.

For the single sender/controller, multiple receiver/actuator situation th=
is
would be almost as fast as the symmetric group key, yet much more secure.=


For the multiple sender situation, you need to replicate things n-times.
But it's still not n*m keys.

    msj> Let's do this the right way. Let's not bow to the "tyranny of=
 the
    msj> light switch" in accepting solutions that are NOT secure, eve=
n for the
    msj> limited scope they are proposing.

+1.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works
 -=3D IPv6 IoT consulting =3D-






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

--------------74BAA0379F6D272B9D5F3872-- --GhCUDwmSXcn8s7bioVQI52We1ne3pkoci-- --pedi4d7GWjS1oxLAcFvimlfCvqDdaqdm2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXoaGAAAoJEIe2a0bZ0nozvaAIAJVCo18zrpyRShZnTl1VJlCV Kz/rbvj4WGV9gHJVtODLygaIH9/j2s20JuOdEWZoOKGeHBrRJcR3rSsxtV8ZPBt5 trch7YK2CFIzfd7h1GNhv64b7ijryYUjBbyvlG50H5uYfzvT+LRjrlC7NxGLJnHj i7oJpg90S/2XNObON38EnqcShZrOtIIigRn3m9rJsq5IygPUFW3wt6XMzBelzr1z YrmEgi1a/ojVbbuzm5AtpWCQqHVaBGfi2f1Q3wtXntgzcZLROg0WunhxDCrSfAgm 9ZHtcmmomOcLLf4kFqCy7WK91isk+tb848WeKmCMjpZuYVuCVwHNUPqgfTk/FvE= =0zte -----END PGP SIGNATURE----- --pedi4d7GWjS1oxLAcFvimlfCvqDdaqdm2-- From nobody Wed Aug 3 15:37:30 2016 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 2CC2712D8C8 for ; Wed, 3 Aug 2016 15:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 1rEViNOP-f1x for ; Wed, 3 Aug 2016 15:37:23 -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 074C512D8CD for ; Wed, 3 Aug 2016 15:37:23 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 Aug 2016 15:48:59 -0700 From: Jim Schaad To: , Date: Wed, 3 Aug 2016 15:37:17 -0700 Message-ID: <04da01d1edd7$9898fe50$c9cafaf0$@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: AdHtPoYq0jj2+v67TYSluvCIdfOugg== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Ace] Review of draft-selander-ace-cose-ecdhe-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 03 Aug 2016 22:37:29 -0000 This may be a bit scatterbrained as I did this review in several sessions and the thoughts might not be consistent. 1. In section #1, I would put in the fact that the derived key would only be used for a period of time, after which a new ECDH key exchange would be run again. 2. It is not clear, but based on how the value of kid_ev is defined, it might be reasonable to state that there is an expectation that generally U will be a client and V a server. 3. I would like to see the PSK half of the world setup so that it is not required that the same key/kid pair be used in both directions. Using a different key in each direction makes things cleaner for some issues. Both cases of the same and different pairs should be permitted. 4. I see no reason to say that what one is negotiating is a hash function. What you are negotiating is a "Key Agreement w/ KDF" algorithm. I don't see that you are using the hash function by itself anywhere. 5. In section 2, you should give a reason for including or not including the nonces in the protocol. Since they are optional when would they be useful? 6. In section 2, do you expect that TCA is restricted to CEK or would MAC algorithms be usable as well? 7. In section 2, I missed where the replay parameter was included in the COSE_Header - it seems to be in the key for party U and non-existant for party V. The closest that one comes it the use of the message_1 signature as AAD. 8. In figure 3, I would prefer to see two different traffic keys being derived. It is not an issue in Figure 2 as that just says keying material. Using different keying material in each direction prevents reflection attacks. 9. In section 2.1, you talk about authentication methods but do not discuss authorization methods. Does this need to be built into message_1 or are there other methods that will be functional here. May need to refer to how some of them might work since this will also potentially affect how the distribution of the keys in advance works. For example, if an OAUTH token is published to a well-known location that contains both authorization and authentication information. 10. In section 3.1, I am not sure that you really want to have only a single algorithm in this specification. I would make it more generation in terms of how a COSE_Key is built and then have a statement elsewhere rather than spread throughout the document about what algorithms are mandatory to support. 11. In section 3.4.2 - I think that you need to have a more comprehensive external_AAD structure that what is here. I am not sure that you should not AAD information from the CoAP header as well in all of the messages. 12. Stupid question - Can you do a PSK in one direction and a signature in the other? 13. Not sure that it matters, but you have the COSE_KDF_Context structure wrong everywhere. The partyU and partyV fields are not optional. 14. Section 3.5, I don't believe in uniquely identified kids on any device unless that device is going to enforce that as a true statement. That means that it will not allow for a key to be registered with it unless the kid is unique. There is nothing wrong with doing an exhaustive search of all of the keys with the same kid as long as the number of them is not too large. 15. Section 3.5.3: If you are sending along a certificate, it is not clear to me that you need to have a kid as well. The certificate is where you are going to get the key from not the kid. 16. Section 4.1 - kid_eu - Does this really need to be a counter on a per party V basis or can it just be a counter based on the use of the credential that is being used to do the authentication? 17. Section 5 - what happens if N_U or N_V is longer than the size of the hash function. Also, what do you mean by the size of the hash function? Is this the barrel size or the output size? 18. Identity of the Parties: There is a question on what the identity structure that is being used to grant access is for ACE. For those who have been in the IETF long enough, one answer would be to move back to the world of SPKI (Simple Public Key Infrastructure) where the key is the entity that is used for identifying an entity and not some other piece of information like a text string or an address. Doing a security analysis, one might find that one wishes to do a binding of the identity information into the key derivation process. If keys are the marker of identity, then this is would be including the keys as part of the context information thus tying the signature and key into the resulting key. The requirement to include identity information is probably needed more if access control is being based on a name rather than a key however. In this case it is likely more important that the binding processes is included in the KDF context in some manner. 19. Use of the signature/MAC for chaining of items: I did a fast review of how the fields of message_1 and message_2 are used in the final KDF processing. From what I saw, there are only a couple of things that are not directly re-used as part of the context. These are: 1) the exact encoding of the messages, 2) the list of key agreement algorithms, 3) the list of TCA algorithms, 4) kid_eu and kid_ev, and 5) the protected attributes in each of the messages. Exact encoding can be addressed by using the same encoding rules that are in COSE - that is use of a minimal encoding size along with a stricter statement bout checking the grammar in the processing rules. I am not worried about the two lists of algorithms as message_1 is authenticated and the rules should state that the returned values in message_2 are checked against the original list. The final pair of algorithms are either directly (TCA) or indirectly (Key agreement) included in the computing of the traffic keys. The KIDs might want to be included, and doing so would allow for generation of different traffic keys in each direction. The protected attributes should potentially be included in the computation along with the keys to provide tying the identity and signatures together in a tighter binding. I don't know that there is an attack that can be launched here, but this would make it that much more difficult. Jim From nobody Thu Aug 18 00:24:00 2016 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 D525B12D75A for ; Thu, 18 Aug 2016 00:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzMQ_ZOhfiG4 for ; Thu, 18 Aug 2016 00:23:45 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF34912D0CA for ; Thu, 18 Aug 2016 00:23:44 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id f93so6157199lfi.2 for ; Thu, 18 Aug 2016 00:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:cc:message-id:date:user-agent:mime-version; bh=F5W5RmAWgI3HOVw5aGdwhsQz1JIrCFw35tipI+w3YLM=; b=dDf1UoS6qvdp++P239XxXuNXfNAxNW7RMMF5t1CKl2d179O1ohhEsgCkYXDaj5yylX Nfan+k9DVq2H9WzbrI+pQNz38x5J+An39dV0CstUALxHlhKECvRkxYaj3u9ZOxInNBjc /Y8edlqKpUOEIsHP6kydTZe5IUMdWDVNhqc8FZuz9P7ps2TZMhf+a5eSX/dcEZVP+46m QONrWV1GJTUHyWo+dj4UemIFOOj3/4l6aT8b/rNmEykLSJLqQZ0a67MfsDY9Ybf8jYEM cVml3+LL670gdhDyHFbu1PSPaKkP0ZIH/DoI/1if/7xEdv/bCi3G98Hrf6gtAV3wP9iL yZng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version; bh=F5W5RmAWgI3HOVw5aGdwhsQz1JIrCFw35tipI+w3YLM=; b=YQzh9vW2k39Cy57259+1M3ilw+9a3VEa/G42H+f/1eh6z6nqGLeiTDM0238RH8NhEl 0iZHqryFbgq4gkh7i903JO0RGLcczdHPQp6q5yofWgD45VRYPQyfRkGJTnOn88D84anp LBJpoH8JEKFGTjsAkB9hDpwku3A5pwqSdXXZwqqhuOg6Ddel+DiMxC8Xa+syrJcfM/I6 A/niRDrE5KT2RPskWl/ucAePTf+tVWyfIi/gkCMh6AfauR2El9v54Iz/Er3B3ME8b6VG 3nn1B+W+hkj7peLCmaOlphCyPdJvGXJ3zZXgRSg3qhvD5DBHmtWZ6oWWbA2HDNOkVaMN +CxA== X-Gm-Message-State: AEkoouvGAiQqSjlJNINKopIWAa6OzjCti4Rmg1SA2199fyk0tZFjLhNo/Vg8xfmeNoKqan1F X-Received: by 10.25.80.84 with SMTP id e81mr187234lfb.96.1471505022118; Thu, 18 Aug 2016 00:23:42 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id h203sm114959lfh.46.2016.08.18.00.23.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 00:23:41 -0700 (PDT) To: Mike Jones , =?UTF-8?Q?Erik_Wahlstr=c3=b6m?= From: Ludwig Seitz Message-ID: Date: Thu, 18 Aug 2016 09:23:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060403010709070101050104" Archived-At: Cc: "ace@ietf.org" Subject: [Ace] Minor typos in draft-ietf-ace-cbor-web-token-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 07:23:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060403010709070101050104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I've noticed some minor things while trying to write code for CWTs: 1.) In section 5.1. it says: "Create a CWT Claims Set containing the desired claims." I'm pretty sure you meant a CBOR map of claims, because that is what you = are showing in your examples. 2.) Also in section 5.1 it says: "3. Create a COSE Header containing the desired set of Header Parameters. The CWT Header MUST be a valid according to the [I-D.ietf-cose-msg] specification." Is it a COSE Header or a CWT Header you are referring to? Also giving an example of what this header could look like would be nice.= 3.) In section 5.2. it says: "5. If the JOSE Header contains a "content type"" That should be COSE Header or CWT Header. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms060403010709070101050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA4MTgwNzIzNDBaMC8GCSqGSIb3DQEJBDEiBCCN2wRuQmqM AEAoSCdBxnVdFBfUmpVOd27JL/BJRDBNuzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQCOl0AcEJxpNRnZx3BbVIWe EXEGIiJmQRYsZWpBrQmKqOrPN+pcIY06Wst5tMykpZJ/6BCVJl2RNufu/1A1kEbcis7d8IY7 TtKdapPKNz2+mYhbv6bp87HmxHaGJyB44pJzWRwoOK5rtxvxbQkT30Igw31Ma5P0uHTBytOu boHOoLMsJzBAWNZYON4pO/rzYcC84Rhs2aqZVVxne1tvavbKamq/YqDWFiyFgQitptms7wK2 wOQ0EO1wgzE+5knB1N1Pw0ZrnzVwMmL2A8DUCHy5nuQWctAHo8l/tSYKxNYpVxAJPo64J1mM PYs3l+qkk6TAaRRi4wEGQcFBRGEgLtthAAAAAAAA --------------ms060403010709070101050104-- From nobody Tue Aug 30 07:33:58 2016 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 F05F312D162; Tue, 30 Aug 2016 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 Qau_5yFGV452; Tue, 30 Aug 2016 07:33:52 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7F12D619; Tue, 30 Aug 2016 07:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1472567457; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=9W7941pJZm2h1JVcWYpzlYMjfFU7/ePK1GSmm3C1+f4=; b=fvpqLZNX9GJUeHirBGpja705wv2TjH8TVrseQCscP6Wnpsyqli2I+dDk8P43YgxSkdeTarGU6IqM87Srp/WMRLs3c6nySzqKda9y5gE/mJ8605vvKaZDf4NLgXiyF59FosrVfyDF26FevkM9N801PC4ZCFhBZU1hV/4pHvqxb4M= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R861e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03293; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----5DeDlVN_1472567447; Received: from 30.39.21.91(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Tue, 30 Aug 2016 22:30:51 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 30 Aug 2016 22:30:43 +0800 From: "Kepeng Li" To: cose , ace Message-ID: Thread-Topic: NomCom 2016-2017: Call for Nominations References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Ace] FW: NomCom 2016-2017: Call for Nominations X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 30 Aug 2016 14:33:57 -0000 FYI. =D4=DA 29/8/16 10:37 pm=A3=AC "NomCom Chair 2016" =D0=B4=C8=EB= : >Please forward on to your Working Groups - > >The 2016-17 Nominating Committee (Nomcom) is seeking nominations from >now until October 8, 2016. The open positions being considered by this >year's Nomcom can be found at the end of this email and also on this >year's Nomcom website: > >https://datatracker.ietf.org/nomcom/2016/ > >Nominations may be made by selecting the Nominate link at the top of >the Nomcom 2016 home page, or by visiting the following URL: > >https://datatracker.ietf.org/nomcom/2016/nominate/ > > {Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > https://datatracker.ietf.org/accounts/create/ } > >If you are unable to use the web form, nominations may instead be made >by email to nomcom-16@ietf.org. If using email, please include the word >"Nominate" in the Subject and indicate in the email who is being >nominated, their email address (to confirm acceptance of the >nomination), and the position for which you are making the nomination. >If you are nominating someone other than yourself, please tell us if >we may tell the nominee that you were the one who made the nomination. >If you wish to nominate someone via email for more than one position, >please use separate emails to do so. > >Self-nomination is welcome! > >Willing nominees will be asked to fill out a questionnaire >specific to the position for which they are nominated. The questionnaires >will be available on September 2, 2016 and have a submission deadline of >October 13, 2016. > >NomCom 2016-17 will follow the policy for "Open Disclosure of Willing >Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The >list of nominees willing to be considered for positions under review >in the current Nomcom cycle is not confidential". Willing nominees for >each position will be listed in a publicly accessible way - anyone >with a datatracker account may access the lists. Additionally, the >nomination form asks if we may share your own name with the >nominee. In all other ways, the confidentiality requirements of BCP10 >remain in effect. All feedback and all Nomcom deliberations will >remain confidential and will not be disclosed. > >There is a field on the form you can mark in order to allow the Nomcom >to tell the nominee that you were the one who made the >nomination. This defaults to =A1=B0no=A1=B1 - so if you don't mark the field >we won=A1=AFt tell. > >In order to ensure time to collect sufficient community feedback about >each of the willing nominees, nominations must be received by the >NomCom on or before October 8, 2016. > >Please submit your nominations as early as possible for the sake of >your nominees. Note that nominations should not wait for management >permission, as it is easier to decline the nomination than put one in >late. > >The Nomcom appoints individuals to fill the open slots on the IAOC, >the IAB, and the IESG. The list of people and posts whose terms end >with the March 2017 IETF meeting, and thus the positions for which >this Nomcom is responsible, follows: > >IAOC > > Lou Berger > >IAB > > Ralph Droms* > Russ Housley* > Robert Sparks > Andrew Sullivan > Dave Thaler* > Suzanne Woolf > >IESG > > Jari Arkko (GEN)* > Deborah Brungard (RTG) > Ben Campbell (ART) > Spencer Dawkins (TSV) > Stephen Farrell (SEC)* > Joel Jaeggli (OPS)* > Terry Manderson (INT) > Alvaro Retana (RTG) > >*- have indicated that they do not intend to accept a >renomination. This information is always up to date on >https://datatracker.ietf.org/nomcom/2016/ > >Please be resourceful in identifying possible candidates for these >positions, as developing our talent is a very crucial requirement for >the IETF, and also, please consider accepting a nomination. You'll >find extensive information about specific positions, developed by the >IAB, IESG, and IAOC, under individual tabs at: > > https://datatracker.ietf.org/nomcom/2016/requirements/ > >In addition to nominations, the Nomcom seeks community input on the >positions themselves. We need and welcome the community's views and >input on the jobs within each organization. If you have ideas on the >positions' responsibilities (more, less, different), please let us >know. > >Please send suggestions and feedback about this to nomcom-16@ietf.org. > >Thank you for your help in identifying qualified nominees! > >Lucy Lynch >Nomcom Chair 2016-17 >nomcom-chair-2016@ietf.org >llynch@civil-tongue.net From nobody Wed Aug 31 01:11:26 2016 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 5F30F12D9E8 for ; Wed, 31 Aug 2016 01:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gD4fvSglu0Lc for ; Wed, 31 Aug 2016 01:11:22 -0700 (PDT) Received: from smtppost.atos.net (smtppost.atos.net [193.56.114.165]) (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 DCAFB12D9DE for ; Wed, 31 Aug 2016 01:11:21 -0700 (PDT) Received: from mail1-ext.my-it-solutions.net (mail1-ext.my-it-solutions.net) by smarthost2.atos.net with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 1bf5_0375_bb4d7323_5267_4285_a165_bc6bd4799871; Wed, 31 Aug 2016 10:11:18 +0200 Received: from mail3-int.my-it-solutions.net ([10.92.32.10]) by mail1-ext.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u7V8BISs029009 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 31 Aug 2016 10:11:18 +0200 Received: from DEFTHW99ETYMSX.ww931.my-it-solutions.net (defthw99etymsx.ww931.my-it-solutions.net [10.86.142.53]) by mail3-int.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u7V8BIBU024766 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Aug 2016 10:11:18 +0200 Received: from DEERLM99EX1MSX.ww931.my-it-solutions.net ([169.254.1.105]) by DEFTHW99ETYMSX.ww931.my-it-solutions.net ([10.86.142.53]) with mapi id 14.03.0294.000; Wed, 31 Aug 2016 10:11:17 +0200 From: "Calvo Alonso, Daniel" To: "ace@ietf.org" Thread-Topic: Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code Thread-Index: AdIDXo/JIWofyYeVRFyCDhU6AnzNSQ== Date: Wed, 31 Aug 2016 08:11:17 +0000 Message-ID: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.86.142.18] Content-Type: multipart/related; boundary="_005_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Subject: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 08:11:25 -0000 --_005_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_ Content-Type: multipart/alternative; boundary="_000_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_" --_000_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, As I promised during my presentation in the ACE WG meeting in Berlin, this = is the correct link to draft-cuellar-ace-pat-priv-enhanced-authz-tokens pro= totype source code: https://gitlab.atosresearch.eu/ari/ACE-PAT-pub Please, don't hesitate in contact me in case you have any doubt or problem. With my best regards, Daniel Calvo Energy and Transport Market Atos Research and Innovation Tel: +34 946 66 20 82 daniel.calvo@atos.net C/Real Consulado s/n, Pol=EDgono Industrial Candina 39011 Santander www.atosresearch.eu Feel free to download our booklet at http://atos.net/en-us/home/we-are/insights-innovation/research-and-innovati= on.html This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. --_000_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
As I promised during my presentation in the ACE WG meeting in Berlin, = this is the correct link to draft-cuellar-ace-pat-priv-enhanced-authz-token= s prototype source code:
 
https://gitlab.atosresearch.eu/ari/ACE-PAT-pub<= /div>
 
Please, don’t hesitate in contact me in case you have any doubt = or problem.
 
With my best regards,
 
Da= niel Calvo
Energ= y and Transport Market
Atos = Research and Innovation
Tel: = +34 946 66 20 82
C/Rea= l Consulado s/n,
Pol=EDgono Industrial Candina
39011 Santander
 
<= /div>
 
Feel free to download= our booklet at
http://atos.net/en-us/home= /we-are/insights-innovation/research-and-innovation.html
 
 
This = e-mail and the documents attached are confidential and intended solely for = the addressee; it may also be privileged. If you receive this e-mail in err= or, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted= .

Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional.
Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.
Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.
This = e-mail and the documents attached are confidential and intended solely for = the addressee; it may also be privileged. If you receive this e-mail in err= or, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted= .

Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente = y pueden estar protegidos por secreto profesional.
Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.
Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.
 
 
 
This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-ma= il in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted= .

Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional.
Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes.
Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus.
--_000_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_-- --_005_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Wed, 31 Aug 2016 08:11:16 GMT"; modification-date="Wed, 31 Aug 2016 08:11:16 GMT" Content-ID: <5152C1D233AE6B4B91F11A3377B02B30@mail.sis.atos.net> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAABAAEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD5/ooo oA//2Q== --_005_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 2.jpg" Content-Description: Picture (Device Independent Bitmap) 2.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 2.jpg"; creation-date="Wed, 31 Aug 2016 08:11:16 GMT"; modification-date="Wed, 31 Aug 2016 08:11:16 GMT" Content-ID: <2C9DF6CA2902574FA5496FEE8D86C9DF@mail.sis.atos.net> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAABAAEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD5/ooo oA//2Q== --_005_8A926B4ADC92E345A40FA5363D47FA3003358C69DEERLM99EX1MSXw_-- From nobody Wed Aug 31 06:55:54 2016 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 9CA0012DCD8 for ; Wed, 31 Aug 2016 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eqswGdr2hBd for ; Wed, 31 Aug 2016 06:55:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2A10312DBA3 for ; Wed, 31 Aug 2016 06:44:42 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-92-57c6df481ccd Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 60.D5.06563.84FD6C75; Wed, 31 Aug 2016 15:44:40 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.133]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 15:44:35 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-selander-ace-cose-ecdhe@tools.ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Review of draft-selander-ace-cose-ecdhe-02 Thread-Index: AdHtPoYq0jj2+v67TYSluvCIdfOuggWT0pOA Date: Wed, 31 Aug 2016 13:44:34 +0000 Message-ID: References: <04da01d1edd7$9898fe50$c9cafaf0$@augustcellars.com> In-Reply-To: <04da01d1edd7$9898fe50$c9cafaf0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <5CD7C3F05D363C4B98E2D7D488AAAE81@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7oq7H/WPhBpNvy1p8/9bDbNF9w8li 9fTvbA7MHhvnTGfzWLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgy/rz1L+iJrvh5fRVrA+OD iC5GTg4JAROJKVs2MoPYQgLrGSXapyt1MXIB2UsYJVY8/8YOkmATcJF40PCICSQhIrCSUeL6 2ntsIAlhAVuJxS+msXQxcgAl7CQ+PIoGCYsIGEkc+d7MBGKzCKhKNP36yQJi8wpYSKw/d5sJ Ypm9xON3H8Hmcwo4SLyd/A5sJKOAmMT3U2vAapgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7GC 2KICehLPTi5mhIgrSlydvpwJ5BxmAU2J9bv0IcZYS5z58IIdwlaUmNL9kB3iHEGJkzOfsExg FJuFZNsshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAGDu45bfu DsbVrx0PMQpwMCrx8C44eTRciDWxrLgy9xCjBAezkgjv9LvHwoV4UxIrq1KL8uOLSnNSiw8x SnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwzn6909DtVFzzo9pbMuLrDIPnWEv1+dx6 eWCS76OF83lLHtz4PGeZ3+WaX2fdrpy3/JnwwmLTvpr2AOUwroXTZ38S5c737nX+Vq/6JiT2 9UOvVSyRz558Ztn3qbav7k0gE5vhcnPdaYb1rw3iDhn4LrvisDA1+OLOBQcWcB0/EypoWXtG WmrrbiWW4oxEQy3mouJEACFURxOtAgAA Archived-At: Subject: Re: [Ace] Review of draft-selander-ace-cose-ecdhe-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 13:55:51 -0000 SGkgSmltLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciBnb29kIGNvbW1lbnRzLCByZXBsaWVzIGlu bGluZS4NCg0KDQpPbiAyMDE2LTA4LTA0IDAwOjM3LCAiQWNlIG9uIGJlaGFsZiBvZiBKaW0gU2No YWFkIiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBvZiBpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPiB3cm90ZToNCg0KPlRoaXMgbWF5IGJlIGEgYml0IHNjYXR0ZXJicmFpbmVkIGFzIEkg ZGlkIHRoaXMgcmV2aWV3IGluIHNldmVyYWwgc2Vzc2lvbnMNCj5hbmQgdGhlIHRob3VnaHRzIG1p Z2h0IG5vdCBiZSBjb25zaXN0ZW50Lg0KPg0KPjEuICBJbiBzZWN0aW9uICMxLCBJIHdvdWxkIHB1 dCBpbiB0aGUgZmFjdCB0aGF0IHRoZSBkZXJpdmVkIGtleSB3b3VsZCBvbmx5DQo+YmUgdXNlZCBm b3IgYSBwZXJpb2Qgb2YgdGltZSwgYWZ0ZXIgd2hpY2ggYSBuZXcgRUNESCBrZXkgZXhjaGFuZ2Ug d291bGQgYmUNCj5ydW4gYWdhaW4uDQoNCkFncmVlLg0KDQo+DQo+Mi4gIEl0IGlzIG5vdCBjbGVh ciwgYnV0IGJhc2VkIG9uIGhvdyB0aGUgdmFsdWUgb2Yga2lkX2V2IGlzIGRlZmluZWQsIGl0DQo+ bWlnaHQgYmUgcmVhc29uYWJsZSB0byBzdGF0ZSB0aGF0IHRoZXJlIGlzIGFuIGV4cGVjdGF0aW9u IHRoYXQgZ2VuZXJhbGx5IFUNCj53aWxsIGJlIGEgY2xpZW50IGFuZCBWIGEgc2VydmVyLg0KDQpD b3JyZWN0LCBidXQgdGhlcmUgaXMgYWxzbyB0aGUgZGVzaXJlIHRvIHVzZSB0aGUgY29udGV4dCBm b3IgY2xpZW50IGFuZA0Kc2VydmVyIHN3aXRjaGluZyByb2xlcywgYW5kIG1vcmUgZ2VuZXJhbGx5 IHNlbmRlciBhbmQgbGlzdGVuZXIgaW4gYSBncm91cC4NClRoaXMgcmVsYXRlcyB0byB5b3VyIGNv bW1lbnRzIG9uIE9TQ09BUC4NCg0KPg0KPjMuICBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBQU0sg aGFsZiBvZiB0aGUgd29ybGQgc2V0dXAgc28gdGhhdCBpdCBpcyBub3QNCj5yZXF1aXJlZCB0aGF0 IHRoZSBzYW1lIGtleS9raWQgcGFpciBiZSB1c2VkIGluIGJvdGggZGlyZWN0aW9ucy4gIFVzaW5n IGENCj5kaWZmZXJlbnQga2V5IGluIGVhY2ggZGlyZWN0aW9uIG1ha2VzIHRoaW5ncyBjbGVhbmVy IGZvciBzb21lIGlzc3Vlcy4NCj5Cb3RoDQo+Y2FzZXMgb2YgdGhlIHNhbWUgYW5kIGRpZmZlcmVu dCBwYWlycyBzaG91bGQgYmUgcGVybWl0dGVkLg0KDQpPSy4NCg0KPg0KPjQuICBJIHNlZSBubyBy ZWFzb24gdG8gc2F5IHRoYXQgd2hhdCBvbmUgaXMgbmVnb3RpYXRpbmcgaXMgYSBoYXNoDQo+ZnVu Y3Rpb24uDQo+V2hhdCB5b3UgYXJlIG5lZ290aWF0aW5nIGlzIGEgIktleSBBZ3JlZW1lbnQgdy8g S0RGIiBhbGdvcml0aG0uICBJIGRvbid0DQo+c2VlDQo+dGhhdCB5b3UgYXJlIHVzaW5nIHRoZSBo YXNoIGZ1bmN0aW9uIGJ5IGl0c2VsZiBhbnl3aGVyZS4NCg0KRm9yIHNpbXBsaWNpdHkgY2hhbmdl ZCB0byBuZWdvdGlhdGlvbiBvZiBLREYsIE9LPw0KDQo+DQo+NS4gIEluIHNlY3Rpb24gMiwgeW91 IHNob3VsZCBnaXZlIGEgcmVhc29uIGZvciBpbmNsdWRpbmcgb3Igbm90IGluY2x1ZGluZw0KPnRo ZSBub25jZXMgaW4gdGhlIHByb3RvY29sLiAgU2luY2UgdGhleSBhcmUgb3B0aW9uYWwgd2hlbiB3 b3VsZCB0aGV5IGJlDQo+dXNlZnVsPw0KDQpJdCBpcyBleHBsYWluZWQgaW4gW1JGQzU4NjldIHdo aWNoIGlzIHJlZmVyZW5jZWQgYnV0IHdlIGNhbiBhZGQgdGhhdC4NCg0KPg0KPjYuIEluIHNlY3Rp b24gMiwgZG8geW91IGV4cGVjdCB0aGF0IFRDQSBpcyByZXN0cmljdGVkIHRvIENFSyBvciB3b3Vs ZCBNQUMNCj5hbGdvcml0aG1zIGJlIHVzYWJsZSBhcyB3ZWxsPw0KDQpDaGFuZ2VkIHRvICJBRUFE IG9yIE1BQyIuDQoNCj4NCj43LiAgSW4gc2VjdGlvbiAyLCBJIG1pc3NlZCB3aGVyZSB0aGUgcmVw bGF5IHBhcmFtZXRlciB3YXMgaW5jbHVkZWQgaW4gdGhlDQo+Q09TRV9IZWFkZXIgLSBpdCBzZWVt cyB0byBiZSBpbiB0aGUga2V5IGZvciBwYXJ0eSBVIGFuZCBub24tZXhpc3RhbnQgZm9yDQo+cGFy dHkgVi4gIFRoZSBjbG9zZXN0IHRoYXQgb25lIGNvbWVzIGl0IHRoZSB1c2Ugb2YgdGhlIG1lc3Nh Z2VfMSBzaWduYXR1cmUNCj5hcyBBQUQuDQoNClllcywgcmVwbGF5IGlzIG1haW5seSBhbiBpc3N1 ZSBmb3IgcGFydHkgVi4NCg0KPg0KPjguICBJbiBmaWd1cmUgMywgSSB3b3VsZCBwcmVmZXIgdG8g c2VlIHR3byBkaWZmZXJlbnQgdHJhZmZpYyBrZXlzIGJlaW5nDQo+ZGVyaXZlZC4gIEl0IGlzIG5v dCBhbiBpc3N1ZSBpbiBGaWd1cmUgMiBhcyB0aGF0IGp1c3Qgc2F5cyBrZXlpbmcNCj5tYXRlcmlh bC4NCj5Vc2luZyBkaWZmZXJlbnQga2V5aW5nIG1hdGVyaWFsIGluIGVhY2ggZGlyZWN0aW9uIHBy ZXZlbnRzIHJlZmxlY3Rpb24NCj5hdHRhY2tzLg0KDQpJIHRoaW5rIHdlIGFyZSBqdXN0IGNvcHlp bmcgVExTIDEuMyB0ZXJtaW5vbG9neSBoZXJlLiDigJx0cmFmZmljX3NlY3JldF8w4oCdDQppcyB0 aGUg4oCcYmFzZSBrZXnigJ0gdXNlZCB0byBkZXJpdmUgdGhlIGRpZmZlcmVudCBjbGllbnQgYW5k IHNlcnZlciBrZXlzIHlvdQ0KcmVxdWVzdC4NCg0KPg0KPjkuICBJbiBzZWN0aW9uIDIuMSwgeW91 IHRhbGsgYWJvdXQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBidXQgZG8gbm90DQo+ZGlzY3Vzcw0K PmF1dGhvcml6YXRpb24gbWV0aG9kcy4gIERvZXMgdGhpcyBuZWVkIHRvIGJlIGJ1aWx0IGludG8g bWVzc2FnZV8xIG9yIGFyZQ0KPnRoZXJlIG90aGVyIG1ldGhvZHMgdGhhdCB3aWxsIGJlIGZ1bmN0 aW9uYWwgaGVyZS4gIE1heSBuZWVkIHRvIHJlZmVyIHRvDQo+aG93DQo+c29tZSBvZiB0aGVtIG1p Z2h0IHdvcmsgc2luY2UgdGhpcyB3aWxsIGFsc28gcG90ZW50aWFsbHkgYWZmZWN0IGhvdyB0aGUN Cj5kaXN0cmlidXRpb24gb2YgdGhlIGtleXMgaW4gYWR2YW5jZSB3b3Jrcy4gIEZvciBleGFtcGxl LCBpZiBhbiBPQVVUSCB0b2tlbg0KPmlzIHB1Ymxpc2hlZCB0byBhIHdlbGwta25vd24gbG9jYXRp b24gdGhhdCBjb250YWlucyBib3RoIGF1dGhvcml6YXRpb24gYW5kDQo+YXV0aGVudGljYXRpb24g aW5mb3JtYXRpb24uDQoNCkdvb2QgY2F0Y2guIFRoZXJlIGlzIGEgc3RvcnkgZm9yIGhvdyBFREhP QyB3b3JrcyB3aXRoIEFDRSBidXQgd2UgZm9yZ290IHRvDQptZW50aW9uIGl0IGhlcmUgYW5kIG1h a2UgdGhlIHJlZmVyZW5jZTogU2VlIGZpZ3VyZSAxIG9mDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2VpdHotYWNlLW9zY29hcC1wcm9maWxlLTAwDQoNCj4NCj4xMC4gIEluIHNl Y3Rpb24gMy4xLCBJIGFtIG5vdCBzdXJlIHRoYXQgeW91IHJlYWxseSB3YW50IHRvIGhhdmUgb25s eSBhDQo+c2luZ2xlIGFsZ29yaXRobSBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBJIHdvdWxkIG1h a2UgaXQgbW9yZSBnZW5lcmF0aW9uDQo+aW4NCj50ZXJtcyBvZiBob3cgYSBDT1NFX0tleSBpcyBi dWlsdCBhbmQgdGhlbiBoYXZlIGEgc3RhdGVtZW50IGVsc2V3aGVyZQ0KPnJhdGhlcg0KPnRoYW4g c3ByZWFkIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50IGFib3V0IHdoYXQgYWxnb3JpdGhtcyBhcmUg bWFuZGF0b3J5IHRvDQo+c3VwcG9ydC4NCg0KWWVzLCB0aGlzIHdhcyBqdXN0IHRvIGJlIGNvbmNy ZXRlLiBHb29kIHByb3Bvc2FsLg0KDQo+DQo+MTEuICBJbiBzZWN0aW9uIDMuNC4yIC0gSSB0aGlu ayB0aGF0IHlvdSBuZWVkIHRvIGhhdmUgYSBtb3JlIGNvbXByZWhlbnNpdmUNCj5leHRlcm5hbF9B QUQgc3RydWN0dXJlIHRoYXQgd2hhdCBpcyBoZXJlLiAgSSBhbSBub3Qgc3VyZSB0aGF0IHlvdSBz aG91bGQNCj5ub3QNCj5BQUQgaW5mb3JtYXRpb24gZnJvbSB0aGUgQ29BUCBoZWFkZXIgYXMgd2Vs bCBpbiBhbGwgb2YgdGhlIG1lc3NhZ2VzLg0KDQpUaGlzIHNob3VsZCBiZSB0aGUgZW50aXJlIG1l c3NhZ2VfMS4NCg0KPg0KPjEyLiBTdHVwaWQgcXVlc3Rpb24gLSBDYW4geW91IGRvIGEgUFNLIGlu IG9uZSBkaXJlY3Rpb24gYW5kIGEgc2lnbmF0dXJlIGluDQo+dGhlIG90aGVyPw0KDQpJ4oCZZCBs aWtlIHRvIHBhc3MgdGhhdCBxdWVzdGlvbiBvbiB0byBDRlJHLg0KDQo+DQo+MTMuIE5vdCBzdXJl IHRoYXQgaXQgbWF0dGVycywgYnV0IHlvdSBoYXZlIHRoZSBDT1NFX0tERl9Db250ZXh0IHN0cnVj dHVyZQ0KPndyb25nIGV2ZXJ5d2hlcmUuICBUaGUgcGFydHlVIGFuZCBwYXJ0eVYgZmllbGRzIGFy ZSBub3Qgb3B0aW9uYWwuDQoNClllcywgd2UgYXJlIHJlLWNvbnNpZGVyaW5nIHRoZSBpZGVudGl0 aWVzIHVzZWQuIEFsc28gcmVsYXRlcyB0byB5b3VyDQpjb21tZW50IG9uIE9TQ09BUC4NCg0KPg0K PjE0LiAgU2VjdGlvbiAzLjUsIEkgZG9uJ3QgYmVsaWV2ZSBpbiB1bmlxdWVseSBpZGVudGlmaWVk IGtpZHMgb24gYW55DQo+ZGV2aWNlDQo+dW5sZXNzIHRoYXQgZGV2aWNlIGlzIGdvaW5nIHRvIGVu Zm9yY2UgdGhhdCBhcyBhIHRydWUgc3RhdGVtZW50LiAgVGhhdA0KPm1lYW5zDQo+dGhhdCBpdCB3 aWxsIG5vdCBhbGxvdyBmb3IgYSBrZXkgdG8gYmUgcmVnaXN0ZXJlZCB3aXRoIGl0IHVubGVzcyB0 aGUga2lkDQo+aXMNCj51bmlxdWUuICAgIFRoZXJlIGlzIG5vdGhpbmcgd3Jvbmcgd2l0aCBkb2lu ZyBhbiBleGhhdXN0aXZlIHNlYXJjaCBvZiBhbGwNCj5vZg0KPnRoZSBrZXlzIHdpdGggdGhlIHNh bWUga2lkIGFzIGxvbmcgYXMgdGhlIG51bWJlciBvZiB0aGVtIGlzIG5vdCB0b28gbGFyZ2UuDQoN CldlIHN0cml2ZSBmb3IgYWxsb3dpbmcgYSkgc2hvcnQgaWRlbnRpZmllcnMgaWYgdGhlcmUgaXMg YSBuYW1pbmcgYXV0aG9yaXR5DQphbmQgYikgc3VmZmljaWVudGx5IGxvbmcgcmFuZG9tIGlkZW50 aWZpZXJzIGlmIGEpIGlzIG5vdCBwb3NzaWJsZS4gSWYNCnBvc3NpYmxlIHdlIHdvdWxkIGxpa2Ug dG8gYXZvaWQgZXhoYXVzdGl2ZSBzZWFyY2gsIGFsdGhvdWdoIHRoYXQgd291bGQgYmUNCmRvYWJs ZS4NCg0KPg0KPjE1LiAgU2VjdGlvbiAzLjUuMzogIElmIHlvdSBhcmUgc2VuZGluZyBhbG9uZyBh IGNlcnRpZmljYXRlLCBpdCBpcyBub3QNCj5jbGVhcg0KPnRvIG1lIHRoYXQgeW91IG5lZWQgdG8g aGF2ZSBhIGtpZCBhcyB3ZWxsLiAgVGhlIGNlcnRpZmljYXRlIGlzIHdoZXJlIHlvdQ0KPmFyZQ0K PmdvaW5nIHRvIGdldCB0aGUga2V5IGZyb20gbm90IHRoZSBraWQuDQoNCkFncmVlLg0KDQo+DQo+ MTYuIFNlY3Rpb24gNC4xIC0ga2lkX2V1IC0gRG9lcyB0aGlzIHJlYWxseSBuZWVkIHRvIGJlIGEg Y291bnRlciBvbiBhIHBlcg0KPnBhcnR5IFYgYmFzaXMgb3IgY2FuIGl0IGp1c3QgYmUgYSBjb3Vu dGVyIGJhc2VkIG9uIHRoZSB1c2Ugb2YgdGhlDQo+Y3JlZGVudGlhbA0KPnRoYXQgaXMgYmVpbmcg dXNlZCB0byBkbyB0aGUgYXV0aGVudGljYXRpb24/DQoNClllcywgdGhlIGxhdHRlciBpcyBmaW5l LiBXZSBhcmUgY29uc2lkZXJpbmcgdGhpcyBhbHNvIGluIE9TQ09BUC4NCg0KPiANCj4NCj4xNy4g IFNlY3Rpb24gNSAtIHdoYXQgaGFwcGVucyBpZiBOX1Ugb3IgTl9WIGlzIGxvbmdlciB0aGFuIHRo ZSBzaXplIG9mIHRoZQ0KPmhhc2ggZnVuY3Rpb24uICANCg0KR29vZCBjYXRjaC4gVGhpcyBjb25z dHJ1Y3Qgd2FzIGludGVuZGVkIHRvIHNpbXBseSBpbmNvcnBvcmF0ZSBhcmJpdHJhcmlseQ0Kc21h bGwgbm9uY2VzLCBhcyBpcyBlbmNvdXJhZ2VkIGluIHNlY3Rpb24gMy4xIG9mIFtSRkM1ODY5XS4N Cg0KDQo+QWxzbywgd2hhdCBkbyB5b3UgbWVhbiBieSB0aGUgc2l6ZSBvZiB0aGUgaGFzaCBmdW5j dGlvbj8gIElzDQo+dGhpcyB0aGUgYmFycmVsIHNpemUgb3IgdGhlIG91dHB1dCBzaXplPw0KDQpP dXRwdXQgc2l6ZS4gIA0KDQo+DQo+MTguICBJZGVudGl0eSBvZiB0aGUgUGFydGllczogIFRoZXJl IGlzIGEgcXVlc3Rpb24gb24gd2hhdCB0aGUgaWRlbnRpdHkNCj5zdHJ1Y3R1cmUgdGhhdCBpcyBi ZWluZyB1c2VkIHRvIGdyYW50IGFjY2VzcyBpcyBmb3IgQUNFLiAgRm9yIHRob3NlIHdobw0KPmhh dmUNCj5iZWVuIGluIHRoZSBJRVRGIGxvbmcgZW5vdWdoLCBvbmUgYW5zd2VyIHdvdWxkIGJlIHRv IG1vdmUgYmFjayB0byB0aGUNCj53b3JsZA0KPm9mIFNQS0kgKFNpbXBsZSBQdWJsaWMgS2V5IElu ZnJhc3RydWN0dXJlKSB3aGVyZSB0aGUga2V5IGlzIHRoZSBlbnRpdHkNCj50aGF0DQo+aXMgdXNl ZCBmb3IgaWRlbnRpZnlpbmcgYW4gZW50aXR5IGFuZCBub3Qgc29tZSBvdGhlciBwaWVjZSBvZiBp bmZvcm1hdGlvbg0KPmxpa2UgYSB0ZXh0IHN0cmluZyBvciBhbiBhZGRyZXNzLiAgRG9pbmcgYSBz ZWN1cml0eSBhbmFseXNpcywgb25lIG1pZ2h0DQo+ZmluZA0KPnRoYXQgb25lIHdpc2hlcyB0byBk byBhIGJpbmRpbmcgb2YgdGhlIGlkZW50aXR5IGluZm9ybWF0aW9uIGludG8gdGhlIGtleQ0KPmRl cml2YXRpb24gcHJvY2Vzcy4gIElmIGtleXMgYXJlIHRoZSBtYXJrZXIgb2YgaWRlbnRpdHksIHRo ZW4gdGhpcyBpcw0KPndvdWxkDQo+YmUgaW5jbHVkaW5nIHRoZSBrZXlzIGFzIHBhcnQgb2YgdGhl IGNvbnRleHQgaW5mb3JtYXRpb24gdGh1cyB0eWluZyB0aGUNCj5zaWduYXR1cmUgYW5kIGtleSBp bnRvIHRoZSByZXN1bHRpbmcga2V5LiAgVGhlIHJlcXVpcmVtZW50IHRvIGluY2x1ZGUNCj5pZGVu dGl0eSBpbmZvcm1hdGlvbiBpcyBwcm9iYWJseSBuZWVkZWQgbW9yZSBpZiBhY2Nlc3MgY29udHJv bCBpcyBiZWluZw0KPmJhc2VkIG9uIGEgbmFtZSByYXRoZXIgdGhhbiBhIGtleSBob3dldmVyLiAg SW4gdGhpcyBjYXNlIGl0IGlzIGxpa2VseSBtb3JlDQo+aW1wb3J0YW50IHRoYXQgdGhlIGJpbmRp bmcgcHJvY2Vzc2VzIGlzIGluY2x1ZGVkIGluIHRoZSBLREYgY29udGV4dCBpbg0KPnNvbWUNCj5t YW5uZXIuDQoNClNvIGZhciBpbiBFREhPQyBhbmQgT1NDT0FQIHRoZSBpZGVudGl0eSBoYXMgYmVl biBhc3NvY2lhdGVkIHRvIHRoZSBrZXksDQptYWlubHkgZm9yIHJlYXNvbnMgb2Ygb3B0aW1pemF0 aW9uLiBBcyBtZW50aW9uZWQgYWJvdmUgd2UgYXJlDQpyZWNvbnNpZGVyaW5nIHRoaXMsIGZvciBy ZWFzb25zIG9mIGdlbmVyYWxpdHkuDQoNCj4NCj4xOS4gIFVzZSBvZiB0aGUgc2lnbmF0dXJlL01B QyBmb3IgY2hhaW5pbmcgb2YgaXRlbXM6ICBJIGRpZCBhIGZhc3QgcmV2aWV3DQo+b2YNCj5ob3cg dGhlIGZpZWxkcyBvZiBtZXNzYWdlXzEgYW5kIG1lc3NhZ2VfMiBhcmUgdXNlZCBpbiB0aGUgZmlu YWwgS0RGDQo+cHJvY2Vzc2luZy4gIEZyb20gd2hhdCBJIHNhdywgdGhlcmUgYXJlIG9ubHkgYSBj b3VwbGUgb2YgdGhpbmdzIHRoYXQgYXJlDQo+bm90DQo+ZGlyZWN0bHkgcmUtdXNlZCBhcyBwYXJ0 IG9mIHRoZSBjb250ZXh0LiAgVGhlc2UgYXJlOiAxKSB0aGUgZXhhY3QgZW5jb2RpbmcNCj5vZiB0 aGUgbWVzc2FnZXMsIDIpIHRoZSBsaXN0IG9mIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtcywgMykg dGhlIGxpc3Qgb2YNCj5UQ0ENCj5hbGdvcml0aG1zLCA0KSBraWRfZXUgYW5kIGtpZF9ldiwgYW5k IDUpIHRoZSBwcm90ZWN0ZWQgYXR0cmlidXRlcyBpbiBlYWNoDQo+b2YNCj50aGUgbWVzc2FnZXMu DQo+RXhhY3QgZW5jb2RpbmcgY2FuIGJlIGFkZHJlc3NlZCBieSB1c2luZyB0aGUgc2FtZSBlbmNv ZGluZyBydWxlcyB0aGF0IGFyZQ0KPmluDQo+Q09TRSAtIHRoYXQgaXMgdXNlIG9mIGEgbWluaW1h bCBlbmNvZGluZyBzaXplIGFsb25nIHdpdGggYSBzdHJpY3Rlcg0KPnN0YXRlbWVudCBib3V0IGNo ZWNraW5nIHRoZSBncmFtbWFyIGluIHRoZSBwcm9jZXNzaW5nIHJ1bGVzLg0KPkkgYW0gbm90IHdv cnJpZWQgYWJvdXQgdGhlIHR3byBsaXN0cyBvZiBhbGdvcml0aG1zIGFzIG1lc3NhZ2VfMSBpcw0K PmF1dGhlbnRpY2F0ZWQgYW5kIHRoZSBydWxlcyBzaG91bGQgc3RhdGUgdGhhdCB0aGUgcmV0dXJu ZWQgdmFsdWVzIGluDQo+bWVzc2FnZV8yIGFyZSBjaGVja2VkIGFnYWluc3QgdGhlIG9yaWdpbmFs IGxpc3QuICBUaGUgZmluYWwgcGFpciBvZg0KPmFsZ29yaXRobXMgYXJlIGVpdGhlciBkaXJlY3Rs eSAoVENBKSBvciBpbmRpcmVjdGx5IChLZXkgYWdyZWVtZW50KQ0KPmluY2x1ZGVkDQo+aW4gdGhl IGNvbXB1dGluZyBvZiB0aGUgdHJhZmZpYyBrZXlzLg0KPlRoZSBLSURzIG1pZ2h0IHdhbnQgdG8g YmUgaW5jbHVkZWQsIGFuZCBkb2luZyBzbyB3b3VsZCBhbGxvdyBmb3INCj5nZW5lcmF0aW9uDQo+ b2YgZGlmZmVyZW50IHRyYWZmaWMga2V5cyBpbiBlYWNoIGRpcmVjdGlvbi4NCj5UaGUgcHJvdGVj dGVkIGF0dHJpYnV0ZXMgc2hvdWxkIHBvdGVudGlhbGx5IGJlIGluY2x1ZGVkIGluIHRoZSBjb21w dXRhdGlvbg0KPmFsb25nIHdpdGggdGhlIGtleXMgdG8gcHJvdmlkZSB0eWluZyB0aGUgaWRlbnRp dHkgYW5kIHNpZ25hdHVyZXMgdG9nZXRoZXINCj5pbg0KPmEgdGlnaHRlciBiaW5kaW5nLiAgSSBk b24ndCBrbm93IHRoYXQgdGhlcmUgaXMgYW4gYXR0YWNrIHRoYXQgY2FuIGJlDQo+bGF1bmNoZWQg aGVyZSwgYnV0IHRoaXMgd291bGQgbWFrZSBpdCB0aGF0IG11Y2ggbW9yZSBkaWZmaWN1bHQuDQoN ClNlZW1zIHBydWRlbnQsIHdlIHdpbGwgY29uc2lkZXIgdGhpcyBpbiB0aGUgbmV4dCB2ZXJzaW9u Lg0KDQpUaGFua3MNCkfDtnJhbg0KDQoNCg== From nobody Wed Aug 31 08:56:18 2016 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 E268412D5A0 for ; Wed, 31 Aug 2016 08:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCT8KRDqncC1 for ; Wed, 31 Aug 2016 08:56:13 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E652612D5B6 for ; Wed, 31 Aug 2016 08:50:16 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w2so37254440wmd.0 for ; Wed, 31 Aug 2016 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Xz2UcsVxD6r1zCcOB9BYGODg714/buTK9/rJmVCT1o=; b=dLE6Bcb+uJvMCRiucxmwrjvEvCIlhB+JDfUa5Yuy3WxOtRlwJ1Rdfb7ZXsv3WwIc7M +ajx+uSWZhsxoc9yJozYxBiJV3Oipt9XgT98CkZxsllHc1KzMYweXf88GWkuD/mkrXoF ONx1H9AjoZ/XP4y7i0Dh3aNEiuy01pauW6GLWT6mGW8hj2t1dYLbKybi8cpOpDAdxBvS iNveIgln3qt3nCLXrUoZGy9wLnQM5ojQGw6oFlUSjt0/T9dOJgOmz5oY3R3BNc0OAATB TaFr9BTK2BcZcECS1yKfcVpanZ32cowPBUwT+qWvj4EOlCOnmJH2HLuxGee1aaG5o5HP w80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Xz2UcsVxD6r1zCcOB9BYGODg714/buTK9/rJmVCT1o=; b=ZN7i+n7K01m3Qnbyu3/G7GhQzxPvR96g4a4RWgXD60Oj4jML1ro3B0kkP+O8o2u4Mr UUvVDJy0kZijlhTh72POxewpSC2qWSFONyi+uju5tElZ+4BD0sySVfojD45+tBmXACB1 IPnsDVf5GCVm9B7I0DmgR2PXEDqiqIlBg08VaKY//U8NpwIIOeiiRgpOhRTjbuUWCa/g R1wjEyuU8XNznO2ZTKBmWj44XRkRWO3/wBfdOTjBgJltt5rYgItwwmvnhY7puZ8T6C00 CZK0Q1Kzi4zVHgY8C46kzFflDj2+JzbatpdpqAigq84bMKanhXK9KpgmAxO+iDEEwp8i ceIQ== X-Gm-Message-State: AE9vXwPyaUn5nwziWTACTHnfIm/kFP0COVp8Acf8z+X3ncmKWp9qMcdR4w78dbnKl8NdrLmm7HnNBimaddRwMg== X-Received: by 10.28.207.69 with SMTP id f66mr21220277wmg.40.1472658614823; Wed, 31 Aug 2016 08:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.2 with HTTP; Wed, 31 Aug 2016 08:50:14 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Wed, 31 Aug 2016 17:50:14 +0200 Message-ID: To: Ludwig Seitz Content-Type: multipart/alternative; boundary=94eb2c0d7c5a9d18e8053b600d6e Archived-At: Cc: Mike Jones , "ace@ietf.org" , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [Ace] Minor typos in draft-ietf-ace-cbor-web-token-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 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, 31 Aug 2016 15:56:18 -0000 --94eb2c0d7c5a9d18e8053b600d6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See inline On Thu, Aug 18, 2016 at 9:23 AM, Ludwig Seitz wrote: > Hello, > > I've noticed some minor things while trying to write code for CWTs: > > > 1.) In section 5.1. it says: > > "Create a CWT Claims Set containing the desired claims." > > I'm pretty sure you meant a CBOR map of claims, because that is what you > are showing in your examples. > I would say that the CWT Claims Set is a CBOR map of claims. Is that unclear? I would prefer not to change. > > 2.) Also in section 5.1 it says: > > "3. Create a COSE Header containing the desired set of Header > Parameters. The CWT Header MUST be a valid according to the > [I-D.ietf-cose-msg] specification." > > Is it a COSE Header or a CWT Header you are referring to? > One could argue either but I think we get less confusion by changing according to your suggestion. The COSE header is the header of the CWT i.e. a CWT header. in JOSE this relation is closer then here > > Also giving an example of what this header could look like would be nice. > > > 3.) In section 5.2. it says: > > "5. If the JOSE Header contains a "content type"" > > That should be COSE Header or CWT Header. > You are right > > > Regards, > > Ludwig > > > > > > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=C3=A4gen 17 > SE-223 70 Lund > > Phone +46(0)70-349 92 51 > http://www.sics.se > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --94eb2c0d7c5a9d18e8053b600d6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See inline

On Thu, Aug 18, 2016 at 9:23 AM, Ludwig Seitz <ludwig@sics.se> wrote:
H= ello,

I've noticed some minor things while trying to write code for CWTs:


1.) In section 5.1. it says:

"Create a CWT Claims Set containing the desired claims."

I'm pretty sure you meant a CBOR map of claims, because that is what yo= u are showing in your examples.

I would= say that the CWT Claims Set is a CBOR map of claims. Is that unclear? I wo= uld prefer not to change.
=C2=A0

2.) Also in section 5.1 it says:

"3.=C2=A0 Create a COSE Header containing the desired set of Header =C2=A0 =C2=A0 =C2=A0Parameters.=C2=A0 The CWT Header MUST be a valid accord= ing to the
=C2=A0 =C2=A0 =C2=A0[I-D.ietf-cose-msg] specification."

Is it a COSE Header or a CWT Header you are referring to?
<= div>

Also giving an example of what this header could look like would be nice.

3.) In section 5.2. it says:

"5.=C2=A0 If the JOSE Header contains a "content type""=

That should be COSE Header or CWT Header.

You are right
=C2=A0


Regards,

Ludwig





--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=C3=A4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://= www.sics.se


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


--94eb2c0d7c5a9d18e8053b600d6e--